Many developers study Rust, experiment with it, and fall in love, but in practice they don't use it professionally. The famous annual Stack Overflow survey proves this - there's a high percentage in the "most loved language" category, but low when compared to actual usage.
Being a relatively new and less popular language, Rust ends up facing some barriers to wider adoption. In this article, I'd like to share my experience in reconciling Rust and using it at work alongside other languages.
Preparing to Be Questioned
Unless you have decision-making power within the company, you'll have to convince your colleagues to adopt it. In my case, I prepared for this by trying to anticipate all the questions I would receive. It's worth noting: everything should be questioned - we shouldn't be offended by this - an idea needs to be challenged to prove its consistency, and thus it will prevail.
We need to formulate answers to explain what advantage Rust brings to development companies - what kind of problem it was designed to solve.
First, it's important to understand that there are various languages to achieve different objectives - and they can coexist and complement each other. So let's explore where Rust fits perfectly.
The Need for Compiled Applications
Beyond enterprise demand - for running large business applications - there's another type of need, which we can exemplify through low-level routines, support, and infrastructure (devops). Here we consider applications with native binary code, without runtime (or VM), with low resource consumption and high performance.
Until recently, this type of application would have been made in C++ almost as a general rule. But given this growing need in the software industry, simpler development alternatives were created, somewhat more familiar to the enterprise world. One result of this was the Go language, now used by giants like Google, Netflix, Uber, etc. Clearly, these companies adopted Go to apply in areas where there was a need for critical processing with low resource consumption. Java, Kotlin, and similar languages are still there processing business rules, but now sharing the backend with Go.
The Need for "Safe Systems Programming"
Microsoft estimates that each severe Windows bug costs $150,000. Per year, 468 such bugs occur, meaning $70.2 million. However, indirectly these bugs can cause other problems, such as opening breaches for Ransomware.
It's estimated that per year these bugs can cause losses of around 4 billion dollars.
Engineers at Microsoft and Google concluded that around 70% of bugs are caused by errors when handling pointers and objects.
At first, this number may seem exaggerated, but notice that this includes Null Pointer References (The Billion Dollar Mistake), memory leaks, improper access to object references, etc. In other words, it's not exclusive to C++, even Java and other languages contribute to this estimate.
So a new industry need emerged: Safe programming.
This is confirmed by trends in some languages trying to reduce Null Pointer Reference problems using option types (or maybe types). A good example is the Dart language, which is including null safety behavior.
Compiled and Safe Language: Where Rust Shines
Rust is the safest language that exists because it doesn't have reference problems such as:
- Null pointer reference
- Access violation
- Invalid type cast
- Memory leak
- Double free
Rust is also safe enough to guarantee that thread execution is free of race conditions - when two threads try to modify the same shared data at the same time.
Remember that 70% of bugs are caused by problems handling pointers and objects. Rust doesn't have these problems.
But it's not just the safety and code quality of Rust that's higher. Rust is one of the fastest languages that exists:
- Has no Garbage Collector and consequently doesn't suffer from its implications
- Much of the memory is allocated on the stack, which is much faster than the heap
- By guaranteeing safety at compile time, execution is free of checking overhead
- Compilation with Zero-cost abstraction, where structuring source code in a more "human" format doesn't affect the compiled code
Let me cite an example so you understand how fast we're talking. A colleague mentioned that an application in Go could validate a million CPFs (Brazilian tax IDs) in 200 milliseconds. Out of curiosity, I did the same test - I created a program that reads a txt file with 1 million formatted CPFs (15 Megabytes in size), unformats and validates all records. In Rust, it took 60 milliseconds, including reading the file.
"Rust? Never heard of it. Who maintains it?"
Rust was developed inside Mozilla, but currently a transition is being made to create an independent foundation. Its project started 10 years ago, so in terms of maturity, its age is similar to Go.
Rust has a very large community:
- According to GitHub, it's the second fastest-growing language. It's in position 13, ahead of Swift, Kotlin, Dart, etc.
- For the 5th consecutive year, it was elected the most loved language on Stack Overflow
- In recent versions, 900 different developers contributed. In total history, there are 2930 contributors
- For comparison, Java in the last 6 months had 200 developers contributing
- The Language Server alone has 200 contributors
Several giants support the project, such as AWS, Microsoft, Google, etc. Many even with financial support.
Recently Facebook and Microsoft announced job openings to contribute directly to the compiler.
"But after all, who uses it in production?"
Google, Microsoft, Facebook, Amazon, Apple, and Discord are some of the cases.
In general, it's used for infrastructure routines such as critical security controls, devops, operations to support high I/O transfer, parallel processing, high-performance web services, etc.
It's also worth mentioning that Rust is being applied in several other libraries and frameworks:
- Fuchsia, Android's replacement, where several modules are being written in Rust
- Chromium, the engine used in Google Chrome and Microsoft Edge browsers, is developing new modules in Rust
- Deno, Node's replacement, is also being developed in Rust
- Linus Torvalds showed support for allowing Rust to develop Kernel modules
- React's core team is evaluating rewriting internal routines in Rust
"What are other positive characteristics of Rust?"
- Modern syntax
- Doesn't allow null
- Concept of Ownership and Borrowing
- Concept of mutability
- Algebraic enums
- Advanced Generics
- Tuples (set of heterogeneous types)
- Intelligent type inference
- Pattern match
- Meta-programming
- Unit testing in the source itself
- Free and Open Source (MIT and Apache 2.0 license)
- Generates native binary code without runtime or VM for various platforms
- Generates dll/so libraries
- Work-Stealing thread management
- Modern package manager
- Many free libraries
- Various editor options
- Modern Language Server
- Great experience in VSCode, including debug
"I heard Rust isn't object-oriented"
Let's review what the aspects of OO are: abstraction, encapsulation, polymorphism, and inheritance.
Rust only lacks inheritance. It's worth remembering that nowadays inheritance is considered an anti-pattern. If necessary, you can achieve similar results using interfaces and composition. So the question of whether Rust is OO or not can be subjective. Regardless, we can say that Rust is a multi-paradigm language: procedural, functional, and with elements of object orientation. Rust also has other advantages that don't exist in OO, such as ownership.
"Being so good, why isn't Rust used in business rules?"
Rust introduces some new concepts that end up generating a steeper learning curve compared to other languages. Some of these concepts require the programmer to adopt a mindset that wasn't necessary before. It's interesting to note: this type of mindset ends up adding to the programmer a better way of programming, being useful even for programming in other languages.
So, depending on the programmer's capacity, they may have difficulty assimilating some things - in general, a certain level of dedication and study is necessary, which perhaps not everyone has the profile for.
Another aspect is the reduced ecosystem of libraries and frameworks for enterprise solutions, which other languages already have consolidated alternatives for.
In summary, Rust has a niche more similar to C++ and Go. However, there are indeed cases of web applications developed entirely in Rust, both on the backend and frontend.
"Rust must have a very steep learning curve"
As explained above, Rust does have elements that don't exist in other languages that in turn need to be studied.
However, the more complex characteristics can be worked around. For example: if you have difficulty with lifetime, use smart pointers Rc or Arc. If you have difficulty implementing interfaces (traits) or functional syntax (closures), use the traditional structured form.
In other words, even without mastering the language, you can somehow prevail and get results while acquiring knowledge to do more advanced things.
"So productivity must be low"
Initially, it's natural not to feel as productive compared to another language you have more experience with. To ensure code safety, the compiler has some stricter rules that the programmer may take more time to adapt to.
But many have already reported that in the long run, the tendency is for the programmer to save time because they'll have to do less maintenance since the program has fewer bugs.
Creating a Proof of Concept and Defining Where to Apply
In my case, I looked for a real problem that Rust could solve where no other language could surpass. The case I chose was to rewrite a routine done in Ruby that took 20 minutes. The result couldn't be more satisfying: the same routine done in Rust took 20 seconds.
Instead of rewriting an existing routine, could I create a new routine to serve as a proof of concept? Yes, but without having a reference, it would be difficult to say how much better it was than another language. The result could be subjective and raise improper deductions.
But will I want to rewrite all Ruby routines in Rust? This should be clear: no. Ruby has its well-defined role and most of the time achieves satisfactory results. However, for routines that require high processing power, Rust can serve as an alternative. Another possibility is for critical routines, even without the need for high performance, that need extreme security - Rust can also be useful to achieve superior robustness.
Conclusion
When we talk about Rust, it's important to consider two aspects we should prepare for:
-
Psychological aspect. Human nature is to restrict changes and learning new things. When describing Rust, be careful not to show features that are too advanced so as not to scare anyone - it should be clear that it's possible to learn.
-
Economic aspect. There may be fear of wasting time rewriting legacy code. It's interesting to convey the idea of Rust being an ally, and not a "silver bullet" solution to replace legacy. Know that there's a gain for the company is essential - the change must result in a real advantage. Explore ideas of processing speed, lower resource consumption, fewer errors, etc.
Those who work with development have certainly heard this: "it has to be fast", "it can't consume so much memory", "it can't have errors", etc. I, being a software engineer, can't see all the computational benefits of Rust and not imagine where it can be applied.
Rust is a modern, innovative, production-ready language that managed to combine safety and performance in the same technology. Large corporations are using and supporting it, which is a positive factor for its adoption, creating a very solid future perspective. Rust can be a powerful ally to work together with other languages. Its learning requires a bit more dedication, but in the end, you get a prize - you'll be able to create high-performance and extremely consistent applications.