Rust in 2024 • Krishna's blog

I saw a few posts by Niko Matsakis and others that inspired this.

and a couple of older posts

Without exception, all of these people know a lot more than me. They’ve worked on massive Rust codebases, and in some cases shepherded the development of critical Rust infrastructure (rustc, rust-analyzer). What they say is more relevant and a better guide to the future than what I say, because they are making it.

That said, I can freely say a bunch of shit with no consequences. Just for my personal satisfaction. I can read these predictions in a couple of years and see how much I got right. On a broad level I expect some progress to be made in each of these areas, but no problem will be completely eliminated. Most progress in most fields is incremental, so it’s not surprising.

I’ll start with the problems pointed out by matklad

Not all programming is systems programming. Agree completely, and it will definitely remain true in 2024. For most programming, I think people won’t need the additional performance offered by Rust. Using safe, managed memory languages like Go or Java or C# will be perfectly valid alternatives. If performance isn’t a consideration at all, Python is great. Yeah, Rust eliminates data races but most people would back themselves to reduce that with code review.
- Prediction - Rust could get substantially simpler but I doubt it.
Complexity in the language. It’s daunting to learn, but definitely easier than before. There’s way more tutorials, books, StackOverflow questions in 2022 than in 2018 or god help us, 2015. Even tooling like a vastly improved IDE experience helps people learn. In the next two years there will be new features added to the language, some of which will make the language harder to learn while others will make it easier. For example, NLL made it easier (Niko pointed this out), while async made it harder.
- Prediction - This net effect of added features might be neutral but my feeling is that they’ll slightly increase complexity. Newbies will still drop out because it’s harder than any other mainstream language (JS/TS, Go, Python etc). Companies will still shy away from spending 1-2 months doing nothing as devs are trained on Rust. The strong survivorship bias will mean Rust will still be “most loved” in StackOverflow surveys.
Compile times. I think people will complain just as strongly as they always have because incremental progress here doesn’t help much. I point out on many threads that it has improved by around 30% between Rust 1.33 and 1.50. I think it’s probably going to get 10% faster in the next couple of years despite adding a bunch of features. The only thing that could get people to stop complaining is if the Cranelift backend is added as an option and it’s 50% faster than LLVM debug with comparable performance. But maybe not even then. I don’t want to criticise the complainers too much because they have a point. Rust competes with langauges like Go which are very fast to compile and even Rust with Cranelift would be slower than Go.
- Prediction - Rust maintains parity in performance. No cranelift backend. People complain.
Maturity. This is less of a problem than it was a year and a bit ago. With the Rust foundation, and with so many Rust contributors being employed by cash rich corporations, I don’t see it being a problem. Small companies writing small tools in Rust can always migrate if the language meanders to irrelevance. But when major companies with plenty of cash like Facebook, Google and Amazon write critical components in a language, they’re likely to keep it afloat. Rust can still have missteps, but I’m willing to bet a lot that it’ll be around 5 years from now.
- Prediction - Rust will be thriving in 2025. If that prediction comes true, then a further prediction - it will exist in 2035. Hard to make long term predictions beyond that. C on the other hand will definitely be critically important even in 2050. Linux alone will ensure that.
Alternatives.
- Prediction - C++ and C will remain strong alternatives. Even today, great projects starting out choose them. That will remain the case. New alternatives like Zig will reach 1.0 and grab mind share among systems programmers who are open to trying new languages.
Tooling. Getting better all the time. rust-analyzer is a star here, but there’s many others like the new and promising tokio-console.
- Prediction - Incremental improvements. Some things will still be clunky. In some domains, Rust tooling would be considered best in class.
Integration. cargo is great for pure Rust projects but doesn’t integrate well with other build systems. That will remain the case. There’s talk of splitting up the package management and building into 2 tools, but my guess is that it won’t happen. The big players have already hacked around it’s current behaviour (like Facebook’s reindeer, “a cargo carrying buck”) so they won’t invest more into it. The small players are content with pure Rust or don’t mind not having one build tool that can build their entire code base.
- Prediction - no change.
Run time Performance.
- Prediction - Marginal improvements, no big regressions is my prediction. I don’t think there will be any complaints because for most use cases, run time performance is good enough.
Unsafe. I really hope there’s progress here. Many people, including Niko and matklad have talked about improving the situation here. But the group that was responsible kinda meandered. I think it’s important for Rust’s long term future that the foundation be solid.
- Prediction - It’s been under-invested in and my prediction for the next 2 years is that it’ll remain so. It’s not a burning issue and no one is complaining. Maybe if there’s some major vulnerability people will suddenly take a look. But otherwise, nothing.

Areas/use cases where Rust can improve

