4 ms·

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 a

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.

spacechild1 3y ago
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?
- quchen 3y ago
  > 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.
  - spacechild1 3y ago
    You're right. I got confused by the C++17 "upgrade" argument (which doesn't make any sense to me). The following point made me laugh, though: > Being written in Rust will help fish continue to be perceived as modern and relevant. Is this tongue-in-cheek or meant seriously?
    - cube2222 3y ago
      I believe it's meant seriously in that being written in Rust it's more likely to attract contributions from people doing it in their free time. I have only read the discussion when the rewrite was first proposed, but I believe that was mentioned as an advantage.
      - spacechild1 3y ago
        > being written in Rust it's more likely to attract contributions from people doing it in their free time. Ah, because there are no Rust jobs? duck
        fidelramos 3y ago
        I'll take the bait. The increasing number of Rust jobs ask you for previous Rust experience, if only on open-source or hobby projects.
    - stouset 3y ago
      > Is this tongue-in-cheek or meant seriously? 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.
      - noobermin 3y ago
        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.
        stouset 3y ago
        I think you’re missing the point. 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.
    - kstrauser 3y ago
      The fishshell.com website starts with: > Finally, a command line shell for the 90s When in doubt, assume the Fish team is being tongue-in-cheek.
menaerus 3y ago
What you're saying > 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 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 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.
- trealira 3y ago
  > 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 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.

spacechild1 3y ago

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?

quchen 3y ago
> 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.
- spacechild1 3y ago
  You're right. I got confused by the C++17 "upgrade" argument (which doesn't make any sense to me). The following point made me laugh, though: > Being written in Rust will help fish continue to be perceived as modern and relevant. Is this tongue-in-cheek or meant seriously?
  - cube2222 3y ago
    I believe it's meant seriously in that being written in Rust it's more likely to attract contributions from people doing it in their free time. I have only read the discussion when the rewrite was first proposed, but I believe that was mentioned as an advantage.
    - spacechild1 3y ago
      > being written in Rust it's more likely to attract contributions from people doing it in their free time. Ah, because there are no Rust jobs? duck
      - fidelramos 3y ago
        I'll take the bait. The increasing number of Rust jobs ask you for previous Rust experience, if only on open-source or hobby projects.
  - stouset 3y ago
    > Is this tongue-in-cheek or meant seriously? 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.
    - noobermin 3y ago
      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.
      - stouset 3y ago
        I think you’re missing the point. 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.
  - kstrauser 3y ago
    The fishshell.com website starts with: > Finally, a command line shell for the 90s When in doubt, assume the Fish team is being tongue-in-cheek.

menaerus 3y ago

What you're saying > 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 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 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.

trealira 3y ago
> 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 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.