3 ms·

Rust is a nice idea, but as of 2019 C++17 is simply better in every way. Yes, there's can be benefit to starting from scratch with a different language w.r.t.

Rust is a nice idea, but as of 2019 C++17 is simply better in every way. Yes, there's can be benefit to starting from scratch with a different language w.r.t. training new teams with good habits and skills from the start. But going into Rust just because it's fashionable at the moment is a recipe for pain several years down the line. If you want a working pain-free solution learn C++17 instead.

bschwindHN 8y ago
> If you want a working pain-free solution learn C++17 instead A solution to what, exactly? I'll admit I haven't worked with C++ in awhile, but I'm skeptical of C++AnyYear being "pain-free". What do you like in C++17 that you feel is lacking in Rust?
ilovecaching 8y ago
This is a really bold statement that sounds like it’s coming from someone who is afraid that their knowledge of C++ is going to be obsoleted in a few years. C++ 17 is still a mess. You still lack a proper package manager, type constraints, modules, sane lookup rules for function calls, thread safety, a proper monastic future type, I could go on. Also most people won’t see C++ 17 or 14 for another decade. Even if the language decides to start bolting on more features the ecosystem is still very slow.
- pjmlp 8y ago
  Those same people are less likely to throw their company jewels away and rewritte everything from scratch, specially if they are using UI toolkits, graphical debuggers, game engines or GPGPU.
- otabdeveloper1 8y ago
  > C++ 17 is still a mess. No, it is not. > proper package manager, modules That's an OS usability issue, not a language problem. Personally, Nix solved this for me. > type constraints C++ has type constraints, and ones that actually work. I suspect what you call 'type constraints' is something that can't exist if you understand the difference between 'run-time' and 'compile-time'. > sane lookup rules for function calls A very minor issue. If you don't like function overloads, then don't use them. > thread safety, a proper monastic future type Please no. The kind of 'thread safety' you want destroys the benefit of using threads in the first place. C++ threading is perfect as it is. > Also most people won’t see C++ 17 or 14 for another decade. Frankly, I don't care about these twisted people stuck in enterprise hell.

bschwindHN 8y ago

> If you want a working pain-free solution learn C++17 instead A solution to what, exactly? I'll admit I haven't worked with C++ in awhile, but I'm skeptical of C++AnyYear being "pain-free". What do you like in C++17 that you feel is lacking in Rust?

ilovecaching 8y ago

This is a really bold statement that sounds like it’s coming from someone who is afraid that their knowledge of C++ is going to be obsoleted in a few years. C++ 17 is still a mess. You still lack a proper package manager, type constraints, modules, sane lookup rules for function calls, thread safety, a proper monastic future type, I could go on. Also most people won’t see C++ 17 or 14 for another decade. Even if the language decides to start bolting on more features the ecosystem is still very slow.

pjmlp 8y ago
Those same people are less likely to throw their company jewels away and rewritte everything from scratch, specially if they are using UI toolkits, graphical debuggers, game engines or GPGPU.
otabdeveloper1 8y ago
> C++ 17 is still a mess. No, it is not. > proper package manager, modules That's an OS usability issue, not a language problem. Personally, Nix solved this for me. > type constraints C++ has type constraints, and ones that actually work. I suspect what you call 'type constraints' is something that can't exist if you understand the difference between 'run-time' and 'compile-time'. > sane lookup rules for function calls A very minor issue. If you don't like function overloads, then don't use them. > thread safety, a proper monastic future type Please no. The kind of 'thread safety' you want destroys the benefit of using threads in the first place. C++ threading is perfect as it is. > Also most people won’t see C++ 17 or 14 for another decade. Frankly, I don't care about these twisted people stuck in enterprise hell.