RSS Feeds

Join the Python Security Response Team!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/02/join-the-python-security-response-team/
Published: 2026-02-17 00:00:00 | Created: 2026-07-23 05:23:40
The Python Security Response Team now has an approved public governance document (PEP 811) and is welcoming new members.
show more
Oh the places you’ll go with spatial data
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/06/23/oh-the-places-you-ll-go-with-spatial-data/
Published: 2026-06-23 07:40:00 | Created: 2026-07-23 05:23:40
Ryan is joined by  Jeffrey Hightower, VP of Places Data at Microsoft, and Amy Rose, CTO of the Overture Maps Foundation, to chat about their partnership in bringing spatial data to the next generation of Microsoft tools; how Overture’s 50 organization members are creating open, standardized, and interoperable  global spatial data sets; and their solutions to the innate challenges of trying to digitally map the world.
show more
The Python Insider Blog Has Moved!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/03/the-python-insider-blog-has-moved/
Published: 2026-03-03 00:00:00 | Created: 2026-07-23 05:23:40
Python Insider now lives at blog.python.org, backed by a Git repository. All 307 posts from the Blogger era have been migrated, and old URLs redirect automatically.
show more
Project goals update — April 2026 (end of 2025H2)
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/05/18/project-goals-2026-04/
Published: 2026-05-18 00:00:00 | Created: 2026-07-23 05:23:40

The 2025H2 Project Goal period has now concluded. Over these months, the Rust Project pursued 41 Project Goals, 13 of which were designated as Flagship Goals. This post contains curated updates on our progress since the last post and the final status for each of the goals (many of which continue as part of the 2026 period). Full details for any particular goal are available in its tracking issue.

Thanks to everyone who contributed! <3

Table of contents

Flagship: Beyond the &

Continue Experimentation with Pin Ergonomics

3 detailed updates available.

Design a language feature to solve Field Projections

5 detailed updates available.

  • Benno Lossin — comment from 2026-01-01

  • Benno Lossin — comment from 2026-01-25

    Earlier this month, Nadrieril Ding Xiang Fei and I held a meeting on autoref and method resolution in a world with field projections. This meeting resulted in a new page for the wiki on autoref.

  • Benno Lossin — comment from 2026-02-28

    The first pull request of the lang experiment has just been merged: rust-lang/rust#152730

    This PR enables the use of the field_of! macro to obtain a unique type for each field of a struct, enum variant, tuple, or union. We call these types field representing types (FRTs). When the base type is a struct that is not repr(packed), only contains Sized fields, this type automatically implements the Field trait that exposes some information about the field to the type system. The offset in bytes from the start of the struct, the type of the field and the type of the base type.

    The feature is still incomplete and highly experimental. We also want to tackle the limitations in future PRs. For the moment this is enough to give us the ability to experiment with library versions of field projections and write functions that are generic over the fields of structs. For example one can write code like this:

    #![feature(field_projections)]

use std::field::{Field, field_of};
use std::ptr;

fn project_ref<'a, T, F: Field<Base = T>>(r: &'a T) -> &'a F::Type {
    // SAFETY: the `Field` trait guarantees that this is sound.
    unsafe { &*ptr::from_ref(r).byte_add(F::OFFSET).cast() }
}

struct Struct {
    field: i32,
    other: u32,
}

fn main() {
    let s = Struct { field: 42, other: 24 };
    let r = &s;
    let field = project_ref::<_, field_of!(Struct, field)>(r);
    let other = project_ref::<_, field_of!(Struct, other)>(r);
    println!("field: {field}"); // prints 42
    println!("other: {other}"); // prints 24
}

    A very important feature of the types returned by field_of! is that you can implement traits for them if you own the base type. This allows anointing fields with information by extending the Field trait. For example, this allows encoding the property of being a structurally pinned field:

    use std::pin::Pin;

unsafe trait PinnableField: Field {
    type StructuralRefMut<'a>
    where
        Self::Type: 'a,
        Self::Base: 'a;

    fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a>
    where
        Self::Type: 'a,
        Self::Base: 'a;
}

fn project_pinned<'a, T, F>(r: Pin<&'a mut T>) -> <F as PinnableField>::StructuralRefMut<'a>
where
    F: PinnableField<Base = T>,
{
    F::project_mut(r)
}

    We can then implement this extra trait for all of the fields of our struct (and automate that with a proc-macro):

    unsafe impl PinnableField for field_of!(Struct, field) {
    type StructuralRefMut<'a> = &'a mut i32;

    fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a>
    where
        Self::Type: 'a,
        Self::Base: 'a,
    {
        let base = unsafe { Pin::into_inner_unchecked(base) };
        &mut base.field
    }
}

unsafe impl PinnableField for field_of!(Struct, other) {
    type StructuralRefMut<'a> = Pin<&'a mut u32>;
    // u32 is `Unpin`, so this isn't doing anything special, but it highlights the pattern.

    fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a>
    where
        Self::Type: 'a,
        Self::Base: 'a,
    {
        let base = unsafe { Pin::into_inner_unchecked(base) };
        unsafe { Pin::new_unchecked(&mut base.other) }
    }
}

    Now you can safely obtain a pinned mutable reference to other and a normal mutable reference to field by calling the project_pinned function and supplying the correct FRT.

    (playground link)

  • Benno Lossin — comment from 2026-03-20

    Plan for 2026

    We have an updated plan for this goal in 2026 consisting of three major steps:

    • a-mir-formality,
    • Implementation,
    • Experimentation.

    Some of their subtasks depend on other subtasks for other steps. You can find the details in the updated tracking issue. Here is a short rundown of each:

    a-mir-formality: we want to create a formal model of the borrow checker changes we're proposing to ensure correctness. We also want to create a document explaining our model in a more human-friendly language. To really get started with this, we're blocked on the new expression based syntax in development by Niko.

    Implementation: at the same time, we can start implementing more parts in the compiler. We will continue to improve FRTs, while keeping in mind that we might remove them if they end up being unnecessary. They still pose for a useful feature, but they might be orthogonal to field projections. We plan to make small and incremental changes, starting with library additions. We also want to begin exploring potential desugarings, for which we will add some manual and low level macros. When we have that figured out, we can fast-track syntax changes. When we have a sufficiently mature formal model of the borrow checker integration, we will port it to the compiler. After further evaluation, we can think about removing the incomplete_feature flag.

    Experimentation: after each compiler or standard library change, we look to several projects to stress-test our ideas in real code. I will take care of experimentation in the Linux kernel, while Tyler Mandry will be taking a look at testing field projections with crubit. Josh Triplett also has expressed eagerness of introducing them in the standard library; I will coordinate with him and the rest of t-libs-api to experiment there.

  • Benno Lossin — comment from 2026-04-02

    Yesterday, we held a t-lang design meeting on our current approach. Nadrieril and I authored a design document with the feedback of Tyler Mandry, Ding Xiang Fei, Alice Ryhl, and Gary Guo. In this document, we provided the motivation for this feature, what the look and feel of a solution fitting into the existing features of Rust is, and a comprehensive + compact introduction to our current approach based on virtual places.

    The general reception was extremely positive. To give some concrete quotes from the meeting:

    • Josh:

      I adore this! I love how orthogonal it is, and how impactful and universal it is. I anticipate this becoming a beloved, pervasive feature of Rust.

      Places and projection seem important enough to me that they're worth giving one of our precious remaining ASCII sigils to, and @ is nicely evocative of a place (something is at a place). So to the extent the final syntax benefits from a sigil, :+1: for giving this @. (See some feedback below on the details, though.)

    • TC:

      Love it. High concept. As I said in the last meeting:

      I particularly like language features that reduce the need for library surface area, and this is one of those.

      There are, of course, many details to resolve and understand further, e.g., with respect to migration issues, interaction with const, async, and other effect-like things, etc. I'm looking forward to seeing the formalization work.

    • tmandry:

      What I love about this direction is how effectively it builds on what Rust already has. I love to see designs that reinforce our existing concepts while pushing them in directions that make them more expressive.

    • Jack:

      Whoo boy. This is great. There's so much here that I'm not exactly sure where to begin and what to comment on. I think this is the type of thing that we will only really be able to figure out the nitty gritty details and ergonomics only after some amount of experimentation.

    There are a few takeaways from this meeting:

    • Mark raised the concern that t-libs should be more involved in reviewing the experimental traits that we intend to add. Ensuring that we don't accidentally stabilize or expose some behavior, have sufficient documentation on our experimental traits, and that t-libs is in the loop of this feature in general.
      • Mark offered to review PRs and I will be tagging him in those.
    • Jack raised the concern that increasing the cognitive load for the 95% use-case should be avoided. Making the right choice between @ and & might be challenging for users.
      • We discussed this point more in the meeting and concluded with that we need to do some experimentation, possibly utilizing the user research team. We will of course keep this in mind and revisit it later when we have a partially working implementation.
    • TC requested that we publish our fine-grained design axioms, essentially the list of things we go through when considering a modification of our proposal.
      • I will write an update on this issue explaining exactly those.

    Aside from the concerns and directly actionable items, the meeting also covered design questions/comments that we want to take a look at in the coming weeks/months:

    Thanks to everyone who participated in the meeting!

Reborrow traits

