Rust is the Lamborghini for Engineers

Many great engineers I know have already tried Rust or have it in their "want to try" backlog.

I see presentations in Green-IT that say: We must consider the system's energy consumption. They share charts showing how much computation power a language needs. And Rust is way up there with C requiring the least amount of energy. After these talks, everyone asks each other if we will develop everything in Rust now (and finally, we might have a reason to do so, but more on that later).

The commercial JavaScript ecosystem likes to squeeze out every millisecond it can get of its build and test scripts^[1]. You can find tons of articles declaring Rust to be the future of the JavaScript ecosystem and infrastructure.

But, in the context of enterprise applications, I state:

Rust is the Lamborghini for engineers.
Everybody wants it, but nobody needs it.

It brings everything to the table that allures engineers. However, for most businesses in the non-tech sectors (like insurance, publishing, etc.), only parts (if any) provide a real case for Rust.

Therefore, it is like a Lamborghini. Every extrovert man would love to own and drive a dragon wagon one day. But there is no logical reason for it. Everybody wants it, but nobody needs it (deliberately exaggerated).

I came up with this statement due to a couple of reasons. The most important ones are:

Rust has a special hype due to the ownership concept it introduced.
Rust's design goal is to be an alternative to C instead of general purpose language for everyone.
Rust's concept conflicts with commercial software surroundings.

There might be more, but these are the prominent ones for me. Let's go through them one by one. After that, I'll present some use cases in which Rust is suitable.

The ownership concept makes Rust special #

In the context of programming languages, we often separate between low-level and high-level languages:

In low-level languages, developers must explicitly allocate and free the memory. Bad memory management often results in memory issues or bugs in production.

On the other hand, high-level languages are easier to use. They provide garbage collection, which regularly looks for no longer-used memory as the program runs. So, these languages pay the ease of use with performance penalties at runtime.

But either way, our written software might still cause bugs in production. Even high-level languages are not secure from memory issues. Especially when we bring in multi-threading, you can quickly get in trouble with whatever you choose.

All this causes situations we know too well: Hunting down weird production bugs. At first, we have no idea what the hell is going on. Only to come across the problem hours, days, or even weeks later by chance. Finally, we can reproduce the bug. We fix it by changing a single line of code.

Rust goes down a different road. What makes Rust so alluring is a powerful language backed by advanced theory. It provides all the features a high-level language supports but no garbage collection.

In Rust, memory is managed through a system of ownership with a set of rules that the compiler checks. This provides great runtime performance since no garbage collection is necessary. It also causes fewer production issues due to catching potential bugs at compile time. The only tradeoff is a development concept that you have to get used to. Due to its complexity, it takes more time to develop. It shifts time spent from hunting production bugs towards building proper software.

These aspects make a strong argument for everyone who wants to build performant and safe software and loves challenges in computing systems. Then, combine this setup with state-of-the-art language expressions and tooling. It is the perfect match for engineers.

Besides the memory differences, low-level languages often lack standardised tooling. Newer high-level languages already applied learnings from software projects of the past. A language needs to be more than its syntax, semantics, and compiler. Engineers need modules, code linter, formatter, package manager and more. Rust provides all of it right out of the box. That drastically reduces the barrier. It's straightforward to structure and scale codebases. In the end, it enables engineers to collaborate.

Rust is an alternative to C #

The creator of Rust had the idea to create a high-level language competing with others like Java and Go. Rust started with that approach by having a runtime with green thread capabilities. You might already be familiar with them from other high-level languages.

However, the community decided to go a different route. They wanted to place the language with its concepts to be a C alternative. They removed the existing runtime without a replacement. This led to various community-driven implementations, with tokio being the most popular. They redesigned the async/await to be an alternative to the state machines developers use in C environments.

Now, the language is an alternative to C. They've designed an FFI interface where you can use C and Rust interchangeably. Plus, there is no runtime overhead. Rust might be a capable alternative everywhere you work with C or have to fall back to C.

Commercial software #

Companies ranging from startups to enterprises are in business as a for-profit organisation. They have to work with limited time, resources, and people to create an offering that others buy. To still work with all these limitations, they have to make tradeoffs.

Especially commercial environments in finance, insurance, or publishing I've seen mostly rely on high-level solutions like the JVM. Engineers build services, bundle them in a container and deploy them to cloud-native environments. There is no need for C or alternatives at this layer.

Don't get me wrong. Placing Rust to be the one language, count me in. Who doesn't want to drive a dragon car daily for work? Every engineering heart will beat faster.

The reality depends on business cases #

In many enterprise business landscapes, more stakeholders are at the table. They bring in their subject-matter-related interests and requirements towards a solution. All requirements together will show how important engineering efficiency, system performance, and stability are.

When designing software products: You might have to cut things short and accept some tradeoffs in many dimensions. You trade in software performance, which is acceptable due to decreasing computing costs. You gain simplicity and reduced implementation time. This is often a big plus due to the high cost of development hours (the high salary you earn) compared to the hardware operating cost. It reduces the overall finance-business equation, shipping earlier and with less cost.

This is why high-level programming languages are often the choice for the non-tech enterprise landscape. You can get faster to a reasonable good enough for now, safe enough to try solution. I don't see enough strengths for a different market direction at the moment.

When is Rust a sweet spot for a business case? #

It needs the aspects of mission-critical, high-performance or a case where your only option is to fall back to C. We can see several cases where this fully makes sense.

1Password provides a password manager. Many parts of their system landscape are built on Rust. It makes sense because their customers store their most sensitive credentials there. A leak of customer information might be an existential threat towards their product.
Additionally, they offer an app for many end devices. Providing shared libraries for various clients, their only option is to fall back to C. This is where the option of using Rust shines.

Cloud providers–the plumbing of technology–leverage Rust to provide large-scale, performant services. They bring many customers across various use cases onto the same physical infrastructure. It's an operation at scale. Compute usage and energy efficiency matter. All performance improvements transfer into money saved. If they save more in the long term than it costs to implement performance improvements, it passes the finance equation.

An on-scale example is CloudFlare. According to their blog, they handle over 60 million requests per second on average. To run efficiently at this scale, they can't afford performance overhead using high-level languages. But they also don't want to risk memory issues using low-level languages with custom memory management. Therefore, they've decided to go with Rust. They even built and open-sourced their framework. As they say, measuring and optimising in microseconds may seem a little silly, but it quickly adds up at that scale.

Last but not least everywhere, where we have all those C and C++ codebases (Browsers, Micro-VMs, operating systems, firmwares, bare-metal, etc.), Rust might be an alternative.

Conclusion #

Rust is rather a niche. Or I make my statement more precise: I think Rust targets a different market than generic software development solutions built in companies across all sectors.

This brings me back to my statement from the start:

Rust is the Lamborghini for engineers.
Everybody wants it, but nobody needs it (deliberately exaggerated).

I hope you gained a few insights or new perspectives. Let me know if you see things differently. If you still want to go with Rust, I gave you some ideas of where to look. If you have any ideas on how to get Rust to mainstream, please tell me: [email protected]

Let’s see what the future holds and if the will/interest of engineers changes that. I'll now head back to my rustlings exercises. In the end, it seems that my engineering heart prevails.

Update 23. January 2025: Clarified that it is about non-tech sectors; Did mentions about memory safety more precise;

Although the JS ecosystem is already the fastest dev tooling I know compared to platform native development, JVM environments, embedded systems or deploying something to the cloud. At least it's nice that they keep pushing the boundaries. ↩︎