Async. Lot of talk about this, especially since it’s so clunky nowadays. Currently I feel pulled towards 3-4 side projects but a project using async rust is not one of them. They need to land a bunch of features in the language to make this happen. Niko Matsakis (works for AWS) and Tyler Mandry (works for Google on Fuschia) are highly motivated to tackle this. Funding is obviously not a problem. If they continue working on this for a couple of years, I think they will come pretty close to their vision. That’ll be a huge win for the ecosystem. Rust’s success as a server/infra language depends on the success of these initiatives.
- Prediction - they’ll ship most of what they hope for, but they won’t reach the zen level that’s in the blog post. But even with a few rough edges, it’ll still be pretty decent.
WASM - I’d like to see Rust interact with DOM APIs directly, so it’s more viable in the browser. This is unlikely to happen. I’d like to see Cloud functions from all providers offer WASM functions like Cloudflare and Fastly. It feels like a no brainer because hardware costs would be lower and so would latencies.
- Prediction - AWS announces WASM functions in 2022/23. And if the async milestones are hit and async rust is easy to use, Rust will possibly one of the best languages to compile to WASM.
Embedded. Feels daunting at the moment for a newbie like me. I’d like to write some embedded code, for example for the Flipper Zero but I don’t know where to start. Ferrous systems have made some tools to improve the experience but I don’t know if it’s quite there yet.
- Prediction - the Ferrocene project is released in the next 3 years and gets at least a few customers. These customers will want better tooling and that’ll be released afterwards.
Game development. Seems to be driven entirely by Bevy at the moment. It has a lot of momentum. Each release seems to bring a lot of features. But they remain far from a comparable engine like Godot. Best case scenario - they maintain that momentum and reach a point where the API is somewhat stable and people are building “real” games on it. I know based on their lavish sponsorships Embark Studios have big plans in this space, but I have no idea what.
- Prediction - don’t know enough to say.
Linux - I’d like to see drivers written in Rust because it’ll prove to fence sitters that Rust is viable, at least as a systems programming language. I hope Rust supports a GCC backend, which I predict it will if antoyo continues to work on it. The one thing is the scope of the work that’s needed to get it into Linux. There’s a lot, at least 2 years work considering fundamental changes to the language are required. For example, Error instead of panic when the system is out of memory.
- Prediction - don’t know enough to say. Ojeda might ship all his work but folks might find that Rust drivers involve too much unsafe to be a substantial improvement over C drivers. Or it might not ship because it’s stuck on something. Or it ships but only a handful of teams are willing to take a gamble on Rust.
Libraries for other languages - similar to Linux, I feel like the main blocker here is panicking on OOM. The curl maintainer pointed out that this is highly unacceptable behaviour for libcurl. I’d tend to agree. I’m sure the embedded folks would too.
- Prediction - Rust remains a good option, but C will be king.
GUI.
- Prediction - There will be some frameworks, but nothing will catch fire. It’ll remain niche compared to the current dominant method - Electron or even other frameworks like GTK and QT.

Misc predictions

Lib.rs stats show that the crate ecosystem has been growing steadily. Crate downloads are growing at a rate of 2.2× per year. Traffic during weekdays is typically 2.4× higher than during weekends (indicating more professional use). There are 19,822 users or teams that have a crate on crates.io. The number of owners is growing at a rate of 1.3× per year. Lib.rs has indexed 77712 crates. Almost all crates work only with the latest versions of Rust.
- Prediction - Continues growing at the same rate. Number of downloads increases, crates increases, number of crate authors increases, more usage skewed towards weekdays. Probably the safest prediction I’m making.
More libraries hit 1.0 - good sign for the ecosystem, gives people more faith. Top 100 crates like rand, ring, log, tracing, base64, time, chrono, hyper aren’t 1.0 yet. It’s a turn off that a lot of this functionality isn’t in std lib. But it looks worse that the “blessed” solutions aren’t even 1.0.
- Prediction - a majority of the mentioned libraries reach 1.0 but a few remain holdouts. No major libraries being imported into stdlib apart from once_cell.
Versioned std. I know I made a post saying this hasn’t been done because it would split the ecosystem, but it could be doable.
- Prediction - definitely not happening. If it ain’t broke, don’t fix it.
Better error handling story. It sucks having to import libraries for this. Sucks not having backtraces.
- Prediction - backtraces in stdlib, but we’re still importing thiserror/anyhow in 2024.
Macro runtime. I hope dtolnay’s watt or something like it is adopted. I think proc macros are the likeliest source of supply chain attacks so I hope this avenue is closed before it’s used. If there is a successful supply chain attack, Rust will find it difficult to shed the tag of insecure. But I think the idea of adding a wasm runtime to the default rust distribution would not be popular. The idea of crates.io distributing pre built wasm files probably even less popular. Which is a shame, because there’s a big security and compile time win here.
- Prediction - no change.

Conclusion

I’ve made 21 predictions, of which 2 are “I don’t know”. Let’s see how I do. Let’s check in middle of 2024.