Rust is infamous for having a steep learning curve. The borrow checker is the first boss you must defeat, but with a good mental model of how memory works, how objects move, and the rules that the borrow checker enforces, it becomes second nature rather quickly. These rules may sound complicated, but really, they are about understanding the fundamentals of how a computer works.
That said… the difficulties don’t stop there. Oh no. As you continue to learn about the language and start dealing with things like concurrency—or, God forbid, Unix signals—things can get tricky very quickly. To make matters worse, mastering idiomatic Rust and the purpose of core traits takes a lot of time. I’ve had to throw my arms up in frustration a few times so far and, while I’ve emerged from those exercises as a better programmer, I have to concede that they were exhausting experiences. And I am certainly not an expert yet.
So, yes, there is no denying in saying that Rust is harder than other languages. But… does it matter in practical terms?
says that we should conclude the post right here with a “no”—and I think that’s the right answer. But let’s see why.
A blog on operating systems, programming languages, testing, build systems, my own software projects and even personal productivity. Specifics include FreeBSD, Linux, Rust, Bazel and EndBASIC.
To answer this question, I’d like to imagine what would happen if we were to use Rust in a large team (say tens of people) that deals with a large codebase (hundreds of thousands of SLoC).
The reason I pick this scenario is totally unrelated (wink, wink) to the work I do on a day-to-day basis in Azure Storage. Our current codebase is written in C++ and has its fair share of NPEs and concurrency bugs, so we have sometimes argued fantasized with the idea of adopting Rust.
An obvious concern that arises is that adding a new language to a large project is… very difficult: fighting inertia, bringing up tooling, training people, porting code … these are all very hard work items. But there is a more subtle worry: even if we went through this whole endeavor, would our developer population be able to learn enough Rust to contribute to the codebase in a meaningful way? The language is, again, complex at first sight, and we should not expect everyone to master it.
The first observation is that, in a sufficiently large team, we will have developers with various levels of expertise no matter the language. This is expected and intentional, but depending on the language, the consequences are different. For example: C++ is also a very complex language. Sure, it may be easier to write than Rust because the compiler is more forgiving, but it’s also much harder to guarantee its correctness. This comes back to bite the developer team at a later point, because now you need to call the experts to debug crashes and race conditions.
The second observation comes from my writing of side projects in Rust. I’m finding that the majority of my time goes into writing straightforward business logic and refactoring tests, for which Rust doesn’t get in the way. It’s only during certain parts of the project’s lifetime that I’ve had to build the foundations (abstractions, layering, async constructs, etc.) or done large redesigns, and it’s only during those times that I’ve had my fights with Rust.
In other words: given a sufficiently large project or team, and irrespective of the language, there will always be a set of core maintainers that design, write and maintain the foundations. This set of people knows the ins and outs of the project and should know the ins and outs of the language and its ecosystem. This set of people is necessary. But once these foundations are in place, all other contributors can focus on the exciting aspects of building features. Rust’s complexities may still get in the way, but not much more than those of other languages.
To conclude, I would like you to consider again that learning a language is not just a matter of learning its syntax. Mastering a programming language requires months of expertise with the language’s idiosyncrasies and its libraries, and one must go through these before making comparisons about long-term maintainability. But yes, Rust could be simpler, and there are efforts to make it so!
Finally, a question for you. I haven’t had the fortune (?) of working in a large-scale Rust project yet, so all I’m doing is hypothesizing here based on experiences with other languages in large projects and teams. If you have converted a team into Rust, or if you were brought in to contribute to an existing Rust codebase, would you mind sharing your experience below? :)