4 ms·

Rather than specifically single it out as "trying to catch up to Rust", I'd say that C++ is doing what it has always been doing. Reaching for the future while m

by eej71 9y ago

Rather than specifically single it out as "trying to catch up to Rust", I'd say that C++ is doing what it has always been doing. Reaching for the future while maintaining backwards compatibility. It's been a great strategy for 30 years and I hope they keep at it.

lallysingh 9y ago
.. And that future is defined as "rust"
- dsacco 9y ago
  Once again: there is plenty of room for both Rust and C++. One language does not need to "win." The Rust community doesn't endorse your flavor of evangelism here. It's not a holy war.
  - pjmlp 9y ago
    Exactly, and even if I complained about the current ergonomics of lifetimes, the amazing work of Rust developers is already influencing design decisions on Haskell, Swift, .NET, Pony and C++ regarding resource management.
    - dsacco 9y ago
      Any chance you could throw up an email for me to contact you, or use the one in my profile? I'd be interested in chatting with you "offline" as it were.
- eej71 9y ago
  While your comment is a bit snarky, there is some truth to it in that if rust successfully evangelizes a technique, I'd expect the C++ world to bring it on board if there is room and I'm sure room can be found. The one topic to consider is this - is there a world where a language's existing code base is so large and the community so diverse that even _you_ would hesitate to break things for them? And at the same time, doesn't it make sense for that community to keep marching forward? Yes the language has baggage and the path forward isn't easy, but there are still paths ahead for C++. My advice to the rust community. Model yourself after the C++ strategy of evolution. Do not repeat the mistakes of the Python 2->3 world or the perl 5->6 world or what appears to be happening to Go. Don't break the past.
  - steveklabnik 9y ago
    In general, Rust is modelling ourselves after that. There was even a recent RFC to explicitly move to a model of language change after the C++ model, but people are concerned that it breaks too much. https://github.com/rust-lang/rfcs/pull/2052 https://github.com/rust-lang/rfcs/pull/2052
nemaar 9y ago
>It's been a great strategy for 30 years and I hope they keep at it. I wouldn't say that it's been great. The evolution of C++ is insanely slow.
- eej71 9y ago
  Perhaps. It's like that old joke about perspective. The length of a minute depends on which side of the bathroom door you're on. :-) From my standpoint, I'm _still_ trying to get my head around all the ramifications of what has arrived in C++-11 (and it's a lot!). And I still have '14 and '17 to plow through too. '20 will be here before I know it. So for me, there is so much to absorb. To my eyes the C++ leadership has done a great job at setting up standards processes for regularly delivering new versions and the compiler community has done an amazing job at keeping up too. I expect to see more movement in the world of standard libraries which is where C++ still feels like a desert compared to other languages. But yes it definitely is not fast when compared to other newer language communities.
- dom0 9y ago
  > The evolution of C++ is insanely slow. The only language today with more independent implementations than C++ is C. Compared to C, C++ evolution is not slow — processes involving so many implementers are inherently not in fast-forward mode. Most major languages only have a handful of active implementations, if it's not just one implementation. Most don't have specs.
  - ThatGeoGuy 9y ago
    I would argue that you're eschewing Lisp and Scheme in terms of independent, active implementations, however in a more general sense I agree. Moving fast (and breaking things) is just not what the standardization committee does, and that's fine. They can move faster since C++11/14, but sometimes you really don't want a giant moving target with new features all the time. I think their approach works for the kind of environment you find C++ used in.

by eej71 9y ago

lallysingh 9y ago

.. And that future is defined as "rust"

dsacco 9y ago
Once again: there is plenty of room for both Rust and C++. One language does not need to "win." The Rust community doesn't endorse your flavor of evangelism here. It's not a holy war.
- pjmlp 9y ago
  Exactly, and even if I complained about the current ergonomics of lifetimes, the amazing work of Rust developers is already influencing design decisions on Haskell, Swift, .NET, Pony and C++ regarding resource management.
  - dsacco 9y ago
    Any chance you could throw up an email for me to contact you, or use the one in my profile? I'd be interested in chatting with you "offline" as it were.
eej71 9y ago
While your comment is a bit snarky, there is some truth to it in that if rust successfully evangelizes a technique, I'd expect the C++ world to bring it on board if there is room and I'm sure room can be found. The one topic to consider is this - is there a world where a language's existing code base is so large and the community so diverse that even _you_ would hesitate to break things for them? And at the same time, doesn't it make sense for that community to keep marching forward? Yes the language has baggage and the path forward isn't easy, but there are still paths ahead for C++. My advice to the rust community. Model yourself after the C++ strategy of evolution. Do not repeat the mistakes of the Python 2->3 world or the perl 5->6 world or what appears to be happening to Go. Don't break the past.
- steveklabnik 9y ago
  In general, Rust is modelling ourselves after that. There was even a recent RFC to explicitly move to a model of language change after the C++ model, but people are concerned that it breaks too much. https://github.com/rust-lang/rfcs/pull/2052 https://github.com/rust-lang/rfcs/pull/2052

nemaar 9y ago

>It's been a great strategy for 30 years and I hope they keep at it. I wouldn't say that it's been great. The evolution of C++ is insanely slow.

eej71 9y ago
Perhaps. It's like that old joke about perspective. The length of a minute depends on which side of the bathroom door you're on. :-) From my standpoint, I'm _still_ trying to get my head around all the ramifications of what has arrived in C++-11 (and it's a lot!). And I still have '14 and '17 to plow through too. '20 will be here before I know it. So for me, there is so much to absorb. To my eyes the C++ leadership has done a great job at setting up standards processes for regularly delivering new versions and the compiler community has done an amazing job at keeping up too. I expect to see more movement in the world of standard libraries which is where C++ still feels like a desert compared to other languages. But yes it definitely is not fast when compared to other newer language communities.
dom0 9y ago
> The evolution of C++ is insanely slow. The only language today with more independent implementations than C++ is C. Compared to C, C++ evolution is not slow — processes involving so many implementers are inherently not in fast-forward mode. Most major languages only have a handful of active implementations, if it's not just one implementation. Most don't have specs.
- ThatGeoGuy 9y ago
  I would argue that you're eschewing Lisp and Scheme in terms of independent, active implementations, however in a more general sense I agree. Moving fast (and breaking things) is just not what the standardization committee does, and that's fine. They can move faster since C++11/14, but sometimes you really don't want a giant moving target with new features all the time. I think their approach works for the kind of environment you find C++ used in.