5 ms·

It's not mentioned in the article, but it's worth considering the entirety of this article in comparison to C++ and its standards process. I've never actually

It's not mentioned in the article, but it's worth considering the entirety of this article in comparison to C++ and its standards process. I've never actually done it, but my understanding is that if you want to change something in C++ you have to - Make the changes and have an example implementation. - Make a paper explaining the change and why it's necessary, using the C++ paper-template/documentation format. - Post it to a listserv for comments, hope that people like your idea after all the time you’ve already invested. - Attend a meeting, possibly in person (!), maybe remote, to make sure that the committee addresses it. - Your change will make it into C++26, which means it doesn't percolate into C++-for-the-average-person for 5 to 10 years. C++20 is a very nice language but I really wonder if it can survive competing with the ecosystem that Rust has. Between the niceness of cargo for package management, allowing for breaking changes, and being open to contributions, it just has a velocity that will make it solve problems with the language in a timespan that C++ can't.

TchoBeer 5y ago
On the other hand, this glacial pace had it's upsides as well
harry8 5y ago
Counterpoint - slowing down the rate of change of a properly designed language makes it stronger. Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. Example C++. It's a fun exercise to think about how you would do C++ fresh starting with ansi C, given what you know now based on the actual experiences of C++, Java, D, Rust etc. C++ has had a tendency to attempt to solve the current problem while being tightly coupled to it, problems which may not even exist later. I submit STL allocators as an example of this. What's the best way of enforcing taste? Slow down the changes, put barriers in the way? That's horrible, sure, but is there something better? Benign Dictator maybe? Bjarne's taste has improved considerably (and I'm sure I could have made a bigger hash of it than he did starting out too).
- duped 5y ago
  C++ is the poster child of cruft and slow moving development, so it doesn't seem that these properties are correlated.
  - otabdeveloper4 5y ago
    > slow-moving development > too much feature churn Pick one, please.
    - kgraves 5y ago
      you can have both if you hire more developers on the project.
    - bryanlarsen 5y ago
      The OP said "cruft" not "too much feature churn". Very different things.
    - detaro 5y ago
      Can you point to the comment you quoted the "too much feature churn" from?
    - simias 5y ago
      High-latency but high-bandwidth. C++ features take forever to land, but there's always something big in the pipeline, for better or worse.
  - harry8 5y ago
    Yeah at first blush. Then you look at when C++ was new and being standardized it was moving pretty damn fast compared to anything else. They had a whole catchphrase "Remember the Vasa!" In an attempt to justify curbing enthusiasm for at least some of the many and disperate proposals. Now, despite the big changes of C++11 as the watershed it has slowed and is doing better for it. Correlated? Maybe. Good taste should also slow the rate of change of "What do I have to deal with as a programmer in this language?" Also if the original language design that people found good enough to use was done really well then it shouldn't need too much change on top of it? Point taken, you can use C++ as an example for anything. Even opposing points. It really has it all! (Like it or not)
johannes1234321 5y ago
I think having an implementation isn't needed. However having an implementation proves that the idea is feasible and simplified verifying it. Also you don't have to be in the meeting in person, however a paper without author or somebody else who can argue for it will have a hard time to get the attention considering the number of papers in the queue.
debacle 5y ago
If rust ever reaches the ubiquity that C++ has, it will have same barrier to change that C++ has.
- binarycrusader 5y ago
  Will it? Rust has editions which C++ does not have which seems like a potentially significant mitigation.
  - otabdeveloper4 5y ago
    How are "editions" any different from C++ standards versions?
    - steveklabnik 5y ago
      Standard revisions are like snapshots in time. Editions are a way of introducing surface-level changes into the language, which are guaranteed to interoperate. Most features land in as many editions as possible simultaneously, the edition differences are purely the things that would be breaking changes, and so require you to opt into which ones you want. Both strategies have advantages and disadvantages.
    - IAmLiterallyAB 5y ago
      You can use new features from new Rust versions/compilers on old editions, as long as the new features don't require backwards incompatible changes. You can't use features from new C++ standards when targeting an older standard.
      - snovv_crash 5y ago
        You can, they just often live in somewhere like std::experimental
    - ben0x539 5y ago
      Editions are opt-in at a per-package level. You can write Rust 2015 code that wouldn't be valid Rust 2018 because of breaking changes, while using libraries that use Rust 2018.
otabdeveloper4 5y ago
I'm pretty sure C++ advances much faster now than Rust will in 30 years. Then again, you'll just point to how awesome it is that Rust doesn't change and stays stable and easy to use for years. It's all just rationalizations for the emotional investments you've already made.
- nickysielicki 5y ago
  Scarecrow. I’m far from emotionally invested in rust and I’ve dealt with the downvote army of zealots who want to rewrite everything in rust. I’m not the evangelist you think I am. C++ is just losing here.
  - titanomachy 5y ago
    Is “scarecrow” the same thing as “strawman”?
    - nickysielicki 5y ago
      A scarecrow is a straw-man. :)
    - elondaits 5y ago
      Strawman is less offensive.
      - nickysielicki 5y ago
        Wait, “scarecrow” is offensive now? How?
        bregma 5y ago
        If it only had a brain?
  - throwaway894345 5y ago
    Agreed (and I'm dealing with an army of Rust zealots right now on proggit). Rust has a track record of carefully considered features and a process that allows it to continue making changes to the language while managing compatibility. I do expect Rust will slow down and bureaucracy will slip in in the next 30 years (because I fully believe Rust will become very popular and many big companies will come to depend on it for security and critical real time systems), but I don't think it will move as slowly as C++ does these days.
zerkten 5y ago
The part that's not mentioned, and a reason why some people wonder why their approach didn't get traction is missing. Before starting any of these steps you need your own analysis of what will make your change successful. You'll probably only be able to make the best analysis if you socialize your idea with relevant people in the community in private. This seems really obvious, but it's a pattern that repeats with engineers engaging in what is only partially an engineering effort. Similar issues occur in the python-ideas list other places. When you follow this approach you can remove the risk of premature investment in the steps listed.
tasogare 5y ago
> allowing for breaking changes Cute for toy projects but a big disadvantage for any another kind of programming. There's a reason established languages like C++ or C# are taking compatibility very seriously.
- ben0x539 5y ago
  And it's probably the same reason Rust takes compatibility very seriously. What's with the "us vs them" attitude?
- lukebitts 5y ago
  I think that was bad phrasing on GP's part. Rust only allows breaking changes for edition changes, which are opt-in. Libraries in older (or newer) editions can still be used together in your project, no matter which edition you are using. Rust allows for breaking changes in a way that doesn't actually break anything.
bob1029 5y ago
This long lifecycle is a double-edged sword between stability & features, but you can grind down one of those edges with enough discipline on backwards compatibility. One compelling example could be the direction MS has started to take w/ .NET Core/5/6+: - Submit issue/PR on the dotnet/aspnetcore repo on GH (anyone can do this). - Conversation starts almost immediately. - Suggested changes could be merged in a matter of weeks. - Expect your changes to become available in an official release in under a year. Pre-release builds much sooner than that. - Expect an LTS release the following year. I have personally experienced this workflow a few times. It is incredible to have this type of feedback loop with something that has historically been a total black box of proprietary decisions. There are still a ton of places where you don't have much leverage, but the fact that there is any movement possible from the community at all is incredible to me (again, from a historical perspective around Microsoft & .NET). I don't have to learn how to draft a PhD thesis in order to add value to the ecosystem. Ideas should not be filtered so harshly in my opinion.
h_ans_m_443 5y ago
This kind of aggressive evangelism is hurting Rusts reputation a lot. I wish people would just stop it. Why do some Rust fanboys have to keep shitting on every other language all the time???????
- staticassertion 5y ago
  Something new is likely to try to correct perceived mistakes in something old. It shouldn't be taken as aggressive to try to say that one approach is better than another tbh.
- lenkite 5y ago
  And God help you if you point out strange warts and syntactic choices in Rust. You will be eviscerated.

TchoBeer 5y ago

On the other hand, this glacial pace had it's upsides as well

harry8 5y ago

Counterpoint - slowing down the rate of change of a properly designed language makes it stronger. Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. Example C++. It's a fun exercise to think about how you would do C++ fresh starting with ansi C, given what you know now based on the actual experiences of C++, Java, D, Rust etc. C++ has had a tendency to attempt to solve the current problem while being tightly coupled to it, problems which may not even exist later. I submit STL allocators as an example of this. What's the best way of enforcing taste? Slow down the changes, put barriers in the way? That's horrible, sure, but is there something better? Benign Dictator maybe? Bjarne's taste has improved considerably (and I'm sure I could have made a bigger hash of it than he did starting out too).

duped 5y ago
C++ is the poster child of cruft and slow moving development, so it doesn't seem that these properties are correlated.
- otabdeveloper4 5y ago
  > slow-moving development > too much feature churn Pick one, please.
  - kgraves 5y ago
    you can have both if you hire more developers on the project.
  - bryanlarsen 5y ago
    The OP said "cruft" not "too much feature churn". Very different things.
  - detaro 5y ago
    Can you point to the comment you quoted the "too much feature churn" from?
  - simias 5y ago
    High-latency but high-bandwidth. C++ features take forever to land, but there's always something big in the pipeline, for better or worse.
- harry8 5y ago
  Yeah at first blush. Then you look at when C++ was new and being standardized it was moving pretty damn fast compared to anything else. They had a whole catchphrase "Remember the Vasa!" In an attempt to justify curbing enthusiasm for at least some of the many and disperate proposals. Now, despite the big changes of C++11 as the watershed it has slowed and is doing better for it. Correlated? Maybe. Good taste should also slow the rate of change of "What do I have to deal with as a programmer in this language?" Also if the original language design that people found good enough to use was done really well then it shouldn't need too much change on top of it? Point taken, you can use C++ as an example for anything. Even opposing points. It really has it all! (Like it or not)

johannes1234321 5y ago

I think having an implementation isn't needed. However having an implementation proves that the idea is feasible and simplified verifying it. Also you don't have to be in the meeting in person, however a paper without author or somebody else who can argue for it will have a hard time to get the attention considering the number of papers in the queue.

debacle 5y ago

If rust ever reaches the ubiquity that C++ has, it will have same barrier to change that C++ has.

binarycrusader 5y ago
Will it? Rust has editions which C++ does not have which seems like a potentially significant mitigation.
- otabdeveloper4 5y ago
  How are "editions" any different from C++ standards versions?
  - steveklabnik 5y ago
    Standard revisions are like snapshots in time. Editions are a way of introducing surface-level changes into the language, which are guaranteed to interoperate. Most features land in as many editions as possible simultaneously, the edition differences are purely the things that would be breaking changes, and so require you to opt into which ones you want. Both strategies have advantages and disadvantages.
  - IAmLiterallyAB 5y ago
    You can use new features from new Rust versions/compilers on old editions, as long as the new features don't require backwards incompatible changes. You can't use features from new C++ standards when targeting an older standard.
    - snovv_crash 5y ago
      You can, they just often live in somewhere like std::experimental
  - ben0x539 5y ago
    Editions are opt-in at a per-package level. You can write Rust 2015 code that wouldn't be valid Rust 2018 because of breaking changes, while using libraries that use Rust 2018.

otabdeveloper4 5y ago

I'm pretty sure C++ advances much faster now than Rust will in 30 years. Then again, you'll just point to how awesome it is that Rust doesn't change and stays stable and easy to use for years. It's all just rationalizations for the emotional investments you've already made.

nickysielicki 5y ago
Scarecrow. I’m far from emotionally invested in rust and I’ve dealt with the downvote army of zealots who want to rewrite everything in rust. I’m not the evangelist you think I am. C++ is just losing here.
- titanomachy 5y ago
  Is “scarecrow” the same thing as “strawman”?
  - nickysielicki 5y ago
    A scarecrow is a straw-man. :)
  - elondaits 5y ago
    Strawman is less offensive.
    - nickysielicki 5y ago
      Wait, “scarecrow” is offensive now? How?
      - bregma 5y ago
        If it only had a brain?
- throwaway894345 5y ago
  Agreed (and I'm dealing with an army of Rust zealots right now on proggit). Rust has a track record of carefully considered features and a process that allows it to continue making changes to the language while managing compatibility. I do expect Rust will slow down and bureaucracy will slip in in the next 30 years (because I fully believe Rust will become very popular and many big companies will come to depend on it for security and critical real time systems), but I don't think it will move as slowly as C++ does these days.

zerkten 5y ago

The part that's not mentioned, and a reason why some people wonder why their approach didn't get traction is missing. Before starting any of these steps you need your own analysis of what will make your change successful. You'll probably only be able to make the best analysis if you socialize your idea with relevant people in the community in private. This seems really obvious, but it's a pattern that repeats with engineers engaging in what is only partially an engineering effort. Similar issues occur in the python-ideas list other places. When you follow this approach you can remove the risk of premature investment in the steps listed.

tasogare 5y ago

> allowing for breaking changes Cute for toy projects but a big disadvantage for any another kind of programming. There's a reason established languages like C++ or C# are taking compatibility very seriously.

ben0x539 5y ago
And it's probably the same reason Rust takes compatibility very seriously. What's with the "us vs them" attitude?
lukebitts 5y ago
I think that was bad phrasing on GP's part. Rust only allows breaking changes for edition changes, which are opt-in. Libraries in older (or newer) editions can still be used together in your project, no matter which edition you are using. Rust allows for breaking changes in a way that doesn't actually break anything.

bob1029 5y ago

This long lifecycle is a double-edged sword between stability & features, but you can grind down one of those edges with enough discipline on backwards compatibility. One compelling example could be the direction MS has started to take w/ .NET Core/5/6+: - Submit issue/PR on the dotnet/aspnetcore repo on GH (anyone can do this). - Conversation starts almost immediately. - Suggested changes could be merged in a matter of weeks. - Expect your changes to become available in an official release in under a year. Pre-release builds much sooner than that. - Expect an LTS release the following year. I have personally experienced this workflow a few times. It is incredible to have this type of feedback loop with something that has historically been a total black box of proprietary decisions. There are still a ton of places where you don't have much leverage, but the fact that there is any movement possible from the community at all is incredible to me (again, from a historical perspective around Microsoft & .NET). I don't have to learn how to draft a PhD thesis in order to add value to the ecosystem. Ideas should not be filtered so harshly in my opinion.

h_ans_m_443 5y ago

This kind of aggressive evangelism is hurting Rusts reputation a lot. I wish people would just stop it. Why do some Rust fanboys have to keep shitting on every other language all the time???????

staticassertion 5y ago
Something new is likely to try to correct perceived mistakes in something old. It shouldn't be taken as aggressive to try to say that one approach is better than another tbh.
lenkite 5y ago
And God help you if you point out strange warts and syntactic choices in Rust. You will be eviscerated.