Catch 22! Rust in Review
It’s getting late in the year, so it’s time to write another blog post looking what good and bad came out of the year for Rust and what’s likely to happen next year.
I guess the second part is also a roadmap post for the next year, so there’s that.
Language-wise, 2022 was a great year for syntactic sugar, with
rapidly reaching stable (I must admit I wasn’t even aware of it until I read
the release blog), and
let chains being worked on in nightly. I was wary of
those until I tried them in the clippy codebase, since then I’m very happy
we’ll get them sooner or later. We also got
GATs in 1.65!
Those who don’t know what that is, don’t worry, it’s all good, and for the
others, that was well worth the wait. Finally!
There also has been some really great work on the async front, with a MVP for async trait landing in nightly in mid-November. No more hacks with attribute macros and boxing all futures, yay!
Some new features were just filling gaps, like destructuring assignments
which brought them to parity with
let bindings. While they undoubtedly made
the implementation more complex, the language complexity was reduced by one
The compiler still got faster, despite serving more features and improving the error messages even more. Cranelift and rustc-codegen-gcc are progressing nicely, and gcc-rust was recently merged into GCC proper. mrustc is still alive and well, so we’ll soon have three compilers and three backends (LLVM, gcc, cranelift) for the official compiler.
Tools & Ecosystem
Rust analyzer got a well-deserved promotion to a proper rust-lang project.
With helix for the terminal and
lapce using its own GUI, we now have two native Rust
editors written in Rust that use the rust-analyzer backend. Cargo gained an
inbuild implementation of the
cargo add subcommand, which was formerly only
available through the
crate (update: With this year’s last release, the
cargo rm subcommand joined
cargo proper, too). The
gitoxide git source control system implementation
finally gained enough functionality to
The tokio runtime saw a steady stream of improvements, with the former making headway in safe & fast web service implementations and notably tooling to dump #an “async backtrace” in case something goes wrong, which finally closes an important gap between sync and async debugging. Async-std development seems to have stalled, with the last commit dating from July.
GUI-wise, we’ve seen multipe frameworks come to life, from the Xi-editor inspired druid and its likely successor xilem over the startup-sponsored slint to iced and dioxus. Other toolkits saw progress, too, the AreWeGUIyet page lists many of them.
Crates.io has more than 99k crates now. This time last year it was about 70k, so the growth hasn’t stalled at all. The registry has counted 24.4 billion downloads, which is more than double last year’s count! The subreddit has cracked 200k subscribers in October and is now bigger than r/golang which it had trailed all the years before. Rust has kept its 19th spot in the redmonk index, and won top spot in the yearly “most loved” StackOverflow survey, in addition it’s “most wanted” for the second year in a row.
The blockchain winter is now in full swing, with many of the fraudulent players going broke. Luckily, my fear that Rust would suffer by association didn’t become reality. The job growth in other fields like machine learning, cloud and elsewhere easily outweighed the losses in blockchain-related Rust jobs. Phew!
This part of the growth curve doesn’t come out of thin air: Many companies large and small spun up Rust teams. We make inroads in the cloud, on mobile, in embedded (notably automotive and aerospace, where the groundwork is currently being laid), in machine learning (where python still reigns supreme, but Rust could win sometimes by superior performance and type-based coding ergonomics). The current Android version 13 has more than 1.5 million Rust lines of code. There’s Rust in the Linux kernel!
Those folks who spelled Rust’s doom because there wasn’t enough buy-in from companies now spell its doom because there’s so much buy-in. I guess some things never change.
The foundation has really come into its own this year. Kudos to all involved! With the community grants, the foundation directly allowed more people to work on what they love while boosting the Rust ecosystem. Also I hear there has been some lobbying in the US that resulted in Rust being the official recommendation for low-level projects.
The project restructuring also saw some good progress; I am personally very happy with the outcome so far.
Now for a look
in the crystal ball on the roadmap:
I see chains of
let. Async traits, too. I see them bloom for me and you. And
I think to myself, what a wonderful Rust… or something.
try blocks will
have to prove their worth in the nightly implemenation. I haven’t tried them
yet, so I cannot predict if they land next year. We will see more whittling
down the missing pieces of features we got this year for sure. Especially on
the async side of things I expect more movement regarding pinning and avenues
for optimizing the task machinery for various use cases.
I have high hope for negative trait bounds which sound like they will enable a bucket of interesting use cases, especially with regards to avoiding the need for specialization. Though there is some compatibility hazard, I’m sure the lang team will take sufficient precautions to make it a net win.
I guess it’s safe to say the compiler will get even faster in ‘23, though we may already see diminishing returns.
As for the backends, we’ll see gcc-rust mature somewhat, and rustc-codegen-gcc as well as cranelift become useable for more cases. Perhaps even some kind of stabilization.
I sure hope we’ll see more evolution on the macro machinery. WebAssembly could be a great base on which to rebuild the macro system; we could even cache pre-compiled macros or have crates.io serve proc-macro crates as WASM blobs, thus reducing compile time for their users.
Tools & Ecosystem
The Rust experience is already pretty good, and the stream of improvements is unlikely to ebb next year. I’d note that with the newly set up fmt team, I expect notable advances in rustfmt functionality.
Most Rustaceans wish for some consolidation; do we really need three async runtimes, eleven web frameworks, fourteen GUI libraries and a dozen or so hash map crates? On the other hand, I think we haven’t seen the end of the experimentation phase; in fact it may just have begun. So I fully expect more delightful new libraries and surprising crates come up every now and then. One size need not fit all, as they say.
Rust has reached the tipping point. From here on the only way is up. The only thing that could pull the trajectory back down would be for an even better new language to emerge, and I don’t expect one to appear in the next three years. That said, if it does appear, I’m so here for it.
With this explosive growth come a set of challenges, which nicely brings us to the next point:
The foundation has shown it can do more than taking care of the trademark or sponsoring email services for This Week in Rust. Now is the time to expand the involvement. The current community grants are a good start, but they’re pretty narrow. The foundation could team up with universities to sponsor PhD theses around Rust. It could give out a yearly award for the most innovative use of Rust in the industry. It could lobby more governments to make memory safe languages the official recommendation.
I dare not hope to see memory safety mandatory, but perhaps at one point it could become a sign of negligence to write code in a memory unsafe language unless there is a good reason to do so. The first country to enact such laws is going to rule the software sector for years to come.
The project will continue spinning out working groups. Currently those can organize however they see fit, but we’ll start to see some standards emerge. While this will lead to some small frustration on some members’ part, it will ultimately help transparency and inter-team ventures.