2026-03-02
official
release
rust
ai-dev-tools
devex
engineering
Cody's Take: Actually has some teeth. Could change how you ship code this week. official signal.
Why care: relevant to Rust tooling or ecosystem changes; touches developer experience or workflow; comes from an official source from rust-blog
Hello, Rust community! Once again, the survey team is happy to share the results of the State of Rust survey, this year celebrating a round number - the 10th edition! The survey ran for 30 days (from November 17th to December, 17th 2025) and collected 7156 responses, a slight decrease in responses compared to last year. In this blog post we will shine a light on some specific key findings. As usual, the full [report][1] is available for download. ──────┬───────┬─────────┬───────────────┬────── **Surv│**Start│**Complet│**Completion │**View ey** │ed** │ed** │rate** │s** ──────┼───────┼─────────┼───────────────┼────── 2024 │9 450 │7 310 │77.4% │13 564 ──────┼───────┼─────────┼───────────────┼────── 2025 │9 389 │7 156 │76.2% │20 397 ──────┴───────┴─────────┴───────────────┴────── Overall, the answers we received this year pretty closely match the results of last year, differences are often under a single percentage point. The number of respondents decreases slightly year over year. In 2025, we published multiple surveys (such as the [Compiler Performance][2] or [Variadic Generics survey][3]), which might have also contributed to less people answering this (longer) survey. We plan to discuss how (and whether) to combine the State of Rust survey with the ongoing work on the [Rust Vision Doc][4]. Also to be noted that these numbers should be taken in context: we cannot extrapolate too much from a mere 7 000 answers and some optional questions have even less replies. Let's point out some interesting pieces of data: * [Screenshotting Rust use][5] * [Challenges and wishes about Rust][6] * [Learning about Rust][7] * [Industry and community][8] ## Screenshotting Rust use Confirmed that people develop using the stable compiler and keep up with releases, trusting our stability and compatibility guarantees. On the other hand, people use nightly out of "necessity" (for example, something not yet stabilized). Compared to last year ([link][9]) we seem to have way less nightly users. This may not be a significant data point because we are looking at a sliding window of releases and differences could depend on many factors (for example, at a specific point in time we might have more downloads of the nightly compiler because of a highly anticipated feature). One example might be the very popular let chains and async closures features, which were stabilized last year. <img alt="which-version-of-rust-do-you-use" src="which-version-of-rust-do-you-use.png"/> [[PNG][10]] [[SVG][11]] [[Wordcloud of open answers][12]] <img alt="what-is-the-oldest-version-of-rust-you-use" src="what-is-the-oldest-version-of-rust-you-use.png"/> [[PNG][13]] [[SVG][14]] We are also interested to hear from (and grateful to) people *not* using Rust (or not anymore) when they tell us why they dropped the language. In most cases it seems to be a "see you again in the future" rather than a "goodbye". <img alt="do-you-use-rust" src="do-you-use-rust.png"/> [[PNG][15]] [[SVG][16]] <img alt="why-did-you-stop-using-rust" src="why-did-you-stop-using-rust.png"/> [[PNG][17]] [[SVG][18]] [[Wordcloud of open answers][19]] Some specific topic we were interested in: how often people download crates using a git repository pinned in the Cargo.toml (something like `foo = { git = "https://github.com/foo/bar" }`). <img alt="how-do-you-download-crates" src="how-do-you-download-crates.png"/> [[PNG][20]] [[SVG][21]] [[Wordcloud of open answers][22]] and if people actually find the output of [`--explain`][23] useful. Internal discussions hinted that we were not too sure about that but this graph contradicts our prior assumption. Seems like many Rust users actually do find compiler error code explanations useful. <img alt="do-you-use-compiler-error-codes" src="do-you-use-compiler-error-codes.png"/> [[PNG][24]] [[SVG][25]] [[Wordcloud of open answers][26]] ## Challenges and wishes about Rust We landed long-awaited features in 2025 (`let chains` and `async closures`) and the survey results show that they are indeed very popular and often used. That's something to celebrate! Now `generic const expressions` and `improved trait methods` are bubbling up in the charts as the most-wanted features. Most of the other desired features didn't change significantly. <img alt="which-features-do-you-want-stabilized" src="which-features-do-you-want-stabilized.png"/> [[PNG][27]] [[SVG][28]] [[Wordcloud of open answers][29]] When asked about which non-trivial problems people encounter, little changes overall compared to 2024: resource usage (slow compile times and storage usage) is still up there. The debugging story slipped from 2nd to 4th place (~2pp). We [just started][30] a survey to learn more about it! <img alt="which-problems-limit-your-productivity" src="which-problems-limit-your-productivity.png"/> [[PNG][31]] [[SVG][32]] [[Wordcloud of open answers][33]] ## Learning about Rust Noticeable (within a ~3pp) flection in attendance for online and offline communities to learn about Rust (like meetups, discussion forums and other learning material). This hints at some people moving their questions to LLM tooling (as the word cloud for open answers suggests). Still, our online documentation is the preferred canonical reference, followed by studying the code itself. <img alt="what-kind-of-learning-materials-have-you-consumed" src="what-kind-of-learning-materials-have-you-consumed.png"/> [[PNG][34]] [[SVG][35]] [[Wordcloud of open answers][36]] <img alt="how-often-do-you-engage-in-community-events" src="how-often-do-you-engage-in-community-events.png"/> [[PNG][37]] [[SVG][38]] ## Industry and community Confirmed the hiring trend from organisations looking for more Rust developers. The steady growth may indicate a structural market presence of Rust in companies, codebases consolidate and the quantity of Rust code overall keeps increasing. <img alt="is-your-organization-planning-on-hiring-rust-developers" src="is-your-organization-planning-on-hiring-rust-developers.png"/> [[PNG][39]] [[SVG][40]] As always we try to get a picture of the concerns about the future of Rust. Given the target group we are surveying, unsurprisingly the majority of respondents would like even more Rust! But at the same time concerns persist about the language becoming more and more complex. Slight uptick for "developer and maintainers support". We know and we are working on it. There are ongoing efforts from RustNL ([https://rustnl.org/fund][41]) and on [the Foundation side][42]. Funding efforts should focus on retaining talents that otherwise would leave after some time of unpaid labor. This graph is also a message to companies using Rust: please consider supporting Rust project contributors and authors of Rust crates that you use in your projects. Either by joining [the Rust Foundation][43], by allowing some paid time of your employees to be spent on Rust projects you benefit from or by funding through other collect funds (like [https://opencollective.com][44], [https://www.thanks.dev][45] and similar) or personal sponsorships (GitHub, Liberapay or similar personal donation boxes). Trust in the Rust Foundation is improving, which is definitively good to hear. <img alt="what-are-your-biggest-worries-about-rust" src="what-are-your-biggest-worries-about-rust.png"/> [[PNG][46]] [[SVG][47]] [[Wordcloud of open answers][48]] As a piece of trivia we ask people which tools they use when programming in Rust. The Zed editor did a remarkable jump upward in the preferences of our respondents (with Helix as a good second). Editors with agentic support are also on the rise (as the word cloud shows) and seems they are eroding the userbase of VSCode and IntelliJ, if we were to judge by the histogram. We're happy to meet again those 11 developers still using Atom (hey 👋!) and we salute those attached to their classic editors choice like Emacs and Vim (or derivatives). <img alt="what-ide-do-you-use" src="what-ide-do-you-use.png"/> [[PNG][49]] [[SVG][50]] [[Wordcloud of open answers][51]] And finally, here are some data about marginalized groups, out of all participants who completed our survey: ────────────────────────────────────────────────────────────┬─────┬────────── Marginalized group │Count│Percentage ────────────────────────────────────────────────────────────┼─────┼────────── Lesbian, gay, bisexual, queer, or otherwise non-heterosexual│752 │10.59% ────────────────────────────────────────────────────────────┼─────┼────────── Neurodivergent │706 │9.94% ────────────────────────────────────────────────────────────┼─────┼────────── Trans │548 │7.72% ────────────────────────────────────────────────────────────┼─────┼────────── Woman or perceived as a woman │457 │6.43% ────────────────────────────────────────────────────────────┼─────┼────────── Non-binary gender │292 │4.11% ────────────────────────────────────────────────────────────┼─────┼────────── Disabled (physically, mentally, or otherwise) │218 │3.07% ────────────────────────────────────────────────────────────┼─────┼────────── Racial or ethnic minority │217 │3.06% ────────────────────────────────────────────────────────────┼─────┼────────── Political beliefs │211 │2.97% ────────────────────────────────────────────────────────────┼─────┼────────── Educational background │170 │2.39% ────────────────────────────────────────────────────────────┼─────┼────────── Cultural beliefs │139 │1.96% ────────────────────────────────────────────────────────────┼─────┼────────── Language │134 │1.89% ────────────────────────────────────────────────────────────┼─────┼────────── Religious beliefs │100 │1.41% ────────────────────────────────────────────────────────────┼─────┼────────── Other │61 │0.86% ────────────────────────────────────────────────────────────┼─────┼────────── Older or younger than the average developers I know │22 │0.31% ────────────────────────────────────────────────────────────┴─────┴────────── While some of these numbers have slightly improved, this still shows that only a very small percentage of the people who are part of marginalized groups make it to our project. While we still do better than many other tech communities, it is a reminder that we need to keep working hard on being a diverse and welcoming FOSS community *for everyone*, which has always been and always will be one of our core values. ## Conclusions Overall, no big surprises and a few trends confirmed. If you want to dig more into details, feel free to download the [PDF report][52]. We want once again to thank all the volunteers that helped shaping and translating this survey and to all the participants, who took the time to provide us a picture of the Rust community. ## A look back Since this year we publish a round number, if you fancy a trip down the memory lane here the blog posts with the past years' survey results: * [2024 State of Rust Survey results][53] * [2023 Rust Annual Survey results][54] * [2022 Rust Annual Survey results][55] * [2021 Rust Survey results][56] * [2020 Rust Survey results][57] * [2019 Rust Survey results][58] * [2018 Rust Survey results][59] * [2017 Rust Survey results][60] * [2016 State of Rust survey][61] [1]: https://raw.githubusercontent.com/rust-lang/surveys/main/surveys/2025/annua l-survey/report/annual-survey-2025-report.pdf [2]: https://blog.rust-lang.org/2025/09/10/rust-compiler-performance-survey-2025 -results/ [3]: https://blog.rust-lang.org/inside-rust/2025/09/22/variadic-generics-micro-s urvey/ [4]: https://blog.rust-lang.org/2025/12/03/lessons-learned-from-the-rust-vision- doc-process/ [5]: https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/#sc reenshotting-rust-use [6]: https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/#ch allenges-and-wishes-about-rust [7]: https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/#le arning-about-rust [8]: https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/#in dustry-and-community [9]: https://raw.githubusercontent.com/rust-lang/surveys/main/surveys/2024-annua l-survey/report/annual-survey-2024-report.pdf [10]: which-version-of-rust-do-you-use.png [11]: which-version-of-rust-do-you-use.svg [12]: which-version-of-rust-do-you-use-wordcloud.png [13]: what-is-the-oldest-version-of-rust-you-use.png [14]: what-is-the-oldest-version-of-rust-you-use.svg [15]: do-you-use-rust.png [16]: do-you-use-rust.svg [17]: why-did-you-stop-using-rust.png [18]: why-did-you-stop-using-rust.svg [19]: why-did-you-stop-using-rust-wordcloud.png [20]: how-do-you-download-crates.png [21]: how-do-you-download-crates.svg [22]: how-do-you-download-crates-wordcloud.png [23]: https://doc.rust-lang.org/rustc/command-line-arguments.html#--explain-prov ide-a-detailed-explanation-of-an-error-message [24]: do-you-use-compiler-error-codes.png [25]: do-you-use-compiler-error-codes.svg [26]: do-you-use-compiler-error-codes-wordcloud.png [27]: which-features-do-you-want-stabilized.png [28]: which-features-do-you-want-stabilized.svg [29]: which-features-do-you-want-stabilized-wordcloud.png [30]: https://blog.rust-lang.org/2026/02/23/rust-debugging-survey-2026/ [31]: which-problems-limit-your-productivity.png [32]: which-problems-limit-your-productivity.svg [33]: which-problems-limit-your-productivity-wordcloud.png [34]: what-kind-of-learning-materials-have-you-consumed.png [35]: what-kind-of-learning-materials-have-you-consumed.svg [36]: what-kind-of-learning-materials-have-you-consumed-wordcloud.png [37]: how-often-do-you-engage-in-community-events.png [38]: how-often-do-you-engage-in-community-events.svg [39]: is-your-organization-planning-on-hiring-rust-developers.png [40]: is-your-organization-planning-on-hiring-rust-developers.svg [41]: https://rustnl.org/fund [42]: https://rustfoundation.org/media/announcing-the-rust-foundation-maintainer s-fund/ [43]: https://rustfoundation.org/members/ [44]: https://opencollective.com [45]: https://www.thanks.dev [46]: what-are-your-biggest-worries-about-rust.png [47]: what-are-your-biggest-worries-about-rust.svg [48]: what-are-your-biggest-worries-about-rust-wordcloud.png [49]: what-ide-do-you-use.png [50]: what-ide-do-you-use.svg [51]: what-ide-do-you-use-wordcloud.png [52]: https://raw.githubusercontent.com/rust-lang/surveys/main/surveys/2025/annu al-survey/report/annual-survey-2025-report.pdf [53]: https://blog.rust-lang.org/2025/02/13/2024-State-Of-Rust-Survey-results/ [54]: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results / [55]: https://blog.rust-lang.org/2023/08/07/Rust-Survey-2023-Results/ [56]: https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021/ [57]: https://blog.rust-lang.org/2020/12/16/rust-survey-2020/ [58]: https://blog.rust-lang.org/2020/04/17/Rust-survey-2019/ [59]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018/ [60]: https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results/ [61]: https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016/
2026-03-20
fresh
official
practical
release
rust
ai-dev-tools
devex
engineering
Cody's Take: Looks actionable. Could change how you ship code this week. official signal.
Why care: relevant to Rust tooling or ecosystem changes; touches developer experience or workflow; comes from an official source from rust-blog
When we set out to understand Rust's challenges, we expected to hear about the borrow checker learning curve and maybe some ecosystem gaps. Of course, we did. A lot. But, of course, it's more nuanced. The conventional wisdom is that Rust has a steep learning curve, but once you "get it," smooth sailing awaits. We found that while some challenges disappear with experience, they are replaced with others. Beginners struggle with ownership concepts, experts face domain-specific challenges: async complexity for network developers, certification gaps for safety-critical teams, ecosystem maturity issues for embedded developers. This isn't all doom and gloom though: we ultimately found that despite Rust's challenges, it remains necessary and desired: > If all the things laid out [to make Rust better] were done, I'd be a happy > Rust programmer. If not, I'd still be a Rust programmer. -- Engineering > manager adopting Rust for performance ## The universal challenges that affect everyone Across every interview, regardless of experience level or domain, we heard about the same core set of challenges. These aren't beginner problems that go away—they're fundamental friction points that manifest differently as developers grow. ### Compilation performance: the universal productivity tax **Every single cohort** we analyzed—from novices to experts, from embedded developers to web developers—cited compilation times as a significant barrier to productivity: > "Java takes about 100 milliseconds, Rust anywhere from 5 seconds to a minute > depending on what you changed" -- Distinguished engineer working on backend > systems at a large company > "8 to 10s iteration cycle... when you want to tweak the padding on a box" -- > GUI development team The impact varies by domain, but the pattern is consistent. CLI tool and GUI developers, who need rapid iteration cycles, are hit hardest. Safety-critical developers with 25-30 minute build times face workflow disruption. Size-constrained embedded developers are forced into optimized builds that take longer to compile and complicate debugging. What's particularly important to note, is that this isn't just about absolute build times; it's about the **development velocity tax** that compounds over time. Long compile times can have strong negative impact on code iteration time. Anything that can reduce this code iteration time - hot reloading, fast debug builds, faster linking - will have an outsized impact on development velocity. Moreover, the compilation performance tax compounds at scale. Individual developers might tolerate 5-10 second builds, but teams with CI/CD pipelines, large codebases, and frequent iterations face exponentially worse impacts. One participant noted 25-30 minute builds that create "wait for 30 minutes before the tool finds out I made a mistake" cycles. ### The borrow checker: first it's sour, then it's sweet The borrow checker is often touted as a "beginner problem", and we found that this is largely true: Novices are most strongly impacted by the borrow checker, but this often extends even into the stage where a developer is *comfortable* writing Rust where they *still* get tripped by the borrow checker sometimes. However, highly-experienced Rust developers basically never cite the borrow checker itself as a frustration for them. > Ownership: The first time I went through the chapter, I was really like, what > is this? - Developer learning Rust as a first language > I actually did not understand the borrow checker until I spent a lot of time > writing Rust - Executive at a developer tools company ### Async complexity: the "Three Horsemen" problem Multiple participants identified `async` as a pain point. Many people, not just beginners, often choose to completely avoid it, instead focusing solely on sync Rust. This is because, for many, `async` Rust feels completely different. > My biggest complaint with Rust is async. If we want to use [a tool], we're > forced into that model...not just a different language, but a different > programming model...I have zero [experience], I've been avoiding it. - > Developer working on a security agent at a large company Of course, those who *do* use it often share how complex it is, how it can feel incomplete in ways, or how it is difficult to learn. > "When you got Rust that's both async and generic and has lifetimes, then those > types become so complicated that you basically have to be some sort of Rust > god" -- Software engineer with production Rust experience > "My general impression is actually pretty negative. It feels unbaked... there > is a lot of arcane knowledge that you need" -- Research software engineer > "There's a significant learning gap between basic Rust and async > programming... creating a 'chasm of sadness' that requires substantial > investment to cross." -- Professional developer The async complexity isn't just about individual developer experience: it is exacerbated by **ecosystem fragmentation and architectural lock-in**: > "the fact that there is still plenty of situations where you go that library > looks useful I want to use that library and then that immediately locks you > into one of tokio or one of the other runtimes" -- Community-focused developer This fragmentation forces architectural decisions early and limits library compatibility, creating a unique challenge among programming languages. Of course, it would be remiss to clarify that plenty of people *do* express positive sentiments of async, often despite the mentioned challenges. ### Ecosystem navigation: choice paralysis and tacit knowledge The Rust ecosystem shows **uneven maturity across domains**: excellent for CLI tools and web backends, but significantly lacking in other domains such as embedded and safety-critical applications. This creates a fragmented adoption landscape where Rust's reputation varies dramatically depending on your domain. > "Biggest reason people don't use Rust is that the ecosystem they'd be entering > into is not what they expect. It doesn't have the tooling that C++ has nor the > libraries." -- Developer for a large tech company > "I think the amount of choice you can have often makes it difficult to make > the right choice" -- Developer transitioning from high-level languages > "the crates to use are sort of undiscoverable... There's a layer of tacit > knowledge about what crates to use for specific things that you kind of gather > through experience" -- Web developer The problem isn't lack of libraries—it's that choosing the right ones requires expertise that newcomers don't have. The Rust Project has made this choice mostly intentionally though: it has chosen not to bless certain crates in order to not unduly stifle innovation. The expectation is that if a newer crate ends up being "better" than some well-established crate, then that newer crate should be become more popular; but, if the Project recommends using the more established crate, then that is less likely to happen. This is a tradeoff that might be worth reevaluating, or finding clever solutions to. ## How challenges amplify differently across domains While the core challenges are universal, different domains have unique challenges that ultimately must be either adoption blockers or acceptable trade-offs. ### Embedded systems: where every constraint matters Embedded developers face the most constrained environment for resources, which can amplify other challenges like learning. > "if you pull in a crate, you pull in a lot of things and you have no control" > -- Embedded systems researcher > "can't use standard collections like hashmaps" -- Embedded software engineer Debug builds become too large for small controllers, forcing developers into optimized builds that complicate debugging. Cross-compilation adds another layer of complexity. The "no-std" ecosystem, while growing, still has significant gaps. ### Safety-critical systems: stability vs. innovation tension Safety-critical developers need Rust's memory safety guarantees, but face unique challenges around certification and tooling: > "we don't have the same tools we have to measure its safety criticality as we > do in C++ and I think it's a worry point" -- Safety systems engineer > "not a lot of people know Rust not a lot of managers actually trust that this > is a technology that's here to stay" -- Safety-critical developer on > organizational barriers The tension between Rust's rapid evolution and safety-critical requirements for stability creates adoption barriers even when the technical benefits are clear. To note, we [previously][1] wrote a blog post all about safety-critical Rust. Check it out! ### GUI development: compile times inhibit iteration speed GUI developers need rapid visual feedback, making compilation times particularly painful: > We've got a UI framework that's just Rust code so when you want to tweak the > padding on a box ... it's a pain that we just kind of accept a 10 seconds or > more iteration cycle. -- Developer working on a GUI app ## Background-dependent learning paths One important insight gained from this work, and it seems obvious if you think about it, is that learning Rust isn't a universal experience: it depends heavily on your background: **High-level language developers** must learn systems concepts alongside Rust: > The challenge for me was I needed to grasp the idea of a lower-level computer > science ideas and Rust at the same time. -- Developer with Typescript > background **Low-level developers** often struggle to unlearn patterns and concepts: > I'm coming from C++ world so I had the big class that does everything. Taken a > while for me to internalize that "dude you gotta go down a level". -- > Developer with C++ background > Rust tried to hide away notion of pointers - Just tell me it's a pointer -- > System-level developer Interestingly though, learning Rust alongside C++ can help students understand both better: > Students learn smart pointers in C++ and then 'we're just now learning smart > pointers with Rust as well' — learning both at the same time makes it easier. > -- Community organizer ## Recommendations ### Invest in compilation performance as a first-class concern Given that compilation performance affects every single user group, we recommend treating it as a first-class language concern, not just an implementation detail. This could include: * **Incremental compilation improvements** that better match developer workflows * **Build system innovations** that reduce the iteration cycle tax * **Tooling integration** that makes build times less disruptive We do want to quickly shout a couple of neat community projects that have this goal in mind: * The [subsecond crate][2] by the Dioxus team allows hot-reloading, which can make workflows like those found in GUI development more seamless * The [Wild linker][3] aims to be a fast linker for Linux, with plans for incremental linking ### Invest in ecosystem guidance and compatibility We [previously][4] made some suggestions in this area, and they still hold true. Finding ways to not only help users find crates that are useful to them, but also enable better compatibility between crates will surely have a net-positive benefit to the Rust community. ### Address learning diversity When someone is learning Rust, their programming language background, level of experience, and domain in which they are trying to work in, all influence the challenges they face. We recommend that the Rust Project and the community find ways to *tailor* learning paths to individuals' needs. For example, for someone with a C or C++ background, it might be useful to be able to directly compare references to pointers. Similarly, having domain-specific learning materials can help newcomers focus on the problems they are facing more specifically than a general "Rust tutorial" might. The [Embedded Rust Book][5] does this, for example. ### Close the gap between sync and async Rust This is a tall order -- there are a lot of moving parts here, but it's clear that many people struggle. On one hand, async Rust feels often "incomplete" in some language features compared to sync Rust. On the other, documentation is often focused on sync Rust (for example, much of [The Rust Programming Language Book][6] is focused on sync code patterns). Within the Rust Project, we can work towards stabilizing long-awaited features such as async functions in dyn traits, or improving compiler errors for issues with, for example, lifetimes and async code. We can include fundamental async library traits and functions within `std`, enabling a more cohesive async ecosystem. Of course, as much as can be done *within* the Rust Project, even getting more community involvement in producing tutorials, example code, and otherwise just sharing knowledge, can go a long way to closing the gap. ## Conclusion Rust's challenges are more nuanced than the conventional "steep learning curve" narrative suggests. They are domain-specific and evolve with experience. Understanding these patterns is crucial for Rust's continued growth. As we work to expand Rust's reach, we need to address not just the initial learning curve, but the ongoing friction that affects productivity across all experience levels. The good news is that recognizing these patterns gives us recommendations for improvement. By acknowledging the expertise gradient, prioritizing compilation performance, creating better ecosystem navigation, and addressing background-dependent challenges, we can help Rust fulfill its promise of empowering everyone to build reliable, efficient software. [1]: https://blog.rust-lang.org/2026/01/14/what-does-it-take-to-ship-rust-in-saf ety-critical/ [2]: https://crates.io/crates/subsecond [3]: https://github.com/davidlattimore/wild [4]: https://blog.rust-lang.org/2025/12/19/what-do-people-love-about-rust/#help- users-get-oriented-in-the-rust-ecosystem [5]: https://blog.rust-lang.org/2026/03/20/rust-challenges/docs.rust-embedded.or g/book/ [6]: https://doc.rust-lang.org/book/title-page.html
official
practical
release
rust
ai-dev-tools
devex
engineering
Cody's Take: Looks actionable. Could change how you ship code this week. official signal.
Why care: relevant to Rust tooling or ecosystem changes; touches developer experience or workflow; comes from an official source from google-developers-ai
While keynotes are available online, Google Cloud Next '26 in Las Vegas offers an irreplaceable in-person experience centered on networking, hands-on problem solving, and the transition to agentic AI. The event features specialized technical tracks covering everything from Gemini multimodal breakthroughs to zero-trust security on Cloud Run, providing developers with the tools to balance individual speed with organizational stability. Beyond formal sessions, the "in-person advantage" lies in over 20 developer meetups and collaborative whiteboard sessions designed to foster serendipitous breakthroughs. Ultimately, the conference serves as a high-energy hub for engineers to move beyond the hype and master the modern building blocks of software architecture together.
2026-03-10
official
practical
copilot
ai-dev-tools
devex
engineering
Cody's Take: Looks actionable. Could change how you ship code this week. official signal.
Why care: relevant to Copilot or AI coding workflows; touches developer experience or workflow; comes from an official source from github-blog
AI is shifting from prompt-response interactions to programmable execution. See how the GitHub Copilot SDK enables agentic workflows directly inside your applications. The post [The era of “AI as text” is over. Execution is the new interface.][1] appeared first on [The GitHub Blog][2]. [1]: https://github.blog/ai-and-ml/github-copilot/the-era-of-ai-as-text-is-over- execution-is-the-new-interface/ [2]: https://github.blog
2026-03-13
official
practical
release
rust
devex
Cody's Take: Looks actionable. Rust folks should perk up. official signal.
Why care: relevant to Rust tooling or ecosystem changes; touches developer experience or workflow; comes from an official source from rust-blog
We would welcome people to try and report issues with the nightly-only `cargo -Zbuild-dir-new-layout`. While the layout of the [build dir][1] is internal-only, many projects need to rely on the unspecified details due to missing features within Cargo. While we've performed a [crater run][2], that won't cover everything and we need help identifying tools and process that rely on the details, reporting issues to these projects so they can update to the new layout or support them both. ## How to test this? With at least nightly 2026-03-10, run your tests, release processes, and anything else that may touch build-dir/target-dir with the `-Zbuild-dir-new-layout` flag. For example: `$ cargo test -Zbuild-dir-new-layout ` Note: if you see failures, the problem may not be isolated to just `-Zbuild-dir-new-layout`. With [Cargo 1.91][3], users can separate where to store intermediate build artifacts (build-dir) and final artifacts (still in target-dir). You can verify this by running with only `CARGO_BUILD_BUILD_DIR=build` set. We are evaluating changing the default for build-dir in [#16147][4]. Outcomes may include: * Fixing local problems * Reporting problems in upstream tools with a note on the [the tracking issue][5] for others * Providing feedback on the [the tracking issue][6] Known failure modes: * Inferring a `[[bin]]`s path from a `[[test]]`s path: * Use [`std::env::var_os("CARGO_BIN_EXE_*")`][7] for Cargo 1.94+, maybe keeping the inference as a fallback for older Cargo versions * Use [`env!("CARGO_BIN_EXE_*")`][8] * Build scripts looking up target-dir from their binary or `OUT_DIR`: see [Issue #13663][9] * Update current workarounds to support the new layout * Looking up user-requested artifacts from rustc, see [Issue #13672][10] * Update current workarounds to support the new layout Library support status as of publish time: * [assert_cmd][11]: fixed * [cli_test_dir][12]: [Issue #65][13] * [compiletest_rs][14]: [Issue #309][15] * [executable-path][16]: fixed * [snapbox][17]: fixed * [term-transcript][18]: [Issue #269][19] * [test_bin][20]: [Issue #13][21] * [trycmd][22]: fixed ## What is not changing? The layout of final artifacts within [target dir][23]. Nesting of build artifacts under the profile and the target tuple, if specified. ## What is changing? We are switching from organizing by content type to scoping the content by the package name and a hash of the build unit and its inputs. Here is an example of the current layout, assuming you have a package named `lib` and a package named `bin`, and both have a build script: `build-dir/ ├── CACHEDIR.TAG └── debug/ ├── .cargo-lock # file lock protecting access to this location ├── .fingerprint/ # build cache tracking │ ├── bin-[BU ILD_SCRIPT_RUN_HASH]/* │ ├── bin-[BUILD_SCRIPT_BIN_HASH]/* │ ├── bin-[HASH]/* │ ├── lib-[BUILD_SCRIPT_RUN_HASH]/* │ ├── lib-[BUILD_SCRIPT_BIN_HASH]/* │ └── lib-[HASH]/* ├── build/ │ ├── bin-[BIN_HASH]/* # build script binary │ ├── b in-[RUN_HASH]/out/ # build script run OUT_DIR │ ├── bin-[RUN_HASH]/* # build sc ript run cache │ ├── lib-[BIN_HASH]/* # build script binary │ ├── lib-[RUN_HAS H]/out/ # build script run OUT_DIR │ └── lib-[RUN_HASH]/* # build script run ca che ├── deps/ │ ├── bin-[HASH]* # binary and debug information │ ├── lib-[HAS H]* # library and debug information │ └── liblib-[HASH]* # library and debug in formation ├── examples/ # unused in this case └── incremental/... # managed by rustc ` The proposed layout: `build-dir/ ├── CACHEDIR.TAG └── debug/ ├── .cargo-lock # file lock protecting access to this location ├── build/ │ ├── bin/ # package name │ │ ├── [BUILD_S CRIPT_BIN_HASH]/ │ │ │ ├── fingerprint/* # build cache tracking │ │ │ └── out/ * # build script binary │ │ ├── [BUILD_SCRIPT_RUN_HASH]/ │ │ │ ├── fingerprint /* # build cache tracking │ │ │ ├── out/* # build script run OUT_DIR │ │ │ └── run/* # build script run cache │ │ └── [HASH]/ │ │ ├── fingerprint/* # build cache tracking │ │ └── out/* # binary and debug information │ └── lib/ # packa ge name │ ├── [BUILD_SCRIPT_BIN_HASH]/ │ │ ├── fingerprint/* # build cache tra cking │ │ └── out/* # build script binary │ ├── [BUILD_SCRIPT_RUN_HASH]/ │ │ ├── fingerprint/* # build cache tracking │ │ ├── out/* # build script run OUT_D IR │ │ └── run/* # build script run cache │ └── [HASH]/ │ ├── fingerprint/* # build cache tracking │ └── out/* # library and debug information └── incremen tal/... # managed by rustc ` For more information on these Cargo internals, see the [`mod layout` documentation][24]. ## Why is this being done? [ranger-ross][25] has worked tirelessly on this as a stepping stone to [cross-workspace caching][26] which will be easier when we can track each cacheable unit in a self-contained directory. This also unblocks work on: * [Automatic cleanup of stale build units][27] to keep disks space use constant over time * [More granular locking][28] so `cargo test` and rust-analyzer don't block on each other Along the way, we found this helps with: * [Build performance][29] as the intermediate artifacts accumulate in `deps/` * [Content of `deps/` polluting `PATH` during builds on Windows][30] * [Avoiding file collisions among intermediate artifacts][31] While the Cargo team does not officially endorse sharing a `build-dir` across workspaces, that last item should reduce the chance of encountering problems for those who choose to. ## Future work We will use the experience of this layout change to help guide how and when to perform any future layout changes, including: * Efforts to reduce path lengths to reduce risks for errors for developers on Windows * Experimenting with moving artifacts out of the `--profile` and `--target` directories, allowing sharing of more artifacts where possible In addition to narrowing scope, we did not do all of the layout changes now because some are blocked on the lock change which is blocked on this layout change. We would also like to work to decouple projects from the unspecified details of build-dir. [1]: https://doc.rust-lang.org/cargo/reference/build-cache.html [2]: https://github.com/rust-lang/rust/pull/149852 [3]: https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-191-2025-10-30 [4]: https://github.com/rust-lang/cargo/issues/16147 [5]: https://github.com/rust-lang/cargo/issues/15010 [6]: https://github.com/rust-lang/cargo/issues/15010 [7]: https://doc.rust-lang.org/cargo/reference/environment-variables.html#enviro nment-variables-cargo-sets-for-cargo-test [8]: https://doc.rust-lang.org/cargo/reference/environment-variables.html#enviro nment-variables-cargo-sets-for-crates [9]: https://github.com/rust-lang/cargo/issues/13663 [10]: https://github.com/rust-lang/cargo/issues/13672 [11]: https://crates.io/crates/assert_cmd [12]: https://crates.io/crates/cli_test_dir [13]: https://github.com/emk/subtitles-rs/issues/65 [14]: https://crates.io/crates/compiletest_rs [15]: https://github.com/Manishearth/compiletest-rs/issues/309 [16]: https://crates.io/crates/executable-path [17]: https://crates.io/crates/snapbox [18]: https://crates.io/crates/term-transcript [19]: https://github.com/slowli/term-transcript/issues/269 [20]: https://crates.io/crates/test_bin [21]: https://github.com/MichaelMcDonnell/test_bin/issues/13 [22]: https://crates.io/crates/trycmd [23]: https://doc.rust-lang.org/cargo/reference/build-cache.html [24]: https://doc.rust-lang.org/nightly/nightly-rustc/cargo/core/compiler/layout /index.html [25]: https://github.com/ranger-ross/ [26]: https://github.com/rust-lang/cargo/issues/5931 [27]: https://github.com/rust-lang/cargo/issues/5026 [28]: https://github.com/rust-lang/cargo/issues/4282 [29]: https://github.com/rust-lang/cargo/issues/16665 [30]: https://github.com/rust-lang/cargo/issues/7919 [31]: https://github.com/rust-lang/cargo/issues/16673
