I read this and felt weird about it initially but couldn’t quite put my finger on it. From my experience, using Rust has lead to faster developer velocity (even for CRUD apps) simply because the strong type system allows you to encode invariants to be checked at compile time, and the tooling and libraries are amazing. This article seems to be about a project that was being developed right around async/await release, which was a rough time for using libraries. Most of the sharp edges are gone now, but I don’t doubt that the state of the ecosystem at that point affected this person’s experience.

However, I do think there is a situation where this advice holds true (even for someone as heavily biased as I am), which is for a very specific kind of startup: a hyper-growth startup with 100%+ YoY engineer hiring. The issue with Rust is not that its slower to develop in, I don’t think that is true, its that in order to develop quickly in Rust you have to program in Rust. And frankly, most new developers to Rust have no idea how to program in Rust because so many languages do not feature strong type systems. And the problem is that if your influx of new developers who need to learn Rust is too large, you won’t be able to properly onboard them. Trying to write Java using Rust is horrible (I’ve worked with a number of colleagues who I’ve had to gently steer away from OO design patterns that they were used to, simply because they make for really difficult Rust code, and are largely obsoleted by the type system).

It isn’t even lifetimes or borrowing that are necessarily tricky, in my experience issues with lifetimes are fairly rare for people and they almost always immediately seek out an experienced Rust dev for guidance (you only need a handful to deal with all questions on Lifetimes; my current team only has me and its been a non-issue). The bigger problems are around how to structure code. Type-driven development is not something most people have experience with, so they tend to stick to really simple Structs and Enums, to their detriment.

For instance, I commonly see new Rust developers doing something like this:

fn double_or_multiply(x: i32, y: Option<i32>, double: bool) -> Result<i32> {
    if double {
        if y.is_some() {
            return Err("Y should not be set");
        }
        x * 2
    } else {
        if y.is_none() {
             return Err("Y should be set");
        }
        x * y.unwrap()
    }
}

Yes, I know its a completely contrived example, but I’m sure you’re familiar with that kind of pattern in code. The issue is that this is using the shallow aspects of Rust’s type system – you end up paying for all of Rust but only reaping the benefits of 10% of it. Compare that to what you could do by leveraging the type system fully:

enum OpKind {
   Double(x),
   Multiply(x, y),
}

fn double_or_multiply(input: OpKind) -> i32 {
    match input {
         Double(x) => x * 2,
         Multiply(x, y) => x * y,
    }
}

Note how the error has disappeared as there is no way to call this function improperly. That means fewer tests to write, less code to maintain, and APIs that can’t be used improperly. One of the most interesting questions I get commonly when I promote this style of code is “how do I test that it fails then?”; its always fun to explain that it can’t fail[1] and there is no need to write a test for the failure. The developer efficiency benefits from this style of thinking everywhere is massive and more than pays for the cost of using Rust.

But developers from other languages take time to get to this point, and it does take time and effort from experienced Rust developers to get everyone on the same page. Too many new people and I can see more and more code leaking in as the first example, which means you get minimal benefits of Rust with all the cost.

I can’t argue with this person’s experience, as much as I love Rust and think it has features that make it an incredibly productive language, but I think the core issue is that the majority of developers do not have experience with strong type-system thinking. As more languages start adding types I’m hopeful this problem becomes less prevalent, because the productivity differences between developers who understand type-driven development vs. those who don’t is large (in languages with strong type-systems).

[1] Technically it can panic, which I do explain, but for the majority of cases that is a non-issue. Generally if there is a panic-situation that you think you might have to handle you use a different method/function which returns a Result and bubble that up. Panics are largely unhandled (and for good reason; they aren’t exceptions and should be considered major bugs).

Basically, the problems that Rust is designed to avoid can be solved in other ways — by good testing, good linting, good code review, and good monitoring.

This sounds like a false economy to me. In my experience catching problems already at compilation stage is pretty much always a saving over catching bugs later in the life cycle – especially if it goes into production and is caught via monitoring. It might initially feel like higher velocity, but as the code complexity grows, it really isn’t.

