Why should I move from C++ to Rust?

I’m a c++ programmer since unfinished the uni a couple years ago, worked for a couple companies with only it on my toolbox. A couple of friends are trying to move me to Rust since it’s the C for the new era. Should I?

Did you find this post useful? Show some love!
Ben Halpern DEV.TO FOUNDER

Hey there, we see you aren't signed in.

Please consider creating an account on dev.to. It literally takes a few seconds and we'd appreciate the support so much. ❤️

Accepting that I'm being a bit nit-picky: you don't have to "move from" one to the other. They're tools for your kit. Not exclusionary religions. A carpenter doesn't move from hammers to nail guns; you learn how to use both and decide if/when to use each.

While I wouldn't recommend trying to learn every new language that pops up on your radar, Rust has shown itself as a serious language worth picking up if you're in the C++ world.

If you're at least familiar in C++ enough to put it on your resume (and not risking being a jack of no trades), then go ahead! It's great to learn a language with other people. Yay community!

If you're not at least at resume-level with C++, I'd stick with that. C++ isn't dying anytime soon.

Seconding this! I'm in the process of learning Rust as well; that tradeoff I mentioned in my other comment has different outcomes for different projects.

By the way, this needs to be put on a billboard in every major tech city...

You don't have to "move from" one [language] to the other. They're tools for your kit. Not exclusionary religions.

up my game in C++ is one of my focus now. thank you very for you advice

Rust is like playing laser tag in a house of mirrors.
C++ is like shooting laser guns in a house of mirrors.

One is crazy and fun, the other smells like sulfur and charred flesh.

Ha ha ha.

But seriously, coming from an expert-level C & C++ developer, that's not exactly the whole picture. We actually do people a disservice when we misrepresent other languages.

C++ gives you a lot more control than many other languages, but it is "infamous" for not stopping you from doing stupid things. You have to know what you're doing...and if you DO, you can do some incredible things most other languages can only dream of.

However, C++14/C++17 is a whole new language. It is no longer necessary to manually manage memory - safe memory idioms are actually implemented and standardizard now - so it's just as safe to work in C++ as in any other language with access to bare metal.

Also, remember that Rust is newer. This means that, while it introduces a whole new concept of safety, it is naturally going to be more prone to bugs. C++ has been around for such a long time, bugs (in the compilers/standard libraries) are relatively few and far between.

Secondarily, Rust's young age means that there's less precedence. A ton of production-quality C++ code exists for just about everything, so it's easy to learn from other people's work. Rust doesn't have anywhere near that much production-grade code floating around the open source world, simply because it hasn't existed long enough. That's not a flaw, per-se, but it's a factor to consider.

Now, yes, C++17 is fairly new as well, but many of the safe-memory features have been in use via Boost since long before C++14's release. Even besides that, switching from the old methods to the new ones is often a nearly 1-to-1 tradeoff (i.e. declaring unique_ptr<T> or shared_ptr<T> instead of T* in the same capacity, and dropping the your delete statements.)

So, ultimately you have a tradeoff to consider:

  • C++17 is as memory-safe as anything, so long as you don't try to wrest control away from those safe-memory idioms by using the legacy techniques. It is also more stable, with a considerably larger precedence (more tutorials, examples, projects, and coders). However, if you're intent on bypassing all the safety rails, there's no stopping you.

  • Rust is designed to be memory-safe from the get-go. You really have to work at it to hurt yourself, and its flat impossible in some cases. However, it's a newer project, meaning you're giving up a bit of time-earned stability, and a LOT of precedence. You'll wind up off-roading (figuring it out yourself) a lot more for production-level challenges, on sheer merit of this being a younger language.

I was also under the standing that C/C++ was memory unsafe/required a ton of manual work, which is why Rust seemed interesting to me at first. I thought everyone was still running their own malloc and free. Rust also has their book which made it easy to jump right in. Do you know of any good places to get started with C++17?

I rather like Barek's Coding Blog, which has a lot of C++17 tutorials and guides. However, I started yeeeeeears ago in college, so I don't know the best "getting started" tutorial for C++17 yet.

I used to work as a Research Assistant for a while.

Professor says "The code has to be fast so you can only use C++".

Sends me some code one day from another Grad Student in an email: "This is an implementation of some algorithm I don't want to describe, just put it in a function and use that." The code is 7 nested for loops over a 2D array using pointers to add different cells into an accumulator. The code was just intended to sum the contents, but ... you would never know by looking at it.

Sometimes less is more. I would still use C++ for lots of projects and assuming a decent team. If someone randomly asks what I think of C++, I will warn them away.

C++ is a great language if you know what you are doing and need to do something fancy. Most teams don't have this level of expertise and don't need anything fancy. Instead I would recommend straight-jackets to counter the baseline insanity of programming.

Sure, but how do you get to know what you are doing if you never use it?

I don't "warn them away" - that just unjustly scares people into not learning a valuable tool. Rather, I point out the dangers, and give them some knowledge of what they're walking into.

In other words, don't tell people not to climb the mountain because it's too dangerous. Tell them it's dangerous, and then point them in the direction of the nearest sherpa shack. ;-) Let THEM decide if/when they are ready.

