5 ms·

The C++ programmers will just switch to C++ 2.0, aka Rust. It's not a big leap.

by Jyaif 5y ago

einpoklum 5y ago
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.
lfowles 5y ago
I'm not sure I'm ready to learn another language to be honest. After a decade+ of C++ it'd feel like driving on the wrong side of the road and I wouldn't blame any employers who didn't want to take a chance on that :)
- deltaonefour 5y ago
  It won't feel this way. Most languages are noticeably better and easier than C++.
- flohofwoe 5y ago
  My advice (after also having spent 'too much' time on C++) is to never focus on a single language, it's better to have a shallow knowledge of several languages than a deep knowledge of a single language (especially when it's a "fractal complexity" language like C++ - the mental capacity to deeply know C++ is enough to be productive with 2..3 less complex languages). Usually it's not the programming language that's important, but the ecosystem around the language (the standard library, available libraries, interests of the community etc...). Programming languages are mostly interchangeable, but their ecosystems are not. Some are more suited for server backend work, some for writing UI applications, some for scripting and automation, etc... After a while (and a few languages under your belt) you'll select a language based on a project's requirement, instead of trying to shoehorn every project into your favourite programming language. IME the multi-language approach is much more fun and fullfilling.
  - wott 5y ago
    > My advice (after also having spent 'too much' time C++) is to never focus on a single language. Well, you/they practised at least C++98, C++11, C++17... That's many different languages already ;-)
  - ModernMech 5y ago
    > Usually it's not the programming language that's important, but the ecosystem around the language (the standard library, available libraries, interests of the community etc...). I no longer consider an ecosystem separate from a programming language given its importance in the overall utility of the language. I came to that conclusion after I realized I wouldn’t like the Rust language so much if it weren’t for cargo and the crates.io package manager. I know a guy who hold the opinion that Docker is a sufficient package manager for C++. I think this misses the degree to which tight coupling of these technologies can yield a lot of leverage.
turminal 5y ago
C++ is not going away in the foreseeable future, like it or not.
- gameswithgo 5y ago
  This is like telling green energy advocates that oil isn’t going away. Everyone knows already. When engaging people consider not assuming maximum naïveté
  - turminal 5y ago
    Coincidentally, both green energy advocates and Rust advocates tend to have fairly naïve expectations. I consider myself a green energy advocate and would be glad to see c++ go away but I find naïveté a huge obstacle on the path to both of those goals.
  - benreesman 5y ago
    Comparing C++ to fossil fuels and Rust to green energy is the most Rust thing ever. Green energy as a jihad is understandable, if maybe counter-productive at times. Rust as jihad makes no sense to me. It’s nifty: exposing mainstream programmers to the Maybe monad, and limited type classes, and cheap (not free!) bounds/use-after-free/double-delete checking is cool. Web browsers and HTTP servers and sshd servers and maybe even shells should probably be written in Rust. But a sense of safety coming from rustc is easy to over-indulge in: lots of really scary attacks are perfectly possible against Rust programs. It kills 90’s-style stack smashes dead, no doubt and in that sense it’s an improvement, but people get pwned lots of interesting ways now, and there will be a headline CVE in a rust program, count on it.
junon 5y ago
Rust is not a solution in every case. It makes me personally want to use it less since everyone shills it mindlessly.

The C++ programmers will just switch to C++ 2.0, aka Rust. It's not a big leap.

by Jyaif 5y ago

The C++ programmers will just switch to C++ 2.0, aka Rust. It's not a big leap.

einpoklum 5y ago

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.

lfowles 5y ago

I'm not sure I'm ready to learn another language to be honest. After a decade+ of C++ it'd feel like driving on the wrong side of the road and I wouldn't blame any employers who didn't want to take a chance on that :)

deltaonefour 5y ago
It won't feel this way. Most languages are noticeably better and easier than C++.
flohofwoe 5y ago
My advice (after also having spent 'too much' time on C++) is to never focus on a single language, it's better to have a shallow knowledge of several languages than a deep knowledge of a single language (especially when it's a "fractal complexity" language like C++ - the mental capacity to deeply know C++ is enough to be productive with 2..3 less complex languages). Usually it's not the programming language that's important, but the ecosystem around the language (the standard library, available libraries, interests of the community etc...). Programming languages are mostly interchangeable, but their ecosystems are not. Some are more suited for server backend work, some for writing UI applications, some for scripting and automation, etc... After a while (and a few languages under your belt) you'll select a language based on a project's requirement, instead of trying to shoehorn every project into your favourite programming language. IME the multi-language approach is much more fun and fullfilling.
- wott 5y ago
  > My advice (after also having spent 'too much' time C++) is to never focus on a single language. Well, you/they practised at least C++98, C++11, C++17... That's many different languages already ;-)
- ModernMech 5y ago
  > Usually it's not the programming language that's important, but the ecosystem around the language (the standard library, available libraries, interests of the community etc...). I no longer consider an ecosystem separate from a programming language given its importance in the overall utility of the language. I came to that conclusion after I realized I wouldn’t like the Rust language so much if it weren’t for cargo and the crates.io package manager. I know a guy who hold the opinion that Docker is a sufficient package manager for C++. I think this misses the degree to which tight coupling of these technologies can yield a lot of leverage.

turminal 5y ago

C++ is not going away in the foreseeable future, like it or not.

gameswithgo 5y ago
This is like telling green energy advocates that oil isn’t going away. Everyone knows already. When engaging people consider not assuming maximum naïveté
- turminal 5y ago
  Coincidentally, both green energy advocates and Rust advocates tend to have fairly naïve expectations. I consider myself a green energy advocate and would be glad to see c++ go away but I find naïveté a huge obstacle on the path to both of those goals.
- benreesman 5y ago
  Comparing C++ to fossil fuels and Rust to green energy is the most Rust thing ever. Green energy as a jihad is understandable, if maybe counter-productive at times. Rust as jihad makes no sense to me. It’s nifty: exposing mainstream programmers to the Maybe monad, and limited type classes, and cheap (not free!) bounds/use-after-free/double-delete checking is cool. Web browsers and HTTP servers and sshd servers and maybe even shells should probably be written in Rust. But a sense of safety coming from rustc is easy to over-indulge in: lots of really scary attacks are perfectly possible against Rust programs. It kills 90’s-style stack smashes dead, no doubt and in that sense it’s an improvement, but people get pwned lots of interesting ways now, and there will be a headline CVE in a rust program, count on it.

junon 5y ago

Rust is not a solution in every case. It makes me personally want to use it less since everyone shills it mindlessly.