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.

Feb 3, 2017 – 10:10


Martin Vidner

Thanks for a high level summary, David!

My own experience with Rust is limited to a handful of exercises from the Advent of Code (which is great fun BTW) plus I read the O'Reilly Programming Rust book.

Originally I naively thought that Rust would simply take over all C/C++ business. But discussions I've seen (especially an informative one about Rust vs Go) have swayed my opinion: Rust is harder, so it will be only used when it pays off.

A subtle strength of Rust is that it is able to replace C (C++?) code incrementally. Federico Mena Quintero has been slowly introducing it in the GNOME SVG library for example. This kind of gradual migration is apparently enabled by

  1. providing a compatible ABI
  2. not requiring a runtime (unlike Go)

A thing I missed in your article are the references: can you point to some websites or books that you found useful?

David Majda

Good point about the incrementality. This is also what Mozilla is doing now with Firefox.

As for references, I mostly followed The Rust Programming Language and googled when I needed more in-depth explanation of some topic (usually landing on some random blog post). During my exploration I also wrote few toy programs on the side, but nothing substantial. (I actually wanted to write some bigger program to get even better feel for the language and see which initial problems tend to fade away and which do not, but I had to cut things short because my attention will focus elsewhere soon.)

Michael Aaron Murphy
Michael Aaron Murphy

So I've had two years of experience with Rust, and I can tell you for certain that developing software with Rust is significantly easier than C or C++. At times it is even simpler than Go. Would I ever write anything in Go/C/C++ now if I have a choice? Heck no.

Why? Rust software just works, and it's incredibly easy to manage and maintain your projects and all of their dependencies. Fixing runtime errors requires serious hard work in other languages, and Rust allows you to ensure that you have your runtime errors fixed at compile-time.

Here's my advice: the longer you stick with Rust, the more natural and instinctual Rust's mechanics become, to the point where after at least a month you'll have a hard time going back to the unsafe monkey business in other languages. Ain't nobody got time for that.

Add comment

It is not possible to add comments to posts older than one month.