Rust impressions

Few days ago I decided to have a look at Rust. I wanted to do this for some time, mostly because Rust seemed like an interesting emerging language that might play an important role in the future. Here are my high-level observations.


The dominating feeling when learning Rust and playing with is was being overwhelmed with complexity. There are lot of concepts in the language and lot of things one needs to know to understand and write Rust programs.

Part of that complexity is because of the type system. Rust’s type system is powerful and expressive, which naturally leads to a multitude of built-in types and to quite complex type definitions and specifications. This problem is not unique to Rust — in the past, I had a similar feeling from Scala and Julia, which also have quite powerful type systems.

I actually don’t think that type system complexity is that big of a problem. In practice, it will tend to be confined to libraries — mostly the ones that define various data structures. An application programmer probably won’t need to understand all of the type system’s features and nuances in order to write programs successfully. This is similar to situation in C++, where I doubt that most programmers are able to fully comprehend the implementation of STL.

Another part of the complexity comes from the borrow checker (the part that makes Rust secure and prevents things like dangling pointers). This is a truly new concept and as such completely unfamiliar. To me, it sometimes felt like a type system squared — first, I had to make my code to satisfy the type system and then the borrow checker. Of course, in reality you have to do both at once and I imagine with complex programs it might sometimes feel like a whack-a-mole.

The bad thing about complexity coming from the borrow checker is that it won’t hide in the libraries. Application programmers will have to deal with it all the time. The good thing is that the rules are not that hard and I think can get used to them quickly. In most cases, they really only formalize thinking that any C/C++ programmer must do anyway.

More observations

Compared to other languages, I found Rust programs harder to follow (in the sense of knowing exactly what is happening in each step and simulating the execution in my head). The only other language with which I had this difficulty was C++. But I suspect this feeling would fade with continued usage and growing familiarity.

One thing that surprised me a lot is that I’m actually not sure whether I like Rust or not. On one hand it seems well designed, consistent, and fit for its purpose (a fast and secure systems language). On the other hand I prefer simpler languages with smaller set of concepts and features. But this is mostly a matter of taste. Moreover, a lot of complexity seems to be inherent to the problem of designing a secure language with C/C++ level of performance and it would be present in any such language.

Use or not?

This brings us to the most important questions: Should you use Rust? And when?

I think it makes sense to consider Rust when writing complex, performance-critical software which absolutely needs to be secure. Think OpenSSL, Apache, or JVM. This is where previously the only reasonable choice was C/C++.

If your software doesn’t have critical performance requirements, it’s probably wiser to use more high-level language — be it something from the managed languages family (Java, C#) or the scripting languages family (PHP, Python, Ruby, JavaScript). There, most of the safety that Rust guarantees is achieved by automating memory management.

If your software isn’t complex or the security isn’t critical (e.g. when writing a backend service that will not face the internet), but you still need performance, Go or even C/C++ might be a better choice. This will allow you to avoid the complexity cost.


Rust brings innovation into an important area of systems programming which was occupied mostly by C++ until now. Despite my reservations, I actually think it would be much less painful to use than C++ for most programmers. I wouldn’t be surprised seeing Rust gradually replacing C++ in the area of performance-sensitive, security-critical software as it matures. This will be not only because of the language and its features, but also because of Rust environment, which is much more modern than the C++ one. For example, one doesn’t have to deal with build systems, packaging, code reuse, etc. — these are all built in. This means that for someone coming from a modern, high-level language, Rust is much more approachable than C++.

Whether Rust will became widely used outside the area I delineated above (say for writing games or general application software) remains to be seen.