4 ms·

Sure we will. Just like we switched to C++ 2.0 aka Java.

smitty1e 5y ago
I keep waiting for the announcement that some propeller-head has implement the Rust borrow checker as a template metaprogram, with the caveat that nothing larger than "Hello, world." compiles within a month.
- nyanpasu64 5y ago
  Google tried and failed, and they didn't even try to model reborrowing (a hidden gotcha in Rust): https://docs.google.com/document/u/1/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub https://docs.google.com/document/u/1/d/e/2PACX-1vSt2VB1zQAJ6...
  - smitty1e 5y ago
    For one quick read, that was a well-written exposition. In short, the type system in C++ just can't quite fully express the requirements. What I didn't see Google do in that article was trot out any template metaprogramming artillery: https://www.boost.org/doc/libs/1_78_0/?view=category_metaprogramming https://www.boost.org/doc/libs/1_78_0/?view=category_metapro...
- tialaramex 5y ago
  You'd probably be happy with the people doing constexpr shenanigans. A whole bunch of terrible behaviour in C++ is defined away during constexpr expansion (e.g. since none of this is really happening at runtime you can't very well have "undefined behaviour" when there is no behaviour at all) so if you can find a way to write everything as constexpr you get a much "safer" language. e.g. buffers don't really exist, so therefore buffer overflows don't compile. There are a LOT of caveats when people take this beyond trivial, not least that the compiler diagnostics are mostly useless because the compiler often isn't sure exactly why what you're doing is nonsense, only that it is nonsense. Hey, it wouldn't even have told you that the code was nonsense if it wasn't constexpr - it would just spit out a program that's also nonsense, so that's a win right?
- einpoklum 5y ago
  C++ has gone down a different path, and reasonable one if I can say so myself. Bjarne Stroupstrup said: > I don't like garbage. I don't like littering. My ideal is to eliminate the need for a garbage collector by not producing any garbage. That is now possible. And indeed, with modern C++ idioms you can avoid leaks at the static analysis level, avoid buffer overflows by simply not passing raw pointers around, etc. So no borrow checker / garbage collector necessary. For a little more elaboration on this point, see: https://stackoverflow.com/a/48046118/1593077 https://stackoverflow.com/a/48046118/1593077 Is it 100% bullet-proof? No, but then, Rust needs some unsafe parts too.
Jyaif 5y ago
Out of curiosity, according to you at what point was Java considered C++ 2.0?
- eternalban 5y ago
  At inception it was sold as an alternative to C++ for general IT work. I switched in ‘96.
  - 13415 5y ago
    Java was also largely successful, by now it's the new Cobol of business software and will never go away. The same for C++, of course, it will not go anywhere, at worst it will slide a few points down the TIOBE index (where, surprisingly, Visual Basic is on place 6).
    - tialaramex 5y ago
      I believe that - without any of them explicitly saying so and perhaps even without them consciously understanding what they were doing - the C++ 20 standards committee actually settled on C++ priorities and set backwards compatibility as inviolable priority #1. It won't go anywhere. But that's including forwards.
      - einpoklum 5y ago
        You are _way_ overstating your case. For those who are not familiar with C++, the past ~12 years have seen _massive_ changes to the language, the standard library and the surrounding ecosystem. Yes, old programs still run, but they are simply not what you would write today nor how you would write today. In fact, the C++20 changes are so significant that it will take years for developers to even transition to utilizing them, like it took years for C++11 to be more-or-less widely adopted.
        tialaramex 5y ago
        Of course they're adding things to C++. They've been adding things to C++ for decades. I don't anticipate that slowing down for many years if ever. Watch Herb Sutter talking about the question of whether C++ is "finished" a few months back. Bjarne wants Unified Functional Call Syntax, which is the sort of crazy "automatic foot-shotgun" feature that C++ deserves and will fit right in†. Herb wants a pattern matching syntax which of course also de-structures, has overloadable typecasting and includes dynamic type ID as well because this is C++. There's no shortage of additions to C++ But C++ is too complicated and too unsafe. The only way to actually fix that would be to face the monster and slim down C++ and that would threaten backwards compatibility and thus can't be countenanced any more. In that same talk Herb talks about these big problems, claiming he's going to address them. But what he actually does is a sleight of hand trick. He redefines the problem. C++ isn't too complicated it lacks extra features that would make it more orthogonal. So adding yet more stuff to it will fix that. C++ isn't too unsafe it's just too easy to get things wrong, adding yet more stuff will avoid that. Nobody should be convinced by this hogwash. † UFCS says foo(a, b) and a.foo(b) are the same thing. In Rust you get one half of this coin, you can call any function at all as a free function, if you can write a.foo(b) there's a (verbose and usually not idiomatic) way to write foo(a,b) instead with the same effect. But you can't do the reverse because it would break a lot of Rust assumptions. In C++ today in most places you need to know whether to write foo(a, b) or a.foo(b) because only one of them will work.

