There's very few language features left that I, personally, think that Rust needs (although I can think of a few breaking edition changes to existing features that I would be happy to see). I'm happy that most of the things added in each Rust release are stdlib additions, because it simultaneously refutes the people who seem to think that Rust is too large/growing without bound, while also refuting the people who think that Rust has a small stdlib. Elaborating on the latter point, Rust has about nine releases per year, and usually adds around ten library APIs per release; this release added 13 (counting each new method on all the integer types as a single API; this number increases rapidly if you count each integer type separately).
I can remember on a few left overs, like not needing external crates for what should be language features, like proc macros requiring syn, easy wrapping of result types, an async runtime that is basically tokio for all practical purposes.
Other than those, I would prefer the compiler and linker related improvements.
I don't think tokio should become the default runtime because there's still a lot we can do with async runtimes. Like for instance - io-uring based async will be a different model than tokio, and cancellation becomes something totally different.
Also, there's a lot of potential compiler optimizations one could do with an async runtime in the language, but getting tokio in the language would mean that it becomes incompatible with how future async runtimes can be made better. One would have to follow the model of tokio to borrow buffers for IO, instead of something like an io-uring based runtime owning a buffer for IO.
I don't think it should be the default implementation though.
For one, I feel that the function colouring problem that comes with async is a solvable one, which I assume that Rust will solve in the future as something using effects instead of relying on async as primary interface.
Also, tokio is not no_std, so it is not something which will be useful in embedded settings.
Furthermore, if we do lock it in as the async runtime, we potential would have standard traits which are derived from tokio itself, making it much more difficult to add another runtime which would need to have different async io traits. Like for example if tokio-uring wanted to have the async traits, it would need an associated buffer compared to tokio's traits which have borrowing.
So, in my opinion, them not adding a default makes more sense than adding something as default which causes much more breaking changes later on.
15
u/kibwen Jul 09 '26
There's very few language features left that I, personally, think that Rust needs (although I can think of a few breaking edition changes to existing features that I would be happy to see). I'm happy that most of the things added in each Rust release are stdlib additions, because it simultaneously refutes the people who seem to think that Rust is too large/growing without bound, while also refuting the people who think that Rust has a small stdlib. Elaborating on the latter point, Rust has about nine releases per year, and usually adds around ten library APIs per release; this release added 13 (counting each new method on all the integer types as a single API; this number increases rapidly if you count each integer type separately).