Writing Rust code is not restricted to programming gurus—but there is no denying that the learning curve is steeper than that of other languages. Or is it? In this post, I’ll try to convince you that the curve does feel steep, but it isn’t when taken into perspective.
Let’s first start by stating that learning a language is not the same as learning its syntax. Learning a language involves learning the syntax, of course, but it also involves familiarizing oneself with its common idioms and grabbing a good sense of what the standard libraries provide. Picking up the syntax can be easy as is the case for Go and Python—both of which can be learned in a single day—but the idioms and libraries require weeks, if not months, of frequent practice.
When seen through these lenses, Rust doesn’t fare as badly as it first seems: sure, learning the basics takes more than a day, but in the grand scheme of things, this “delay” is not relevant: you will need a lot more time to master the language—any language—anyway and thus the first days of learning are amortized.
The problem is that simpler languages make you feel productive from day one and when Rust is stacked up against e.g. Go, it loses. But that’s a fallacy. Even if you are able to deliver code quickly after picking up one of those languages, your first code will be… “suboptimal” to put it mildly, and not something that can be deployed or released.
Let’s now take a different spin on this issue by talking about Computer Science (CS) fundamentals. I posit that writing Rust is not inherently difficult: it “just” requires one to be very aware of basic computing principles regarding memory allocation and concurrency. Sadly and sorry to say, but a lot of programmers nowadays are unaware of these basic concepts: they have grown in a world of fully-managed, garbage collected languages like Python or JavaScript where little of this matters on a day to day basis1.
Rust falls in the more traditional camp of systems languages: there is no garbage collector; all resources are managed via scoping rules (think RAII). And as we saw, Rust goes to great extents to ensure usage of these resources doesn’t cause data races via the borrow checker. But here lies the problem: writing Rust requires a very good understanding of the fundamentals behind a computer’s processor and memory model.
My take on this: for a modern C++ programmer familiar with RAII and smart pointers, Rust should be relatively easy to pick up. For a C programmer, it is borderline hard due to the higher level of abstractions involved (mutability vs. immutability, traits, etc.). But for someone that has only ever used garbage-collected languages… I’m afraid they are in a more troublesome spot.
The good thing is that these fundamental concepts can be learned by anyone and learning them is never a waste of time: the underlying computing principles sometimes leak through abstractions, which means knowing how memory and concurrency work will benefit you no matter what language you write code in.
Let’s conclude by saying that, indeed, not all of Rust is easy to pick up though. As in any language, there are advanced concepts that require more patience and practice to master, but you’ll rarely need those frequently. Just become aware of what those are so that, in the rare situations where you may need them, you know where to head to.
Some context: I’ve run dozens of interviews at Google in which I ask very simple questions (a la the famous “how do you reverse a list”). The point of this question is not only to get a solution: for me, it’s to find knowledge gaps by drilling down into the abstractions used to solve the problem. For example: these kinds of problems inevitably require using a list or dictionary and the confusion begins as soon as I ask: “what is an array?” or “what are the alternatives to implement a list?”. ↩︎