r/rust • u/manpacket • 1d ago
📡 official blog Rust 1.99.0 is out
https://blog.rust-lang.org/2026/10/01/Rust-1.99.0/450
u/Illustrious_Car344 1d ago
Can't wait for Rust 2
180
u/dashingThroughSnow12 1d ago
I once bumped a service from 1.9 to 1.91.
A coworker asked “why not 1.10?”
“Because 1.10 is less than 1.9.”
My co-worker got the joke and approved the PR.
139
u/stumblinbear 1d ago
When I was much younger, I was convinced that Minecraft would bump from 1.9 to 2.0 because... Well, how else would it work?
I was shocked and appalled. My world flipped, turned upside down. I am a shell of my former self
100
u/dashingThroughSnow12 1d ago
I like Linux’s rationale when it bumps major version. It is whenever Linus feels the minor number is getting too large.
51
u/stumblinbear 1d ago
I bumped from version 0.14.3 to 4.0.0 at work about 6 months ago. Fight me
15
u/dashingThroughSnow12 1d ago
Without bumping any cargo dependencies? Just the rustc/cargo version number?
14
u/stumblinbear 1d ago
Actually it was in a Flutter project
No dependencies changed between versions. Nothing changed at all, in fact. The update amounted to bumping the version number, haha
15
7
u/qurious-crow 1d ago
Gnome went from 2.38 to 40. Which was, in fact, their 41st release. I love this because I always start numbering things from 0.
-3
u/Icarium-Lifestealer 1d ago edited 1d ago
I think Linux would benefit from using the two digit year as major version, and counting up the minor version within the year.
This would make it easy to tell how old a kernel version is, while having few downsides compared to the current versioning scheme.
14
u/stumblinbear 1d ago
Two digit year? Oh man, I can't wait for Y2K part 2
4
u/dashingThroughSnow12 1d ago
I think we owe it to developers in the 2090s to pass on culture.
We get y2k, y2k38, and various other overflows.
We should bestow them with a few.
3
u/Icarium-Lifestealer 1d ago
I don't think that will be a problem here. Version numbers already have a variable number of digits, and the pattern cleanly extends to three digits from (2)100 to (2)999. If somehow Linux is still in use by then, people can decide if they want to continue with 1000 or 3000.
7
u/stumblinbear 1d ago
If you say it's a two digit year, people will rely on it being two digits. Parsers will absolutely be written that expect two digits there
That's what Y2K was. People not planning for their code to still be running when it rolls over to 00
4
u/kibwen 1d ago
Let's keep in mind that the amount of code in the wild that stores and processes timestamps is quite sizeable, while the amount of code in the wild that parses specifically Linux kernel versions--not raw strings, not semver-compatible versions, but Linux kernel versions and only Linux kernel versions--is not.
0
1
1
8
4
u/a_jasmin 1d ago
I'll remember that trick that could avoid genuine confusion. Though if human friendliness is a concern, you probably wouldn't want get all the way to 1.991
15
1
2
u/tobiasvl 1d ago
I just, literally today, fixed a bug in a server at work that checked the version if its client as a string. The client is version 0.9 now but would soon be bumped to 0.10 and the server would have checked whether "0.10" < "0.9" and it would be. So!
3
27
u/noop_noob 1d ago
You kid, but Rust 1.100 is a relatively large release.
11
23
u/Baanloh 1d ago
1.99,1.999,1.9999...4
17
u/D7mnCh 1d ago
1.100...,1.101.....
27
u/manpacket 1d ago
..., 1.18446744073709551615.0, and since semver uses u64 - 2.0.0!
6
u/_TheDust_ 1d ago
Fun fact, if you would release a version every second, 18,446,744,073,709,551,616 would still take you 600 billion years!
5
3
10
38
u/Kampffrosch 1d ago
Why is Box::from_non_null better than Box::from_raw for cleanup? Why does it not have the "problematic interactions"?
39
u/Icarium-Lifestealer 1d ago edited 1d ago
The problematic function is
leakwhich returns a reference. Bothfrom_rawandfrom_non_nullare equally valid, provided their input was produced byinto_raw/into_non_nulland is not descended from a reference returned byleak.
94
u/CobbwebBros 1d ago
Stable c variadic support is awesome
16
u/aPieceOfYourBrain 1d ago
Can we now use variadics in normal rust with VaList? Because it kinda looks like it's possible with a few hoops to jump through
Edit spelling
16
u/noop_noob 1d ago
You can pass a VaList around normally, yes. However, the only ways to construct a VaList is to either call a variadic function or clone an existing VaList. I don't know why you'd want to do this other than as a helper function for variadic functions though.
4
u/aPieceOfYourBrain 1d ago
So in the docs for VaList: https://doc.rust-lang.org/std/ffi/struct.VaList.html we couldn't just call vmy_func, we would need to call the extern C my_func first? But even that kinda looks like you don't actually need to call any C code, just telling rust to use C conventions is enough
9
u/noop_noob 1d ago
Sorry, but I don't know what you mean. You can just call a variadic function defined in rust, from a function defined in rust. It wouldn't be particularly useful, but you can do it.
1
u/foonathan 23h ago
VaList only supports essentially i32, i64, f32, f64 and raw pointers. It is also unsafe.
19
u/a_jasmin 1d ago
Make sense to cover the whole ABI. If you're implementing libc for instance.
When introducing rust in a C project however, I would steer away from them. variadic are notoriously weakly typed.
25
u/villiger2 1d ago edited 1d ago
Workspace members on edition 2024 or later can now override an inherited workspace dependency's
default-featuresfield. For example,serde = { workspace = true, default-features = false }now turns off default features even when the workspace definition enables them. On earlier editions,default-features = falseis ignored with a warning.
What if a member crate overrides to false but also depends on a sibling workspace member that either implicitly or explicitly depends on the opposite? Does the "features are always additive" then cancel out the member level override?
Feels like we're approaching Yugioh trap card levels of interaction :P
17
u/noop_noob 1d ago
I'm guessing that cargo probably does its usual thing of adding all the features of every use of a single crate, so we'd end up enabling the default features for serde.
1
u/villiger2 21h ago
That's my assumption too, but it undermines the whole "override a field" thing. I hoped to see some mention of this conflict in the PR but I couldn't find anything.
I'm wondering does it emit a warning when the override is overridden? If not it seems like a pretty weak feature.
34
18
u/ThatOneArchUser 1d ago
why does String::from_utf8_lossy_owned not reusethe buffer for invalid utf8 case? wouldn't be possible to modify the buffer in place to replace invalid utf8 and reuse the buffer instead of reallocating
44
u/manpacket 1d ago
Lossy representation can be longer - might not fit in the same buffer.
3
u/ParasiticWormLover 1d ago
How could it be longer?
14
u/_ChrisSD 1d ago
lossymeans it converts invalid unicode bytes into the unicode replacement character�. That is three bytes so for example 0xFF becomes 0xEF 0xBF 0xBD.3
6
u/EventHelixCom 1d ago edited 1d ago
The headline feature is defining C-ABI variadic functions in Rust:
rust
unsafe extern "C" fn sum(mut args: ...) -> i32 {
let a = unsafe { args.next_arg::<i32>() };
let b = unsafe { args.next_arg::<i32>() };
a + b
}
As I read it, this only works for extern "C" / "C-unwind" functions. Arguments come through an untyped VaList; each read is unsafe, and only VaArgSafe types are allowed. So it's mostly an FFI feature, for things like implementing a C API in Rust.
My question: is there any path from here to variadics for regular Rust-ABI functions? Or is the VaList machinery unrelated to the variadic-generics discussions? For now, are macros and tuples/slices still the recommended way to take a variable number of arguments in pure Rust code?
Curious to hear from people who've followed the RFCs.
8
8
u/Kivooeo1 rust 1d ago
Awesome release, even if it doesn't have many new features, but because it gets us closer to the massive 1.100 release!
3
u/Natsuawa_Keiko 1d ago
put purism jokes aside, do we really need a sugar for VaList? it feels strange.
6
u/ConstructionHot6883 1d ago
Does this always happen at the same time of day? In my timezone it's been "mid afternoon" the last couple of times.
5
u/manpacket 1d ago
Not really.
4
u/ConstructionHot6883 1d ago
I'm curious, is make a version the new stable a manual step that Somebody Does? The precise dates seem to be planned months in advance.
15
u/jerknextdoor 1d ago
It's every 6 weeks and always on a Thursday. The time is based on what works best for the team.
https://forge.rust-lang.org/release/process.html#release-day-thursday
10
u/CUViper 1d ago
Yeah, we rotate this responsibility, and it's usually later when I do it, working from US/Pacific. (times in UTC below)
$ git tag -l 1.9?.0 --format='%(tag) %(creatordate:format:%T)' 1.90.0 13:31:21 1.91.0 18:29:34 1.92.0 14:58:19 1.93.0 13:51:44 1.94.0 18:44:07 1.95.0 12:47:36 1.96.0 17:50:34 1.97.0 12:25:09 1.98.0 17:10:21 1.99.0 12:41:052
11
u/manpacket 1d ago
Dates - yes, mostly stable. There's multiple manual steps - preparing release notes, preparing blog post, tests, etc.
https://www.reddit.com/r/rust/comments/1gxyhkx/the_2024_edition_was_just_stabilized/lyl2mr5/
3
1
-18
u/DecadentCheeseFest 1d ago
It’s bonkers that we use a full stop as the separator for semantic versioning. The inadvertent mental load it induces is… more significant than we might like to let on.
9
u/Ok_Study3236 1d ago
It's thinking like this that caused PHP to end up with ` as a namespace separator. Heathen!
-32
u/dashingThroughSnow12 1d ago
Nice. No breaking changes. Rust is getting more and more stable; breaking changes are getting rarer.
20
u/noop_noob 1d ago
Please see https://rust-lang.github.io/rfcs/1122-language-semver.html and the "compatibility notes" sections of https://doc.rust-lang.org/releases.html
-5
u/dashingThroughSnow12 1d ago
I know about those docs. Which is why some previous releases have frustrated me and why I’m happy it is getting better.
13
u/hgwxx7_ 1d ago
Which features led to breakage?
5
u/lenscas 1d ago
Iirc there were a couple that broke type inference in certain situations. Some of them were expected, known and deemed acceptable but a couple were also an accident.
Still, those cases are ancient at this point I think.
1
u/hgwxx7_ 20h ago edited 20h ago
Those are bugs, which is normal and expected in a software project.
A breaking change is something different, which Rust shouldn't have had since 1.0 (11 years ago).
1
1
u/dashingThroughSnow12 18h ago
If code used to compile then doesn’t and this affects many thousands of open source projects and hundreds of thousands of private projects, it is a breaking change.
If one removes a flag from the stable version of cargo, breaking my build, it is a breaking change.
2
118
u/joseluis_ 1d ago
This is very welcome.
Very nice.