I had a conversation with a colleague at $COMPANY recently. We catch up every now and again to discuss Life, The Universe, and Sometimes Work Things1. He knows I’m a bit of a Rust fan-boy, so if I bring it up in conversation, he tends to be less fan-boyish and more rational in his approach to thinking about it. This is a Good Thing! We need people to make unbiased judgments on new technologies, ideally with the help of a number of years experience in other languages or domains to shape their thoughts.

However, one thing he said gave me pause. When discussing my wishful thought that a core C++ framework that’s heavily used in $COMPANY should be re-written in Rust (or Re-write It In Rust - RIIR), his response included this gem: What, and piss off all the $FRAMEWORK developers?

This made me think - a dangerous prospect at the best of times. Bear with me while I try and put my thoughts into words…

Why Would They Be Pissed Off?⌗

OK, obviously a relatively simple reason. This is a long, well-established C++ framework (first built over 19 years ago!), heavily used throughout the firm (thousands of human users, not to mention hundreds of thousands of grid cores), with a suitably massive source tree to go with it. It’s, to be blunt, a Big Fucking Deal at $COMPANY.

The people that work on it have a huge amount of time invested in learning it, extending it, fixing bugs in it, and generally making sure that the rest of the users have as smooth a ride as they possibly can when using it.

So, if some random Grumpy Dude from the internet some other department were to come in and proclaim loudly “Tools down folks, and start brushing up on your copies of Rust for Rustaceans”, their first few thoughts would have a lot of very naughty words in them.

Should They Be Pissed Off?⌗

So, this is where my brain started wandering after hearing the initial response to my day dream. My initial response to this is (fairly obviously, since if I agreed with it, this post would be much shorter), “No, they shouldn’t be pissed off. Why on earth would they be?”. But as with all great sweeping statements, the interesting parts are more nuanced.

Let’s look at the higher-level aspects of this. Of course they should be pissed off. There’s a huge investment in time and effort that’s gone into making $FRAMEWORK the success story that it is2. You don’t just throw this away for <insert programming language of the week here> since it’s getting all the hits on Hacker News and you’re having fun doing this year’s Advent of Code in it. If that was the only reason for doing it, then you should rightly be told to “piss off, and take your fancy new programming language with you”.

Are You Experienced?⌗

Stepping back a bit though, both sides of that conversation are missing some key context. Why do I want to RIIR? Why should something’s longevity be a default reason to say no to something newer? What makes either side of the argument qualified to say that their side is more correct than the other? I think the key things that are important to this are understanding, curiosity and a willingness to step outside of your comfort zone.

Understanding⌗

When it comes to programming languages, everyone is very rational in the way they approach the Language Wars, and there’s very rarely any bias involved. In the few cases where this isn’t true, we often have two prime behaviours on display:

  • “This new thing is so cool. It’s really interesting, and does some neat stuff. We should totally do everything in it. Everyone would really enjoy it, just like I do!”
  • “Bugger me, not another new flavour of the month. $CODE has been working perfectly well, we understand it in and out, and it works perfectly for what we need it to do."3

Both are equally flawed, for pretty obvious reasons:

  • If something’s new, it doesn’t mean it’s automatically better.
  • If you enjoy it, it doesn’t mean other people will.
  • If something works now, it doesn’t mean that it’s couldn’t be made better.
  • If you understand it perfectly well, it doesn’t mean that someone else does.

This last one is a really key one for me, and really sums up my thoughts on C++ development. My (obviously biased) take on C++ is:

  • It’s been around for a long time. What made sense when it was designed doesn’t make a lot of sense now in a lot of ways.4
  • It’s unforgiving.
  • You can work around the unforgiving nature, but only if you (at runtime mostly) remember to check lots of things. If you forget to check them, you open yourself up to random run-time weirdness. Remembering to do this each time is akin to building up muscle memory when developing new code, but not all developers will have that same muscle memory when maintaining a codebase.
  • Template meta-programming is terrible to understand unless you have a lot of experience in it.
  • Debugging output is a nightmare (hi STL!).
  • If you get it all right, it’s awesome.

The last selling point tends to be what sells C++ to others. If you get an experienced C++ dev with years of experience, and they write code with the right checks in place, the resulting binaries will be fast and effective. But good C++ devs are not as common as you’d like. Even then, good devs can still make mistakes, and since they’re not caught until run-time, you’re introducing the change of random behaviour when you least want or expect it.

So how does Rust compare to C++ in this case?

  • It’s relatively new.
  • It’s conceptually a bit harder to learn, in that it requires you to think about low-level object lifetimes and management up front. This is because…
  • A lot of the checks that you have to remember to do but aren’t enforced by the C++ compiler are caught at runtime by the Rust compiler.
  • Macro stuff is still a bit weird.
  • If you get it all right, it’s awesome.

