# Rust Blog Empowering everyone to build reliable and efficient software. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Be alert: targeted attacks on prominent Rustaceans DevFeed: [Be alert: targeted attacks on prominent Rustaceans]() Original publisher: [Read original article]() Author: Adam Harvey Published: 2026-09-17T00:00:00Z Content type: news Language: en Sources: [Rust Blog]() Topics: [Security](), [Malware](), [Rust]() Tags: [attacks](), [developers](), [malware](), [mfa](), [rust](), [security]() ### AI overview The Rust project warns of an ongoing campaign targeting Rust community members and maintainers of popular crates. Attackers use seemingly legitimate job or project outreach, video calls, fake company profiles, and malicious commands or software to compromise devices and accounts and publish malware. The advisory recommends using trusted call platforms, checking account activity, and enabling MFA. ### Source excerpt We believe that there is an ongoing campaign targeting rust-lang members and owners of popular crates that is attempting to compromise devices and accounts in order to use them to publish malware. What we've seen A video call is set up for something positive -- maybe for a job, maybe for a project, maybe for a contract opportunity -- and then that's used as a vector to either get the target to install something on their computer (such as a purportedly missing audio codec) or execute another command (for example, via putting a command on the clipboard). These attackers are setting up new but legitimate seeming company profiles, including plausible LinkedIn presences, in order to pass cursory inspection. A previous attack of this form targeted many prominent Rust developers in June, and, last month, the arrayref crate was briefly compromised through similar attacks. At this moment we do not know if these are all a part of the same campaign. This attack style is known to be used by the DPRK, and has been seen outside of the Rust community as well. What you can do Please take extra care in the near term. Be appropriately suspicious of cold outreaches, and ensure that any calls you have with new people are on platforms you trust -- ideally, try to be the one who sets up the call on a platform you already use. Please also re-check that your accounts look normal: MFA enabled, no unexpected logins on platforms that can track that, and so on. If you have any concerns about your accounts, please reach out to help@crates.io (for crates.io account concerns) and/or security@rust-lang.org (for any other concerns). We're very happy to help. ## Rust debugging survey 2026 results DevFeed: [Rust debugging survey 2026 results]() Original publisher: [Read original article]() Author: Sam Kellam Published: 2026-09-07T00:00:00Z Content type: article Language: en Sources: [Rust Blog]() Topics: [debugging](), [Rust](), [ide](), [Command-line interface]() Tags: [2026](), [command-line](), [debugger](), [debugging](), [developers](), [ide](), [rust](), [survey]() ### AI overview The Rust project reports results from its first Rust Debugging Survey, which received more than 2,300 responses. The article examines who uses debuggers, how Rust developers debug programs, and the debugging challenges they encounter. More than 46% of respondents currently use debuggers, while print debugging and the macro are widely used, followed by debugging inside an IDE and on the command line. ### Source excerpt One of the biggest challenges Rust developers report in our annual surveys is a subpar debugging experience. So, back in February, we ran our first Rust Debugging Survey, in the hopes of identifying how Rust developers are using debuggers and what problems they are facing when doing so. We received over 2,300 responses, and we'd like to thank everyone who took the time to participate in the survey! In this report, we'll go over some of the results of the survey. If you'd like, you can also check out the complete results of the survey. If you'd like to skip ahead to any particular section, you can do so with this index: Who Uses Debuggers? How Are Debuggers Used? Challenges Debugger Visualizers Closing Remarks Who Uses Debuggers? The first step to making sense of the survey results is understanding who took the survey. We asked respondents to rate their Rust expertise, from "Never used it" to "Advanced". Over 80% reported themselves as "Advanced" or "Intermediate", split roughly evenly between the two: [PNG] [SVG] We also asked respondents if they currently use or have used debuggers in Rust. Over 46% said they currently do, with the remaining responses split between "have in the past" and "never have". That means that over half of respondents do not currently use a debugger for Rust! [PNG] [SVG] Categorized by expertise, the responses reveal that roughly half of "beginners" have never used debuggers in Rust! On the other hand, nearly half of "advanced users" currently do use debuggers in Rust: [PNG] [SVG] For respondents who indicated they had previously used Rust but no longer did, we asked if challenges with debugging support were why they stopped. For nearly 3%, the answer was "yes", with an additional 24% reporting debugging issues as being partially responsible (though mind the small response count; most respondents were active users of Rust): [PNG] [SVG] How Are Debuggers Used? Knowing what debuggers developers are using and how is another important part of un ## Announcing Rust 1.98.1 DevFeed: [Announcing Rust 1.98.1]() Original publisher: [Read original article]() Author: The Rust Release Team Published: 2026-09-03T00:00:00Z Content type: release Language: en Sources: [Rust Blog]() Topics: [releases](), [ci]() Tags: [bugs](), [ci](), [release](), [rust](), [update]() ### AI overview Rust 1.98.1 is a point release that fixes a vtable-generation miscompilation which could produce undefined behavior, including null-pointer segfaults or arbitrary effects. ### Source excerpt The Rust team has published a new point release of Rust, 1.98.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.98.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.98.1 Rust 1.98.1 fixes a miscompilation in vtable generation. In Rust 1.98.0, in some circumstances, rustc would incorrectly generate a trait object vtable with a null pointer where a function pointer should be. This leads to undefined behavior in the emitted code. In some cases this may 'just' cause segfaults due to the null pointer being loaded, but it is possible for it to be justification for arbitrary effects (as is typical for UB). If you'd like to help us out by testing future releases, you might consider using the beta (rustup default beta) and nightly (rustup default nightly) channels locally and in your CI. Please report any bugs you might come across! Contributors to 1.98.1 Many people came together to create Rust 1.98.1. We couldn't have done it without all of you. Thanks! ## Announcing rustup 1.29.1 DevFeed: [Announcing rustup 1.29.1]() Original publisher: [Read original article]() Author: The Rustup Team Published: 2026-09-01T00:00:00Z Content type: release Language: en Sources: [Rust Blog]() Topics: [releases]() Tags: [bug](), [cli](), [concurrency](), [docs](), [http](), [releases](), [rust](), [toolchain](), [update](), [windows]() ### AI overview Rustup 1.29.1 improves concurrent update and component-install operations, adds local HTTP documentation serving, and changes several installation behaviors. The release also fixes Windows-related installation issues and updates target terminology. ### Source excerpt The rustup team is happy to announce the release of rustup version 1.29.1. Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software. What's new in rustup 1.29.1 The headlines of this release are: Concurrency in certain rustup operations has been improved: When running rustup update, rustup will first check for possible updates in parallel. pr#4752 When running rustup component add with multiple components, they will be installed concurrently. pr#4790 Implicit installation of the active toolchain in rustup-init and rustup invocations has been deprecated where deemed unnecessary and will now produce a warning. pr#4840 Please see our blog post for more details regarding this change. rustup doc now supports the --serve flag which allows serving the docs over local HTTP. This should help users with containerized browser and/or rustup setups. pr#4986 Installing i686-pc-windows-* host toolchains on 64-bit Windows now requires --force-non-host. pr#4935 rustup-init will no longer leave unexpected files on disk after cancelled installations. pr#4996 A bug has been fixed which might cause Windows installation to fail when using rustup-init.sh. pr#4756 "Target triple" has been renamed to "target tuple" across the project to reflect the new terminology. pr#4743 pr#4827 pr#4834 Please note that this is not a breaking change in the CLI since the existing options such as --target are not using this terminology. In addition, rustup now officially supports aarch64-pc-windows-gnullvm as a host platform. pr#4523 Further details are available in the changelog! How to update If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running: $ rustup self update Rustup will also automatically update itself at the end of a normal toolchain update: $ rustup update If you don't have it already, you can get rustup ## Announcing our first Maintainers in Residence DevFeed: [Announcing our first Maintainers in Residence]() Original publisher: [Read original article]() Author: Lori Lorusso, Jakub Beránek Published: 2026-08-26T00:00:00Z Content type: article Language: en Sources: [Rust Blog]() Topics: [Rust](), [Maintainers](), [Amazon Web Services](), [Google](), [OpenAI]() Tags: [aws](), [blog](), [contributors](), [google](), [maintainers](), [openai](), [rust](), [support]() ### AI overview The Rust Project announces its first Maintainers in Residence and Maintainer Grant recipients, with funding for at least 12 months through the Rust Foundation Maintainers Fund. The article explains the program's support categories, selection process, and focus on strengthening critically underfunded, high-impact Rust teams. ### Source excerpt We are very happy to announce the Rust Project's first round of Maintainers in Residence: Gen Li (@rami3l), Chris Denton (@ChrisDenton), Alejandra González (@blyxyas), León Liehr (@fmease), and Maintainer Grant recipients: Jason Newcomb (@Jarcho) and Jonas Böttiger (@joboet). These contributors will be funded for their rust-lang maintenance activities for (at least) the following 12 months! The funding of the Maintainer in Residence (MiR) and Maintainer Grantee roles is possible thanks to generous donations to the Rust Foundation Maintainers Fund (RFMF) from Google, AWS, OpenAI, the Rust Project Leadership Council and also individual sponsors. We also want to thank the people who advocated for maintainer funding within their companies; Tyler Mandry from Google, Niko Matsakis and Jess Izen from AWS and Predrag Gruevski from OpenAI, and also the whole Rust Leadership Council and our funding advisors. If you would like to help us support even more Rust contributors, consider donating to RFMF. The Rust Foundation has published a press release and a blog post, where you can learn more about the sponsors and the supported contributors. Read more below to learn about the MiR program, how we chose the funded contributors, and of course who they are! Background The Maintainer in Residence program, established in RFC 3931, is designed to provide stable financial support for Rust contributors, so that they can truly focus on crucial maintenance activities. Currently, there are three categories of support that we offer: Full-time MiR: funded for 5 days/week of Rust Project work Half-time MiR: funded for ~2.5 days/week of Rust Project work Maintainer Grant: funded for ~1 day/week of Rust Project work Funding for this program comes from the Rust Foundation Maintainers Fund, which was launched recently, and the whole program is managed by the Rust Funding team. When deciding who to fund, we took a systematic approach. First, we looked at Rust teams to understand their maintenance ## Enabling the next-generation trait solver on nightly DevFeed: [Enabling the next-generation trait solver on nightly]() Original publisher: [Read original article]() Author: lcnr Published: 2026-08-21T00:00:00Z Content type: article Language: en Sources: [Rust Blog]() Topics: [toolchain]() Tags: [bugs](), [diagnostics](), [inference](), [performance](), [rust](), [types]() ### AI overview Rust is enabling its next-generation trait solver by default on nightly ahead of planned stabilization. The compiler-internal replacement changes trait and associated-type handling, fixes many known issues, and needs testing for breakage, performance regressions, and diagnostics. ### Source excerpt After nearly 4 years of active development, the next-generation trait solver is close to stabilization. We are enabling it by default on nightly to surface any remaining issues and plan to stabilize it in the next months. This is the largest single change to the Rust compiler since its initial release. It completely replaces how we prove where-clauses, normalize associated types, and much more. Please try out the latest nightly and open an issue if you encounter any bugs or regressions. This is an internal component of the compiler. The main benefits of this rework will come in the future. The removal of the old implementation will unblock features such as Type Alias Impl Trait and Return Type Notation, allow us to add new implicit default trait bounds (e.g., Move and Forget), and enable us to fix the remaining type system unsoundnesses. Even so, this already fixes a huge number of issues. As an underapproximation, we currently know of more than 200 issues on GitHub fixed by this change. This also has a significant impact on compile times; more on that later. When developing on nightly, you may accidentally rely on behavior only supported by the new trait solver. This is an incredibly big change which results in a non-trivial amount of breakage. Most of these changes are intended improvements to type inference or the removal of undesirable behavior. We are tracking the known issues and breakage in a pinned GitHub issue. What can I do? Please update to the latest nightly version by using rustup update nightly and use it to test your existing projects and libraries. Please tell us if you encounter any breakage, compile-time performance regression, or bad diagnostics. We have not yet spent too much time on error messages for the next-generation trait solver, so we would also appreciate you using this nightly for development to find poor diagnostics and other bugs in our error handling. If you encounter any issue, take a quick look at the pinned GitHub issue to see if t ## Supply chain attack on arrayref DevFeed: [Supply chain attack on arrayref]() Original publisher: [Read original article]() Author: Manish Goregaokar Published: 2026-08-20T00:00:00Z Content type: news Language: en Sources: [Rust Blog]() Topics: [Rust](), [Security]() Tags: [local](), [payload](), [research](), [rust](), [security](), [supply-chain]() ### AI overview The Rust Security Response Team confirmed a supply-chain attack involving malicious crates. A compromised build script downloaded a malicious payload, leading to the deletion or yanking of affected versions and the locking of a potentially compromised account. Developers are advised to inspect their local Cargo registry cache for the listed crates and versions. ### Source excerpt What happened On 2026-08-20 at 7:15 UTC we got a report that the proc-macro1 crate was malicious. The Rust Security Response Team verified this to be the case: the crate had a build script that was downloading a malicious payload. This crate proc-macro1 and others like it (proc-macro-en, aovine, arone, aronenao, tinymember) have been deleted. Furthermore, we discovered that the popular arrayref crate had recently been republished and made to depend on this crate, with the most recent versions yanked. We have removed the malicious version and unyanked the maliciously-yanked versions. Other crates by that author (internment, append-only-vec) were also affected so we have done the same for those, and locked the account as a precaution. We do not believe the author of arrayref to be acting maliciously, but their computer or credentials are likely compromised, and we are attempting to contact them. What you need to do We recommend you check your local dependencies to ensure these crates were not pulled in. Here are the malicious versions that we deleted from crates.io: append-only-vec@0.1.9: published at 2026-08-20T07:37:49Z, deleted at 2026-08-20T09:25:24Z. Online for 107 minutes. arrayref@0.3.10: published at 2026-08-20T07:15:00Z, deleted at 2026-08-20T08:41:40Z. Online for 86 minutes. internment@0.8.7: published at 2026-08-20T07:34:07Z, deleted at 2026-08-20T09:04:11Z. Online for 90 minutes. proc-macro1, proc-macro-en, aovine, arone, aronenao, tinymember (any versions). You can quickly check if these crates have been used locally by going through ~/.cargo/registry/cache with this command: find ~/.cargo/registry/cache -type f \( \ -name 'append-only-vec-0.1.9.crate' -o \ -name 'arrayref-0.3.10.crate' -o \ -name 'internment-0.8.7.crate' -o \ -name 'proc-macro1-*.crate' -o \ -name 'proc-macro-en-*.crate' -o \ -name 'aovine-*.crate' -o \ -name 'arone-*.crate' -o \ -name 'aronenao-*.crate' -o \ -name 'tinymember-*.crate' \ \) -print Thanks We'd like to thank the Research T ## Announcing Rust 1.98.0 DevFeed: [Announcing Rust 1.98.0]() Original publisher: [Read original article]() Author: The Rust Release Team Published: 2026-08-20T00:00:00Z Content type: release Language: en Sources: [Rust Blog]() Topics: [releases]() Tags: [bugs](), [optimization](), [release](), [rust]() ### AI overview Rust 1.98.0 introduces algebraic floating-point methods that permit compiler optimizations and buffered integer formatting aimed at performance. The release also discusses a compiler bug affecting prior versions. ### Source excerpt The Rust team is happy to announce a new version of Rust, 1.98.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.98.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.98.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.98.0 stable Algebraic floating-point methods The floating-point types f32 and f64 now have "algebraic" methods for addition, subtraction, multiplication, division, and remainder. These allow optimizations on these operations using the algebraic properties of real numbers, even though these properties do not hold with the limitations of floating-point representations. The exact set of optimizations is not specified, but may be similar to the kind of optimization you would see with the -ffast-math option in other languages. For example, floating-point addition is not associative, so a sum like a + b + c + d must be evaluated in the left-associative order in which it is parsed, like ((a + b) + c) + d. If you write the same sum as a chain of algebraic_add calls, then the compiler is free to reorder it, perhaps like (a + b) + (c + d) to evaluate the partial sums simultaneously. Broader loop-vectorization is often enabled by using these algebraic methods as well. These methods are non-deterministic, since the compiler is free to choose different optimizations, but they never cause undefined behavior. See the library documentation and the original API change proposal for more details. Buffered integer formatting All of the primitive integer types now have a format_into method that takes a &mut NumBuffer parameter, which i ## Enabling the next iteration of the borrow checker on nightly DevFeed: [Enabling the next iteration of the borrow checker on nightly]() Original publisher: [Read original article]() Author: Jack Huey Published: 2026-08-04T00:00:00Z Content type: article Language: en Sources: [Rust Blog]() Topics: [Rust](), [Code]() Tags: [code](), [performance](), [rust](), [testing]() ### AI overview Rust is enabling the Polonius Alpha borrow checker on nightly for testing ahead of planned stabilization. The new formulation provides flow-sensitive borrow checking for lifetime outlives relationships, potentially allowing code that current NLL borrow checking rejects, while nightly testing will help identify performance regressions, unsoundness, and diagnostic issues. ### Source excerpt TL;DR We are enabling the next iteration of the borrow checker (coined Polonius Alpha) on nightly in preparation for stabilization in the next few months. Whaaaaaat? Yes! You heard it right! The next iteration of the Rust borrow checker is coming! Rust's first borrow checker ("AST borrowck") was very limited and was phased out in 2019 in favor of NLL, other than a "migrate mode" that was used to provide nice error messages. That migrate mode was finally removed in 2022. The Polonius borrow checker spun out of the NLL effort in 2018. The initial formulation passed the NLL test suite and accepted (sound) code that NLL did not. However, performance was a critically-limiting factor; generally borrow check was slower than NLL, but certain programs were considerably slower than NLL to the extent that using that implementation/formulation of Polonius was a non-starter. Attempts were made over the years to implement the Polonius formulation in a performant manner, without much luck in addressing the core issues. In 2023, a new formulation of a Polonius-style borrow checker was imagined that required minimal rearchitecture of the existing NLL implementation and could be extended to allow more code to compile. We had hoped, to try to stabilize this new formulation in 2024; but, various things popped up that delayed this. But! We're nearly there now! At this point, there are no known remaining issues with the subset coined Polonius Alpha that we intend to stabilize. And, performance is generally acceptable for stabilization (will discuss that a bit below). So, we are enabling the Polonius Alpha borrow checker on nightly for testing until we stabilize fully later in the year. We're doing this in order to help find: Any serious performance regressions we're unaware of Unsoundness in the formulation that we haven't thought about Any weird diagnostic issues that we need to improve Note: we have not yet seen any diagnostic changes You can report any issues on Github or on Zulip. Ok ## Announcing Rust 1.97.1 DevFeed: [Announcing Rust 1.97.1]() Original publisher: [Read original article]() Author: The Rust Release Team Published: 2026-07-16T00:00:00Z Content type: release Language: en Sources: [Rust Blog]() Topics: [Rust](), [releases](), [LLVM](), [Optimization](), [Programming language](), [Beta channel](), [ci]() Tags: [beta-channel](), [bugs](), [ci](), [llvm](), [optimization](), [programming-language](), [release](), [releases](), [rust](), [update]() ### AI overview Rust 1.97.1 is a point release that fixes a miscompilation related to an LLVM optimization. The release backports an LLVM fix and disables the underlying change in Rust 1.97.0 that increased the likelihood of the issue. ### Source excerpt 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! ## crates.io: development update DevFeed: [crates.io: development update]() Original publisher: [Read original article]() Author: Tobias Bieniek Published: 2026-07-13T00:00:00Z Content type: article Language: en Sources: [Rust Blog]() Topics: [Code](), [Syntax Highlighting](), [Authentication](), [servers](), [JSON](), [Front end](), [releases](), [json-ld]() Tags: [authentication](), [code](), [development](), [frontend](), [github](), [http](), [identity](), [json](), [releases]() ### AI overview This development update describes major crates.io improvements, including a source code viewer for published crate versions, searchable file trees, syntax highlighting, shareable line selections, and planned version-to-version diffs. It also explains the archive and manifest infrastructure used to serve files efficiently and outlines work to make crates.io usernames independent of GitHub accounts, enabling future support for other identity providers. ### Source excerpt 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