And anyway, wouldn't it be better for someone to play with C++, blow up their program in a terrifying barrage of segfaults, and then learn "ohhhh, I have to be careful with this", instead of having them never learn C++ until they're asked to use it on the job, and then have that barrage of segfaults be in prod? (Because, yes, that'll happen to some people, because management.)

I recommend that everyone learns lots of major languages in no particular order:

Python
C++
C
C#
F#
Groovy
Basic
Java
JavaScript
Ruby
Bash
Haskell
OCaml
Rust
Lisp
SQL
TCL

certainly not an exhaustive list.

As also an experienced C++ programmer I have very different views. If you are doing anything remotely cross platform or are in a situation where you aren’t running on the latest versions of a particular OS you simply won’t have c++14/17 available to you. If you need your code to run on RHEL 6 you don’t even get a fully functional C++11 toolchain. I have tried bootstrapping alternative tool chains on these older OSes but it’s an exercise in futility. Yes if you have the luxury of not needing to support any older systems you may be able to use c++17 but where you can’t, you can still use rust as it’s binaries are statically linked and mostly just require a Linux kernel made in the past decade. Also like you say c++14/17 are really a different language and if you have to learn something new I would definitely pick rust. It’s like what c++17 would be if it could drop all the legacy baggage of older c++ and c. And it’s still ABI compatible with C so it’s pretty easy to bring in all that other production code that what’s written.

That's fair. I work a lot with C-level memory management, so I know you sometimes you just have to go there.

I would say that the difference between C++11 and C++17 is not as vast as the difference between C++11 and Rust. So, if it comes down to time constraint, it's still faster to learn the new features than an entirely different platform. (For one thing, Rust's memory management doesn't even resemble C++'s; which may be a good or a bad thing, depending on the situation.)

Honestly, as I think has already been established, learn them both.

Well that’s still assuming c++11. The software I was developing at my previous job had OS constraints that kept us having to use C89/C++98. I personally have no desire to invest time in c++11/14/17 because it won’t be a viable option for enterprise software dev for at least another 5-10 years. 5 years until the distros that don’t support c++11 get end of lifed and more like 10+ years until the c++14 is the minimum standard across most deployed systems. Contrast that with the fact that today I can write rust code and deploy to those ancient distros using the latest and greatest language features. If someone had a remotely reasonable way to bootstrap a clang/llvm/muscl/libcxxrt/libc++ toolchain to generate fully statically linked c++ binaries that don’t require the distro to support newer runtime features that would change a lot. Doing this with pure C isn’t terribly difficult as you can mostly just build muscl and statically link it without issues. Attempting it with C++ is near impossible. It can be done for sure but you could probably learn rust in the amount of time it would take to get it correct. Given that, to me it doesn’t make sense to invest resources in the newer c++ specs are especially when imo rust is a nicer language. It has a consistent language design, proper error handling that isn’t exception based, functional programming influences, and much nicer standard library, proper enums and the list could go on. Modern C++ has attempted to add several of these things but they are hacks on an aging language that don’t fit well and have to be overly verbose to accomplish the same as rust.

Yes, and that's called "using a language on its own merit" right there. If Rust works, more power to ya. But the fact that C++17 isn't viable in your use case isn't saying it has none - that's all I'm saying. It's worth knowing both, because both have many cases where one is going to work better than the other in that situation.

For the record, I don't find C++ verbose at all, and I'm a Pythonista at heart (long live brevity and elegance!). I've learned that "verbose" is terribly subjective - it's usually our mental shorthand for "I don't like how it looks".

By the way, C++11/14 has already been a viable option for enterprise software dev for many years. C++17 is just in its early stages of adoption in that regard. What you mean is it's not an option for your enterprise software dev...which is valid, but isn't the same thing as all. ;)

Again, nothing against Rust here. They just both have their place, and your use case is certainly good information in regards to Rust's merits!

True enough. If you are lucky enough to be more selective with what OSes you have to support more power to you. I work I. The network security space and not supporting ancient OSes is usually out of the question. Knowing both would be great. If you are like me and have limited time for learning both isn’t always an option.

I honestly would not "leave a language" for any language. As others have said, if you believe you already know C++ at a well enough level then sure learn another language to expand your knowledge and tool box.

But really I just think C++ has gotten a bad name and with a lot of people teaching it completely wrong. Too many people seem to just teach it as an extension of C and not as its own language. I still see way too much C++ code is that is pretty much just C code with classes. Not using the standard library at all.

Then there is Modern C++ with C++11/14/17. Which is even more of a completely different language. You can still make things go seriously wrong if you want to, but the language is there to help you. Let the language help you. The standard library has so many things to help you, don't shy away from it.

Everyone seems to address the memory safety of Rust - but for me, a major advantage was just the overall consistent and clean language design. Rust is just more fun to work with. For example, in C++ you can always write C-structs/typedefs, which add a whole new syntax (but everyone tells you to not use them anyways). Another example is that in Rust the compiler does not need the virtual keyword, which is a great simplification without the loss of control. Enum variations can contain data. Const is the default and mutable must be added. References automatically dereference, when required. The std lib feels like it's been designed, not just somehow written. Rust has no exceptions and no nullptr, but instead uses common language constructs to achieve the same thing with less complexity and less code (just like boost, but seamlessly integrated into the language).

I think most people underestimate the psychological factor of having to work with a language that has been modified on every corner for over twenty years, which always leads to inconsistencies.

When people ask me how C++ is, I answer: C++ consists of just a few simple rules, but a ton of strange exceptions.

At least try out Rust, and then realize for yourself that you don't want to go back :D

I think move isn't the right term. Learning something new is always a good way to add a weapon to your arsenal (is there any other way?). Fun fact my C++ really improved since I am learning rust.

I could understand why C devs don't wanna switch to Rust, but C++?

What makes you prefer C++ over Rust besides knowing it better?

Classic DEV Post from Apr 11

What do you do on a daily basis for your job?

...

READ POST
Follow @ben to see more of their posts in your feed.