DEV Community

[Comment from a deleted post]
Collapse
 
mkeeler profile image
Matt Keeler

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.

 
codemouse92 profile image
Jason C. McDonald

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.

 
mkeeler profile image
Matt Keeler

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.

 
codemouse92 profile image
Jason C. McDonald • Edited

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!

 
mkeeler profile image
Matt Keeler

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.