This is an important lesson. Rust is aimed at being a safer systems language. There are a lot of safe applications languages with more mature ecosystems, better tooling, and so on. If you are in a situation where you don’t need fine-grained control over memory layout, where you can tolerate the memory and jitter of a global garbage collector, then Rust is as much the wrong choice as C would be. Rust is a good choice for situations where, if Rust didn’t exist, C would be a good choice. If you wouldn’t consider using C for a project, don’t use Rust. Use Erlang/Elixir, C#/F#, JavaScript/TypeScript, Swift, Pony, or anything else that targets application programming problems.

the problems that Rust is designed to avoid can be solved in other ways — by good testing, good linting, good code review, and good monitoring

This stuck out to me, as the four things the author mentions here are the exact things that have always been in short supply in my current line of work, on under-resourced teams at a public sector employer. Obviously Rust is not the only productive language out there offering good compile-time guarantees and the firm guiding hand of a type system, but in general I wonder if “just let me crush code and we’ll fix it in post catch the issues in the test suite/CR” isn’t an abundance mindset. I frequently have to fix things (in Python or Perl or JavaScript) where nobody including me has looked at the code in 3 or more years and there are no tests; I’d give my kingdom for mypy --strict on those occasions.

Coming from a Haskell background, many of the complaints here are things that strike me as strange. For example,

What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used

Or, you can make changes to load bearing interfaces and the compiler tells you everywhere you need to update something, which makes it mechanical work and removes the possibility of human error.

when I’m building a new feature I usually don’t have all the data types, APIs, and other fine details worked out up front. I’m often just farting out code

If you have a strong type system, you tend to fart around in the type system instead.

The expected load on this service was going to be on the order no more than a few queries per second, max, through the lifetime of this particular system

So why was this a microservice at all? Why not just a nice monolith where you can take advantage of the type system strongly?

Rust has made the decision that safety is more important than developer productivity.

I think this forgets that safety improves developer productivity in the long run. But what Rust actually tries to achieve is safety without loosing performance, and that comes at a cost of developer productivity. Plenty of other languages are safe as well, but they usually sacrifice performance to achieve that.

I think the main question in choosing to use Rust is “do you value performance more than productivity?”. And the answer to that depends on the system.

You will have a hard time hiring Rust developers.

It’s kinda funny - we’re a small startup (6 people) and I keep getting great CVs to my email, even while we don’t search. When we do we get around 50~ per week, mostly high end candidates. I think there are many Rust developers who just wait for the opportunity to use that as their main language.

To give some perspective, our main project had to be low level, so we did Rust. Then, we needed to do a backend service and the designated engineer decided to go with Rust (though it wasn’t our first choice because of prejudice as seen above). He shipped it very fast, high performance, well documented, many battries included and edge cases covered just because the eco system makes you be robust. Adding new features is easy because it’s hard to break things real bad.

I feel like a lot of what is said here can also apply to other “fancy” but rigorous languages like Haskell. It solves a lot of issues well, but the deployment velocity might suffer a bit and it can be hard to hire for.

I commented on this on twitter, and I think it’s accurate, but there’s one point missed in the comments here that I think is worth diving into.

Any choice of rust web framework made now is probably wrong long-term.

One could say that axum is maybe the least bad option today, but given the state of affairs the major version dance of the couple frameworks on major versions make them less easy to work with than the non-major-versioned libraries. Because the pace of change requires them to bump major versions. I think the rust web frameworks are nice, but they need to shake out like all the other major languages have, with a few good ones and many semi-abandoned ones that simply made wrong design decisions.

I hope this comment doesn’t apply a year from now. A statistical view of some of the frameworks, but I would need a crystal ball to pick the one or more that’s going to become the de facto standard. https://github.com/flosse/rust-web-framework-comparison

Couple of things I want to highlight from this article that bear repeating (indeed, perhaps, stamping onto the arms of developers tempted to forget):

The only reason we were using Rust was because the original authors of the system were Rust experts, not because it was an especially good fit for building this kind of service.

