Announcing Rust 1.96
adamch
120 points
22 comments
May 28, 2026
Related Discussions
Found 5 related stories in 92.4ms across 8,861 title embeddings via pgvector HNSW
- Rust 1.95.0 caution · 11 pts · April 16, 2026 · 80% similar
- Performance of Rust Language [pdf] tanelpoder · 47 pts · May 25, 2026 · 54% similar
- Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc heldrida · 490 pts · May 09, 2026 · 54% similar
- An incoherent Rust emschwartz · 160 pts · March 23, 2026 · 54% similar
- Bun ported to Rust in 6 days qprofyeh · 99 pts · May 09, 2026 · 52% similar
Discussion Highlights (3 comments)
Tuna-Fish
I honestly didn't expect the ranges to be ever fixed, I just expected they would remain as an eternal wart. I wonder how painless the transition will be.
PoignardAzur
Woohoo, assert_matches! After all these years!
j1elo
Why replace the already existing std::range in-place with the new version, and move the old one to std::range::legacy? That's confusing and not forward thinking, what if a design improvement is found in some years and a new iteration is wanted? Will it end up as a std::range::legacy::legacier? The other day there was some talking about Go's stdlib around here, and I truly believe they got it much better thought out. std::range should stay where it is, and the new one be introduced as std::range/v2 or std::range::v2 or whatever syntax was deemed adequate. Solving the problem of how to iterate the stdlib in a maintainable and consistent way would also help to take away the reservations against adding actual batteries to the stdlib. The old adage against adding APIs because "once a new API enters the stdlib, it has to stay like that forever" has meant that Rust never takes a stance to pick a set of opinionated choices for the majority of the community who just want an "official" language-vetted way to get stuff done.