The fact that it’s a new language makes it a hard sell for replacing existing, well-established software codebases. This really shows when you look at the number of C++ developers on the marketplace versus the number of Rust developers with any serious experience. The C++ devs vastly outnumber the Rustaceans.

My general appreciation for Rust isn’t just about the borrow checker though (Trust me, I’ve spent enough time moaning about it when staring at the compiler output!) For me, the key selling point is that stuff that used to be checked at runtime (and segfaults if not done properly) is checked at compile time. The cognitive load of having to remember to do a lot of this stuff isn’t there anymore, as the code won’t compile if it’s not done properly.

It’s worth highlighting that this is true for experienced devs who should know better, and for new devs who may not have that real world experience of working on larger codebases. The benefit from this is a greatly reduced code-compile-test cycle time, as the test part of it is moved earlier on to the compile phase.

Most folks who dislike Rust tend to focus on the first two points (It’s new! It’s hard!). They’re valid! But I really feel that the third point is the main selling point here, and automatically catching these things without even having to write unit tests to do it is huge.

Curiosity⌗

While understanding (rationally!) both side of a discussion is important, when it comes to programming languages, curiosity is a very important characteristic to have.

There are a ridiculously huge number of programming languages out there. All have varying degrees of uptake (some surprisingly so). My personal experience tends to show me that programmers who have worked with more than one language in any serious depth tend to be more well rounded and able to appreciate what different languages have to offer. They’re interested in working out why <insert hot programming language here> is picking up places in the Stack Overflow Most Loved Language survey each year.

Sadly, a lot of folks tend to just stick to what they know. This is a real tragedy, as given a bit of exposure, their years of experience could help find ways to drive new languages forward in terms of adoption and pushing the languages to be better.

It’s worse than that though, as a lot of teams don’t push for this characteristic when interviewing. It feels like a missed opportunity, a form of perpetuation, ensuring that language group-think keeps things moving along as they always have. This can be fairly dangerous for the long-term success of a project/platform. Hyperbolic? Probably. Is there some truth to what I just said? Hopefully…

Stepping Out Of Your Comfort Zone⌗

This is closely related to curiosity. If you’re curious about a new language, a new role, a new way of life, you’ll be willing to overcome the very human tendency of not wanting to venture out too far from your cave. This isn’t a very common attribute to possess though, so a lot of people find it difficult.

With Rust, the infamy of the borrow checker definitely doesn’t help. The reality of it is that when you get used to it, and understand why it’s doing what it’s doing, it’s not too bad. Did knowing that it was a bit tricky put me off learning it? A little, but in the end, the buzz around the other features of the language made me overcome this (and overcome the initial WTFisms that came from my first few Rust programming attempts), and in the end, hopefully made me a more well-rounded developer.

As with curiosity though, a lot of teams will not hire based on a willingness to do something different, but look for more of the same. As an industry, we should encourage this interest in variety in our hiring practices. I think we’ve got a long way to go on this front though.

So… Are We RIIR?⌗

Will $FRAMEWORK ever get the RIIR treatment? Not a chance, and rightly so!

  • There’s far too much sunk into it, and it’s simply too large to effectively start again from scratch.
  • Although there are segfaults from time to time (more than I’d like, but not enough to worry about in the overall scheme of things), the code is solid, and works without any real showstopping issues, meaning there’s no compelling reason to start again.
  • There are still far more C++ developers who could come in at a moments notice and be productive very quickly. This is huge and something that will take a lot of time for Rust to overcome.

Hopefully though, the mindset of wanting to do things differently will spread, and that there will at least be a balanced debate on whether the features of a language like Rust might be useful in some way in other codebases, or even in small parts of existing codebases.

As my colleague pointed out, one of the great takeaways of learning Haskell isn’t so much that we want to rewrite everything in Haskell, but that we take the concepts of functional programming (lack of side effects, etc) and apply them to other languages. That particular day dream is much more realistic, and one I hope we can achieve in the not too distant future.

  1. This may well be the title of Douglas Adams' unpublished masterpiece. ↩︎

  2. Everyone that I know has looked at or worked with $FRAMEWORK describes it as an incredibly well designed and maintained piece of software. Any piece of software, C++ or otherwise, would struggle to be used in mostly its original form for more than 5 or 10 years. Getting close to 20 is nothing short of phenomenal. ↩︎

  3. There’s sometimes a “Get off my lawn” type addendum to this too. ↩︎

  4. C++ keeps evolving, and adding more features that mimic features found in other languages. But by having to remain broadly backwards compatible, you now have both the old and the new ways of doing things, and so you end up with a Frankenlanguage of sorts that tries to be all things to all people. Maybe Herb Sutter’s C++ 2.0 will help here though, if anything ever comes of it. ↩︎