Rust Blog
blog.rust-lang.org · Company blog · on HN since 2014
The official Rust project blog, with release news, roadmaps, language design posts, and survey results.
What HN saysHN commenters cite it for language and compiler changes, including the borrow checker rework, plus cargo and tooling discussions.
533HN people shared it
313linked it in comments
605stories submitted
42Kstory points
2 months agolast shared
2014people per year2026
Most-shared posts
- 1Fearless concurrency with Rust28 people · 544 points · first shared 2015 · 179 comments on HN
- 2Stability as a Deliverable20 people · 148 points · first shared 2014 · 41 comments on HN
- 3Announcing the Keyword Generics Initiative16 people · 28 points · first shared 2022 · 4 comments on HN
- 4Introducing MIR15 people · 736 points · first shared 2016 · 164 comments on HN
- 5Fearless Concurrency in Firefox Quantum13 people · 628 points · first shared 2017 · 174 comments on HN
- 62023 Annual Rust Survey Results11 people · 40 points · first shared 2024 · 2 comments on HN
- 7Rust's 2018 roadmap10 people · 515 points · first shared 2018 · 244 comments on HN
- 8Shape of errors to come10 people · 425 points · first shared 2016 · 161 comments on HN
- 9Rust 1.0: Scheduling the trains9 people · 330 points · first shared 2014 · 183 comments on HN
- 10Security vulnerability in Rust standard library9 people · 88 points · first shared 2022 · 41 comments on HN
- 11Polonius Update – Inside Rust Blog9 people · 5 points · first shared 2023 · discussion on HN
- 12Announcing Rust 1.08 people · 1.4K points · first shared 2015 · 306 comments on HN
- 13The Road to Rust 1.08 people · 570 points · first shared 2014 · 238 comments on HN
- 14Abstraction without overhead: traits in Rust8 people · 212 points · first shared 2015 · 137 comments on HN
- 15The Push for GATs Stabilization8 people · 33 points · first shared 2021 · discussion on HN
What HN people wrote when they linked it
aw1621107 · 2026-08-10
For a bit of context, this is the basis of what the Rust devs would eventually call Polonius. This first iteration didn't quite pan out, but the devs eventually developed a new version [0] that seems to have worked out to the point that they recently announced that they are enabling a subset of this new version (called Polonius Alpha) in nightly with the intent to stabilize later this year [1].
[0]: https://smallcultfollowing.com/babysteps/series/polonius-revisited/
[1]: https://blog.rust-lang.org/2026/08/04/enabling-polonius-alpha-on-night…
steveklabnik · 2026-07-16
> Does cve-rs break any type system rules?
Yes.
> If so, why hasn't it been fixed yet?
Pretty classic software engineering reasons.
The part of the system that it involves was in the process of being re-written already. The re-write fixes the bug. Because it is essentially a theoretical issue, and not an actual problem in any real code, it is not a five alarm fire. Waiting for that re-write to land makes the most sense, instead of putting in a ton of work that will be thrown away.
Other, more serious miscompilations get fixed faster. In fact, a version of the Rust compiler was released today to fix one, even https://blog.rust-lang.org/2026/07/16/Rust-1.97.1/
This one was impacting actual users, and did not require re-writing entire subsystems to fix properly. So the engineering and product tradeoffs are different.
epage · 2025-12-28
> It may have been nice to expose some reasonable defaults for code coverage measurements too.
Would love built in coverage support but investigation is needed on the design (https://github.com/rust-lang/cargo/issues/13040) and we likely need to redo how we handle doctests (https://blog.rust-lang.org/inside-rust/2025/10/01/this-development-cyc…
mplanchard · 2025-04-05
I love this. We are a rust shop and we use clickhouse a fair bit. We’ve been quite impressed with its speed and flexibility. I’m glad to see this kind of direct, real-world feedback around both the benefits and difficulties of mixing rust and C++, which we have also had to do a bit of (albeit in the opposite direction: a smattering of C++ in a sea of rust).
I’m not sure if the poster here is the post author, but it would be great if the author would consider filling out this survey that was recently released asking for feedback on the future of rust’s vision: https://blog.rust-lang.org/2025/04/04/vision-doc-survey.html
I’d love to see rust become the de facto standard for cross-language portable code by virtue of its ease of use, but as this and our experience highlights, there’s some way to go yet!
CJefferson · 2025-02-19
Well, of course you should, but it’s easy to forget as it’s not required. It also used to be recommended to not save it, so some people put it in their gitignore.
For example, here is a post saying it was previously recommended to not save it for libraries: https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html
Lammy · 2025-02-13
> more social media outrage and religious wars than any other technical project I have been following for the past 20 years.
It is unfortunately wrapped up in larger-scale outrage culture than just within tech/programming circles. Rust as a community is very gay and very trans:
https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-res…
https://blog.rust-lang.org/2025/02/13/2024-State-Of-Rust-Survey-result…
To be clear I am 111% down for that as one of the Alphabet People myself lol. We just can't pretend like it isn't a factor.
Disclaimer: I realize these numbers are probably skewed high due to self-selection of people who are willing to take diversity surveys. The actual percentages are probably somewhat lower, but Rust undoubtedly has the highest concentration of any programming-language community. Zero question.
estebank · 2024-12-24
It is also behavior that we want to change, it's just non-trivial to do so.
https://smallcultfollowing.com/babysteps/blog/2024/06/02/the-borrow-ch…
https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html
DylanSp · 2024-12-24
Case 1 is definitely addressed by the Polonius-related work. There's a post [1] on the official Rust blog from 2023 about that, and this post [2] from Niko Matsakis' blog in June 2024 mentions that they were making progress on it, though the timeline has stretched out.
[1]: https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html
[2]: https://smallcultfollowing.com/babysteps/blog/2024/06/02/the-borrow-ch…
willglynn · 2024-05-17
The best treatment is at:
https://blog.rust-lang.org/2024/03/30/i128-layout-update.html
Note also that this involves LLVM, so clang < 18 had the same u128 behavior as Rust < 1.77/1.78.
jokethrowaway · 2024-03-16
Over the years compile speed improved quite a bit (recently this: https://blog.rust-lang.org/2023/11/09/parallel-rustc.html made quite the difference)
If we can squeeze more performance that's great but the largest concern I have around compilation is with the size of the target directory
It can balloon up to node_modules levels
lifthrasiir · 2024-01-24
You have a good point and lock poisoning had the same reasoning, but wasn't really popular [1]. (In hindsight the poisoning itself was a great idea but should have been decoupled from locks.) Compared to other languages with similar constructs, Rust panic is probably regarded as less fatal because an incorrect but safe Rust code tends to have a limited reach.
Ah, and it should be also noted that some non-fatal signals were also delivered only via panic. The best-known example is a memory allocation failure, which is recoverable in Rust but needed unwinding for a long time. Nowadays you have an unsafe but non-unwinding alternative.
[1] https://blog.rust-lang.org/2020/12/11/lock-poisoning-survey.html
thesuperbigfrog · 2023-12-18
Mara's blog post also describes the benefits of standardizing Rust.
Since she created the RFC for standardizing Rust (https://github.com/rust-lang/rfcs/pull/3355) and is also on the team that is working on Rust standardization (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html), I think she was making the point that Rust has good controls in place for adding features while compatibility, not that "Rust does not need a standard".
If she really believed that Rust does not need a standard, why would she create the RFC and join the team working on the effort?
Rust is a great language. There is no reason why it should not have a standard to better formalize its requirements and behaviors.
andrewaylett · 2023-11-26
The advantages of Rust come when trying to do complex things with concurrency, and wanting to know that they're either going to be safe, or fail to compile.
Consider the now-classic "Fearless Concurrency" post about Stylo: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-…
Strictly, C++ pretty much has to be no slower than Rust. But it's certainly possible that a regular human might in practice write higher-performing parallel code when using Rust.
DougBTX · 2023-06-09
For Rust, pre-GAT, there was no way to “output” a type which could be “called” with further arguments (very fuzzy terminology, sorry, best I can do!) or maybe in other words, you could write functions which retuned values, but not new functions.
Nowadays, GATs support a bigger subset of HKTs, but still not everything as I understand it.
https://blog.rust-lang.org/2022/10/28/gats-stabilization.html
VWWHFSfQ · 2021-11-10
I love this kind of stuff! It's important for source code to be able to handle non-ASCII characters but we need to be mindful of the different ways that an editor will "lie" to you about your code. The most recent example of this in Rust [1].
> As part of their research, Nicholas Boucher and Ross Anderson also uncovered a similar security issue identified as CVE-2021-42694 involving homoglyphs inside identifiers. Rust already includes mitigations for that attack since Rust 1.53.0. Rust 1.0.0 through Rust 1.52.1 is not affected due to the lack of support for non-ASCII identifiers in those releases.
The easy reaction is "Why are we allowing non-ASCII characters at all? Just so we can put emojis in our variable names?"
This project is a good example of why we do it. But as with everything, we need to be careful about it.
[1] https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html
wolfadex · 2021-07-29
A little history of why Rust's error messages look and read they way they do:
- [1] back in 2015 Elm puts out a blog post titled Compiler Errors for Humans
- [2] then another, Compilers as assistants
- [3] then in 2016 Rust announces they'll borrow from Elm for error messages
Really great that the students were able to see how much the Rust community cares about error message quality.
1. https://elm-lang.org/news/compiler-errors-for-humans
2. https://elm-lang.org/news/compilers-as-assistants
3. https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html
andy_threos_io · 2021-07-07
Just a not so recent news from the rust compiler:
https://blog.rust-lang.org/2021/05/10/Rust-1.52.1.html
"The Rust team has prepared a new release, 1.52.1, working around a bug in incremental compilation which was made into a compiler error in 1.52.0. We recommend all Rust users, including those currently using stable versions prior to 1.52.0, upgrade to 1.52.1 or disable incremental compilation. Guidance on how to do so is available below."
Is this mature enough to be bring in the kernel ????
kevincox · 2021-03-25
std::array::IntoIter[1] is great. I used to maintain a crate[2] to do this. Of course doing so requires unsafe so I am happy to move that danger into std::
I guess I can deprecate it now!
[1] https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#arrayintoiter-s…
[2] https://docs.rs/array_iterator
no_wizard · 2021-02-11
Disclaimer: I'm new to Rust and lower-level programming of this type in general. The 'lowest' level language I've worked with on the regular before this is C#[2]
I know Rust already has Tuples[0], so I'm assuming Const Generic Indexing For Arrays[1] is a happy path for the compiler to optimize what amounts to a finite sized Generic Tuple? (Finite size in terms of memory not elements)
Excellent feature, I just seem some (admittedly only high level) surface overlap in this language feature.
[0]: https://doc.rust-lang.org/rust-by-example/primitives/tuples.html
[1]: https://blog.rust-lang.org/2021/02/11/Rust-1.50.0.html#const-generic-a…
[2]: Which, while generally accepted to be a strongly typed language, is not near the level of Rust
mrec · 2021-01-17
Worth noting that this blog post was written before the official Error Handling Project Group got going. The Group aims to regularize best practice and bring it into the standard library.
https://blog.rust-lang.org/inside-rust/2020/11/23/What-the-error-handl…
(Disclaimer: I'm not involved with this group in any way.)
angrygoat · 2020-07-16
This rather niche fixing of unsafe behaviour is excellent:
https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html#fixing-unsoundn…
I spent a few years as a scientific programmer and this is exactly the sort of thing that just bites you on the behind in C/C++/Fortran: the undefined behaviour can actually manifest as noise in your output, or just really hard to track down, intermittent problems. A big win to get rid of it.
jasondclinton · 2020-04-17
Yea, the survey says that IDE support is the third-highest item for increasing adoption (https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html#rust-adopt… Rust users would benefit greatly from the Analyzer work that is in flight. Really looking forward to this becoming stable. The tooling it offers is great.
bluejekyll · 2020-01-28
I think this was truly the most amazing thing about learning Rust. After having experienced the pain (the issues brought up in the linked slide deck) of threads in C, then C++ and Java, it was wild to work with a language that provided some significant safety rails for working with data across threads.
Now async/await gives us even better options on top of that, but it’s truly what made me enjoy the language so much. This article is what resonated with me and got me to invest so much spare time over the last 5 years in working with Rust: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html
lskillen · 2019-05-01
For context to others: Unless you've been following developments in Rust recently, you may or may not have realised that Rust 1.34 [1] introduced the ability to point Cargo (the Rust package manager) at your own private registry, either self-hosted or managed.
So this is really exciting for anyone looking to privately develop or distribute Rust crates (packaged libraries), or to mirror some portion of crates.io for other reasons (e.g. availability, isolation, modification of public crates, etc.).
[1]: Rust 1.34: https://blog.rust-lang.org/2019/04/11/Rust-1.34.0.html
tlrobinson · 2019-04-03
It seems fairly common for a small number of prominent members of some community to move on to a new technology and have a number of people follow them for various (good and probably not good) reasons.
I'm not that familiar with Rails or Rust, but Steve Klabnik (http://www.rustforrubyists.com/) and Yehuda Katz come to mind in this case (https://blog.rust-lang.org/2014/12/12/Core-Team.html).
chrisseaton · 2019-03-31
MIR is probably a good example as it solves the problem I'm suggesting they'll encounter https://blog.rust-lang.org/2016/04/19/MIR.html.
Ideal is also a classic https://www.oracle.com/technetwork/java/javase/tech/c2-ir95-150110.pdf…
cesarb · 2018-08-10
In Rust (I don't know about Go), there's a sharp line between "panic" and other error handling: the unwinding on a "panic" is optional. A program or library might be compiled with "panic=unwind", or it might be compiled with "panic=abort" where a panic kills the whole process instead of trying to unwind. This means "panic" can't be used for normal error handling, only for "can't happen" errors like an out-of-bounds index into a slice.
In your categorization, Rust with "panic=abort" would be at step 2, not 5 (and it's used in production that way, for instance AFAIK Firefox uses "panic=abort"). And interestingly, not unwinding on panic in Rust is newer than unwinding on panic: it was added only on Rust 1.10 (https://blog.rust-lang.org/2016/07/07/Rust-1.10.html). So Rust seems to be following your list of steps somewhat backwards.
kibwen · 2018-05-10
async/await has been on the 2018 roadmap from the start: https://blog.rust-lang.org/2018/03/12/roadmap.html
As for non-lexical lifetimes, there's lots that's been implemented but much of it is still experimental; follow Niko Matsakis' blog series at http://smallcultfollowing.com/babysteps/blog/2018/04/27/an-alias-based… to stay up to date with what's happening.
iknowstuff · 2018-02-16
I haven't studied this extensively, but Mozilla made the following claim:
>Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical!
https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-…
maffydub · 2017-11-15
Borrowing from https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html (linked to from the original post), the following code tries to access a lock-protected vector.
fn use_lock(mutex: &Mutex<Vec<i32>>) {
let vec = {
// acquire the lock
let mut guard = lock(mutex);
// attempt to return a borrow of the data
access(&mut guard)
// guard is destroyed here, releasing the lock
};
// attempt to access the data outside of the lock.
vec.push(3);
}
It doesn't compile because the lock is not held long enough.
error: `guard` does not live long enough
access(&mut guard)
^~~~~
There are several more examples in that article, but you can read them there rather than here!