1 detailed update available.

  • Aapo Alasuutari — comment from 2026-02-28

    PR open to get the first working version of the Reborrow and CoerceShared traits merged.

    Blockers

    Currently "blocked" on PR review, and of course my (and Ding's) work to fix all review issues.

    The review has brought up an opportunity to replace Rvalue::Ref / ExprKind::Ref with a more generalised variant that could encompass both references and user-defined references. This would be powerful, but it would be a very big and scary change. If this turns out to be a blocking issue for reviewers, then this will block the goal for the foreseeable future as the PR then starts on a massive refactoring.

    Help wanted

    The PR currently does not include derive traits, but we'd really want them. Instead of these:

    impl<'a> Reborrow for CustomMarker<'a> {}
impl<'a> CoerceShared<CustomMarkerRef<'a>> for CustomMarker<a'> {}

impl<'a, T> Reborrow for CustomMut<'a, T> {}
impl<'a, T> CoerceShared<CustomRef<'a, T>> for CustomMut<'a, T> {}

    we'd prefer to have something like this:

    #[derive(Reborrow, CoerceShared(CustomMarkerRef))]
struct CustomMarker<'a> { ... }

#[derive(Reborrow, CoerceShared(CustomRef))]
struct CustomMut<'a, T> { ... }

    If anyone feels like picking up this thread, that'd be awesome: the derive macros do not need to really perform any validity checking, as the trait itself will do that.

    If the PR merges soon, then public testing and exploration of the traits will be the next big thing. Likely concurrently with that the massive refactoring to generalise Rvalue::Ref / ExprKind::Ref.

Flagship: Flexible, fast(er) compilation

build-std

4 detailed updates available.

Production-ready cranelift backend

Promoting Parallel Front End

Flagship: Higher-level Rust

Ergonomic ref-counting: RFC decision and preview

Stabilize cargo-script

3 detailed updates available.

Flagship: Unblocking dormant traits

Evolving trait hierarchies

In-place initialization

1 detailed update available.

Next-generation trait solver

1 detailed update available.

Stabilizable Polonius support on nightly

2 detailed updates available.

  • Rémy Rakic — comment from 2026-01-30

    This month's update:

    • tiif is making progress on normalizing opaques while computing implied bounds
    • we discussed how to investigate and fix the remaining correctness issues in Tage's work, to be able to evaluate it more accurately: in particular around variance and bidirectional edges, and without the reliance on NLL (having computed region values / errors)
    • we've tried to see if it'd be possible to remove the cfg region elements
    • Amanda is still working on her two papers, one about the current borrow checker and one about the work on Polonius. Her major PR for the restructuring of placeholder handling during region inference is stalled due to a conflict with further trait solver developments and may have to be abandoned. Work with the larger types team is ongoing and smaller patches/refactorings/improvements are being landed in the meantime.
    • #149639 has now landed, and #150551 is still in review
    • I've also fixed more small inefficiencies (computing boring/relevant locals on-demand in diagnostics, removed conversions between locations and points, etc) building on top of the previous PRs (so they need to be reviewed first)
    • I've looked at crates.io again with the alpha, to find functions that are slower than with NLLs. AFAICT the worst case there is 60% for a 5KLOC function with 42K loans, 255K statements, and 125K outlives constraints. I'll see what we can do with this. Small composable functions is still good advice.
    • there seem to be optimization opportunities to 1. limit propagation to the smaller number of blocks that could be affected by bidirectional edges, 2. for unifying invariant lifetimes of live locals that are assigned at most once (à la use-def chains), 3. for invalidations that are just the activation of a reservation
    • we discussed possible plans to gather actual statistics, using the infrastructure that was created for the Metrics project
    • we're also preparing the new project goal for this year, where we'll want to stabilize the alpha 🤞

  • Rémy Rakic — comment from 2026-02-28

    We had a bit less time this month, the update will be shorter, but still meaningful I hope:

    • #150551 has landed, and it feels stabilizable. To me, this part of the goal is achieved.
    • still, "stabilizable" is not stable, and there is more work to do. We plan to stabilize this year, and the project goal proposal for 2026 tracks how.
    • tiif is still deep in #152051, and a-mir-formality work with Niko and I.
    • Amanda has opened a few cleanup PRs (#152438, and #152579), and #151863 has landed already. She also has started looking into Tage's old PR to see if we can fix it, benchmark it more accurately, and see the cool parts there that we could be using.
    • Jack is possibly going to have some time to work with us this year! His help will be very welcome, especially as I will have less time available myself.
    • we'll be tracking the opaque type region liveness soundness issue in #153215, and I've added a couple tests, in case tiif's PR or anything that impacts them lands.
    • some of the tiny cleanups I mentioned last time have also landed in #152587.

Other goal updates

Add a team charter for rustdoc team

Borrow checking in a-mir-formality

C++/Rust Interop Problem Space Mapping

5 detailed updates available.

  • Joel Marcey — comment from 2026-01-20

    The Rust Foundation is opening up a short-term, approximately 3-month, contracting role to assist in our Rust/C++ Interop initiative. The primary work and deliverables for the role will be to make substantial progress on the Problem Space Mapping Rust Project Goal by collecting discrete problem statements and offering up recommendations on the work that should follow based upon the problems that you found.

    If you are interested in how programming languages interoperate, are curious in understanding the problems therein, and are have a passion to think about how those problems may be resolved for the betterment of interop, then this work may be for you.

    An ideal candidate will have experience with Rust programming. Having experience in C++ is strongly preferred as well. If you have direct experience with actual engineering that required interoperating between Rust and C++ codebases, that's even better.

    If you are interested, please email me (email address found in my GitHub profile) or contact me directly on Zulip by Tuesday, January 27 and we can take it from there to see if there may be a potential fit for further discussion.

    Thank you.

  • Joel Marcey — comment from 2026-01-31

    The effort to fill the contracting role to support this project goal is in the process winding down. The interview and discussion process is nearly complete. We expect to make a final decision for the role in early February.

  • teor — comment from 2026-02-27

    Hi, I'm the new contractor on the interop problem space mapping project goal.

    In the last week and a half, I've:

    Next step is prioritising a few of the use cases, then working on related problem statements in more detail.

    Blockers

    Nothing at the moment, still working through the high level mapping of the problem space.

    Help wanted

    Suggestions for more interop use cases would be very welcome, just open a discussion in t-lang/interop and I'll turn it into a ticket. Or go ahead and open a use case ticket directly.

    I'll post an update here every few weeks, you can follow more detailed weekly updates on Zulip.

  • teor — comment from 2026-03-30

    In the last month, I've:

    • met with the lang team, Crubit team, and cxx author, and Joel and Mara have met with the C++ standards working group
    • expanded some draft high-level problem statement summaries, and added code examples
    • added 6 new interop use cases
    • added more relationships between problems/use cases and existing project goals & unstable compiler features
    • prepared for the Rust All Hands, and started mentoring for Outreachy

    Specifically, the last month we've identified and prioritised two high-priority use cases for more detailed work:

    And I analysed the problems / use cases we've collected so far, with priorities, responsible language, and a split into semantics or tooling changes.

    Next step is continuing to work on overloading and build systems in more detail. If you have specific Rust/C/C++ build system blockers, please open a chat or ticket.

    Blockers

    Nothing at the moment, everyone has been extremely helpful, and I'm getting good feedback on use cases, problems, priorities, and Rust language experiments.

  • teor — comment from 2026-05-01

    In the last month, I've:

    Specifically, the last month we've made detailed progress on two high-priority use cases:

    Next step is continuing to work on the overloading experiment, along with RustWeek/All Hands preparation, and collecting feedback during the conference.

    Blockers

    Nothing at the moment. There is a steady stream of new use cases, problems, code examples and Rust language experiment feedback.

Comprehensive niche checks for Rust

Const Generics

6 detailed updates available.

  • Niko Matsakis — comment from 2026-01-27

    Boxy and I have established a regular time to check-in on formalizing this within a-mir-formality. Today we mostly worked on the "model" of const values, starting with this

    #[term]
pub enum ConstData {
    // Sort of equivalent to `ValTreeKind::Branch`
    #[cast]
    RigidValue(RigidConstData),

    // Sort of equivalent to `ValTreeKind::Leaf`
    #[cast]
    Scalar(ScalarValue),

    #[variable(ParameterKind::Const)]
    Variable(Variable),
}



#[term]
pub enum ScalarValue {
    #[grammar(u8($v0))]
    U8(u8),
    #[grammar(u16($v0))]
    U16(u16),
    #[grammar(u32($v0))]
    U32(u32),
    #[grammar(u64($v0))]
    U64(u64),
    #[grammar(i8($v0))]
    I8(i8),
    #[grammar(i16($v0))]
    I16(i16),
    #[grammar(i32($v0))]
    I32(i32),
    #[grammar(i64($v0))]
    I64(i64),
    #[grammar($v0)]
    Bool(bool),
    #[grammar(usize($v0))]
    Usize(usize),
    #[grammar(isize($v0))]
    Isize(isize),
}


#[term($name $<parameters> { $,values })]
pub struct RigidConstData {
    pub name: RigidName,
    pub parameters: Parameters,
    pub values: Vec<Const>,
}

    i.e., a const value can be a scalar value (as today) or a struct literal like Foo { ... } (which would also cover tuples and things). We got the various tests passing. Huzzah!

  • Boxy — comment from 2026-01-30

    In addition to what niko posted previously there's been a lot of other stuff happening. A lot of people have opened PRs to improve mGCA this month: León Orell Valerian Liehr Noah Lev @enthropy7 Kivooeo mu001999 @Human9000-bit Redddy @Keith-Cancel @AprilNEA

    A rough list of things that have been improved for mGCA:

    • Lots of new expressions now supported by mGCA: const constructors, tuple constructor calls, array expressions, tuple expression, literals
    • associated_const_equality has been merged into min_generic_const_args. the former was effectively dependent on the latter already so this just makes it nicer to use the former :)
    • traits can now be dyn compatible if all associated constants are type consts and are specified in the trait object (e.g. dyn Trait<ASSOC = 10>)
    • type consts are enforced to be non-generic
    • a bunch of ICEs have been fixed
    • camelid has been working on "non-min" version of mGCA which will allow arbitrary expressions to be used in the type system (a blog post with more detail will be published once this actually lands)

    In non-mGCA updates, as niko says, we've been meeting regularly to make progress on modelling const generics in a-mir-formality. I've also been spending time thinking about the interactions between adt_const_params and ADTs with privacy/safety invariants and I think I know how to structure the RFC in this area so can make progress on that again

    There's some more detail about the various bits of work people have done and who did what here: #project-const-generics > perfectly adequately sized wins @ 💬

  • Niko Matsakis — comment from 2026-02-13

    Boxy and I have met (and continue to meet) and work on modeling const generics in a-mir-formality. We're still working on laying the groundwork.

    There is a proposed project goal for next year.

  • Boxy — comment from 2026-02-28

    There's been a lot of miscellaneous fixes for mGCA this month. I've also started drafting some blog posts to explain what's going on with mGCA/oGCA as well as soliciting use cases/experience reports for them and adt_const_params. I also talked with some folks at Rust Nation this month about const generics and what features would be useful for them and why.

  • Boxy — comment from 2026-04-02

    Late on the update :') niko and i continue to meet to discuss const generics. we've made some progress on figuring out problems around privacy/safety in const generics. we've also been discussing the big picture stuff for const generics and where we're "heading".

  • Boxy — comment from 2026-05-01

    started running weekly meetings about const generics to make it easier to keep up to date with all the people who are working on const generics stuff. i think min_adt_const_params is now at the point of what the RFC is going to specify.

    GCA is making good progress thanks to ashley's work. i also met with lcnr where we talked about whether there was some version of mGCA that is stabilizeable in the near future or not (maybe!)

Continue resolving cargo-semver-checks blockers for merging into cargo

1 detailed update available.

Develop the capabilities to keep the FLS up to date

2 detailed updates available.

  • Pete LeVasseur — comment from 2026-03-04

    We have a Project Goal in 2026 that we'll take on: Stabilize FLS Release Cadence. Progress towards 1.93.1 looks good, most issues are closed.

    Help wanted

    We'd love more folks from the safety-critical community to contribute to picking up issues or opening an issue if you notice something is missing.

  • Pete LeVasseur — comment from 2026-04-02

    Trying to prepare FLS releases earlier:

    • since we completed the 1.94.0 release of the FLS a bit early this time, we checked into the stretch part of our goal this year to look at 1.95.0 early
    • we learned a bit more of the release notes process thanks to tips from Eric Huss and TC
    • Tshepang Mbambo and I attended the t-release meeting last week where we chatted about working a little "upstream" with them on generating the release notes a bit earlier
    • tomorrow in our t-fls meeting we'll discuss our interest with engaging over there; at a minimum I'll get engaged with t-release

    Glossary and main-body text harmonization:

    • the first PR landed from Tshepang Mbambo removing IDs from the glossary
    • further steps planned, we have a tracking issue for it

    Developer guide:

    • akin to how the Reference now has a developer's guide now for contributing we'll do the same in the FLS
    • Hristian Kirtchev has been working on this

Emit Retags in Codegen

4 detailed updates available.

  • Ian McCormack — comment from 2026-01-09

    Here's our January status update!

    • Yesterday, we posted an MCP for our retag intrinsics. While that's in progress, we'll start adapting our current prototype to remove our dependence on MIR-level retags. Once that's finished, we'll be ready to submit a PR.
    • We published our first monthly blog post about BorrowSanitizer.
    • Our overall goal for 2026 is to transition from a research prototype to a functional tool. Three key features have yet to be implemented: garbage collection, error reporting, and support for atomic memory accesses. Once these are complete, we'll be able to start testing real-world libraries and auditing our results against Miri.

  • Ian McCormack — comment from 2026-02-24

    We just posted our February status update for BorrowSanitizer. TL;DR:

    • We provide detailed error messages for aliasing violations, which look almost like Miri's do!
    • We have two forms of retag intrinsic: __rust_retag_mem and __rust_retag_reg. We no longer require a compiler plugin to determine the permission associated with a retag, which will make it possible to use BorrowSanitizer by providing a single -Zsanitizer=borrow flag to rustc. You can check out our MCP for more detailed design updates.
    • We are starting to have a better understanding of how BorrowSanitizer performs in practice, but we do not have enough data yet to be certain. From one test case, it seems like we are somewhat faster but still in the same category of performance as Miri when we compare against other sanitizers. Expect more detailed results to come as we scale up our benchmarking pipeline.
    • We have a tentative plan for upstreaming BorrowSanitizer in 2026, starting with its LLVM components. We intend to start the RFC process on the LLVM side this spring, once our API is stable.

  • Ian McCormack — comment from 2026-03-30

    We just posted our March status update for BorrowSanitizer. TL;DR:

    • We added hundreds more relevant tests from Miri's test suite. At the moment, 80% pass.
    • We improved our cargo plugin (cargo-bsan) to better support multilanguage libraries. This will let us start to recreate the bugs from our earlier evaluation.

    Our goal for April is to continue expanding our test suite, finish an initial version of the LLVM components of BorrowSanitizer, and hopefully start the RFC process on the LLVM side.

  • Ian McCormack — comment from 2026-04-29

    We have some exciting news: our talk on BorrowSanitizer was accepted at RustConf this year! We’re grateful for the opportunity and looking forward to sharing our results with the broader community this September.

    We just posted our April status update. It’s a bit of a technical one. Here’s the TL;DR:

    • BorrowSanitizer now uses a shadow stack to track metadata at runtime - this is a significantly different strategy than other LLVM sanitizers, and it will help us support garbage collection.
    • We are now ready to start sending in PRs for our retag intrinsics. It will take a little time to split our changes up into meaningful, reviewable chunks—you can expect to see these throughout the next week.

    The RFC for our LLVM components is taking a little longer than expected, but it was worth taking the extra time to test out compiler changes and make sure that we had the core parts of the instrumentation pass settled. We’ll be drafting the RFC throughout the next few weeks.

Expand the Rust Reference to specify more aspects of the Rust language

1 detailed update available.

Finish the libtest json output experiment

Finish the std::offload module

2 detailed updates available.

  • Manuel Drehwald — comment from 2026-01-16

    std::autodiff is moving closer to nightly, and std::offload is gaining various performance, feature, and hardware support improvements.

    autodiff

    Jakub Beránek, sgasho, and I continued working on enabling autodiff in nightly. We have a PR up that builds autodiff in CI, and verified that the artifacts can be installed and work on Linux. For apple however, we noticed that any autodiff usage hangs. After some investigation, it turns out that we ended up embedding two LLVM copies, one in rustc, and one in Enzyme. It should be comparably easy to get rid of the second one. Once we verified that this fixes the build, we'll merge the PR to enable autodiff on both targets in nightly.

    offload

    A lot of interesting updates on the performance, feature, and hardware support side.

    1. Marcelo Domínguez, @kevinsala, @jdoerfert, and I started implementing the first benchmarks, since that's generally the best way to find missing features or performance issues. We were positively surprised by how good the out-of-the-box performance was. We will implement a few more benchmarks and post the results once we have verified them. We also implemented multiple PRs which implement bugfixes, cleanups, and needed features like support for scalars. We also started working on LLVM optimizations which make sure that we can achieve even better performance.
    2. I noticed that our offload intrinsic allowed running Rust code on the GPU, but it wasn't of much help when calling gpu vendor libraries like cuBLAS. I implemented a new helper intrinsic which allows calling those functions conveniently, without having to manually move data to or from the device. It will benefit from the same LLVM optimizations as our full offload intrinsic. It also a bit simpler to set up on the compiler and linker side, so it already works with std and mangled kernel names, something that we still have to improve for our main offload intrinsic.
    3. A lot of work happened on the LLVM offload side for SPIRV and Intel GPU support. At the moment, our Rust frontend is tested on NVIDIA and AMD server and consumer GPUs, as well as AMD HPC and Lapotop APUs. Karol Zwolak reached out since he wants to help with with also running Rust on Intel GPUs. Offload relies on LLVM which started gaining Intel support, so hopefully we won't need much work beyond a new intel-gpu target and a new stdarch module. There is also work on a new spirv target for rustc, which we could also support if it goes through LLVM. Due to some open questions around typed pointers it does not seem clear yet whether it will, so we will have to wait.
    4. Nikita started working on updating our submodule to LLVM 22. This hopefully does not only brings some compile and runtime performance improvements, but also greatly simplifies how we can build and use offload. Once it landed I'll refactor our bootstrapping logic, and as part of that start building offload in CI.

  • Manuel Drehwald — comment from 2026-04-01

    std::autodiff is now partly in CI, and std::offload got tested on a lot more benchmarks.

    autodiff

    Work continued on enabling autodiff in nightly. Since the last update, we have enabled autodiff in some Mingw and Linux runners. Users can now download libEnzyme artifacts, place them locally in the right spot for their toolchain, and then use autodiff on their nightly compiler. Once macOS is added, we will enable a new rustup component that will handle the download for users. Before enabling autodiff on macOS, however, we want to change how we distribute LLVM on this target (from static to dynamic linking). There are a lot of workflows and users of this target, not all of which can be modelled in the Rust CI. Our last two attempts sadly broke such downstream users and local contributors, so both attempts had to be reverted. Since testing here is tricky, progress here might be on the slower side; we will see.

    offload

    Most of the work on the offload side lately has been invisible, since we were working on implementing more benchmarks and LLVM optimizations, as well as missing features, discovered by those benchmarks. We achieved excellent performance on those benchmarks; more details will soon be presented by Marcelo Domínguez at the EuroLLVM conference in two weeks!

    Beyond benchmarks, there was a lot of tinkering on smaller PRs, reviewing, and housekeeping. LLVM-22 landed, so we updated our bootrstrap code to make use of new APIs, and tried to move a few smaller PRs forward, mainly around a better user experience and for making more Rust features available. Since the focus is still on benchmarks, not many of those PRs landed. They are in a mostly ready state, so it's a good time to pick them up if you're considering contributing. Please ping me on Zulip or in any PR with the offload label if you are interested!

Getting Rust for Linux into stable Rust: compiler features

4 detailed updates available.

Getting Rust for Linux into stable Rust: language features

6 detailed updates available.

  • Tomas Sedovic — comment from 2026-01-19

    Update from the 2026-01-14 meeting.

    Deref / Receiver

    Ding's arbitrary_self_types: Split the Autoderef chain rust#146095 is waiting on reviews. It updates the method resolution to essentially: deref_chain(T).flat_map(|U| receiver_chain(U)).

    The perf run was a wash and a carter has completed yesterday. Analysis pending.

    RFC #3851: Supertrait Auto-impl

    Ding has submitted a Rust Project goal for Supertrait Auto Impl.

    Arbitrary Self Types rust#44874

    We've discovered the #[feature(arbitrary_self_types_pointer)] feature gate. As the Lang consensus is to not support the Receiver trait on raw pointer types we're probably going to remove it (but this needs further discussion). This was a remnant from the original proposal, but the Lang has changed direction since.

    derive(CoercePointee) rust#123430

    Ding is working on a fix to prevent accidental specialization of the trait implementation. rust#149968 is adding an interim fix.

    Alice opened a Reference PR for rust#136776. There are questions around the behaviour of the as cast vs. coercions.

    Pass pointers to const in assembly rfc#3848

    Gary opened implementation for the RFC: rust#138618.

    Field Projections goal#390

    Benno updated the Field Representing Types PR to the latest design. This makes the PR much simpler.

    Tyler opened a Beyond References wiki to keep all the proposals, resources in one place.

    In-place initialization goal#395

    Ding is writing a post to describe all the open proposals including Alice's new one that she brouhght up during the LPC 2025. He'll merge it in the Beyond References wiki.

    Macros, attributes, derives, etc.

    Josh brought up his work on adding more capable declarative macros for writing attributes and derives. He's asked the Rust for Linux team for what they need to stop using proc macros.

    Miguel noted they've just added dependency on syn, but they would like to remove it some day if their could.

    Benno provided a few cases of large macros that he thought were unlikely to be replaceable by declarative-style ones. Josh suggested there may be a way and suggested an asynchronous discussion.

  • Tomas Sedovic — comment from 2026-02-16

    Updates from the 2026-01-28 and 2026-02-11 meetings:

    Removing the likely/unlikely hints in favour of cold_path

    The stabilization of core::hint::cold_path lint is imminent and after it, the likely and unlikely hints are likely (pardon the pun) to be removed.

    The team discussed the impact of this. These hints are used in C but not yet in Rust. cold_path would be sufficient, but likely/unlikely would still be more convenient in cases where there isn't an else branch. Tyler Mandry mentioned that these can be implemented in terms of cold_path.

    Niche optimizations

    We discussed the feasibility of embedding data in lower bits of a pointer -- something the kernel is doing in C. This could also enable setting the top bit in the integers (which is otherwise never set) and make it represent an error in that case (and a regular pointer otherwise).

    Ideally, this would be done in safe Rust, as the idea is to improve the safety of the C code in question.

    Extending the niches is something Rust wants to see, but it's waiting on pattern types. There are short/medium-term options by using unsafe and wrapping it in a safe macro, but the long-term hope is to have this supported in the language.

    Vendoring zerocopy

    The project has interest in vendoring zerocopy. We had its maintainers Jack Wrenn and Joshua Liebow-Feeser join us to discuss this and answer our questions. The main question was about whether to vendor at all, how often should we (or will have to) upgrade, and how much of it is expected to end up in the standard library.

    The project follows semver with the extended promise to not break minor versions even before 1.0.0. We could vendor the current 0.8 and we should be upgrade on our own terms (e.g. when we bring in new features) rather than being forced to.

    Right now, the project is able to experiment with various approaches and capabilities. Any stdlib integration a long way away, but there is interest in integrating these to the language and libraries where appropriate.

    New trait solver

    There's been a long-term effort to finish the new trait solver, which will unblock a lot of things. Niko Matsakis asked about things it's blocking for Rust for Linux.

    This is the list: unmovable types, guaranteed destructors, Type Alias Impl Trait (TAIT), Return Type Notation (RTN), const traits, const generics (over integer types), extern type.

    2026 Project goals

    This year brings in the concept of roadmaps. We now have a Rust for Linux and a few more granular Goals. We'll be adding more goals over time, but the one merged cover what we've been focusing on for now.

  • Tomas Sedovic — comment from 2026-03-11

    Update from the 2026-02-25 meeting:

    2026 Project goals

    We spent most of the meeting going over the open Project goals, the Rust for Linux roadmap and other things we'd like to see that aren't the right shape for a goal.

    Miguel Ojeda brought up the upcoming Debian 14 release (coming out probably somewhere around Q2 of 2027) and we went over each item and decided whether it's something we need to make sure is in that release or not.

    Debian stable is an important milestone and the Rust version in it serves as a baseline for Rust for Linux development.

    I'll add all this data into the roadmap.

  • Tomas Sedovic — comment from 2026-03-16

    Update from the 2026-03-11 meeting:

    Field projections

    We now have a macro and machinery that uses the projection mechanism.

    The dma_read! / dma_write! macros switched over to it. This also fixes a soundness issue 1.

    Note: this is done entirely via macros and doesn't use any Field projections language features. The Field projection syntax and traits should make this more ergonomic and integrate the borrow checker so we can accept more code.

    We're planning to have a design meeting with the Lang team in the last week of March.

    rustfmt imports formatting and trailing slashes

    We talked about the rustfmt formatting of the use statements again. While the trailing empty comment // workaround (see this update) is acceptable as a temporary measure, we need to find a long-term solution where you can configure rustfmt to accept this style.

    We don't have a issue for this specific formatting yet, though it was discussed in #3361.

    The next step are to create such an issue. We were hesitant to add burden to a team that's already at limit, but having the issue would let us track it from the Rust for Linux side.

  • Tomas Sedovic — comment from 2026-03-26

    Update from the 2026-03-26 meeting:

    Const generics

    Boxy asked the team for features that are most important under the const generics umbrella. This might help with prioritisation and just understanding of practical uses.

    1. Ability to do arithmetic on const generic types: e.g. the kernel has a type Bounded which has a value and a maximum size (in bits). Both the bit width and value are const values. They want to be able to do arithmetics on these types (starting with bit shifts) that will guarantee the the result will fit within the specified size at compile time.
    2. Argument-position const generics: right now, the const generic types must be specified in the type bound section (within the angle brackets). So for example you have to write: Bounded::<u8, 4>::new::<7>() instead of the more natural Bounded::<u8, 4>::new(7). This gets more complicated when there's const-time calculation happening rather than just a numerical constant -- in which case this also needs to be wrapped in curly brackets: { ... }.
    3. Being generic over types other than numbers: pointers would be useful for asm_const_ptr. String literals too -- even if they're just passed through without being processed / operated on. And if going from a passthrough string makes it possible to pass through any type, that would help the team replace some typestate patterns they're using with an enum.

    statx

    Alice Ryhl proposed being able to create std::fs::Metadata from Linux statx syscall.

    This was discussed in the Libs-API meeting and they had questions about possible evolutions of the statx ABI -- if/how it can grow in the future and how they could handle that if they wanted some of the new data available. So we discussed it in the Rust for Linux meeting.

    In the end, it seems prudent to be reasonably defensive rather than relying on the syscall pre-filling default values.

    Alice Ryhl proposed an opaque statx struct that would give the stdlib a way to decide on the struct's size, pre-filled contents and mask.

    Miguel Ojeda suggested contacting Christian Brauner and Alexander Viro (i.e. the VFS maintainers); Josh Triplett agreed that it would be good if we can get a thread with the right people in linux-fsdevel.

  • Tomas Sedovic — comment from 2026-04-10

    Update from the 2026-04-08 meeting:

    zerocopy features in Rust's std

    zerocopy uses two traits that are both polyfills for unstable traits : KnownLayout (for ptr_metadata) and Immutable (for Freeze). It would help maintenance of zerocopy (which Rust for Linux plans to start using) if these were stabilised.

    ptr_metadata is something the team wants in the kernel independently. It's possibly blocked on (or at least might have interactions with) the Sized Hierarchy work.

    Freeze (now NoCell) has an RFC.

    Deref/Receiver

    Jack Huey started reviewing Ding Xiang Fei's PR to split the autoderef chain and feels it's not ready to go in front of the full Lang team.

    We also discussed the dependence/independence of the Deref and Receiver implementations, in particular whether it ever makes sense to implement Deref but not Receiver. Josh Triplett suggested gathering examples for cases like that (where you can't use the type as a Self type in the function declaration, but allow calling methods on it).

    The current plan for the experiment is to have these traits separate, but have the compiler enforce that if they implement the same type, their targets are identical. This will let us open the door for any future possibilities (a supertrait / subtrait relation, or having diverging targets in the future).

    We want to experiment to see where and how these traits and their possible evolution might be helpful.

    null-ptr-deref

    The team would like to have a (an optional) compiler guarantee, that the compiler never removes null checks on raw pointers. What can currently happen in C is that if you deref a null pointer, the compiler can do optimisations including removing any subsequent checks whether that pointer is null, because dereferencing a null pointer is undefined behaviour.

    But the null check can still help prevent further bugs and in C, the kernel now disables the optimisation that would remove it.

    Miguel Ojeda is going to open an MCP for this.

    In-Place Initialization

    Benno Lossin opened a proposal for an in-person room at the 2026 All Hands for In-place initialization.

    Here's a meta issue tracking all the proposals and discussions about the feature.

    The design space is complex and the team hopes that discussing it in person will help move it forward.

Implement Open API Namespace Support

MIR move elimination

1 detailed update available.

  • Amanieu d'Antras — comment from 2026-04-03

    The RFC has just been published. It has been significantly reworked since the last draft.

    Notable changes:

    • Removed the concept of activation/de-activation. Now the semantics don't need to deal with partially allocated locals. This is less powerful optimization-wise but should still cover most cases.
    • Added byref/byval to call arguments to clarify how they are passed.
    • Added a separate section for the surface language changes to separate it from the MIR changes.
    • Added more details on the MIR optimization which eliminates moves.
    • Changed the MIR operand evaluation order to be left-to-right, except for destination places which are always evaluated last.
    • Added StorageLive back: we need it to mark the location where llvm.lifetime.start should be inserted, which is not the same as the location where a local is initialized. In the opsem, StorageLive doesn't actually allocate the local, that's still done when it is initialized by a write.

Prototype a new set of Cargo "plumbing" commands

Prototype Cargo build analysis

1 detailed update available.

  • Weihang Lo — comment from 2026-01-08

    The prototype of this project goal is basically complete.

    Current state

    This project goal introduces build analysis support in Cargo, with the aim of making build behavior understandable across multiple invocations, not just a single run.

    At a high level, the prototype:

    • Records build metadata over time, including:
      • rebuild reasons
      • timing information
      • relevant invocation context
    • Stores this data locally in a structured log format suitable for later analysis
    • Exposes the data via unstable cargo report subcommands, such as:
      • cargo report sessions - list session IDs
      • cargo report timings - HTML timing report
      • cargo report rebuilds - Why things rebuilt

    See the Reference for a more thorough usage documentation

    Path towards stabilization

    Before this feature can be stabilized, the following unresolved questions must be answered. They might not block stabilization, but need to be evaluated if it is fine to leave for future.

    cargo report commands

    This is a stabilization blocker.

    • Currently all three report commands (sessions, rebuilds, timings) implicitly inspect global log files when if not in a workspace.
      • Should this be explicit with a flag?
      • Should this be an error if not in a workspace?
    • Bikeshed on command names
      • Currently we have all nouns
        • For sessions
          • runs simple but ambiguous
          • Just log like git log
          • history user-friendly (docker history, shell history, though not alike)
        • For timings:
          • Not controversial, as we have --timings flag already
        • For rebuilds:
          • rebuild-reasons more explicit
      • Or move to action-oriented verbs:
      • cargo report list-sessions
      • cargo report analyze-timings (bazel analyze-profile)
      • cargo report explain-rebuilds
      • Or question-oriented verbs:
      • cargo report what-ran more general (buck2 log what-ran)
      • cargo report why-rebuilt/why-reran
    cargo report sessions
    • Currently it prints a human-readable output without a format for programmable use cases.
      • Should we provide a programmable output (for example behind --message-format=json)?
    cargo report rebuilds

    Log message schema

    This is a stabilization blocker.

    Log infrastructure

    These are mostly future possibilities, not a stabilization blocker, as it is highly possible to do incremental improvements.

    See also https://github.com/rust-lang/cargo/issues/16471#issuecomment-3724915770

    Nested Cargo calls

    See https://github.com/rust-lang/cargo/issues/16477.

    Basically, we need to have a way to associate log files of nested Cargo calls. That helps other tools as well as cargo fix itself.

    This is a stabilization blocker.

    How contributors can help

    Future contributors can help by:

    A series of follow-up tasks has been cut to track remaining work:

    • https://github.com/rust-lang/cargo/issues/16470
    • https://github.com/rust-lang/cargo/issues/16471
    • https://github.com/rust-lang/cargo/issues/16472
    • https://github.com/rust-lang/cargo/issues/16473
    • https://github.com/rust-lang/cargo/issues/16474
    • https://github.com/rust-lang/cargo/issues/16475
    • https://github.com/rust-lang/cargo/issues/16477
    • https://github.com/rust-lang/cargo/issues/16488

reflection and comptime

5 detailed updates available.

Rework Cargo Build Dir Layout

2 detailed updates available.

  • Ross Sullivan — comment from 2026-01-15

    Fine grain locking for build-dir was merged and now available on nightly via -Zfine-grain-locking unstable flag. 🎉

    There are some known issues we'd like to address before doing a formal call for testing. Notably, improving blocking messages, fixing potential thread starvation in Cargo's job queue when locks block, and investigate increasing rlimits to reduce risk of hitting max file descriptors for large projects.

    I am hopeful that these issues will be resolved over the coming month and we can do a call for testing to start gathering feedback from the community on whether the new locking strategy improves workflows.

  • Ross Sullivan — comment from 2026-03-09

    After the initial PR from the last update was merged, we shifted our focus to resolving some of the known issues. Notably, locking blocks the Cargo job queue slowly causing thread starvation if many build units are held by another Cargo instance.

    We investigated adding the ability for Cargo to "suspend" a job internally while waiting for a lock, but we felt this change was a bit invasive and did not fit well with how the job queue was designed. Instead we plan to change our design to acquire all build unit locks prior to running the job queue (see #16657).

    At the same time, we have continued to refine the new build-dir to prepare it for a call for testing and eventual stabilization. (#16542, #16502, #16515, #16514)

    Finally we decided to split .cargo-lock into 2 locks to allow cargo check and cargo build to run in parallel when artifact-dir == build-dir (and -Zfine-grain-locking is enabled)

    I suspect this may be the last update on this goal, as the 2026 slate of goals is coming up. While I did not renew this goal for 2026, I do plan to continue work on this and eventually stabilize this within this year.

Run more tests for GCC backend in the Rust's CI

Rust Stabilization of MemorySanitizer and ThreadSanitizer Support

3 detailed updates available.

Rust Vision Document

  • People involved: Niko Matsakis, vision team
  • Status: Partially completed; work continues outside of Project Goals

rustc-perf improvements

Stabilize public/private dependencies

Stabilize rustdoc doc_cfg feature

SVE and SME on AArch64

5 detailed updates available.

  • David Wood — comment from 2026-01-15

    rust-lang/rust#143924 has been merged, enabling scalable vector types to be defined on nightly, and I'm working on a patch to introduce unstable intrinsics/scalable vector types to std::arch

  • David Wood — comment from 2026-02-17

    Progress has been slow since the last update because I've been busy, but I've been working on a rebase of rust-lang/stdarch#1509, which has bitrot quite a bit. Rémy Rakic is joining me to work on the Sized Hierarchy parts of the goal.

  • David Wood — comment from 2026-03-17

    On the scalable vector half of the goal, I've got a branch with rust-lang/stdarch#1509 rebased, though without the intrinsic-test tool having been updated - that ended up being tricky and we've agreed to do it as a follow-up. We've opened rust-lang/rust#153286 with the compiler fixes that the stdarch patch requires, which should land soon (rust-lang/rust#153653 was opened and landed in the interim).

    On the sized hierarchy half of the goal, Rémy Rakic has been updating our RFC such that we can discuss it in design meetings with the language team on the 18th and 25th - we'll update rust-lang/rfcs#3729 later today. We've split out the const Sized parts as a future possibility (though one we are committed to pursuing) as that has more open design questions, and we've discussed the proposed syntax and approach to migration - which are what we intend to focus on in the design meetings. He's also been working out how we can start implementing our migration strategy and help resolve blockers in other areas.

  • David Wood — comment from 2026-03-17

    Per last comment, rust-lang/rfcs#3729 has been updated

  • David Wood — comment from 2026-04-14

    For the scalable vector half of the goal, we've landed a bunch of compiler fixes - rust-lang/rust#153286, rust-lang/rust#153608, rust-lang/rust#154850, rust-lang/rust#154950, rust-lang/rust#155106 and rust-lang/rust#155243 - and opened our stdarch patch with intrinsics - rust-lang/stdarch#2071. That patch should be passing CI tomorrow once nightly updates to fix an unrelated spurious CI failure. We've got a handful of follow-ups to do afterwards, listed on rust-lang/rust#145052.

    For the sized hierarchy half of the goal, Rémy Rakic and I had two design meetings with the language team (2026/03/18 and 2026/03/25) discussing the syntax/naming and migration strategy respectively.

    On syntax, the language team preferred introducing an "only bounds" syntax to control opting-out of default bounds and opting-in to alternative bounds in a family of traits (described in an alternative in the RFC), but there was an open question of whether that syntax should apply to an individual bound or all of the bounds - Niko Matsakis is investigating that.

    On naming, the language team also preferred the name SizeOfVal over MetaSized, and didn't like Pointee but had no better alternatives. Rémy Rakic prepared rust-lang/rust#154374 to do that renaming and started a discussion with the library team to confirm they were happy with the name, because changing it involves an amount of churn. The library team wanted to know what other traits in the hierarchy might later be introduced, as that would help inform the naming of the currently proposed traits, so Rémy Rakic wrote up a document with that information. We're holding off on doing any name changes until we find some consensus between libs and lang - who is responsible for these traits' names is a bit unclear.

    On migration, the language team were largely happy with our proposed approach, and we realised that the approach proposed by lcnr for associated types might also work for our other migrations. Rémy Rakic has had meetings with lcnr to better understand that approach and to work out the next steps for implementing it.

Type System Documentation

Unsafe Fields

2 detailed updates available.
show more
The 2026 Developer Survey is now open (for human developers only)!
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/06/23/the-2026-developer-survey-is-now-open-for-human-developers-only/
Published: 2026-06-23 14:00:00 | Created: 2026-07-23 05:23:40
Once again, we're asking for your help to take the temperature of software development.
show more
Python 3.12.13, 3.11.15 and 3.10.20 are now available!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/03/python-31213-31115-31020/
Published: 2026-03-03 00:00:00 | Created: 2026-07-23 05:23:40
[Python Releases For Your Security!](https://discuss.python.org/t/python-3-12-13-3-11-15-and-3-10-20-are-now-available/106363) New security releases for 3.10, 3.11 and 3.12 are now available.
show more
Your AI shipped a backend that boots. That is the whole problem.
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/06/23/your-ai-shipped-a-backend-that-boots-that-is-the-whole-problem/
Published: 2026-06-23 14:08:58 | Created: 2026-07-23 05:23:40

No content available

Security Advisory for Cargo (CVE-2026-5222)
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/05/25/cve-2026-5222/
Published: 2026-05-25 00:00:00 | Created: 2026-07-23 05:23:40

The Rust Security Response Team was notified that Cargo incorrectly normalized the URLs of third-party registries using the sparse index protocol. If a hosting provider allowed multiple registries to be hosted with arbitrary names within the same domain, an attacker able to publish crates in a registry could obtain the credentials of others users of the same registry.

This vulnerability is tracked as CVE-2026-5222. The severity of the vulnerability is low, due to the extremely niche requirements needed to achieve the attack.

Overview

Originally Cargo only supported storing a registry's index within git repositories. Most git hosting solutions allow accessing a git repository with or without the .git suffix, so Cargo mirrored this behavior when normalizing registry URLs. This allowed credentials for https://example.com/index to be used for https://example.com/index.git.

This normalization was unintentionally applied to the new sparse indexes too. Sparse indexes can be hosted on any HTTPS server, which treat URLs ending with .git as different URLs than those without the suffix.

If the following conditions apply:

  • https://example.com/index is a sparse index.
  • https://example.com/index allows crates to depend on crates from any other registry.
  • The attacker is able to publish crates on https://example.com/index.
  • The attacker is able to upload arbitrary files to https://example.com/index.git.

...the attacker could configure https://example.com/index.git to be a Cargo sparse registry requiring authentication for downloads, and with a download URL pointing to a server recording any credentials set to it.

When the attacker then publishes a crate foo to https://example.com/index depending on a crate bar from https://example.com/index.git, and tricks the victim into downloading foo, Cargo will think the two registries share the same credential and send the victim's Cargo token to the malicious registry.

Mitigations

Rust 1.96, to be released on May 28th, 2026, will update Cargo to only strip the .git suffix from registry URLs using the git protocol. No mitigations are available for users of older versions of Cargo.

Affected versions

All versions of Cargo shipped between Rust 1.68 (the stabilization of sparse registries) and 1.96 are affected.

Acknowledgements

We'd like to thank Christos Papakonstantinou for reporting this to us according to the Rust security policy.

We also want to thank the members of the Rust project who helped us address the vulnerability: Arlo Siemens for developing the fix; Weihang Lo, Eric Huss and Emily Albini for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure.

show more
CPython: 36 Years of Source Code
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/03/cpython-codebase-growth/
Published: 2026-03-08 00:00:00 | Created: 2026-07-23 05:23:40
An analysis of the growth of CPython's codebase from its first commits to the present day
show more
Security Advisory for Cargo (CVE-2026-5223)
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/05/25/cve-2026-5223/
Published: 2026-05-25 00:00:00 | Created: 2026-07-23 05:23:40

The Rust Security Response Team was notified that Cargo incorrectly handled symlinks inside of crate tarballs downloaded from third-party registries, allowing a malicious crate to override the source code of another crate from the same registry.

This vulnerability is tracked as CVE-2026-5223. The severity of the vulnerability is medium for users of third-party registries. Users of crates.io are not affected, as crates.io forbids uploading crates containing any symlink.

Overview

When building a crate, Cargo extracts its source code in a local cache (stored within ~/.cargo), reusing it for any future build. Cargo includes protections to prevent any file from being extracted outside of the crate's own cache directory.

It was discovered that it's possible to craft a malicious tarball able to extract files one level below the crate's own cache directory. With the way the cache is structured, that allowed the malicious crate to override the cache of other crates belonging to the same registry.

Mitigations

Rust 1.96.0, to be released on May 28th, 2026, will update Cargo to reject extracting any symlink within crate tarballs, regardless of whether they come from crates.io (which already forbids them) or third-party registries. Note that Cargo never added symlinks when running cargo package or cargo publish, so the impact of this should be minimal.

Users who are not able to upgrade to the most recent Rust version are recommended to audit the contents of their registry for the presence of any symlink, and to configure their registry to reject symlink (if such option is available).

Affected versions

All versions of Cargo shipped before Rust 1.96.0 are affected.

Acknowledgements

We'd like to thank Christos Papakonstantinou for reporting this to us according to the Rust security policy.

We also want to thank the members of the Rust project who helped us address the vulnerability: Josh Triplett for developing the fix; Arlo Siemsen for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure; Ed Page and Eric Huss for advising during the disclosure.

show more
Python 3.15.0 alpha 7
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/03/python-3150-alpha-7/
Published: 2026-03-10 00:00:00 | Created: 2026-07-23 05:23:40
The penultimate 3.15 alpha is out!
show more
Does “rtk” skill really cut agent tokens by 60–90%? We tested it
Feed: The JetBrains Blog (https://blog.jetbrains.com/feed/)
Link: https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/
Published: 2026-07-20 10:11:44 | Created: 2026-07-23 05:23:40

Does “rtk” reduce Claude Code token usage?

Part 2 of a series where we take public “token saving” add-ons for coding agents and run the same paired A/B benchmark against each of them. Part 1 was the caveman skill (advertised −65%, measured −8.5%).

TL;DR: rtk advertised saving: 60–90%. Measured on real agent work: +7.6% more expensive at low reasoning effort (p=0.004), ±0% at high effort. Setup: Claude Code 2.1.201 · claude-sonnet-5 low and high efforts · SkillsBench. Task quality: unchanged in both arms, at both effort levels.

Why we ran this

rtk (“Rust Token Killer”) is a CLI proxy with a simple, appealing pitch: your agent runs git status, rtk intercepts it, runs the real command, and hands the model a compressed version of the output — * master / M a.txt / ?? b.txt instead of eleven lines of porcelain. A Claude Code PreToolUse hook rewrites eligible shell commands transparently, so the model doesn’t even have to know rtk exists. The README promises 60–90% less token consumption and walks through a 30-minute session where 118k tokens of command output become 24k.

The compression itself is real and often tasteful. Here is rtk on a live repo, captured from our test container:

# git status                              # rtk git status
On branch master                          * master
Changes not staged for commit:             M a.txt
  (use "git add <file>..." to update…)   ?? b.txt
	modified:   a.txt
Untracked files:
  (use "git add <file>..." to include…)
	b.txt
no changes added to commit …

# python -m pytest  (19 lines)            # rtk pytest
…full pytest output…                      Pytest: 2 passed, 1 failed
                                          Failures:
                                          1. [FAIL] test_fail
                                               test_demo.py:3: in test_fail
                                               E  AssertionError: one is not two

We liked the idea enough to test it properly. Two questions the README doesn’t answer:

First, how much of a real agent session is Bash output at all? The savings table assumes the agent shells out for everything. But Claude Code reads files with its built-in Read tool, searches with Grep, and both bypass the Bash hook completely (rtk’s docs acknowledge this). Whatever those tools carry, rtk can never touch.

Second, does compression cost correctness? A filter that summarizes test output is making an editorial judgment about what the model needs. If it drops the one line that mattered, the agent re-runs commands, reads files raw, or, worse, declares victory on a failing build. Token savings that come with a quality tax are not savings.

Setup

HarnessHarbor 0.18 – Docker sandboxes, task verifiers, paired runs
AgentClaude Code 2.1.201, headless, bypassPermissions, pinned in both arms
Modelclaude-sonnet-5 – full run twice: at low and at high reasoning effort
BenchmarkSkillsBench, 86 of 87 tasks, auto-graded 0–1 with partial credit
Arm Astock Claude Code
Arm Brtk v0.43.0 exactly as rtk init -g ships it: binary + PreToolUse hook + RTK.md
Volume4 paired runs (10-task smoke, same 10 at k=3, full 86 at low effort, full 86 at high effort) total of 425 billed trials, ≈USD 320 (Harbor-recorded USD 317 plus reconstructed subagent spend)

Because the hook rewrites every eligible Bash call mechanically, arm B measures rtk’s as-shipped ceiling: no “did the model remember to use it” gap to argue about. Every with-rtk trial also persists rtk’s own audit log and analytics database, as proof the treatment actually fired.

Finding 1: Most agent bytes never touch the hook

Before spending anything we replayed 83 existing baseline transcripts (same model, same benchmark) and asked: if rtk had been installed, what could it even have touched?

Two structural reasons. First, Claude Code reads files with its built-in Read/Grep tools, which bypass the Bash hook entirely; rtk’s own README admits this in a footnote. Second, half of what agents run in a shell is python3 … and other uncovered commands, and a sixth uses pipes-to-files, heredocs and substitutions that rtk deliberately refuses to rewrite. What’s left, 33% of Bash calls, carries just under 20% of tool-result chars; and tool results are themselves only a slice of what a session bills as input, because the same context is re-read on every turn. Squeeze rtk’s whole share by 70% and the cap works out to ≈3% of input tokens. This number cost nothing to compute, and it predicted the outcome.

Finding 2: No token savings; but a small, significant cost increase

We ran the ladder the caveman eval taught us to run. The k=1 smoke on ten deliberately Bash-heavy tasks (rtk’s best case) showed the rtk arm a median +35% more expensive. Alarming, until you know that identical attempts of the same task in the same arm differ by a median 22% in cost anyway. At k=3 most of the scare evaporated into noise (Wilcoxon p≈0.65), exactly as a k=1 mirage should.

Then the full 86 tasks gave the noise-resistant answer, and it wasn’t zero. Across 80 clean pairs the with-rtk arm came out a median +7.6% more expensive per task (p=0.004, after correcting a cost-accounting gap we found along the way), on +13.8% more turns (p=0.03) and +14.3% more cache reads (p=0.008). Meanwhile “new input”; the only token class rtk actually compresses, moved just +3.2% (p=0.23): a flat null precisely where the ceiling analysis said the entire benefit had to live.

The more commands the hook rewrote, the larger the penalty. On the same corrected cost basis as the headline result, heavily exposed task pairs cost about 24% more than baseline, versus 5% for pairs the hook barely touched. Controlling for task difficulty did not reproduce this pattern, so harder tasks using more Bash does not appear to explain it. Transcript forensics found no single villain: one genuinely broken rewrite (compound find predicates turned into usage errors and retries), a few compression-induced re-reads, and a lot of ordinary variance on the extreme pairs. A thin, systematic tax rather than a dramatic failure.

Finding 3: At high effort, even the penalty disappears

“You only tested at low reasoning effort” was the obvious critique, so we ran all 86 tasks again at high effort – the most expensive single run of the series. Result: the cost penalty does not replicate there. Median paired delta +0.1% (p=0.99), turns +0.0 (p=0.74), quality still tied. At high effort, the model seems to waste fewer turns reacting to compressed output; though at k=1 all we can say is that the penalty didn’t show up there, not that the two effort regimes probably differ. Either way, at no point did rtk save anything.

Finding 4: Quality survives

The scary failure modes from rtk’s issue tracker including over-filtered test output, masked exit codes, pipes fed compressed text, they barely materialized. A forensic pass over the six smoke pairs with the biggest turn deltas found exactly one broken rewrite (the same compound-find failure mode the full run hit) and one case of the agent deliberately bypassing the hook, across ~150 Bash calls. In those transcripts no recovery files were read and no compressed pipe produced a wrong count (the full runs saw exactly one recovery-file read); the extra turns were overwhelmingly the model choosing different solution paths, not rtk confusion. On the full runs, task scores landed at 5 better / 4 worse / 71 tie at low effort and 5 / 4 / 62 at high (sign test p=1.0 both); showing the arms are statistically indistinguishable on quality, with partial credit counted.

One honest asterisk: on one task (dialogue-parser) rtk’s own binary refused to start inside the task’s image (it needs a newer glibc), so the with-rtk trial died at setup in both full runs while the plain arm scored 0.667. Paired analysis excludes that task from both arms, but it’s a real compatibility failure, not Docker noise. Even scoring every errored trial as zero, the arms stay tied (sign test p=1.0).

Finding 5: rtk’s own scoreboard vs the bill

This is the finding that explains the gap. Across the low-effort full run, rtk’s built-in analytics (rtk gain) reported 96.2 million tokens saved — 99.8% of everything it touched; while the measured bill for the same trials went up. Three mechanisms make the scoreboard read high:

First, rtk counts the full raw output as its counterfactual. One cat of a 1.2 MB CSV logged 320k tokens “saved”, but Claude Code truncates any tool result long before 320k tokens; so the agent would have received a few thousand either way. The full run logged 190 of such giant reads at an average of ~506k “saved” tokens each. Second, rtk estimates tokens as chars÷4 at the moment of execution, while most of a session’s input cost is cached re-reads billed at a tenth of the price. Third, the hook simply never sees the majority of context. The scoreboard is grading its own homework.

Verdict

Honest engineering, wrong counterfactual. We wanted this one to win; the demo is genuinely satisfying to play with. The filters are real and often elegant; quality doesn’t suffer; the hook mechanism works exactly as designed. But on real agentic coding work the advertised 60–90% never had anywhere to live: the hook only ever sees about a fifth of the tool output, Claude Code already truncates the pathological outputs rtk brags about compressing, and the cached re-reads that dominate input cost bill at a tenth of the price. What’s left is a measured median +7.6% cost increase at low effort and a flat zero at high effort, a thin tax from a broken rewrite here and an extra exploration turn there, never a saving.

The deeper lesson generalizes beyond rtk: a tool’s self-reported savings are a claim about its counterfactual, not about your bill. rtk’s scoreboard said 96 million tokens saved while the invoice went up. If you evaluate any context-compression tool, measure the paired bill, not the tool’s diff.

Methodology notes

Same discipline as part 1, learned the expensive way:

  • Never trust k=1. The run ladder was: free transcript replay → 1-trial wiring check → 10 Bash-heavy tasks at k=1 → the same 10 at k=3 → the full 86 at k=1, twice (low and high effort). Per-task scores flip freely between attempts in both arms; only paired deltas that survive the ladder get reported.
  • Paired analysis only. Every number compares the same task across arms under the same job; tasks that errored in either arm are excluded from both. Quality uses an exact sign test over non-ties; token/cost deltas use per-task medians plus Wilcoxon signed-rank, because arm totals are outlier-dominated, a single session crossing the 200k long-context pricing tier can bill 25× normal and flip a raw total.
  • Endpoints pre-registered. Primary: per-task paired delta in cost and in “new input” tokens (uncached + cache-creation; where compressed tool results actually land). Decided before any paid run, along with the adoption-stratified split.
  • Adoption instrumented, not assumed. Every with-rtk trial persists rtk’s hook audit log and its history.db, so we can prove per-trial that rewrites fired and executed – and distinguish “rtk saved nothing” from “rtk never ran,” which are very different findings. Depending on the run, the hook rewrote a third to a half of the Bash calls it saw (33–50%, after discounting our own per-trial wiring check); the model itself typed rtk six times in 86 trials.
  • Provenance. rtk v0.43.0 release binary (sha256-pinned), Claude Code 2.1.201 pinned in both arms, claude-sonnet-5, Harbor 0.18, SkillsBench with bike-rebalance excluded (its allow_internet=false crashes local Docker jobs). rtk, Harbor and SkillsBench are all Apache-2.0.

Next in the series: drop a tool name and we’ll put it on the ladder. Few word enough. We test.

P.S. The dithered chart style in this post is borrowed with admiration from dither-kit by grim — reimplemented from scratch as a dependency-free inline widget.

show more
Python 3.15's JIT is now back on track
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/03/jit-on-track/
Published: 2026-03-23 00:00:00 | Created: 2026-07-23 05:23:40
A look at Python's JIT in 3.15a7.
show more
Escape Analysis in Go – Stack vs. Heap Allocations Explained
Feed: The JetBrains Blog (https://blog.jetbrains.com/feed/)
Link: https://blog.jetbrains.com/go/2026/07/20/escape-analysis/
Published: 2026-07-20 10:15:24 | Created: 2026-07-23 05:23:40

One of the design choices Google made when developing Go was to abstract memory management away from developers so they could focus on what really matters – writing code. Things like escape analysis and garbage collection are thus automatic, and the Go compiler works in almost mystical ways.

That’s one of the best features of Go, so long as your program works. But when memory issues arise, and you need to demystify the process to optimize it, that’s when the perspective shifts and the mystery is no longer so appealing.

In this article, we’ll explain one of the most confusing performance optimization problems – escape analysis, i.e. how the compiler decides what stays on the stack, and what moves to the heap. We’ll cover what escape analysis is and how it works, what the most common escape cases are and how to inspect them, why inspections might be hard to use, and even how GoLand can perhaps help with that.

What is escape analysis in Go?

Escape analysis is a compiler optimization that determines whether a value can be allocated on the stack or must be moved to the heap. In other words, in Golang, the escape analysis process inspects every value your program creates to answer the question: Can this safely live on the stack, or does something outside the current function still need it after the function returns (and therefore it needs to live on the heap)?

The stack is a per-goroutine region where allocations are significantly cheaper and reclaimed automatically when a function returns, so storage happens fast but is short-lived. The heap is a shared, longer-lived memory space that the garbage collector must track and clean up, so it’s more resource-intensive. Escape analysis is the bridge between the two.

A value is said to “escape” when the compiler can’t prove that it’s done being used by the time the function exits, as explained in the Go documentation. For each value, it asks whether any reference to that value can outlive the function that created it. If the answer is no, the value stays on the stack. If the answer is yes – or if the compiler simply can’t prove the answer is no – the value is allocated on the heap to be safe. The classic example is returning a pointer to a local variable – the function ends, but a reference to that variable lives on, so the value can’t sit on the stack frame that’s about to be discarded. It escapes to the heap instead.

It’s worth pointing out here that escape decisions are not set in stone. They can change depending on how you structure your code, the Go version you’re compiling with, as well as on the environment (OS/architecture), compiler settings, and other optimization decisions like inlining. That’s why you can’t assume a value will or will not always escape in a given context – you need to check every time.

And why should I care?

Unlike in some other languages, in Go you don’t manually choose between stack and heap allocation the way you might with malloc and free in C. Instead, the compiler makes the call. Go also manages memory safety for you, so as to prevent escaped values from being unsafe.

Many developers stop there and never bother with escape analysis. After all, the documentation says that “you don’t need to know”, and if it works, it works, right?

Having said that, you do still have agency and can write code in ways that influence these compiler decisions – in a good way or indeed in a bad way. That’s why an understanding of escape analysis is actually a must-have skill for any Go developer.

Common reasons values escape to the heap

Most of the time, when a value escapes to the heap, it’s for one of a handful of recurring reasons. Recognizing these patterns helps you read compiler output faster and tells you whether a given allocation needs investigation or is simply the best way to run your code. 

It’s important to note that not every escape is a problem – programs with any degree of complexity will inevitably have things living on the heap. The goal here is to recognize the patterns, not to eliminate them all.

Returning pointers

Returning a pointer to a local value is probably the most common cause of an escape. The value is created inside the function, but the caller holds onto a reference after the function returns, so it can’t live on the stack frame that’s being torn down.

func NewUser(name string) *User {
    u := User{Name: name} // u escapes to the heap
    return &u
}

This is safe in Go – the compiler notices that &u outlives NewUser and moves the value to the heap automatically. Whether you should care depends on context. Returning pointers is idiomatic and often the right call for API clarity and readability. The right choice depends on your API design and measured performance impact, not on a blanket rule about avoiding pointers.

Closures and goroutines

Captured variables will escape when a closure or goroutine may outlive the function that created them. The compiler has to assume the captured value is still reachable, so it allocates it on the heap.

func process(data []byte) {
    go func() {
        handle(data) // data may escape: the goroutine can outlive the process
    }()
}

Goroutines are a frequent source of confusion here, precisely because they can keep running after the parent function has returned. From the compiler’s point of view, anything the goroutine touches might be needed indefinitely, so it plays it safe.

Interfaces and dynamic values

Passing a concrete value through an interface can sometimes lead to a heap allocation. This most often occurs in formatting, logging, and interface-based APIs, where values are boxed into an interface{} (any) before they are handled.

func logValue(v int) {
    fmt.Println(v) // v is passed as an interface and may escape
}

However, interface use does not automatically cause heap allocation. Plenty of interface calls don’t allocate at all, and the compiler keeps getting better at this. Treat interfaces as something to check rather than avoid entirely.

Slices, maps, and structs

Values can escape when they’re stored inside a data structure that outlives the current function. If you put a pointer into a map, a slice, or a struct field, and that container lives longer than the function, the stored value has to live just as long.

type Cache struct {
    items map[string]*Item
}

func (c *Cache) Add(key string, it *Item) {
    c.items[key] = it // it escapes: stored in a structure that outlives the call
}

The relationship between the container and the value it holds is crucial here. A slice that never leaves the function may keep its contents on the stack; the same slice returned to a caller or stored in a long-lived struct will push its contents to the heap.

How to check escape analysis in Go

The good news is you don’t really need to remember any common reasons for escapes or guess whether a value escaped or not in a particular instant. The Go compiler flags can tell you that, and in fact, inspecting the compiler’s output is the only reliable way to know what’s happening for sure.

The log covers more than just escapes, though. Alongside allocation decisions, the compiler reports inlining details and other diagnostics, so you get a fairly complete picture of the optimization choices it made for a given build. The downside is that the output isn’t precisely user-friendly or easy to navigate, but we will come back to that later.

How to use compiler flags

The Go compiler surfaces escape analysis information through the -gcflags debug flag with the -m option:

go build -gcflags="-m" ./...

The -m flag asks the compiler to print its optimization decisions, including whether a value escaped. The output looks roughly like this:

./user.go:6:2: moved to heap: u
./user.go:7:9: &u escapes to heap

You can pass -m twice (-gcflags="-m -m") for more detailed reasoning, though that quickly becomes verbose. There are more flag variations, but -gcflags="-m" is the one you’ll probably reach for most.

As you can see, the output is keyed by file, line, and column, and escape analysis can be buried among other comments. This means the real work is mapping each message back to the relevant source code so you can understand it in context.

Why it’s hard to work with escape analysis logs

While compiler flags are the only way to reliably see what decisions the compiler made, they are arguably not the most ergonomic one. The report may be perfectly readable when you work with a small file, but in larger projects and with daily use, it can quickly become frustrating. No wonder then that it’s a heavily underutilized feature of the Go SDK.

A few common pain points have come up in our discussions with Go developers:

  • The output is noisy – a real build prints escape decisions, inlining notes, and other diagnostics all in one place, and most of it isn’t what they’re looking for at the moment.
  • Messages are hard to connect to the source – each line is tagged with a file, line, and column, but they still have to open that file and find the right spot.
  • They have to constantly switch context – reading a message in the terminal, then jumping to the editor to see the code, then back again. This disrupts their concentration and slows the investigation.
  • Not every escaping value is worth optimizing, but the output treats every allocation equally. Meanwhile, most of them don’t matter for performance, and it’s hard to separate signal from noise.

None of this makes command-line escape analysis bad. It’s a genuinely powerful diagnostic that’s just not always convenient, especially when you’re trying to answer a focused question inside a large codebase. Because escape analysis has been locked behind obscure compiler flags and hard-to-parse logs, it’s become a niche practice even among experienced Go developers. That’s why our GoLand team has designed a tool that lowers the barrier to entry and bridges the gap between “powerful” and “convenient”.

How GoLand helps with escape analysis

The GoLand escape analysis support that arrived in the 2026.2 release was built to address the pain points we’d heard from developers. Under the hood, the tool largely does what you would do manually, running the go build command with the -gcflags="-m -m" flag. (To be precise, GoLand runs -gcflags="-m=2 -json=0,<path>", since we found that storing logs in JSON format provides a more structured and stable output).

But the tool now also adds a layer that parses that raw gcflags output and brings it directly into the editor, so you can stay close to your code while investigating allocation decisions instead of bouncing between the terminal and your files.

Running the escape analysis tool

The workflow is pretty straightforward. You open the Go Optimization window, choose Escape analysis, pick a scope, and run it.

You can analyze a single file or a whole package – the file-scoped option is handy for tightly focused units of code, such as an individual AWS Lambda handler, where you only care about one function’s allocations.

You can also choose which message types to show (see: How to read escape messages) and set environment variables for the Go process before running. The most frequently used are compiler flags (goflags) – on top of the standard -m, you might also be interested in -N (disables compiler optimizations) and -l (disables function inlining). The values of the GOARCH and GOOS environment variables can also affect your output, as some compiler decisions are target-dependent and can affect inlining, allocation decisions, and the diagnostics reported by gcflags.

Working with the output

Once the analysis finishes, you’ll find the results where they’re most useful:

  • In the editor: Gutter markers with escape messages appear right next to the lines they describe. If several messages belong to one line, the marker will show you the count. Also, hovering over the gutter marker will show you the compiler message and the escape flow. Hovering over a function name will show the escape results for that function, so you no longer have to match line numbers by hand.
  • In Go Optimization tools: This tool window lists the results by file, function and/or category, and then message type. You can also filter the logs by message type to cut through the noise. Click on any result to jump straight to the corresponding line in the editor.
  • Views: By default, the Escape analysis tool shows the output as a parsed tree. If you prefer the unprocessed output from the compiler’s command, the console output view shows it raw. Even there, the lines are clickable and take you to the right place in your code.

Comparing files

After you make changes to your code, you can rerun the analysis and compare results in separate tabs to see whether the allocation actually moved off the heap. This is important for iterative work and making sure the changes you make actually move the needle. If you’re already used to profiling your programs, this is a natural extension of that process. And if not, you can read more on how to profile Go code with GoLand to get a more detailed picture.

How to read escape messages

The console messages are generic. The two you’ll see most often are escapes to heap and moved to heap. Both indicate that a value couldn’t stay on the stack. Others describe inlining and parameter behavior.

Treat these as the diagnostic signals that they are, not as refactoring instructions. A moved to heap message is just information about what the compiler did. Whether it’s worth acting on depends entirely on how that affects performance.

Here are the message types that the GoLand tool surfaces and what they mean – they map directly to the compiler reports:

MessageWhat it means
Escape to HeapA value must be allocated on the heap because it’s still needed after the function returns.
Moved to HeapThe compiler couldn’t guarantee the value is no longer needed after the function returned, so it allocated it on the heap.
Leak ParamA function parameter escapes the current function and may need to stay valid after it returns.
Can InlineA function is small and simple enough that the compiler can (but doesn’t have to) replace calls to it with its body.
Inlining CallThe compiler actually inlined a specific call.
OtherAdditional compiler diagnostics related to escape and optimization decisions.

To read more about this and see examples, go to the GoLand documentation.

Escape analysis and performance

Escape analysis matters for performance because heap allocations aren’t free. Every value on the heap generates more work for the garbage collector to track and reclaim, and the allocation itself carries overhead that stack allocation doesn’t. If you reduce unnecessary heap allocations on a hot path, you can potentially meaningfully cut both GC pressure and latency.

That said, heap allocation is normal and frequently necessary in Go. Plenty of values should live on the heap, and trying to force everything onto the stack is a losing game that hurts your code’s readability for little to no gain. Escape analysis is most valuable in specific places: hot paths, tight loops, high-throughput services, serialization and deserialization code, and latency-sensitive workflows. Outside those areas, an escaping value is usually just an escaping value. In other words, the old adage about premature optimization applies to escape analysis like nowhere else, and you should only focus on the proverbial 3%.

The single most important habit is to measure. Escape analysis tells you what the compiler decided, but it doesn’t tell you whether that decision is hurting you – only benchmarks and profiling can do that. Use escape analysis alongside benchmarks and profiling in Go, and always measure before and after a change to see whether it actually helped. Escape analysis is one performance input, not a complete strategy on its own, and not every escaping value is worth a developer’s time.

Best practices for working with escape analysis

Finally, here’s a short, practical checklist for using escape analysis well in real projects:

  1. Start with measurement. Use profiling and benchmarks to find allocations that actually matter before you open the escape analysis logs. Don’t optimize unquestioningly.
  2. Focus on hot paths. Concentrate your attention on tight loops, high-throughput code, and latency-sensitive sections. Apart from these instances, escapes rarely justify the effort of avoiding them.
  3. Understand why the value escaped. Read the compiler message and the escape flow so you’re fixing the cause, not the symptom.
  4. Avoid unnecessary micro-optimizations. Treat heap allocation as a signal worth examining, not as an automatic bug to be eliminated.
  5. Protect readability and design. Don’t contort an API or sacrifice clarity to shave an allocation that doesn’t show up in your benchmarks. Maintainable code always wins over clever code.
  6. Verify your changes. Rerun the analysis and re-measure to confirm that a change did what you intended.

You may also be interested in Go’s official Guide to the Go Garbage Collector, which has an optimization guide for the entire GC, including how to eliminate heap allocations with escape analysis.

FAQ

Does escape analysis improve Go app performance?

Yes and no. When speaking of escape analysis as a part of the compilation process, it was designed to ensure optimal performance by prioritizing fast allocation and reducing garbage collection pressure, both of which improve your app’s performance.

However, as a developer tool, escape analysis is just a diagnostic, not an optimization that you turn on. What can improve performance is using its output to spot avoidable heap allocations on hot paths and adjusting your code accordingly. With code that isn’t performance-critical, acting on escape results usually changes nothing measurable.

Is escape analysis the same as profiling?

No. Profiling tells you where your program spends time or memory at runtime. Escape analysis is a compile-time snapshot of where values are allocated and why. They’re complementary: Profiling tells you where to look, and escape analysis helps you understand why the allocations are occurring in those locations.

Can the results of an escape analysis change between Go versions?

Yes. Escape decisions depend on the compiler, and the Go team improves its analysis and inlining over time, as they did in the 1.25 and 1.26 releases. A value that escapes in one Go version may stay on the stack when using another.

Should developers avoid pointers to reduce heap allocations?

Not as a rule. Returning or passing pointers can cause values to escape, but pointers are idiomatic and often the clearest choice. Avoiding them everywhere harms readability and can even hurt performance if large values have to be copied. Decide based on API design and measured impact, and use escape analysis to check rather than to enforce a blanket policy.

Do interfaces always cause values to escape?

No. Passing values through interfaces can contribute to heap allocation in some cases – often around formatting and logging – but it doesn’t always, and the compiler keeps getting better at avoiding it. Interface boundaries are worth keeping an eye on in the compiler output, but they’re not a guaranteed source of escapes.

When should I care about Go escape analysis?

When you have a performance-sensitive path and evidence that allocations are part of the problem. If profiling points to allocation pressure in a hot loop, a high-throughput service, or serialization code, escape analysis helps you understand and address it. For everyday code that meets its performance goals, you can let the compiler do its job and move on as Go intended.

show more
Announcing Rust 1.96.0
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/05/28/Rust-1.96.0/
Published: 2026-05-28 00:00:00 | Created: 2026-07-23 05:23:40

The Rust team is happy to announce a new version of Rust, 1.96.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.96.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.96.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.96.0 stable

New Range* types

Many users expect Range and related core::ops types to be Copy, but this is not the case: they implement Iterator directly, and it is a footgun to implement both Iterator and Copy on the same type so this has been avoided. RFC3550 proposed a set of replacement range types that implement IntoIterator rather than Iterator, meaning they can also be Copy. The standard library portion of that RFC is now stable, introducing:

  • core::range::Range
  • core::range::RangeFrom
  • core::range::RangeInclusive
  • Associated iterators

A Rust version in the near future will also add core::range::RangeFull and core::range::RangeTo as re-exports from core::ops (these do not implement Iterator and already implement Copy), and core::range::legacy::* as the new home for the current ranges. Range syntax like 0..1 still produces the legacy types for now, but will be updated to core::range types in a future edition.

With these stabilizations, it is now possible to store slice accessors in Copy types without splitting start and end:

use core::range::Range;

#[derive(Clone, Copy)]
pub struct Span(Range<usize>);

impl Span {
    pub fn of(self, s: &str) -> &str {
        &s[self.0]
    }
}

The new RangeInclusive also makes its fields public, unlike the legacy version which avoided exposing the exhausted iterator state. This isn't a concern with the new type since it must be converted to begin iteration.

Library authors should consider making use of impl RangeBounds in public API, which accepts both legacy and new range types. If a concrete type is needed, prefer using new ranges as this will eventually become the default.

Assert matching patterns

The new macros assert_matches! and debug_assert_matches! check that a value matches a given pattern, panicking with a Debug representation of the value otherwise. These are essentially the same as assert!(matches!(..)) and debug_assert!(matches!(..)), but the printed value improves the possibility of diagnosing the failure.

These new macros have not been added to the standard prelude, because they would collide with popular third-party crates that provide macros with the same name. Instead, they should be manually imported from core or std before use.

use core::assert_matches;

/// [Random Number](https://xkcd.com/221/)
fn get_random_number() -> u32 {
    // chosen by a fair dice roll.
    // guaranteed to be random.
    4
}

fn main() {
    assert_matches!(get_random_number(), 1..=6);
}

Changes to WebAssembly targets

WebAssembly targets no longer pass --allow-undefined to the linker which means that undefined symbols when linking are now a linker error instead of being converted to WebAssembly imports from the "env" module. This change prevents modules from linking unless all linking-related symbols are defined to catch bugs earlier and prevent accidental issues with symbol naming or similar.

Undefined linking-related symbols are often indicative of build-time related bugs or misconfiguration. If, however, the old behavior is intended then it can be re-enabled with RUSTFLAGS=-Clink-arg=--allow-undefined or by editing the source code and using #[link(wasm_import_module = "env")] on the block defining the symbol.

This change was previously announced on this blog, and now takes effect in Rust 1.96.

Stabilized APIs

Two Cargo advisories

Rust 1.96 contains fixes for two vulnerabilities for users of third-party registries.

  • CVE-2026-5223 is a medium severity vulnerability regarding extraction of crate tarballs with symlinks.

  • CVE-2026-5222 is a low severity vulnerability regarding authentication with normalized URLs.

Users of crates.io are not affected by either vulnerability.

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.96.0

Many people came together to create Rust 1.96.0. We couldn't have done it without all of you. Thanks!

show more
Python 3.15.0a8, 3.14.4 and 3.13.13 are out!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/04/python-3150a8-3144-31313/
Published: 2026-04-07 00:00:00 | Created: 2026-07-23 05:23:40
A final alpha and two bug fixes are awaiting your upgrade.
show more
Rust for CPython Progress Update April 2026
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/04/rust-for-cpython-2026-04/
Published: 2026-04-08 00:00:00 | Created: 2026-07-23 05:23:40
Rust for CPython project status update April 2026
show more
Python 3.14.5 release candidate
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/05/python-3145rc1/
Published: 2026-05-04 00:00:00 | Created: 2026-07-23 05:23:40
A special release candidate with a new (old) garbage collector.
show more
Busy Plugin Developers Newsletter – Q2 2026
Feed: The JetBrains Blog (https://blog.jetbrains.com/feed/)
Link: https://blog.jetbrains.com/platform/2026/07/busy-plugin-developers-newsletter-q2-2026/
Published: 2026-07-21 13:22:14 | Created: 2026-07-23 05:23:40

Your quarterly dose of plugin dev news, tools, and tips from JetBrains

🧩 Marketplace Updates

Internal API Usage Notifications

To support the ongoing IntelliJ Platform API stabilization, JetBrains Marketplace now automatically notifies plugin authors when their plugins use internal APIs. This gives authors an opportunity to review and replace unsupported APIs before they affect plugin compatibility.

Exceptions Tab Available by Default

Access to the Exceptions tab is now enabled automatically for all plugin authors, no need to request access anymore. Use the Exception Analyzer to track production exceptions, diagnose issues faster, and improve plugin stability.
Learn more about the Exception Analyzer →

🔧 Plugin Development Tooling Updates

IntelliJ Platform Plugin Template 2.6.0

Repository that simplifies the initial stages of plugin development for IntelliJ-based IDEs. 

  • Updated to org.jetbrains.intellij.platform 2.16.0, IntelliJ IDEA 2025.2.6.2, and Gradle 9.5.0.
  • Simplified project configuration by removing settings and changelog configuration now handled automatically by the IntelliJ Platform Gradle Plugin.
  • Streamlined GitHub Actions workflows with updated actions and simplified plugin artifact upload.
  • Cleaned up the template by removing outdated UI testing workflow and fixing the Run Plugin sandbox log path.

View Changelog →

IntelliJ Plugin Verifier 1.409

Tool that checks binary compatibility between IntelliJ-based IDE builds and plugins. 

  • Reduced memory usage and improved performance for batch verification, report generation, and compatibility checks.
  • Improved HTML report rendering with faster processing and parallel per-plugin generation.
  • Restored Windows compatibility by fixing ZIP file handling.
  • Updated Kotlin ecosystem libraries and key dependencies, including ASM, Jackson, ByteBuddy, and Bouncy Castle.

View Changelog →

IntelliJ Platform Gradle Plugin 2.18.1

Plugin that helps configure your environment for building, testing, verifying, and publishing plugins for IntelliJ-based IDEs. 

Highlights from the 2.18.x release series:

  • Added support for product-specific IDE Starter dependencies and new options to customize the test IDE classpath.
  • Improved product release handling for IDE selection and plugin verification.
  • Enhanced TestIdeTask with more accurate bundled plugin resolution and better configuration cache support.
  • Excluded bundled translation plugins from the test classpath and fixed GrammarKit cleanup behavior.

View Changelog →

💡 Tip of the Quarter

Optimize Distribution Size

Users with poor internet may cancel long downloads. Reuse platform utilities and bundled libraries, eliminate duplicate dependencies, optimize assets, and consider downloading large resources on-demand rather than bundling them.

📚 Resources & Learning

📖 Blog

Make Your Plugin Remote Development-Ready

Remote development is reshaping plugin development for JetBrains IDEs. With client-server architecture, plugin authors need to rethink how and where their code runs. In this post, we share resources to help you build plugins that work in both remote and local environments.
Read  →

The Road to Responsive IntelliJ-Based IDEs

Discover the multi-year effort to improve UI responsiveness in IntelliJ-based IDEs. Learn how new APIs and architectural changes are moving performance-sensitive work off the UI thread to deliver a smoother developer experience.
Read →

Improving Accessibility in JetBrains IDEs: What’s New and What’s Next in 2026

Explore the latest accessibility improvements in JetBrains IDEs, from better support for screen readers and magnifiers to enhanced keyboard navigation and new audio feedback features.
Read →

Async VFS Content Writes – What Plugin Authors Need to Know

If your plugin saves files through VFS and then hands them off to a CLI, formatter, VCS command, or Java file API, this update is for you. Learn when to flush pending VFS writes to ensure external tools see the latest file content.
Read →

Structuring IntelliJ Plugins with Optional Content Modules

Need your plugin to adapt to different IDE editions or features? Discover how optional content modules help you keep functionality modular and available only when needed.
Read →

The Dev Containers Story: Introducing EelApi for Plugin Authors

Modern development environments are changing how plugins interact with files, processes, and paths. Learn how the new EelApi helps your plugin work seamlessly across local projects, WSL, and Dev Containers.
Read →

Open-Sourcing the LSP Client API in IntelliJ IDEA 2026.2

The IntelliJ Platform LSP client is becoming open source, making the same battle-tested API available across JetBrains IDEs, Android Studio, and other IntelliJ-based products. Learn what this means for your plugins.
Read →

 🛠 IntelliJ Platform Plugin SDK

Error Reporting

Improve plugin diagnostics with the IntelliJ Platform’s error reporting APIs. Learn how to implement custom reporting flows, automatic exception collection, and UI freeze reporting.
Read →

⭐ Community Spotlight

Gradle Setup Powering Multi-module IntelliJ Plugins

Róbert Novotný demonstrates how to build modular IntelliJ plugins with Gradle, from organizing content modules and shared code to adding optional functionality with the IntelliJ Platform Gradle Plugin.

Stop Pasting Tokens: OAuth2 for JetBrains IDE Plugins

Learn how to implement a browser-based OAuth2 login flow for JetBrains IDE plugins. In this video, Jakub Chrzanowski demonstrates secure authentication with PKCE and storing access tokens in PasswordSafe.

Until next time — happy coding!
JetBrains Marketplace team

show more
Code isn’t the only thing causing your production failures
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/06/25/code-isnt-causing-your-production-failures/
Published: 2026-06-25 07:40:00 | Created: 2026-07-23 05:23:40
Ryan sits down with Anish Agarwal, CEO and co-founder of Traversal, to chat about why AI coding agents have made writing code easier but running it safely in production harder, why production failures are really caused by interactions between systems and not just the code itself, and how teams can troubleshoot more effectively when traditional observability tools are not enough for agentic AI workflows.
show more
Python 3.15.0 beta 1 is here!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/05/python-3150-beta-1/
Published: 2026-05-07 00:00:00 | Created: 2026-07-23 05:23:40
The propreantepenultimate 3.15 beta is out!
show more
Paging Charity! How can engineering leaders avoid becoming Bond villains?
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/06/26/paging-charity-how-can-engineering-leaders-avoid-becoming-bond-villains/
Published: 2026-06-26 14:00:27 | Created: 2026-07-23 05:23:40
If you want your values to spread throughout the industry, the best thing you can possibly do is succeed and make others want to imitate you.
show more
Launching the Rust Foundation Maintainers Fund
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/06/02/launching-the-rust-foundation-maintainers-fund/
Published: 2026-06-02 00:00:00 | Created: 2026-07-23 05:23:40

If you want to financially support the development of Rust, please consider donating to the Rust Foundation Maintainers Fund.

A few months ago, the Rust Foundation announced the Rust Foundation Maintainers Fund (RFMF). Since then, the Rust Project has been closely cooperating with the Rust Foundation to determine how exactly this fund will be used to support Rust maintainers. This resulted in the acceptance of RFC #3931, which established the Funding team and the Maintainer in Residence program.

The primary goal of the Funding team is to ensure that maintainers who work on Rust and its toolchain will be properly supported. We will talk to Rust Project members to figure out their funding situation, meet Rust team leads to learn about their maintenance needs, approach companies to find opportunities for them to invest into Rust by supporting Rust maintainers, coordinate various funding efforts and ensure that the beneficial effects of funded maintenance are visibly promoted, with the help of the Content team.

Maintainer in Residence is a new program dedicated to financially supporting existing Rust Project maintainers1. Each Maintainer in Residence will be funded to maintain one or more critical parts of Rust, such as the compiler, the standard library, Cargo, Clippy or one of many other projects that the Rust Project develops and maintains. The funded work will include activities such as performing large-scale refactorings, code reviews, unblocking new features, issue triaging, mentoring other contributors and more, and will be split between priorities guided by the teams they are supporting and priorities of their own choosing within the Project. Where applicable, Maintainers in Residence are also encouraged to propose, champion, and drive forward Rust Project Goals.

The goal of this program is to provide stable and long-term funding so that maintainers can focus on important work that ensures the long-term health of Rust. The funding team will select Maintainers in Residence based on funding availability and maintenance needs within the Rust Project, and help ensure that they are successful. We expect that this will usually be a (near) full-time position, but that will depend on the nature of the work and the area of maintenance.

This program extends our existing support for Rust maintainers, such as the program management program and the compiler-ops program. An important development is that we now have a centralized mechanism for gathering donations from both individuals and companies, and a dedicated team that will help direct those funds to specific maintainers. You can find more details about the funding team and the Maintainer in Residence program in the RFC.

We expect to hire the first Maintainer in Residence in the upcoming months and announce it on this blog, so stay tuned!

How to contribute funds

If you are an individual who wants to help Rust succeed and thrive, you can donate to the RFMF through GitHub Sponsors2. Companies who would like to invest in better maintenance of Rust can also donate through GitHub Sponsors or they can contact the Rust Foundation directly.

The important thing is that all proceeds from this fund will be directly used to support Rust Project maintainers. We currently expect that to happen primarily through the Maintainer in Residence program, but it can also be done in the form of smaller-scale grants or other mechanisms, as determined by the Funding team. We will figure this out on the go, as this is also quite new for us.

We really appreciate each donation, however small, because with more money we can hire more maintainers to ensure that we can continue to develop Rust and that important improvements are not blocked on maintenance tasks. This is especially important at this time, where Rust is starting to get used more and more in the industry in various application areas, which increases the need for sustained maintenance. The importance of multiple funding sources is underscored by an unfortunate trend we currently observe, where key Rust maintainers are losing their funding for Rust work due to budget shifts. The Rust Foundation Maintainers Fund is designed to provide stable funding for Rust maintainers that is less dependent on sudden shifts in the job market and the IT industry.

As with most things, there is no one-size-fits-all solution, so there are multiple ways to support Rust financially. The RustNL Maintainers Team recently hired several Rust Project maintainers. Previously, we wrote about how you can support specific individuals working on Rust. And there are also Rust Project Goals in search of funding. We welcome all efforts that can help support Rust Project maintainers, who often do work that is near invisible and thankless, while at the same time incredibly important and necessary, on a volunteer basis.

Thank you for considering sponsoring the development and maintenance of Rust! You can find more information about funding Rust on our Funding page.

  1. This program was inspired by the Developer in Residence concept used by the Python Software Foundation (PSF), with which we led several helpful discussions. Thank you, PSF! ↩

  2. Note that the fact that GitHub Sponsors is currently enabled on the rustfoundation GitHub organization, and not the rust-lang organization, is an implementation detail that might change in the future. All donations raised on this Sponsors page will be routed to the Rust Foundation Maintainers Fund and will be spent on directly supporting Rust Project maintainers. ↩

show more
Why intent prediction needs more than an LLM
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/06/30/why-intent-prediction-needs-more-than-an-llm/
Published: 2026-06-30 07:40:00 | Created: 2026-07-23 05:23:40
Ryan sits down with Frank Portman, CTO at Yobi, to talk about why next-token prediction, though great for language, isn’t the right inductive bias for forecasting human behavior. They discuss how Yobi builds a “foundation model of behavior” using transformers and graph neural networks instead of chat-style LLMs, and what it takes to run millions of personalization decisions per second while keeping consumer data private.
show more
The many journeys of learning Rust
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/06/25/vision-doc-journeys-to-learning-rust/
Published: 2026-06-25 00:00:00 | Created: 2026-07-23 05:23:40

This is another post in our series covering what we learned through the Vision Doc process. We previously described the overall approach and what we learned about doing user research, we explored what people love about Rust, dug into what it takes to ship safety-crticial Rust, and described some of the major challenges that people face when using Rust.

In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.

As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.

Many paths to needing Rust

The interviews surfaced several different paths into Rust: curiosity, embedded work, job-market pressure, organizational adoption, and reassignment after a team or company chose Rust. That last path matters because many learners are not evaluating Rust from a blank slate; they are trying to become productive after Rust has already arrived in their work.

"Funny enough, I've advocated for more niche languages than Rust in the past. Rust has pretty much stopped being as much of a niche language as it was, but it's not Java." -- Fractional CTO

Rust learning resources

Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.

"I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier

Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.

"The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant

"Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage

These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.

"We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry

Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.

Beginner stumblings and unlearning habits

It's pretty typical for Rust to be the 2nd, 3rd or Nth programming language that someone picks up. They'd end up writing their most familiar language in Rust, whether C++ patterns, Java patterns, or whatever they knew, for months or even years. Eventually they got comfortable enough to start writing idiomatic Rust.

"There's a bit of a drop in productivity compared to C if you're already familiar with it just because you're learning new rules, new syntax." -- Principal Firmware Engineer (mobile robotics)

"In the beginning it was more poking around the code and adding and removing some ampersands and asterisks to try to make sense of mut and not mut and whatever." -- Senior engineer with 20 years of Java experience in cloud and IoT

We also spoke with someone who found that not having much of a programming background seemed to benefit people picking up Rust. Not having worn-in grooves from other languages may play a role here, and it's worth investigating further.

"I had someone who had never programmed much before start working on the internals of [our Rust project]. She was just fine with getting into Rust. It's more of the senior people that struggle as they need to unlearn practices which may work in other languages, but it's not the 'Rust' way." -- Researcher, Automotive OEM R&D Lab

Learning to work with the borrow checker

We heard a lot about learning to work with the borrow checker instead of against it. People get there through different paths, but a few patterns came up repeatedly.

The compiler as teacher

Rust's diagnostics did the teaching on their own, especially around lifetimes.

"If you mess up the lifetimes in a piece of code that you've written by hand, I usually find that Rust's diagnostics are very helpful" -- Researcher working on static analysis of Rust programs

"Whatever's missing, the compiler usually fills in: it tells me 'you need to declare the lifetime of this reference', so I know and can figure it out. That all generally works pretty well." -- Senior Software Engineer

Learning by doing

Others felt like they only really internalized the borrow checker after writing a lot of Rust. It took projects, coding challenges, prototyping and so on until at some point it clicked.

"I actually did not understand the borrow checker until I spent a lot of time writing Rust" -- Founder of a startup built on Rust

"Besides the prototyping work, I also did coding-challenge-type stuff to get familiar with Rust for Advent of Code. [..] It eventually clicked to the point where I wasn't fighting with Rust, it was working for me. I had that experience other people describe: when I managed to get my program to fit with Rust, it worked. I didn't spend time debugging." -- Principal Software Engineer, large SaaS provider

Letting go of "clone guilt"

Some learners arrive with the assumption that good Rust means zero clones, zero copies, lifetimes threaded through everything. They set the bar at optimal before they've learned how to write idiomatic Rust, and it makes the borrow checker feel harder than it needs to be at the outset.

"On one of my first projects, I was like, 'I don't ever want to copy or clone anything,' so I carefully wove through all the lifetimes and got myself into a bit of a bind. Then I saw someone else just cloning the struct I was working with, and it was super cheap. Sometimes you can just clone and it's going to be okay." -- Researcher at a university

The experienced Rust developers we spoke with consistently said the same thing: clone freely while you're learning, then optimize when you understand the problem. Rust's reputation for performance and correctness feeds this. Newcomers assume anything less than optimal is wrong before they've written a first working program, and clone guilt is how that shows up.

We think it could be an interesting area of future study to check into the patterns Rust programmers employ at different levels of experience and under which circumstances. One member of the Rust Vision doc team that's very experienced with Rust noted that there's kind of an "expected shape" they understand as passing the compiler. This knowledge influences how they approach writing code which wouldn't take that shape and they naturally find themselves understanding when to use so-called workarounds, such as passing around indices into arrays or Vecs.

Multi-paradigm, but not the OOP some are used to

The Rust programming language is multi-paradigm, and how that lands depends on what you're coming from. We heard some that came from a functional background were delighted with digging into learning how much Rust inherits from that lineage. Some others noted that they and others on their teams struggled to unlearn the object-oriented style they'd come to use heavily in other languages like C++ and Java.

"Developers coming from C++ tend to think object-oriented. I think that's a difference between C++ and Rust." -- Architect at Automotive OEM

"I had exactly that thing, where I would apply all my years of Java and JS thinking, where I could just create some object, not care about it, return it, have it sloshing around between various functions. Found myself reaching for these patterns and then being told 'no, you cannot do that'." -- Principal Engineer at a SaaS company

Developers coming from functional programming had less to unlearn: strong typing, pattern matching, and an expression-oriented style were already familiar.

"My background has been more functional programming, strong typing. That originated for me as a Lisper: once a Lisper, always a Lisper." -- Principal Software Engineer working on Rust tooling for safety-regulated industries

"The languages I primarily used before Rust were things like OCaml. Way back, I came from C and C++, the classic languages, and then I spent quite a long time doing primarily pure functional stuff. These days I've ended up back in what I like to think of as a pragmatic center ground [with Rust]." -- Fractional CTO

Teaching Rust in academia

We spoke with a university professor that's been teaching Rust generally. In the academic environment, they were able to use proxies for some things such as "traits are like interfaces in Java" because the students had already gone through a set of courses in their first and second years that taught them Java. They introduced concepts slowly throughout the course, choosing to deal with some more complex topics like generics later. The outcome generally was that students had no problem picking up Rust in this setting.

"I couldn't see any big difference on the embedded side. We also teach an embedded class, and we did an experiment. Half of the students' feedback was worse on the Rust class, mostly because they needed to build the project themselves. The C students just got one from [an LLM], absolutely no problem." -- University Professor, on teaching Rust

The C cohort leaned on LLMs for the project in ways the Rust cohort couldn't. We don't yet have a clear answer for why.

What did come through clearly was the Rust cohort's experience with the community. Some students needed to figure out which drivers to use for the embedded project and how to use them. Their professor encouraged them to open issues and ask questions directly on GitHub, and the maintainers responded. Students who had never contributed to open source before were getting answers from the people who wrote the code.

Learning using LLMs

Some experienced folks shared that they saw LLMs as a tool that can help someone come up to speed quickly, either as a research tool or for generating example Rust code to understand concepts.

"I'm optimistic that there's a way to work [LLMs] in that will cut down that learning curve. One of the big things these tools bring is reducing the learning curve in general; these are very good tools to help you navigate a space that you don't know yet." -- Maintainer of large open source Rust crate

"I try [LLMs] out once a month, usually for generating an example or something like this. Just like with Stack Overflow: when you read an example, you should read it carefully and try to understand it. Not copy and paste it, but type it in your own words in code and then check it, because that's where the teeny tiny little mistakes are." -- Founder of startup built on Rust

For some learners, an LLM is just another way to find answers, no different than a search engine.

"So for the most part, picking up Rust - how do I learn? I'll [use web search for] things, I'll ask [an LLM], I'll just poke around and read the code." -- Senior Software Engineer working in a regulated space

One founder went further and claimed that LLMs change who can become a Rust developer. One consulting company founder described hiring high school graduates with no systems programming background and training them as Rust developers, with LLMs filling in the learning gaps that would previously have required years of experience.

"At the beginning, I was worried, but now that we have [LLMs] supporting development, the difficulty of the language doesn't matter. I'm seeing a huge opportunity behind strong runtime languages like Rust. [..] In [Developing Country] we hire 20-25 high school graduates, train them to be Rust programmers, then they enhance our workforce worldwide." -- Founder of a consulting company

We heard this from one organization. This is a claim that the combination of Rust's compiler and LLM tooling can dramatically shorten the path from beginner to working developer. Whether it generalizes depends on questions we can't answer from a single interview: how long these developers stay, what kind of code they can maintain independently, and whether this training/learning model works outside this company's particular structure. If it holds up, the pool of people who can become Rust developers is much larger than the usual hiring profile suggests.

Organizational considerations for Rust learners

We spoke with a number of folks on teams that are using Rust in larger organizations. Teams wanted to know that everyone would end up at roughly the same level of competence, which led a good number to invest in training courses to get there. Some leaders found that staff was able to ramp well enough by reading The Rust Programming Language, going through Rustlings, and then picking up lower risk and priority tickets to work on. Having a sense of community was also important within companies; it helps people know they are not alone when they are asked to work on Rust after, say, a reorganization happens.

"[..] the idea with the class as opposed to 'just read the Rust book on your own' was that this gives everyone kind of the same baseline going in." -- Principal Firmware Engineer (mobile robotics)

"So typically we're going to have people work through Rustlings, work through The Rust Programming Language. We have them then start to pick up lower risk tickets to work on." -- Principal Engineer at a large SaaS provider

"We've got an internal Slack channel for Rust learning where people can drop questions and others will come in and answer them. That helps build up understanding and community." -- Software Engineer at a large corporation

Some organizations found that while the person they'd hire would need to learn Rust, it was still preferable to the alternative of hiring someone for a critical piece of software written in another language.

"They needed to grow and maintain this C++ codebase. They had a C++ wizard, and they tried for about two years to find someone with the same level of expertise. They ended up hiring people that didn't know Rust and ramping them up, creating FFI bindings from the C++ side so they could work in Rust. And you can feel it: the borrow checker is teaching these people the right way to handle their systems." -- Principal Engineer at an Automotive OEM

The community and helping each other aspect seems to grow bonds as organizations mature.

"Our team is [all about] mentorship. I've mentored people coming up to speed on Rust, and people help each other hugely." -- Principal Software Engineer at a large SaaS company

Silent attrition

We identified some cases where people have approached Rust and bounced off of it, for one reason or another. In the below case, someone with a background in a language with fewer guardrails found themselves frustrated enough with Rust to walk away.

"All of that means that that embedded ecosystem is very frustrating to somebody who comes from C and is like, why can't I just get a pointer to this peripheral and then write into the registers. What are you doing to me? [..] My friend never got over that. He looked at it and said, I'm not going to deal with this and walked away." -– A second University Professor

There may be language features that for a particular domain are not seen as comfortable or usable yet, such as async Rust usage in a safety domain. We'd like to map which language features feel off-limits in which domains; async in safety-critical work probably isn't the only case.

"We're not fully sure how async [Rust] will work out in the long run in our domain. [..] People don't feel comfortable yet since C++14 doesn't provide such concepts. [..] It's the chicken-and-egg problem again: we probably need to gain some experience to see whether we can actually benefit from these new concepts in the automotive and safety domains." -- Team Lead at Automotive Supplier (ASIL D target)

We heard in at least one case, that while the language was challenging and there was a near bounce, the tooling helped keep them coming back and trying.

"Well, I think my early impressions of Rust - one is I find C++ so intimidating, and I think a big part of why I was able to succeed at [..] learning Rust is the tooling. I mean, all this makes sense [..] but it's like, for me, getting started with Rust, the language was challenging, but the tooling was incredibly easy." -- Founder of another startup built on Rust

While it might be considered more of a community concern, if there are interactions online and in spaces that point to learners having so-called "skill issues" this feeds into the narrative that Rust must be hard to learn. We may be unintentionally turning away Rust Project contributors and maintainers due to the vibes being put out when new learners show up in certain spaces.

"People are very helpful, but generally the attitude is: if your program is very complicated, it's mostly a skill issue. There's not that much empathy when people get stuck learning, and a lot of people are just pushed away by it. There's probably a huge number of people who silently stop wanting to write Rust, because at some point it gets complicated and the feedback they get is 'you just need to be a better programmer, obviously'." -- Software Engineer at a SaaS Provider

Feedback on near-bounces from survey

We found a few interesting perspectives collected in the Rust Vision doc survey which we administered with examples of bouncing and coming back:

"I started before 1.0, got stuck very soon when trying to translate patterns from C++ to Rust (due to borrow checking). I tried again after 1.0 and it stuck. [..]" -- Survey Respondent A

Survey Respondent A went on to share in a more detailed response about a perceived weakness in Rust learning materials related to lifetimes and the borrow checker are explained. There was an observation that it's fairly easy to run into more complex situations with lifetimes and the borrow checker. They felt that the current state of this sort of material and tutorials is fairly superficial and can leave learners stuck when they run into those more complex situations.

One respondent that bounced once and came back shared challenges around usage of async. In concert with Rust's memory-safety and the borrow checker, they found some of the nitty-gritty details of async were difficult to learn. While we're aware of the Rust Project's continuous efforts to improve Rust's async story, this is another data point of a user that faced challenges.

Another survey respondent shared how they had multiple times bounced in trying to learn Rust. They returned after a year or so and found Rustlings to be highly motivating. We note that having multiple pathways for folks to learn Rust opens up more possibilities for those that nearly bounced, just like this person.

Need more focused work on silent attritrion

The thing that stood out most to us was the lack of real, first-hand knowledge of having bounced when learning Rust. While this is an obvious effect of soliciting answers to our survey and opportunities to interview through Rust channels and our networks, this cohort is good future candidate where interviews could start.

Conclusions

Across these conversations, the experience of learning Rust depended heavily on context. Why someone was learning and what support they had mattered as much as the borrow checker. The same kinds of examples kept coming up: a training course that got a team to a shared baseline, a maintainer answering a student's first GitHub issue, and a colleague whose code showed that cloning was okay.

That context is largely something the community has a hand in. With that in mind, here is what we take away from what we heard, and what we still don't know.

What seems worth trying

Learning materials aimed at unlearning. Syntax barely came up when people described their struggles. People struggled with unlearning habits from previous languages, whether OOP structuring from C++ and Java or the instinct to grab a raw pointer to a peripheral. Most of our learning materials teach Rust from first principles, and that works. What we didn't come across is much written for, say, the engineer with ten years of Java who lands on a Rust team after a reorg: material that names the patterns they'll reach for that won't transfer, and shows what to do instead. The professor we spoke with did a version of this in the classroom, leaning on "traits are like interfaces in Java" and saving generics for later in the course, and the students did fine. Something similar could work outside the classroom too.

Put the "clone freely while you're learning" advice somewhere official. Every experienced developer we spoke with gave the same advice, but learners seem to mostly pick it up by accident, like the researcher who happened to see someone else cloning the struct they had been carefully threading lifetimes through. Saying it early in official materials would take some of the steepness out of the curve. The broader version belongs there too: idiomatic Rust doesn't have to mean optimal Rust, especially on a first project.

Diagnostics are already a primary learning resource: several people told us the compiler taught them lifetimes before any documentation did. Diagnostics reach learners right at the moment they're stuck. When writing new ones, it seems worth keeping the confused newcomer in mind alongside the expert, because for a lot of people this is where the learning happens.

Is "the book" actually out of date? Whether or not The Rust Programming Language or other materials are actually behind, a team evaluating Rust looked at its repository, saw unresolved issues and unmerged PRs, and moved on. As more companies evaluate adoption, more people will look at these materials with the same fresh eyes. Visible issue triage and some communication about what's current and what's planned would address the perception, separately from whatever content work may or may not be needed.

How stuck learners get treated is shaping who stays. We heard about students getting answers on GitHub from the maintainers who wrote the code, and we heard about learners being told their struggles were a skill issue. The first group came away with a lasting good impression of Rust. Some of the second group walked away entirely, and because they leave quietly, it's easy to underestimate how many of them there are. The welcoming side of the community came up unprompted as a reason people stayed, so we know it makes a difference when we get this right.

Every organization we spoke with described essentially the same ramp-up for bringing a team to Rust. Teams that brought groups of developers to Rust described roughly the same approach: get everyone to a shared baseline with a training course or with The Rust Programming Language and Rustlings, start people on lower-risk tickets, and give them somewhere internal to ask questions. Several organizations also found that hiring developers without Rust experience and ramping them up worked out better than continuing to search for rare expertise in another language. None of this is complicated, and teams weighing adoption don't need to invent a training program from scratch.

What we still don't know

The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.

We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.

The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.

show more
Introducing JetBrains Context: Repository Intelligence for Coding Agents
Feed: The JetBrains Blog (https://blog.jetbrains.com/feed/)
Link: https://blog.jetbrains.com/ai/2026/07/introducing-jetbrains-context-repository-intelligence-for-coding-agents/
Published: 2026-07-21 13:40:22 | Created: 2026-07-23 05:23:40

Today, we’re launching JetBrains Context, a new repository intelligence layer that helps coding agents work more efficiently and produce higher-quality results on complex codebases. As part of the JetBrains AI for Teams and Organizations rollout, JetBrains Context is now available in early access at no additional cost with your JetBrains AI subscription. It integrates with Claude Code, Codex CLI, and Junie CLI, and can be used from JetBrains IDEs, Air, VS Code, and other supported editors.

JetBrains has always focused on making developers more efficient, even when working with the most complex codebases. Historically, that meant providing intelligent features like autocomplete, code analysis, and navigation. Today, we’re extending that same productivity to AI agents by giving them the repository intelligence they need to write, validate, and review code effectively.

“We’ve spent decades helping developers get up to speed in complex codebases. It turns out AI agents need much of the same help when they’re working in an unfamiliar project.”

Vlad Tankov Chief Technology Officer, JetBrains Agent Systems

In enterprise-scale codebases, context is essential. It’s the difference between mediocre results that require painstaking review and rework and efficient agentic coding that understands your codebase, APIs, dependencies, implementation patterns, and engineering conventions.

Just like developers, agents don’t need much hand-holding on small-scale proof-of-concept projects, but they need extra context: the unwritten institutional knowledge and insight that allows them to work effectively with large codebases.

The new reality for agents

Our investment in context echoes a growing need among developers to upskill their agents. Whereas developers used to be satisfied with just about any AI-driven output, now the “honeymoon phase” is ending and things are getting more complicated. The expectations placed on developers are increasing, and the scope of AI usage is growing as developers strive to meet the new requirements. The demand for AI ROI translates to shortened timelines for teams and emerging AI quotas. This means we can no longer spend limitless tokens to brute-force problems with top model crunching. The demands of reality are quickly catching up to the agents’ newfound superpowers.

What was once a mere inconvenience is slowly turning into a bottleneck. Most problem-solving and feature development tasks require agents to perform extensive code exploration to understand the current state or get a reference for the planned changes. In practice this means running searches, spinning up exploration agents, and reading files – activities that often eat up time and tokens. Even with today’s most capable models, limited context and repository visibility can prevent agents from finding the right code, locating good implementation examples, or identifying existing patterns worth reusing. The result is simple: The less time agents spend exploring repositories, the more time they can spend on the task at hand. That’s exactly the problem JetBrains Context was designed to address.

What JetBrains Context is

JetBrains Context is a repository intelligence layer for coding agents such as Claude Agent, OpenAI Codex, and JetBrains Junie. It incrementally builds a semantic index of your repositories and provides semantic retrieval, helping agents access relevant repository knowledge instead of repeatedly searching and reading files. Instead of relying solely on keyword searches and repeated file exploration, it can ask any question directly or look up related terms or concepts. To make that work, we rely on two main components: a backend that incrementally indexes the repo and semantic search tools that allow agents to query that data.

One important capability we’re excited to be rolling out is multi-repo search. Instead of being limited to the current repository, agents can discover relevant code across your organization’s codebase, including repositories that aren’t checked out locally. This helps them validate APIs and dependencies, understand the impact of changes, or locate reusable code in remote projects. The net effect is maintaining a higher bar of code quality, avoiding unnecessary work, and increasing architecture conformity across the codebase.

Sample output of jbcontext analyze tool

The proof is in the pudding (or, should we say, the testing)

We validated JetBrains Context on 205 open-source SWE-bench tasks, 175 production-monorepo tasks, and 1,953 code-localization tasks. Across these benchmarks, JetBrains Context reduced agent turns by up to 68%, latency by up to 59%, and execution cost by up to 48%.

Measuring AI systems consistently isn’t easy. Modern coding agents are inherently probabilistic, so we designed our evaluation around established industry benchmarks and production-scale repositories. Through evaluations, we managed to improve this technology to the point where we can confidently say it makes a huge difference in time, cost, and code quality for large codebases.

JetBrains Context early access is already included with your subscription!

Follow the instructions on our landing page to get started:

  1. Install the CLI with a simple GET request.
  2. Authenticate using the CLI jbcontext login command.  Your credentials will work as-is. A JetBrains AI license is needed, but no quota will be consumed by JetBrains Context.
  3. Navigate to your project folder and set up JetBrains Context for your preferred coding agent using the jbcontext setup-agent command. You might also do it globally in the user scope.
  4. JetBrains Context will pre-index your code automatically by agent hooks, or you can do it explicitly by calling the jbcontext index command. Your source code is not stored on JetBrains Context servers.

From now on, as you go about your normal coding, you’ll see the agent is equipped with new repository intelligence capabilities that make it much more productive. 

After trying JetBrains Context out, if you’re unsure about whether it’s helping you or not, you can check out our new built-in analytics! Just hit jbcontext analyze to see cost and time savings based on your real time data.

We’d love to hear what you think. Share your feedback, ask questions, or tell us about your experience in the comments below. You can also use the jbcontext send-feedback command directly from the CLI.

show more
Announcing Rust 1.96.1
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/06/30/Rust-1.96.1/
Published: 2026-06-30 00:00:00 | Created: 2026-07-23 05:23:40

The Rust team has published a new point release of Rust, 1.96.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.96.1 is as easy as:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website.

What's in 1.96.1

Rust 1.96.1 fixes:

It also fixes three CVEs affecting libssh2 (which is compiled into Cargo):

Contributors to 1.96.1

Many people came together to create Rust 1.96.1. We couldn't have done it without all of you. Thanks!

show more
How do you turn AI coding chaos into a repeatable playbook?
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/07/02/ai-coding-chaos-into-a-repeatable-playbook/
Published: 2026-07-02 07:40:00 | Created: 2026-07-23 05:23:40
Vivek Raghunathan, SVP of engineering at Snowflake, joins Leaders of Code at Snowflake Summit to break down the five-stage framework his org used to go from "let chaos reign" to a repeatable, org-wide system for AI-assisted engineering.
show more
Announcing Rust 1.97.0
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/07/09/Rust-1.97.0/
Published: 2026-07-09 00:00:00 | Created: 2026-07-23 05:23:40

The Rust team is happy to announce a new version of Rust, 1.97.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.97.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.97.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.97.0 stable

Symbol mangling v0 enabled by default

When Rust is compiled into object files and binaries, each item (functions, statics, etc) must have a globally unique "symbol" identifying it. To avoid conflicts when linking together different Rust programs, Rust mangles the original name of items to include additional context such as the module path, defining crate, generics, and more. Historically, this mangling was based on the Itanium ABI, also (sometimes) used by C++.

The new mangling scheme resolves a number of drawbacks from the previous one:

  • Generic parameter instantiations preserve their values, rather than being tracked solely behind a hash
  • Inconsistencies: not all parts used the Itanium ABI, meaning that custom demangling was still necessary

Since Rust 1.59, the compiler has supported opting into a Rust-specific mangling scheme via -Csymbol-mangling-version=v0. Since November 2025, this scheme has been enabled by default on nightly, and 1.97 is now enabling it on stable Rust. The legacy mangling scheme can only be enabled on nightly, and the current plan is to fully remove it.

See the previous blog post for more details.

Cargo support for denying warnings

It's common practice to deny warnings in CI. Historically, doing so is typically done through RUSTFLAGS=-Dwarnings. With Rust 1.97, Cargo controls how warnings interact with build success: either silencing them (via allow level), rendering without failing (default, warn), or denying them (via deny).

As a result of Cargo configuration determining the behavior, using this feature doesn't invalidate the underlying build cache, meaning that it's easy to temporarily opt-in. For example, if warnings are adding unwanted noise while working through fixing errors after a refactor, you can run CARGO_BUILD_WARNINGS=allow cargo check, temporarily silencing them.

In CI, jobs can instead set CARGO_BUILD_WARNINGS=deny to deny warnings. This can be combined with --keep-going to collect all errors and warnings rather than stopping on the first failing package.

See the documentation for more details.

Linker output no longer hidden by default

rustc invokes a linker on behalf of users. Historically, rustc has silenced linker output by default if the link completes successfully. This can mask real problems, though, so in Rust 1.97 we are enabling linker messages by default. These are emitted as a warning lint, for example:

warning: linker stderr: ignoring deprecated linker optimization setting '1'
  |
  = note: `#[warn(linker_messages)]` on by default

Common linker messages that have been diagnosed as false positives or intentional behavior are filtered out by rustc. Several defects have already been fixed as a result of no longer hiding this output on nightly.

Note that currently, linker_messages is a special lint that is not affected by the warnings lint group. This is intentional as rustc generally doesn't control linker output as precisely, and it's not uncommon for output to only appear on some platforms. If you are seeing what you think is a false positive output from the linker, please file an issue.

To silence the warning in the mean time, you can configure the lint level to allow. This can be done through Cargo.toml by adding a lints section like this:

[lints.rust]
linker_messages = "allow"

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.97.0

Many people came together to create Rust 1.97.0. We couldn't have done it without all of you. Thanks!

show more
GitLab 19.1 released
Feed: GitLab (https://about.gitlab.com/atom.xml)
Link: https://docs.gitlab.com/releases/19/gitlab-19-1-released/
Published: 2026-06-18 00:00:00 | Created: 2026-07-23 05:23:40

No content available

Python 3.14.5 is out!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/05/python-3145-is-out/
Published: 2026-05-10 00:00:00 | Created: 2026-07-23 05:23:40
A special release with a new (old) garbage collector.
show more
crates.io: development update
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/07/13/crates-io-development-update/
Published: 2026-07-13 00:00:00 | Created: 2026-07-23 05:23:40

Another six months have passed since our last development update, and the crates.io team has been busy. Here's a summary of the most notable changes and improvements made to crates.io since then.

Source Code Viewer

Crate pages now have a "Code" tab that lets you browse the contents of published crate versions directly on crates.io. This shows you the exact files that cargo downloads when you add a crate as a dependency, which might differ from the linked repository. This makes it much easier to audit your dependencies, including files that never appear in the repository, like the normalized Cargo.toml files that cargo generates.

The viewer comes with a file tree sidebar with search functionality, syntax highlighting, and GitHub-style line selection, where clicking or dragging line numbers produces shareable #L10-L20 URLs.

Under the hood, the server now builds a zip file for every published version. Since the .crate files that cargo consumes are gzipped tarballs without random access support, a background job re-packs each of them into a seekable zip archive plus a JSON manifest describing the contained files. Both are served from our static CDN. The frontend then fetches only the manifest and loads each file on demand with an HTTP range request. Because of this architecture, browsing crate sources essentially adds no load on the crates.io API servers. Existing crate versions have been backfilled, so this works for old releases too.

The rendering library behind the code viewer is a diff renderer at heart, and that's no accident: a version-to-version diff viewer built on the same infrastructure is currently in the works. This will allow you to review exactly what changed between two published versions, right on crates.io. Stay tuned!

Untangling crates.io Accounts from GitHub

At the end of May, the crates.io team accepted RFC #3946. Crates.io accounts always have been tightly coupled to GitHub: signing in means "Log in with GitHub", and your crates.io identity is your GitHub username. The RFC changes that. It introduces usernames that are native to crates.io and independent of linked GitHub accounts, as a prerequisite for eventually supporting login via other identity providers.

The implementation of crates.io usernames has started, but there is still a lot left to do, most visibly the ability to change your crates.io username. After that is complete, there will be future RFCs and implementation for signing in with identity providers other than GitHub. Since all of this touches authentication and account security, we are deliberately taking it slow and rolling these changes out in small, carefully reviewed steps.

Advisories and Suggestions

In our January update we introduced the "Security" tab, which shows security advisories from the RustSec database. We have since taken this integration one step further: crates that RustSec has flagged as unmaintained now show a warning banner directly on their crate pages, linking to the corresponding advisory for details and possible alternatives. Thanks to Dirkjan Ochtman for implementing this feature!

Unmaintained warning banner on the ansi_term crate page

Related to this, some popular crates have been largely absorbed into the Rust standard library over the years, like lazy_static, which has been superseded by std::sync::LazyLock since Rust 1.80. Crate pages of such crates now show a friendly "You might not need this dependency" banner describing the standard library replacement, and superseded crates in dependency lists get a small light bulb icon with a similar hint.

The dataset behind this feature lives in the new rust-lang/std-replacement-data repository, together with a documented inclusion policy: standard library replacements only, every entry must cite the stable std, core, or alloc API and Rust version, and crate maintainers get a notice-and-comment window before an entry is added. New entries can be proposed upstream and can benefit other tools too.

Ferris

The most delightful change of this cycle: the Ferris on our error pages now follows your mouse cursor with its eyes:

Ferris' eyes following the mouse cursor on the error page

Getting a 404 error on crates.io is now slightly less sad.

Svelte Frontend Migration Completed

In our January update, we announced that we were experimenting with porting the crates.io frontend from Ember.js to Svelte. This experiment has concluded successfully: the new frontend reached feature parity, went through a public testing phase in April, became the default at the beginning of May, and the Ember.js app has been removed from our repository.

We designed this change to be invisible for our users, since the new frontend is a 1:1 port of the previous design and functionality. For the team and our contributors, however, it is a big deal: the frontend is now built on a more modern framework, which should make it easier for new contributors to get started. It also allows us to iterate faster, as the source code viewer above demonstrates.

We want to thank the Ember.js team for a framework that served crates.io well for many years, and the Svelte team for making the transition so enjoyable.

Miscellaneous

These were some of the more visible changes to crates.io over the past six months, but a lot has happened "under the hood" as well:

  • Search performance: Relevance-sorted search queries previously ranked every crate matching the query, which could take 1-2 seconds for short or common search terms. Ranking is now bounded to the 1,000 matching crates with the highest recent download counts.

  • Reverse dependencies performance: The reverse dependencies endpoint no longer recomputes the full dependent set on every request. It is now served from a precomputed table kept in sync by database triggers, turning an expensive join into a bounded index scan and greatly reducing the chance of getting a timeout error.

  • New ARCHITECTURE.md: If you've ever wondered how crates.io actually works, our ARCHITECTURE.md document got a complete rewrite. It is now organized around the high-level systems that make up crates.io and how they fit together, and includes walkthroughs of what happens when you run cargo publish, why a typical crate download never touches our API servers, and how download counts are derived from CDN access logs.

  • Definition lists: READMEs now render Markdown definition lists, a widely used Markdown extension. Our markdown renderer comrak already supported them, the extension just wasn't enabled yet. Thanks to @mistaste for this contribution!

  • CDN cache tags: Files uploaded to our static CDN now carry cache-tag metadata, allowing us to invalidate all cached files of a crate or a specific release in a single operation, instead of issuing one invalidation per file URL.

  • Caching improvements: We removed a global Vary: Cookie response header that was preventing our CDNs from caching public API responses and frontend assets effectively. Per-user responses now use Cache-Control: no-store instead, resulting in better cache hit rates at the CDN edge.

  • Accessibility: We have made crates.io friendlier to screen readers: decorative icons are now hidden from the accessibility tree, heading hierarchies have been fixed, and lists are marked up as proper lists. ARIA snapshot tests now ensure that regressions can't slip in unnoticed. We plan to continue to improve crates.io accessibility over the coming months.

  • Git index performance: The background worker's local clone of the git index is now a bare and shallow repository, eliminating roughly 250,000 checked-out files and the full commit history from its disk, improving its performance as we see increased rates of crate publication. The periodic index squashing now goes through the GitHub API instead of generating large git packs locally, which had previously caused out-of-memory failures on the production worker.

Feedback

We hope you enjoyed this update on the development of crates.io. If you have any feedback or questions, please let us know on Zulip or GitHub. We are always happy to hear from you and are looking forward to your feedback!

show more
One vulnerability view: From scanner coverage to AI governance
Feed: GitLab (https://about.gitlab.com/atom.xml)
Link: https://about.gitlab.com/blog/one-vulnerability-view/
Published: 2026-06-18 00:00:00 | Created: 2026-07-23 05:23:40

Most enterprises use a handful of different security scanners, each configured and enforced, project by project. With no single view of what scanners run where, policies drift, blind spots go undetected, and important projects could silently go unprotected. With GitLab 19.1, you can now integrate the security scanners you already use, giving a single view of your scanner coverage. GitLab enforces third-party scanners at scale across all of your projects, and the vulnerabilities they detect get remediated automatically. On the governance side, we're launching the beta of AI audit event streaming, so you can see whether your agents are acting safely.

Enforce third-party scanners on every project at scale

For most security teams, the hardest part of application security is scanner coverage. Different scanners are set up project by project, so whether a scanner runs depends on individual teams setting it up. New projects can go unnoticed and can ship for weeks before teams realize they are not scanned. When coverage depends on tribal knowledge rather than policy, code ships unscanned, vulnerabilities ship to production, and audits expose gaps.

You can now enforce third-party scanners at scale across all of your GitLab projects. Any scanner that outputs SARIF runs under your policies, and the vulnerabilities identified flow into GitLab natively. Every finding lands in one vulnerability view governed by the same rules, so coverage becomes something you can prove rather than hope for.

From there, third-party scanner findings run through the same GitLab Duo Agent Platform auto-remediation workflow as GitLab native scanner findings. SAST False Positive Detection triages findings to prioritize those with real risk, and Agentic SAST Vulnerability Resolution opens a ready-to-merge fix to automatically remediate findings before they go into production. Your team gets coverage it can prove with one governed view across every scanner, and automated remediation for third-party findings.

Catch secrets earlier, and spend less time on false positives

Secret detection runs in your pipelines to catch leaked credentials, but teams have historically struggled with two things: missed secrets and noisy findings. On a new branch, only the latest commit gets scanned, so a secret committed earlier might ship unnoticed. The findings detected come mixed with test credentials, placeholder values, and example tokens, so developers spend time clearing noise instead of addressing real exposures.

Secret detection now scans every commit on a new branch instead of only the latest one, and Secret False Positive Detection, now generally available, adds a confidence score and an explanation to each finding, shown in the vulnerability report. Your team catches secrets wherever they were introduced, and spends time reducing risk from real exposures rather than false positives.

Decide what your AI agents can do, and prove it

Companies have adopted AI agents for coding. Agents open merge requests, call tools, and commit code alongside the developers they work for. However, once an agent is approved for a project, it can write, delete, and push without anyone reviewing the action first. Your company remains accountable for changes in the codebase, regardless of whether an agent makes them or a developer. Enterprises need to determine what an agent is allowed to do before it acts, and to show exactly what it did after.

GitLab 19.1 closes that governance gap. With AI audit event streaming, now in beta, every action an agent takes is recorded as an audit event and streamed to your audit log destinations, with the rest of your audit trail. The release also gives you control over what agents can do on your platform. Agent tool approval guardrails, also in beta, let an administrator set each agent tool to run on its own, pause for human approval, or stay blocked, so a sensitive action like writing a file or deleting a resource waits for a team reviewer before it runs. Every approval decision is recorded as an audit event for teams to retroactively review.

The result is governed autonomy. Agents can run end to end, inside the guardrails you set, and a risky action does not reach the codebase unless a person signs off on it. When an auditor or an incident responder later asks what an agent did, the answer is already in the audit trail the team runs.

Audit trail of agent activity showing an alert flagged for an agent dismissing a high-severity finding without human approval

Governed autonomy for your agents

GitLab 19.1 puts governance around the agents in your codebase, with full security scanner coverage across every project and automatic remediation of third-party scanners. You set what each agent is allowed to do before it acts, and every action lands in your audit trail.

To see what your agents can do inside the guardrails you set, and prove what they did, start a free trial of GitLab Duo Agent Platform today.

show more
Announcing Rust 1.97.1
Feed: Rust Blog (https://blog.rust-lang.org/feed.xml)
Link: https://blog.rust-lang.org/2026/07/16/Rust-1.97.1/
Published: 2026-07-16 00:00:00 | Created: 2026-07-23 05:23:40

The Rust team has published a new point release of Rust, 1.97.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.97.1 is as easy as:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website.

What's in 1.97.1

Rust 1.97.1 fixes a miscompilation in an LLVM optimization.

We have backported both an LLVM fix and a disable of the underlying change in Rust 1.97.0 of Rust's generated IR that increased the likelihood of this happening. However, note that the underlying miscompilation has been present since at least Rust 1.87.

If you'd like to help us out by testing future releases, you might consider running your code's CI or locally using the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

Contributors to 1.97.1

Many people came together to create Rust 1.97.1. We couldn't have done it without all of you. Thanks!

show more
Python 3.15.0 beta 2 is here!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/06/python-3150-beta-2/
Published: 2026-06-02 00:00:00 | Created: 2026-07-23 05:23:40
The antepenultimate 3.15 beta is out!
show more
Python 3.14.6 and 3.13.14 are now available!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/06/python-3146-31314/
Published: 2026-06-10 00:00:00 | Created: 2026-07-23 05:23:40
A pair of bug fix releases await your upgrade.
show more
Python 3.15.0 beta 3 is here!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/06/python-3150-beta-3/
Published: 2026-06-23 00:00:00 | Created: 2026-07-23 05:23:40
The penultimate 3.15 beta is out!
show more
What’s New in PyCharm 2026.2
Feed: The JetBrains Blog (https://blog.jetbrains.com/feed/)
Link: https://blog.jetbrains.com/pycharm/2026/07/what-s-new-in-pycharm-2026-2/
Published: 2026-07-21 15:53:12 | Created: 2026-07-23 05:23:40

In PyCharm 2026.2, you can build Python extensions with the new Rust plugin and debug them using debugpy, which is now the default engine. Running external utilities is now managed through a redesigned settings UI for uvx, while multi-project setups are supported out of the box for uv, Poetry, and Hatch workspaces. This release also introduces an editor minimap, integrates the Pyrefly engine for faster type insights, adds AI project generation, and more.

Python extension development with the Rust plugin [Beta][Pro]

Work seamlessly with Python projects that leverage Rust modules to speed up performance-critical components.

debugpy as the default debugger

Following its introduction as an optional backend in 2026.1, debugpy is now enabled by default for all Python projects and Jupyter notebooks, using the Debug Adapter Protocol (DAP).

Support for uv-backed tools and uvx

PyCharm now leverages the uv toolchain to streamline how you run your external development utilities, eliminating manual package setups that clutter your local environment.

Support for uv, Poetry, and Hatch multi-projects and uv workspaces [Beta]

Previously available as an optional feature in PyCharm 2026.1.1, this functionality is enabled by default in version 2026.2. It streamlines your subproject management and provides richer dependency insights directly within your configuration files. 

Editor minimap

Navigate complex source files and notebooks more efficiently with the official editor minimap. It provides a high-level visual overview of your document structure across all supported file types – while offering a dedicated layout built just for Jupyter notebooks.

Pyrefly type engine integration

Use Pyrefly as an external type engine to significantly accelerate code insight features for large-scale Python codebases.

Start new projects with AI

If you have a JetBrains AI license, you can now generate fully configured, runnable projects from scratch using natural language prompts directly from the Welcome screen.

Agent skills manager

AI agents are only as useful as the context they have. When they don’t have knowledge of your frameworks, conventions, and tooling, you end up re-explaining the same setup in every new chat window.

Agent skills fix that. Install them once in PyCharm, and your agents carry that domain knowledge across every project and session – automatically. Browse and manage skills directly from the IDE, expand the built-in library with external registries like public GitHub repositories, or let PyCharm import skills you’ve already set up for Claude Code or Codex. 

show more
Mitigated API authentication bypass for python.org download metadata
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/06/mitigated-api-bypass-for-download-metadata-python-dot-org/
Published: 2026-06-23 00:00:00 | Created: 2026-07-23 05:23:40
Vulnerability mitigated in python.org with follow-up third-party audit from Trail of Bits
show more
The good, the bad, and the AI apps
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/07/03/the-good-the-bad-and-the-ai-apps/
Published: 2026-07-03 07:40:00 | Created: 2026-07-23 05:23:40
Ryan welcomes Benny Chen, co-founder of Fireworks AI, to the show to explore what actually makes an AI application good or not, how to balance qualitative signals with quantitative metrics when evaluating AI, and how open-source eval protocols and community efforts are setting the standard for AI evaluation.
show more
RubyMine 2026.2: Agentic Debugging, Native GitHub Copilot Integration, Default Symbol-Based Code Insight, and More
Feed: The JetBrains Blog (https://blog.jetbrains.com/feed/)
Link: https://blog.jetbrains.com/ruby/2026/07/rubymine-2026-2-agentic-debugging-native-github-copilot-integration-default-symbol-based-code-insight-and-more/
Published: 2026-07-21 16:05:46 | Created: 2026-07-23 05:23:40

RubyMine 2026.2 is out!

RubyMine 2026.2 introduces agentic debugging, native GitHub Copilot integration, AI completion with third-party providers, and symbol-based code insight enabled by default. You’ll also find improvements across the Ruby ecosystem and everyday IDE workflows.

You can download RubyMine 2026.2 from our website or update via the Toolbox App.

Let’s look at what’s new.

AI

Agentic debugging

Instead of manually stepping through your application, you can now ask an AI agent to investigate a problem using the RubyMine debugger. 

Agentic debugging is powered by bundled skills – predefined workflows that give compatible AI agents access to IDE capabilities. RubyMine 2026.2 includes the new rubymine-debugger skill, allowing agents to launch debug sessions, inspect runtime state, and analyze application behavior on their own. This helps them identify issues that are difficult to understand from source code and logs alone.

AI completion with third-party providers

AI-based code completion is available to all JetBrains AI users out of the box and provides inline suggestions and next edit suggestions that go beyond the cursor without consuming AI credits.

With RubyMine 2026.2, you can now use your own OpenAI-compatible model providers for AI completion, making it easier to integrate your preferred models into your development workflow.

Native GitHub Copilot integration

Thanks to our partnership with Microsoft, Copilot is now built into RubyMine and available directly from the AI chat.

Just pick GitHub Copilot from the agent selector, sign in with your GitHub account, and you’re ready to go.

Smarter code insight, now enabled by default

In RubyMine 2026.1, we introduced a new symbol-based code insight engine as an experimental feature. Starting with 2026.2, it’s enabled by default.

The new engine changes how RubyMine understands Ruby classes, modules, and constants, providing more accurate navigation and documentation while serving as the foundation for future improvements.

The new release expands symbol-based modeling across the IDE and makes it even more efficient.

Richer Quick Documentation

Quick Documentation now presents definitions more clearly and displays additional type information whenever it’s available.

Ctrl/Cmd+Hover has also become more informative and now shows type information for more Ruby symbols, including constants and global variables.

Better support for partially resolved code

Even if a class, module, or constant cannot be completely resolved, features like Go to Declaration, Find Usages, Rename, and Quick Documentation continue to work whenever meaningful information is available.

Parameter definitions

Parameter definitions now use the same symbol-based modeling as the rest of the engine.

Besides the performance improvements, this also brings more accurate Rename refactoring, better fuzzy completion, and smarter handling of complex names inside string literals.

If necessary, you can still switch back to the previous implementation in Settings | Languages & Frameworks | Ruby | Code Insight.

Ruby ecosystem improvements

Better RBS experience

RubyMine 2026.2 brings several improvements to the RBS experience:

  • Type parameter hints now display variance modifiers, upper bounds, and default values.
  • Module self-types are shown directly in Ruby code.
  • Managing RBS hints is easier thanks to new editor actions available directly from the code.

Expanded RSpec 4 support

RubyMine now offers broader support for RSpec 4, making it easier to migrate existing projects.

The IDE detects deprecated syntax, highlights compatibility issues, and provides quick-fixes for common upgrade scenarios.

Inspections now cover top-level DSL declarations, deprecated should expectations, and other RSpec 4 compatibility changes, making it easier to modernize test suites before they become a problem.

Skipping non-project code while debugging

When stepping through code, you usually care about your own application – not framework internals.

The Ignore non-project sources option now works much more reliably. RubyMine skips Ruby standard library code, framework internals, third-party gems, and excluded directories, allowing you to stay focused on the code you’re actually debugging.

The result is less manual stepping and cleaner debugging sessions.

User experience improvements

Faster gem environment updates

Gem environment refreshes now happen in the background, reducing UI freezes and keeping RubyMine responsive while SDK and dependency information is updated.

Simpler project opening

Opening existing projects now requires less manual setup.

RubyMine can automatically detect the appropriate Ruby interpreter from project configuration files, reducing unnecessary setup notifications and helping you get started faster.

More efficient RuboCop processing

Background RuboCop analysis has been optimized to reduce unnecessary CPU usage, improving IDE responsiveness during everyday development.

Stay in touch

To learn about the latest features as they come out, please follow RubyMine on X. 

We invite you to share your thoughts in the comments below and to suggest and vote for new features in the issue tracker.

Happy developing!

The RubyMine team

show more
GitLab Patch Release: 19.1.1, 19.0.3, 18.11.6
Feed: GitLab (https://about.gitlab.com/atom.xml)
Link: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-1-1-released/
Published: 2026-06-24 00:00:00 | Created: 2026-07-23 05:23:40

No content available

Packaging Council Inaugural Election Dates
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/06/2026-packaging-council-election-dates/
Published: 2026-06-28 00:00:00 | Created: 2026-07-23 05:23:40
A new Python Packaging Council (PPC) is being established, with their election of the inaugural PPC will be held in parallel to the 2026 PSF Board election.
show more
Google Antigravity agents get full context with GitLab Orbit
Feed: GitLab (https://about.gitlab.com/atom.xml)
Link: https://about.gitlab.com/blog/gitlab-orbit-and-google-antigravity/
Published: 2026-06-25 00:00:00 | Created: 2026-07-23 05:23:40

Developers working in Google Antigravity can now install our lifecycle context graph, GitLab Orbit, directly from the Antigravity MCP Store and give their agents structured access to projects, pipelines, merge requests, vulnerabilities, and source code across their GitLab instance.

The Orbit integration is a new addition to a family of purpose-built GitLab integrations already in the Google Cloud ecosystem and brings GitLab's context layer into Google's agent-first development platform.

Query your software lifecycle within Antigravity

Antigravity agents, without GitLab Orbit, can see the files and reach the terminal. They do not understand the broader system: which services depend on the code being changed, whether similar vulnerabilities have been flagged elsewhere, or who reviewed comparable changes in the past. That context lives in your DevSecOps platform. Getting it to a coding agent has meant using custom scripts or copy-pasting between tools.

GitLab Orbit indexes your GitLab instance and builds a knowledge graph of relationships between groups, projects, users, work items, merge requests, pipelines, vulnerabilities, and source code. It surfaces that graph through two MCP tools: query_graph, which executes structured queries, and get_graph_schema, which returns available node types, properties, and relationships.

With this integration, an Antigravity agent can be more accurate and you can answer the most complex questions about your software lifecycle with this context layer:

  • Which projects depend on this module, and will this change break them?
  • Have any unresolved vulnerabilities been found in this project?
  • Based on past reviews and file ownership, who should review this merge request?
  • Which projects produce the most pipeline failures in this group?

The agent composes the query in GitLab Orbit's JSON DSL and gets typed results back, instead of requiring you to switch between browser tabs and paste context into the coding platform.

In early internal tests, agents grounded with GitLab Orbit responded up to 11 times faster, used up to 4.5 times fewer tokens, and produced up to 45 times fewer hallucinations.

Key user journeys

With GitLab Orbit and Antigravity, several key user journeys are enhanced by the interoperability of the two services.

Blast radius analysis

Before refactoring a shared auth library, an engineer asks an Antigravity agent connected to GitLab Orbit: What depends on this module? Which open merge requests touch those files? And who owns them? The agent queries the knowledge graph and returns all three in one answer: the importers, every in-flight merge request against those files, and their owners. The engineer sees which open work the refactor will collide with, and who to involve, before editing a line. Without Orbit, the same agent sees only the open files and the terminal, with no ability to query the importers, merge requests, and owners that live in GitLab.

Blast radius visual map

Onboarding and codebase exploration

A developer returning to an unfamiliar service asks for its dependencies, entry-point files, and the merge requests opened against it this week. The agent runs the queries against the knowledge graph and produces a Walkthrough Artifact, a scannable map the developer keeps rather than a chat answer that scrolls away. Orbit reindexes within minutes of a change, so the map reflects the service as it is today, not the stale wiki that onboarding usually relies on.

GitLab Orbit for onboarding and codebase exploration

Dependency mapping with image generation

A tech lead queries GitLab Orbit for a group's service-dependency structure and has the agent render it as an architecture diagram with Nano Banana Pro. Its nodes and edges are drawn from the live graph rather than relying on a diagram that's already out of date. For a narrower view, like only the services with open security findings, the tech lead re-queries and regenerates a diagram. Every query is filtered to what the tech lead can access, so the diagram is safe to share as-is. A text-only agent can't turn a graph query into a diagram, let alone keep it current. GitLab is building the same capability natively as a Software Architecture Map; in Antigravity, it works today.

GitLab Orbit for dependency mapping

Install from the MCP Store in clicks

Antigravity's MCP Store is a built-in integration hub inside the settings. It uses the Model Context Protocol to connect agents to external tools and services in a standardized way.

Open the MCP Store panel from the settings. Within the customization tab, find the MCP section. Click “Add MCP” and add GitLab Orbit. Authenticate with GitLab through the on-screen prompts. Once installed, Orbit's tools are automatically available to your agents. No config files or terminal setup required.

Build on the same context that powers GitLab Duo Agent Platform

GitLab Orbit is the same engine that provides context to Duo Agent Platform. For platform engineering teams managing large GitLab instances, agents working inside Antigravity draw on the same governed knowledge graph as agents working inside GitLab, without a separate context pipeline to configure and maintain.

Orbit indexes code in Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, and C# from the default branch, and reindexes within minutes of a change. Queries through MCP consume GitLab Credits; calls to get_graph_schema are free.

Get started

GitLab Orbit is available for GitLab Premium and Ultimate tiers on GitLab.com. To try it out, turn on Orbit for your top-level group, then install the GitLab Orbit integration from the Antigravity MCP Store.

If you are not yet using GitLab Duo Agent Platform, start with a free trial.

If you are on GitLab's Free tier, sign up for Duo Agent Platform with these steps.

If you are a GitLab Premium or Ultimate subscriber, turn on Duo Agent Platform and use the GitLab Credits included with your subscription.

show more
When the sensor starts thinking: SnortML, agentic AI, and the evolving architecture of intrusion detection
Feed: Stack Overflow Blog (https://stackoverflow.blog/feed/)
Link: https://stackoverflow.blog/2026/07/06/when-the-sensor-starts-thinking-snortml-agentic-ai-and-the-evolving-architecture-of-intrusion-detection/
Published: 2026-07-06 15:23:34 | Created: 2026-07-23 05:23:40
Signature-based detection has always known what it was looking for. Machine learning and autonomous agents are changing the question entirely, shifting from "does this match a known pattern?" to "does this actually make sense in context?"
show more
What’s new: Air gets more agents, local models, and Java/Kotlin code intelligence
Feed: The JetBrains Blog (https://blog.jetbrains.com/feed/)
Link: https://blog.jetbrains.com/air/2026/07/what-s-new-air-gets-more-agents-local-models-and-java-kotlin-code-intelligence/
Published: 2026-07-21 16:56:49 | Created: 2026-07-23 05:23:40

The new release of JetBrains Air brings support for GitHub Copilot, OpenCode, Pi, Cline, and other ACP-compatible agents. It also adds IntelliJ-powered navigation and diagnostics for Java and Kotlin and runs Windows tasks in Docker containers.

Try Air for Mac, Linux and Windows

Bring your own agents and harnesses

Air gives coding agents separate workspaces where they can run tasks in parallel. You can then review each agent’s changes before they reach your codebase. Until now, this workflow was limited to the agents bundled with Air, including Claude, Codex, Gemini CLI, and Junie. You can now connect other supported agents and use them throughout the same task and review workflow.

This is made possible by the Agent Client Protocol (ACP), an open protocol developed by JetBrains and Zed. ACP gives coding agents and development environments a shared way to communicate. When an agent supports ACP, Air can connect it to its workspace without requiring a separate integration built specifically for that agent.

With this change, the two most requested workflow improvements have become a reality.

Use your company’s approved coding agent in Air

Many companies standardize on one AI coding tool and do not allow alternatives. Previously, if your company had only approved GitHub Copilot, that meant you could not use Air because Air could not connect to the Copilot access your company provided.

Air can now connect to the GitHub Copilot CLI through its ACP server mode. This lets you use your company-managed Copilot access in Air: The Copilot CLI runs the coding agent and provides access to the available models, while Air adds parallel workspaces and its review workflow.

Configuring GitHub Copilot as an ACP agent in Air

The same applies to other ACP-compatible coding agents Air supports. You can use the tool your company has already approved without asking it to adopt another AI provider.

Ready to connect your own agent? Follow our setup guide for GitHub Copilot, OpenCode, or Cline with a local Ollama model. It includes working acp.json configurations.

Use the agent harness you prefer

A model is only one part of a coding agent. The harness is the software around it: It gathers context, calls tools, manages the task, and turns the model’s responses into code changes. Different harnesses approach this workflow differently and support different model providers.

Air can now connect to supported ACP agents such as OpenCode and Pi. You choose the harness and configure it with a model or provider it supports. For example, you could use OpenCode with your preferred cloud provider or Pi with a local model.

The available models and agent-specific features depend on the harness and what it exposes through ACP.

Work with local models

Local-model support was one of our most requested additions. You can now use a model running on your computer through a local model runner such as Ollama or LM Studio. An ACP-compatible coding agent connects to the local model, and Air connects to that agent.

This lets you develop with a model that runs offline and choose the one that best fits your codebase, task, or environment.

Navigate Java and Kotlin projects and catch errors

Air now supports Java and Kotlin language intelligence, including mixed Java/Kotlin projects, powered by the IntelliJ IDEA code engine (in Beta).

While creating a task, you can jump to definitions, find usages, search for symbols, and follow code paths directly in Air. This helps you understand the code the agent will touch and give it more precise context.

After the agent finishes, Air highlights errors and warnings in the affected Java and Kotlin code. You can inspect problems before accepting the changes, without opening your IDE or waiting for the code to fail during compilation.

Docker tasks now run on Windows

Air can now run agent tasks in Docker containers on Windows, matching the existing macOS support. Use Docker tasks when you want dependencies and agent commands to run in an isolated container instead of directly on your machine. Docker Desktop is required.

Download Air for x64 / Download Air for ARM64

More control during agent runs

Review proposed changes before granting permission. When an agent asks to modify a file, click the file name to open the complete edit in the Proposed Change tab. You can inspect what the agent intends to change instead of relying on a short snippet in the chat.

See how much context Claude has used for a given task. Air now shows context-window usage and token counts for Claude Agent. This helps you recognize when a long task is approaching its context limit and decide whether to finish the task or start a new one.

Adjust the effort level for demanding tasks. Claude Fable, Opus, and Sonnet 5 now support an “xhigh” effort level for when a task needs more reasoning.

Keep your Mac awake during long tasks. Enable the new macOS setting to prevent your computer from sleeping while an agent is working, and ensure your task continues while you step away.

Try the new release

Download the latest Air release at air.dev/download or update through JetBrains Toolbox. Try it with your existing agents and models, then tell us how it works for you.

show more
What's new in Git 2.55.0?
Feed: GitLab (https://about.gitlab.com/atom.xml)
Link: https://about.gitlab.com/blog/whats-new-in-git-2-55-0/
Published: 2026-06-29 00:00:00 | Created: 2026-07-23 05:23:40

The Git project recently released Git 2.55.0. Let's look at a few notable highlights from this release, which includes contributions from the Git team at GitLab.

What's covered:

git-history(1) learns fixup

In our highlights of Git 2.54.0, we covered the introduction of git-history(1). In 2.55.0, a new subcommand for this tool was added: fixup.

Imagine you've made some changes and you want to amend those changes into an existing commit. The most common approach to this is to create a fixup commit and autosquash it with git-rebase(1):

git commit --fixup=<commit-id>
git rebase -i --autosquash <commit-id>^

Doing this in two steps is clumsy, especially because it requires an interactive rebase. Instead you can use the git-history(1) fixup command:

git history fixup <commit-id>

This takes the staged changes and amends them into the given commit. As an added bonus, because you're using git-history(1), all other local branches that contain the fixed-up commit are updated as well. So when working with stacked branches, fixup-ing a commit in the stack will automatically rebase all related branches.

This feature was implemented by Patrick Steinhardt.

fsmonitor daemon for Linux

When working with large monorepos, git-status(1) can be slow to determine what changed in the local worktree because Git would need to traverse the whole working tree to see which files are modified. To speed up this process, in January 2018 a setting core.fsmonitor was added in Git 2.16. Back then, you had to provide your own tool (like Watchman). When this was configured, this tool runs in the background and monitors changes on the file system. This informs Git that a file was touched and Git then verifies whether the file was modified and updates the cached status. Then whenever the user calls git-status(1), it can simply return the cached status.

In April 2022, the setting core.fsmonitor was changed to accept a boolean value. When this setting is set to true, a daemon built-in into Git is used and no more third-party tool is needed. But this filesystem monitor was only implemented for Windows and macOS, support for GNU/Linux did not yet exist.

This changes in Git 2.55, where support for Linux has been added, too. To achieve this, inotify(7) is used. inotify(7) was chosen over fanotify(7) because fanotify(7) requires elevated privileges. This comes with a small caveat though, the fsmonitor needs to put a watcher on each and every directory in the repository. In a large repo you might hit the limit of inotify watches (fs.inotify.max_user_watches), which you may need to raise.

These changes were submitted by Paul Tarjan based on work by Eric DeCosta and Marziyeh Esipreh.

git push to a remote group

Quite some time ago git-fetch(1) learned to fetch from a group of remotes.

The following command configures a group of remotes:

git config set remotes.forks "origin upstream"

When this is set up, you can git-fetch(1) from this "forks" group, and then all the remotes in that list are fetched from. This can be useful when you want to get the updates from a set of remotes in one go.

git-push(1), however, was not able to use remote groups.

In Git 2.55, this gap is closed and git-push(1) now accepts a remote group too. For example if you want to push the main branch to the group mentioned above:

git push forks main

Similar as with git-fetch(1), this command pushes the specified refs to each of the remotes in the group. Each remote is pushed independently and honors its own remote.<name>.push mapping and mirror settings.

This feature was submitted by Usman Akinyemi, suggested by Junio C Hamano.

Limiting git log --graph lane width

The --graph option of git-log(1) draws an ASCII representation of the commit history. In a repository with many active contributors this graph can grow very wide. For example, on the git.git repository this graph grows nine lanes wide after only 30 commits:

* 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | | cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | | ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | | 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | |   621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \ \
| * | | | | | 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_|/
| |/| | | |
* | | | | |   0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \ \
| * | | | | | 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | | | 042221cccb doc: config/sideband: fix description list delimiter
| * | | | | | 3eb61fda62 doc: config: terminate runaway lists
* | | | | | |   49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \ \ \
| * | | | | | | e8f12e0e95 t1400: have fifo test clean after itself
* | | | | | | |   b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \ \ \ \
| * | | | | | | | 55088ac8a4 describe: limit default ref iteration to tags

This happens because every lane continues downward to the commit from where the branch was created. This pushes the commit messages off to the right, making it harder to read. Especially when the terminal screen width is reached, this becomes unusable.

Git 2.55 adds a new --graph-lane-limit=<n> option to limit the number of lanes that are drawn. Any lanes beyond the limit are replaced with a ~ truncation mark, so it stays obvious that the graph was trimmed:

git log --graph --graph-lane-limit=5

Using this option for the same 30 commits as above, we'll get:

* 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | ~ cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | ~ ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | ~ 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | ~ 621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \~
| * | | | ~ 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_~
| |/| | | ~
* | | | | ~ 0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \~
| * | | | ~ 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | ~ 042221cccb doc: config/sideband: fix description list delimiter
| * | | | ~ 3eb61fda62 doc: config: terminate runaway lists
* | | | | ~ 49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \~
| * | | | ~ e8f12e0e95 t1400: have fifo test clean after itself
* | | | | ~ b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \~
| * | | | ~ 55088ac8a4 describe: limit default ref iteration to tags

The option only makes sense together with --graph. The default is 0, which means no limit, and zero or negative values are treated the same way, just like --max-parents does.

This feature was submitted by Pablo Sabater.

Evolution of Rust in the Git codebase

In March 2025, with the release of Git 2.49, the first Rust code was added to the Git codebase. Rust bindings were added to allow Rust code to call into libgit. But none of that Rust code was used by the Git binaries.

In November 2025, in Git 2.52, the first Rust production code was introduced into Git. Then a Rust implementation for the varint subsystem was added. This code is optionally compiled if the Rust compiler is available, and when it's not, the C implementation is used. This was added as a test balloon for distributors to start preparing their tooling for a Git release that requires Rust at some point.

Earlier this year, in Version 2.54, more Rust code was added to the codebase with the introduction of the ObjectID type. This was added as part of the efforts to implement interoperability between SHA-1 and SHA-256.

Until this release, both build systems Make and Meson would gracefully fall back to the C implementation if the Rust compiler is not found. With this v2.55 release the Rust compiler is required unless you explicitly disable it in the build system.

Please note that this doesn't affect users of Git. It only affects those who build Git from source. If you compile Git and don't want to use Rust, disable it with one of these commands:

# Meson
meson configure -Drust=disabled

# Makefile
make NO_RUST=YesPlease

Bringing Rust into Git has been an ongoing (and unfinished), multi-release, community effort. It's impossible to attribute this to a single person, but some of the most prominent contributors include brian m. carlson, Patrick Steinhardt, Ezekiel Newren, and Calvin Wan.

Faster git-grep(1) and git-cherry(1) in partial clones

git-clone(1) has this feature called partial clone. This allows the user to apply a filter to what is sent over from the server. In practice, this is done with the --filter option. For example:

git clone --filter=blob:none <remote>

This will clone the repository, but that clone excludes all blobs (i.e. the contents of the files in the tree). This can speed up the clone tremendously, but it comes at the cost that Git needs to download blobs later when other commands are used that read file contents. And some commands might need a lot of missing blobs.

git-grep(1) is one of those commands, as it searches the content of the files. To do so, it obviously needs to have those files. Imagine you want to search the word "TODO" 100 commits back in history:

git grep TODO HEAD~100

This command resolves the HEAD~100 commit and the trees associated with that. But those trees might point to blobs that aren't downloaded yet. Previously, each blob was downloaded separately. But that is improved in Git 2.55. In this version of Git, the blob downloads are batched together into a single negotiating round-trip with the server.

This batching is now implemented for both git-grep(1) and git-cherry(1).

This change was submitted by Elijah Newren.

Read more

This article highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the official release announcement of the Git project. Also, check out our previous Git release blog posts to see other past highlights of contributions from GitLab team members.

show more
Python 3.15.0 beta 4 is here!
Feed: Python Insider (https://blog.python.org/feeds/posts/default?alt=rss)
Link: https://blog.python.org/2026/07/python-3150-beta-4/
Published: 2026-07-18 00:00:00 | Created: 2026-07-23 05:23:40
The final 3.15 beta is out!
show more
Claude Sonnet 5 on GitLab: More reliable, more efficient
Feed: GitLab (https://about.gitlab.com/atom.xml)
Link: https://about.gitlab.com/blog/claude-sonnet-5-on-gitlab/
Published: 2026-06-30 00:00:00 | Created: 2026-07-23 05:23:40

Anthropic’s Claude Sonnet 5 is now available on GitLab Duo Agent Platform across all tiers and deployment models through GitLab's AI Gateway. Claude Sonnet 5 is built for work that agents assist software teams with every day: multi-step tasks, generating code that holds up under review, and conducting workflows affordably at scale. It’s also the first model in GitLab's evaluation suite to complete all of our benchmark tasks. Sonnet 4.6, its predecessor, completed 93.8% of them. For teams running GitLab Duo agents in production, this translates to tasks that finish with higher-quality code.

"Claude Sonnet 5 handled the full range of coding tasks we tested it on, while resolving more issues. It's a meaningful improvement to both quality and efficiency. We made it available on GitLab Duo Agent Platform today on all tiers and deployment models."

– Manav Khurana, Chief Product and Marketing Officer, GitLab

Finish every agent run

The most expensive agent failure is often the one that stops halfway. When a run stalls partway through a multi-step task, the cost isn't just the lost work — it's the diagnosis, the re-prompt, and the verification of whatever partial output came back. Reliability is what turns an agent from something you supervise into something you delegate to.

That's the bar Claude Sonnet 5 clears: It's the first model in our evaluation suite to finish every benchmark task. And paired with 8.8% more issues resolved, it means the work that comes back is more likely to be usable, not just present.

For teams using GitLab Duo Agentic Chat, this is what changes the daily loop of prompt, wait, evaluate. A multi-file refactor produces reviewable output instead of a dead end. Test generation can return coverage you can use. Security investigations can trace further across repository history. Duo foundational agents can handle more of their assigned work without intervention, so your time goes to reviewing results rather than restarting runs.

Asking Claude Sonnet 5 for investigating pipeline failures over the past two months using Orbit

Spend less for better results

Efficiency and reliability compound. An agent that finishes more of its work and uses fewer resources getting there lowers the real cost of every completed task.

Different models on GitLab Duo Agent Platform consume GitLab Credits at different rates, and the right choice depends on the task. Running a broad set of everyday development work on a model whose cost profile fits that work is how teams keep agent workflows affordable at scale.

For a full list of models and their credit consumption, see the GitLab Credits documentation.

Choose the right model for your workflow

The point isn't one model for everything. It's a reliable, cost-efficient default for the broad middle of day-to-day agent work, with heavier models a click away when a task earns them.

Claude Sonnet 5 joins a growing set of AI models available on GitLab Duo Agent Platform. Sonnet-class models balance quality, speed, and cost for everyday development work. For complex, long-horizon agentic tasks that demand maximum reasoning depth, Claude Opus 4.8 remains available. You select models per task through model selection in your GitLab instance.

Get started today

Claude Sonnet 5 is available now on GitLab Duo Agent Platform through GitLab's AI Gateway. Like other models, it runs on GitLab Credits.

Start a free trial of GitLab Duo Agent Platform today, or sign up from the GitLab Free tier by following a few simple steps. Existing GitLab Premium or Ultimate subscribers can use the GitLab Credits included with your subscription.

show more
GitLab Patch Release: 18.8.11
Feed: GitLab (https://about.gitlab.com/atom.xml)
Link: https://docs.gitlab.com/releases/patches/patch-release-gitlab-18-8-11-released/
Published: 2026-07-01 00:00:00 | Created: 2026-07-23 05:23:39

No content available

Page 647 of 1014 (50698 total items)
Recent Feeds
Все публикации подряд на Хабре BBC News World news | The Guardian ABC News: Top Stories The Latest News from the UK and Around the World | Sky News The Guardian TIME WSJ.com: World News BBC Russian BBC News NYT > Top Stories Home - CBSNews.com NPR Topics: News TechCrunch WIRED PBS News Hour - The Latest NBC News Top Stories World Vox World & Nation
Show all feeds