There can be tremendous advantages your team is missing out on due to what is effectively an accident of history. In the case of a CRUD app with a couple of routes making a database call, Express (JS) or Sinatra (Ruby) or Flask (Python) can just bury the competition in productivity. It took longer to write this comment than a simple index API route in those frameworks/languages. Just because your founding team likes X doesn’t mean that decision shouldn’t be reviewed.

We started having weekly “learn Rust” sessions for the team to help share knowledge and expertise. This was all a significant drain on the team’s productivity and morale as everyone felt the slow rate of development.

Developers need to learn the domain, learn the process, and learn the tooling during the course of doing their work. Choosing non-standard or difficult tooling means that their efficiency will suffer. It sounds like the author’s team navigated this as best they could with professional development, but the real solution of using an easier and better-fit tool would have been preferable.

I’m often just farting out code trying to get some basic idea working and checking whether my assumptions about how things should work are more-or-less correct.

My favorite point that the author makes. In my experience, especially on high-velocity teams trying out lots of stuff, the exact things that make languages like Rust, Haskell, and others so good at their domains make them liabilities. If your language requires a strong and carefully-expressed model of the business rules and business logic in order to do anything, until you have that model you will do nothing.

~

Overall, a neat article, and I’m glad to hear some skepticism.

I work at a startup that uses Rust and this rings very true to me.

I like programming Rust. It’s fun and its interesting and it makes me feel smart when I use it.

hiring, onboarding, code reviews, estimates, sprint planning, library maturity, being on-call, maintaining existing projects? yeah. That’s a different thing.

The high-level point that if you quickly hire a lot of people without Rust experience, they need more time to get up to speed compared to Go, is likely correct.

It’s incorrect and beside the point, though, to bring up C++ and complaints about Rust you hear from C++ developers. First, ownership and lifetimes shouldn’t be conceptually new for C++ programmer. Second, as pcwalton pointed out on Twitter, relative to Go, Rust favors performance—Go is safe, too. The complaint that Rust favors safety is a C++ PoV complaint that seems off the mark here.

This is a large reason I’ve been drawn more to Zig and Python than Rust in my personal graphics/audio/gamedev related projects. I like to prototype numerical algorithms quickly, and numpy is killer for that. When I want control over memory (which absolutely matters in certain prototypes), I’ll drop to Zig. It provides better guardrails than C or C++, gives me access to all my favorite C libs through @cImport, but is still much faster to prototype with than Rust. [1]

Like the article mentions if you’re writing an OS kernel (or filesystem, or database, or a cryptography library, or a mission-critical scheduler, or any number of other multithreaded + safety + performance sensitive code [2]), Rust is a great choice. In established organizations, Rust also has an edge since larger companies are more focused on risk-mitigation, have larger teams, and benefit from stronger SDLC constraints to keep code consistent when dozens of programmers get their grubby paws on everything. But I can definitely see how a small startup that needs a bunch of short-term wins to survive would struggle with Rust. I’m sure there are startups building products where safety and performance are main features, and I bet Rust would provide an edge in some of those cases as well. But for a SaaS CRUD app with a handful of developers, it probably wouldn’t rank high on my list of languages to use.

[1]: I’d pick Rust even for my prototypes if worked on my problems that were multithreaded, but the safety guarantees of Zig are strong enough for the small, single-threaded programs I usually write. I’ve really enjoyed contributing a few small Rust patches to open source projects though, so I might also pick it if I wanted to make collaboration easy.

[2]: Although, it might even be tricky with some of these examples since they could require a decent chunk of unsafe code which is another sticking point for Rust.

I just don’t understand this need to be first out the door with features. Microsoft, a behemoth of a company, has never been first to market anything in its lifetime, except maybe BASIC interpreters (maybe). Operating system for the PC? Nope (there were three available up on the release of the IBM PC, and Microsoft wasn’t the first choice). GUI? Nope. Spreadsheet? Nope. Word processor? Nope. Slide presentations? Nope. Cloud offerings? Nope. Linux support? Nope. It hasn’t seemed to hurt them being second, or third, or fourth, to market one bit.