They said that they thought it wasn't worth updating from C++11 to C++17. In their defense, C++17 adds only some incremental changes. There isn't much to port anyway.
Although I don't disagree with this:
> Sorry, you're never ever going to beat "we did it to chase the new shiny" which is the story across the dev world.
I don't think that's the case here. Rust offers more advantages over C++11 than C++17 or C++20 do.
For people who don't want to find the relevant part of the original post, this is it:
> We moved to C++11 in 2016 (some quick calculation shows that's 5 years after the standard was released), and we're still on C++11 because the pain of upgrading is larger than the promises of C++14/17.
But why would they need to "upgrade" to C++17/20 in the first place? If you don't need any new features, you can just stay at C++11. (C++11 vs. C++98 is a whole other category.)
So why exactly did they need to rewrite it in Rust?
> So why exactly did they need to rewrite it in Rust?
The root comment links to a post literally about this, the post you're replying to lauded its content. Reading it sounds like a good idea. You can then still disagree, but the question you've asked is definitely answered there.
Let’s assume it was originally written in FORTRAN. Would you think it was a joke or serious?
The writing is on the wall for C++. They’re a little ahead of the curve, but rewriting in a well-liked modern language will likely benefit the health of the project’s contributor pipeline for years to come. There aren’t a lot of people choosing to learn C++ (or FORTRAN) these days.
Fortran has a modern version that codes are written in today in the scientific world. Heck, I write fortran myself and did so last night now that I realise it.
Do users still exist? Sure. Is it a healthy, thriving ecosystem with a promising future, increasing mindshare, and serious advantages over the alternatives? Not so much.
> In their defense, C++17 adds only some incremental changes. There isn't much to port anyway.
contradicts what they're saying
> and we're still on C++11 because the pain of upgrading is larger than the promises of C++14/17.
I wouldn't understand what "pain" they're suggesting since the "process" of upgrading the codebase to a newer C++ standard is merely done by replacing the -std=c++11 with -std=c++17 in your build flags. In 99% of the cases, you call it a day. In the remaining 1% of the cases, you deal with the warnings the compiler may have issued because of possibly deprecated functions/headers/keywords you may be using in your code. Since there are very few of them (https://isocpp.org/files/papers/p0636r0.html#removed), and are mostly quite a niche or very old legacy, in the worst case it's going to be a matter of a few days it will take you to fix them.
Since C++ (thankfully) pays attention to ABI stability (aka frowned upon "backward compatibility"), the code will still continue to run as before. Tada ... you're done.
P.S. C++17 is more than just an incremental release (https://isocpp.org/files/papers/p0636r0.html) and offers a lot of goodies both in the language spec (e.g. guaranteed copy elision, fold expressions, compile-time if, structured bindings, compile-time lambdas, improved TMP etc.) and library spec (string_view, variant, optional, any, read-write locks, polymorphic allocators, filesystem support etc.).
However, that does _not_ obligate you in any sense to all of the sudden rewrite your whole codebase (!) with new fancy C++17 features - the secret sauce in mature dev environments is that you do it incrementally and where you see fit.
Fish authors decided to take a drastically different route, and that's totally fine, it's their code after all, but in the absence of quantifying the "pain" or the lack of "promises" I call it a FUD.
> What you're saying contradicts what they're saying
I don't think so. The fact that there are only incremental changes would mean that any sort of effort at all in updating may make the update considered to be not worth the effort.
> P.S. C++17 is more than just an incremental release (https://isocpp.org/files/papers/p0636r0.html) and offers a lot of goodies both in the language spec (e.g. guaranteed copy elision, fold expressions, compile-time if, structured bindings, compile-time lambdas, improved TMP etc.) and library spec (string_view, variant, optional, any, read-write locks, polymorphic allocators, filesystem support etc.).
Some of those things I hadn't considered, but the majority of all those things I would consider to be incremental changes, even if they're good and useful changes.
> I call it a FUD.
They've given their reasoning for why they decided to rewrite it in Rust instead of updating their C++ code to a more recent standard. They're not saying C++ is worthless, or that no one should use it; they're just giving their opinions on why they made the decisions they made. And you're right that without quantifying anything, it's obviously just their subjective opinions. It's not like the authors of the Fish shell are on a mission to discredit C++ by rewriting it in Rust, which is what "FUD" implies to me.
It does because you claim that the changes are "incremental" and they claim that there's an (unsubstantiated) "pain of upgrading". These two formulations are in contrast one to another. The pain of upgrading would be something that is substantial or complex and long-lasting. Incremental OTOH is considered something more trivial and something that can be done in much less time. Switching to C++17 is an incremental change but not an incremental release.
Since they have not given any substantiated reason for "we're still on C++11 because the pain of upgrading is larger than the promises of C++14/17", I'm afraid that this is a FUD by its very own definition:
FUD is generally a strategy to influence perception by disseminating negative and dubious or false information, and is a manifestation of the appeal to fear.
I hope it's clear now that giving false information with a negative appeal without substantiated content is not how it's done when it's done in good faith. I couldn't care less how they write software and in which language but bad arguments are bad arguments.
Although I don't disagree with this:
> Sorry, you're never ever going to beat "we did it to chase the new shiny" which is the story across the dev world.
I don't think that's the case here. Rust offers more advantages over C++11 than C++17 or C++20 do.
For people who don't want to find the relevant part of the original post, this is it:
> We moved to C++11 in 2016 (some quick calculation shows that's 5 years after the standard was released), and we're still on C++11 because the pain of upgrading is larger than the promises of C++14/17.