Clark Kampfe

As the years go on and more people use Rust, we're seeing more and more of these "Rust was a bad choice and here's what I don't like about it" posts, like this one. (Discussion here)

My goal with this post is not to discuss the above linked gamedev post directly. Rust should have a better gamedev story. My goal with this post is to try to understand a tiny bit about why so many people are publically expressing the feeling that Rust doesn't work for them.

One reason I think this is happening because Rust has actually been too successful at selling itself. How so? Rust has largely achieved what many people thought was impossible: it has supplanted a non-trivial amount of C/C++ code at places like Cloudflare, Amazon, Google, Microsoft, and others of similar caliber. The Linux kernel, not exactly a project known to live on the bleeding edge, is starting to evaluate and integrate Rust for drivers. This is great! A ton of low level infrastructure code in things like proxies, routers, SDKs, VMs, runtimes, languages, hypervisors, etc., is now arguably safer for end-users than if it were written in C or C++. It appears that Rust is here to stay at the highest (lowest?) levels of technology.

But too successful? Yes. Rust has overachieved. All of these stories of Rust's success in the holy halls of Big Tech have inundated us mere mortals with so much positivity that we're now witnessing that "if it worked for them it'll work for me" syndrome that we saw with so many other technologies over the years. Things like document databases, eventual consistency, Hadoop/"Big Data"/Spark/Kafka, object oriented programming, microservices, and more I'm forgetting. Things that most people didn't need but a lot of people tried, because they were popular, they had the hype, Big Tech people talked about them at conferences, they looked good on a resumé. Now, I'm not saying Rust is a fad, like some of those. I think the impact of Rust is quite a bit larger than microservices. But Rust is popular and hot like microservices were popular and hot.

This popularity has resulted in bringing a mass of new people in to Rust, people with all kinds of use cases, and some of those use cases are a poor fit for the tool. To those folks coming in evaluating Rust, I say this sincerely: if you need the simplest language to learn, or the fastest possible iteration times, or a great run-time reflection story, or the most straightforward migration from your existing tech stack, or the language with the largest-possible library coverage, or the language where you don't have to think about resource ownership at all, or the language with the shortest compile times, Rust might not be the best fit for your use case.

Rust is terrific in its niche, but like everything else, it has a niche. What we are witnessing now, in real-time, is people discovering the blurry edges of that niche through their pain. And in doing so, those edges are becoming slightly less blurry for all of us. And this is fine, actually. We're seeing where Rust works, and where it doesn't work well enough yet. This is how it goes when a technology is genuinely novel and you don't yet know where it's going.

(As an aside: I think that a great deal of people who have tried Rust and found it lacking, or hard, or a bad fit, or whatever else would be better served by either Elixir/Erlang or Go. There has been an enormous amount of criticism made (and frankly, hot air blown) against Rust's async story in particular, and while I think people's perceptions on async are valid, I often disagree with their conclusions. I think Rust's async is good. But most people and most companies would be better served by a more straightforward, conventional concurrency story, one that doesn't have strict ownership and zero-cost as goals, and for those use cases, Elixir and Go are great.)