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.
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 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.)
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>orshared_ptr<T>instead ofT*in the same capacity, and dropping the yourdeletestatements.)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.
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 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
mallocandfree. 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.