I keep waiting for the announcement that some propeller-head has implement the Rust borrow checker as a template metaprogram, with the caveat that nothing larger than "Hello, world." compiles within a month.

nyanpasu64 5y ago
Google tried and failed, and they didn't even try to model reborrowing (a hidden gotcha in Rust): https://docs.google.com/document/u/1/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub https://docs.google.com/document/u/1/d/e/2PACX-1vSt2VB1zQAJ6...
- smitty1e 5y ago
  For one quick read, that was a well-written exposition. In short, the type system in C++ just can't quite fully express the requirements. What I didn't see Google do in that article was trot out any template metaprogramming artillery: https://www.boost.org/doc/libs/1_78_0/?view=category_metaprogramming https://www.boost.org/doc/libs/1_78_0/?view=category_metapro...
tialaramex 5y ago
You'd probably be happy with the people doing constexpr shenanigans. A whole bunch of terrible behaviour in C++ is defined away during constexpr expansion (e.g. since none of this is really happening at runtime you can't very well have "undefined behaviour" when there is no behaviour at all) so if you can find a way to write everything as constexpr you get a much "safer" language. e.g. buffers don't really exist, so therefore buffer overflows don't compile. There are a LOT of caveats when people take this beyond trivial, not least that the compiler diagnostics are mostly useless because the compiler often isn't sure exactly why what you're doing is nonsense, only that it is nonsense. Hey, it wouldn't even have told you that the code was nonsense if it wasn't constexpr - it would just spit out a program that's also nonsense, so that's a win right?
einpoklum 5y ago
C++ has gone down a different path, and reasonable one if I can say so myself. Bjarne Stroupstrup said: > I don't like garbage. I don't like littering. My ideal is to eliminate the need for a garbage collector by not producing any garbage. That is now possible. And indeed, with modern C++ idioms you can avoid leaks at the static analysis level, avoid buffer overflows by simply not passing raw pointers around, etc. So no borrow checker / garbage collector necessary. For a little more elaboration on this point, see: https://stackoverflow.com/a/48046118/1593077 https://stackoverflow.com/a/48046118/1593077 Is it 100% bullet-proof? No, but then, Rust needs some unsafe parts too.

Jyaif 5y ago

Out of curiosity, according to you at what point was Java considered C++ 2.0?

eternalban 5y ago
At inception it was sold as an alternative to C++ for general IT work. I switched in ‘96.
- 13415 5y ago
  Java was also largely successful, by now it's the new Cobol of business software and will never go away. The same for C++, of course, it will not go anywhere, at worst it will slide a few points down the TIOBE index (where, surprisingly, Visual Basic is on place 6).
  - tialaramex 5y ago
    I believe that - without any of them explicitly saying so and perhaps even without them consciously understanding what they were doing - the C++ 20 standards committee actually settled on C++ priorities and set backwards compatibility as inviolable priority #1. It won't go anywhere. But that's including forwards.
    - einpoklum 5y ago
      You are _way_ overstating your case. For those who are not familiar with C++, the past ~12 years have seen _massive_ changes to the language, the standard library and the surrounding ecosystem. Yes, old programs still run, but they are simply not what you would write today nor how you would write today. In fact, the C++20 changes are so significant that it will take years for developers to even transition to utilizing them, like it took years for C++11 to be more-or-less widely adopted.
      - tialaramex 5y ago
        Of course they're adding things to C++. They've been adding things to C++ for decades. I don't anticipate that slowing down for many years if ever. Watch Herb Sutter talking about the question of whether C++ is "finished" a few months back. Bjarne wants Unified Functional Call Syntax, which is the sort of crazy "automatic foot-shotgun" feature that C++ deserves and will fit right in†. Herb wants a pattern matching syntax which of course also de-structures, has overloadable typecasting and includes dynamic type ID as well because this is C++. There's no shortage of additions to C++ But C++ is too complicated and too unsafe. The only way to actually fix that would be to face the monster and slim down C++ and that would threaten backwards compatibility and thus can't be countenanced any more. In that same talk Herb talks about these big problems, claiming he's going to address them. But what he actually does is a sleight of hand trick. He redefines the problem. C++ isn't too complicated it lacks extra features that would make it more orthogonal. So adding yet more stuff to it will fix that. C++ isn't too unsafe it's just too easy to get things wrong, adding yet more stuff will avoid that. Nobody should be convinced by this hogwash. † UFCS says foo(a, b) and a.foo(b) are the same thing. In Rust you get one half of this coin, you can call any function at all as a free function, if you can write a.foo(b) there's a (verbose and usually not idiomatic) way to write foo(a,b) instead with the same effect. But you can't do the reverse because it would break a lot of Rust assumptions. In C++ today in most places you need to know whether to write foo(a, b) or a.foo(b) because only one of them will work.