The Rationale of Rust

Today I’ll write a short and sweet post that talks about the rationale of Rust, why you’d want to learn such a language and the many benefits you’ll find in the various corners of the language.

First, let’s get this out of the way. Rust does have a steeper learning curve than your average modern language out there. Those who open up a fairly complicated codebase often scoff and dismiss its syntax as being a bit ugly, verbose and confusing. And while the language authors are working hard to minimize the boilerplate around syntax and enhance the ergonomics of the language there still exists an increased expenditure in both writing and reading Rust code. Admittedly, should you find yourself working in Rust at some point, you will spend more brain power up front.

Let’s harp on this point again so that you can first accept it before going forward.

When reading or writing Rust, you will spend more brain power up front.

Let’s also acknowledge that the Rust authors are constantly taking a hard look at the language. They are interested in writing a language that succeeds and that you ultimately find as a valuable tool in your tool box. They’re not interested in providing a language that is cryptic, noisy and just plain hard to follow. But what they’re faced with is a hard challenge known as the trifecta: safety, speed and concurrency.

I’ll bring another point home: If you are one of those developers that compares a language like Python to Rust and quickly dismisses Rust for being too complicated you are not making a fair comparison here. Python was never originally designed to address the trifecta. Speed was traded for developer productivity and concurrency was traded for…well it’s been kind of absent/broken in Python for awhile now and is now being addressed with Python 3. Don’t get me wrong, Python has its place in the world and I still love the feeling of being able to quickly lay down some code that reads and writes easily.

Also, if you working in a domain where you can make trade-offs where you can sacrifice speed, perhaps don’t need concurrency and just need something safe, then congratulations you don’t really need to bother with Rust. But what if you do want or need all three of these options? Which language do you reach for? The obvious big two that come to mind is C and C++…but even these languages don’t achieve the trifecta. Both can be used successfully with a very disciplined programmer with many years of experience but both are still very, very unsafe if you are not careful.

Even if you are super careful, you are still human and will make mistakes. Thorough testing, detailed code reviews and years of experience are your allies. But what if I told you there exists a language where you don’t need a decade of experience to be good at it? There exists a language where you don’t even need to be very disciplined on the subject of correctness? And there exists a language that will help you exploit the speed of the hardware you’re running?

You see the point that you are missing with your naivety is that all of those burdens above are farmed off to Rust’s wicked compiler. Rust’s compiler is disciplined, it’s experienced and it will help you to exploit speed and concurrency all while being safe.

Therein lies the rationale on why Rust’s learning curve is higher than other languages. You need to put in a little more effort upfront to help the compiler and in return your resulting binary is fast, safe and concurrent all while being correct. The point here is that you end up with rock-solid software that allows you to mostly focus on what your business logic. For everything else, the compiler has your back.

Rust helps you write correct applications that are fast, concurrent and safe.

I’m going to play devils advocate here and provide various responses to this article so far from a few different naive perspectives:

C/C++ Guru

C++ Guru: @deckarep obviously you must not realize that the OS you’re running on was written in C or C++ and you obviously don’t realize that we now have modern extensions to these languages like C99, C++98, C++03, C++11, C++14, C++17, C++20 which all help to write smart, modern object-oriented code.

My response: That’s great…I don’t have the time or energy to read all these specifications, I also don’t want to work in a language that needs backwards compatibility going back as far as the Jurassic period AND I want to work in this space too without having 15 years of experience and btw, it’s common knowledge that OOP sucks!

Just Another Perl Hacker

JAPH: @deckarep want to know why Rust is lame? I can literally rewrite the the Rust compiler in Perl in like 1/50th of the code size. Boom: Mic Drop.

My response: Good for you, I can appreciate fun cryptic coding puzzles just like the next person but Perl is slow, the syntax is sdrawkcab and I’m not interested in maintaining a 3-line implementation of the Raft protocol when you decide to join that next company.

Gopher

Gopher: @deckarep you nailed it; this is why Google created Go and actually built-in concurrency from the ground up where you can send data through channels this way your application is properly synchronized…oh and it’s type safe too!

My response: mmkay…how exactly is this: interface{} type-safe? Also, good luck tracking down data-race riddled code. Engineers still need to be incredibly disciplined here which many are not and the race-detector is NOT bullet-proof. I see it all the time…

Node.js Hacker

Node.js Dev: @deckarep, I don’t care about Rust I’ve got my safety and speed of the V8 engine and I’ll just utilize promises to ensure I can have my concurrency cake and eat it too.

My response: GTFO scrub…also read this.

Before you get up in arms about my artificial responses first off let me say…ANY language has its problems, Rust included. I’ve used all of the languages above at some point or another. Some I like more than others but I can appreciate them all in the right scenario.

This post remember, was about the rationale of Rust and so all of my artificial responses provide clues as to why people are working so incredibly hard to make this language succeed.

• Rust doesn’t want to be tied down by 30+ years of backwards compatibility. Imagine how inventive you can be and what you can try when you start fresh.
• Rust eschews object-oriented design. The world has moved on…we’ve lived and learned and in the process have realized that true object-oriented design is hard to do well especially when things get deep. Favor composition.
• Rust still wants to be readable and is trying really hard to get this right. An incredible amount of thought is being put into the ergonomics of the language and they’re doing what they can to hide and abstract away details without sacrificing speed. It’s getting better with every release…and it’s looking pretty damn good.
• Rust also understands that concurrent software scales well but also needs to be safe. It’s not enough to introduce concurrency without having a mechanism for correctness. Why? Because the last thing you want is to deploy a program that has undefined behavior in production because you have unsynchronized reads and writes of a Hashtable. This is why you fight the compiler…but in reality it’s doing you a solid.
• Lastly, Rust’s target audience is wide yet focused. The Rust implementors know that it can be used for systems-programming, embedded programming, networked applications, command-line applications, games, etc. Why? Because they are trying to appeal to the lowest common denominator…I’m sure if Rust powers the micro-controller of a rocket one day…it’s going to do just fine for your mobile game.

In conclusion, I’d like for you to sit down and think about this post. Wouldn’t it be great if you added Rust to your tool-belt? Yes there is a learning curve but in the end you make yourself more marketable and when you learn the odds and ends about this language and really understand why it’s here and what it’s trying to solve you’ll walk away a better engineer then when you came.

If you enjoyed this article, please leave comments as it motivates me to write more. Also please see my other articles where I talk about the Paradigms of Rust from a Go developer perspective and one where I talk about pulling off proper synchronization in Go with mutexes.

Cheers!

@deckarep