4 ms·

But most of the things you just listed are just aspects of the existing ecosystem (libraries, tooling, etc.). There's no doubt C++ has an incredibly large ecosy

by _bxg1 8y ago

But most of the things you just listed are just aspects of the existing ecosystem (libraries, tooling, etc.). There's no doubt C++ has an incredibly large ecosystem and will therefore be around for quite a while to come, but that doesn't make it a good language, it just makes it one that happens to have been very popular for a very long time. Our industry is one that values progress over tradition in the long run. I think C++ has entered its twilight years. That could mean five, ten, or twenty, but I think it's peaked, and I don't think that's a bad thing.

ncmncm 8y ago
That doesn't make C++ a good language. It just is one. Rust is also a good language. Trash-talking C++ does no one any good. Overwhelmingly, the substantial gains to be made are moving people off of C. Every other possible benefit is a rounding error. It is still much easier to get people to C++. Once dislodged, they might continue on to Rust, or br seduced by C++'s greater expressive power and more powerful libraries. Either way the world will be better. C++ today seems weighed down by legacy cruft, compared to Rust, but Rust is rapidly accumulating its own legacy cruft. By the time it is mature it will have easily as much of its own.
- _bxg1 8y ago
  "or be seduced by C++'s greater expressive power" There's a deeper debate lying at the heart of the Rust-vs-C++ conversation (it's the same one at the heart of Haskell-vs-Lisp), which is really about expressive freedom vs. the strategic usage of constraints. That debate will, truly, outlive all of us. You can probably guess which side I'm biased towards; I won't lay it all out here.
  - ncmncm 8y ago
    This is not about "expressive freedom" vs "constraints". Rust lacks many of C++'s key core language facilities to capture semantics in a library. As a consequence, you cannot write powerful libraries in Rust that you can in C++, and you cannot use powerful libraries such as are written in C++. Since you cannot use these powerful libraries, you are (if you like) "constrained" to write fragile code at what would have been the call site. Each use of a powerful library eliminates all the bugs that would have come from not using one. Those are bugs that Rust designers have elected to keep, in exchange for the memory-use bugs that we largely eliminate, in C++ code, by reliance on powerful libraries. Powerful libraries eliminate many, many more bugs besides memory misuse.
    - _bxg1 8y ago
      "Rust lacks many of C++'s key core language facilities to capture semantics in a library." Can you be more specific? I don't even know what you mean by "powerful library". If you mean a library that's been developed and debugged for a long time, then sure, C++ currently has the advantage there, but that's a transient state and nonspecific to the language itself. If you mean a library that does wild, earth-moving things then I would call that a liability, not an advantage. The language features that allow such things are sources of bugs that Rust designers have elected not to introduce in the first place. The question of, "In April 2019, which language and ecosystem are more reliable?" is a perfectly valid one. Stronger language semantics vs decades of library refinement. It's not at all obvious. But the answer to "Is Rust or C++ a better language in the long run?" seems clear to me.
      - ncmncm 8y ago
        Could you write a Rust equivalent of the STL, or its modern cousin Ranges? That's just one library (as of C++20), but if Rust is not up to that, there's no point in going further.
        steveklabnik 8y ago
        The equivalent of Ranges is already in Rust’s standard library, and has been forever. We call it Iterator. It also provides extra static guarantees against invalidation.
        ncmncm 8y ago
        I see that you did not understand my question. I see, too, that there are plans for some support for generics in the near future. So the answer might become yes, in time.
        steveklabnik 8y ago
        Rust has also had generics for a very long time.
- koffiezet 8y ago
  I started came from a C background (mostly for embedded stuff, where on many platforms a C++ compiler wasn't an option) - and eventually moving to C++ for backend and library work was a pain in the ass. I got the hang of it, but never loved it, although for the goals we had to achieve, it was a sensible choice. I however moved into more of an ops/SRE role mainly due to to C++ not entirely being my thing while the dev that was always most in touch with the ops side of thing. I do see many of the advantages of both Rust and C++, but one of the reasons I like C is its relative simplicity. I only did a single small thing in Rust to try it out, and while still quite complex, at least it felt more manageable than C++ once you understood the borrow checker. The big elephant in the room however is Go. Every time I started something and would consider Rust, it ended up being 'why not just Go?'. At least for me, it was much better suited language to be moving to coming from a C background. The biggest initial hurdle was setting up the dev environment with the completely backward GOPATH and GODIR environment variables - which just feels absolutely wrong (although this now in the process of being addressed). The language itself however was an absolute breeze, I felt right at home. Simple, quick, straight-forward, with tons of libraries and tools for my current field of work, coupled with performance more than acceptable for 99% of the applications I need and static binaries which are easily deployed anywhere, also eliminating a ton of complexity. Is it perfect? No, but what language is? But if you want to convince C-programmers to ditch C for a memory-safe language - Go is imho in many cases a much better option to move to.
jclay 8y ago
The point is that I've noticed a broad "religious" trend where those promoting Rust don't lend any credit to the places where C/C++ has valid strengths, even if due to it's legacy. It doesn't do a great service to either community to constantly pit the two against each other, and to misrepresent the other in a way that's not honest. C++ doesn't exist and continue to evolve just because it's been around forever, there are a number of things leading to it's continued use that should be brought into the discussions. C++ isn't going anywhere. In 20 years you may not be writing in it, but you'll still be calling into it somewhere in the software stack (especially if things continue moving the WebAssembly direction). Even if you're using Python's SciPy today, you're calling into LAPACK written into Fortran.
- pjmlp 8y ago
  Case in point, most modern OS GUIs are written in managed languages nowadays, even Qt has JavaScript bindings now. Yet, C++ is still there as the binding layer between UI and GPGPU.

by _bxg1 8y ago

ncmncm 8y ago

That doesn't make C++ a good language. It just is one. Rust is also a good language. Trash-talking C++ does no one any good. Overwhelmingly, the substantial gains to be made are moving people off of C. Every other possible benefit is a rounding error. It is still much easier to get people to C++. Once dislodged, they might continue on to Rust, or br seduced by C++'s greater expressive power and more powerful libraries. Either way the world will be better. C++ today seems weighed down by legacy cruft, compared to Rust, but Rust is rapidly accumulating its own legacy cruft. By the time it is mature it will have easily as much of its own.

_bxg1 8y ago
"or be seduced by C++'s greater expressive power" There's a deeper debate lying at the heart of the Rust-vs-C++ conversation (it's the same one at the heart of Haskell-vs-Lisp), which is really about expressive freedom vs. the strategic usage of constraints. That debate will, truly, outlive all of us. You can probably guess which side I'm biased towards; I won't lay it all out here.
- ncmncm 8y ago
  This is not about "expressive freedom" vs "constraints". Rust lacks many of C++'s key core language facilities to capture semantics in a library. As a consequence, you cannot write powerful libraries in Rust that you can in C++, and you cannot use powerful libraries such as are written in C++. Since you cannot use these powerful libraries, you are (if you like) "constrained" to write fragile code at what would have been the call site. Each use of a powerful library eliminates all the bugs that would have come from not using one. Those are bugs that Rust designers have elected to keep, in exchange for the memory-use bugs that we largely eliminate, in C++ code, by reliance on powerful libraries. Powerful libraries eliminate many, many more bugs besides memory misuse.
  - _bxg1 8y ago
    "Rust lacks many of C++'s key core language facilities to capture semantics in a library." Can you be more specific? I don't even know what you mean by "powerful library". If you mean a library that's been developed and debugged for a long time, then sure, C++ currently has the advantage there, but that's a transient state and nonspecific to the language itself. If you mean a library that does wild, earth-moving things then I would call that a liability, not an advantage. The language features that allow such things are sources of bugs that Rust designers have elected not to introduce in the first place. The question of, "In April 2019, which language and ecosystem are more reliable?" is a perfectly valid one. Stronger language semantics vs decades of library refinement. It's not at all obvious. But the answer to "Is Rust or C++ a better language in the long run?" seems clear to me.
    - ncmncm 8y ago
      Could you write a Rust equivalent of the STL, or its modern cousin Ranges? That's just one library (as of C++20), but if Rust is not up to that, there's no point in going further.
      - steveklabnik 8y ago
        The equivalent of Ranges is already in Rust’s standard library, and has been forever. We call it Iterator. It also provides extra static guarantees against invalidation.
        ncmncm 8y ago
        I see that you did not understand my question. I see, too, that there are plans for some support for generics in the near future. So the answer might become yes, in time.
        steveklabnik 8y ago
        Rust has also had generics for a very long time.
koffiezet 8y ago
I started came from a C background (mostly for embedded stuff, where on many platforms a C++ compiler wasn't an option) - and eventually moving to C++ for backend and library work was a pain in the ass. I got the hang of it, but never loved it, although for the goals we had to achieve, it was a sensible choice. I however moved into more of an ops/SRE role mainly due to to C++ not entirely being my thing while the dev that was always most in touch with the ops side of thing. I do see many of the advantages of both Rust and C++, but one of the reasons I like C is its relative simplicity. I only did a single small thing in Rust to try it out, and while still quite complex, at least it felt more manageable than C++ once you understood the borrow checker. The big elephant in the room however is Go. Every time I started something and would consider Rust, it ended up being 'why not just Go?'. At least for me, it was much better suited language to be moving to coming from a C background. The biggest initial hurdle was setting up the dev environment with the completely backward GOPATH and GODIR environment variables - which just feels absolutely wrong (although this now in the process of being addressed). The language itself however was an absolute breeze, I felt right at home. Simple, quick, straight-forward, with tons of libraries and tools for my current field of work, coupled with performance more than acceptable for 99% of the applications I need and static binaries which are easily deployed anywhere, also eliminating a ton of complexity. Is it perfect? No, but what language is? But if you want to convince C-programmers to ditch C for a memory-safe language - Go is imho in many cases a much better option to move to.

jclay 8y ago

The point is that I've noticed a broad "religious" trend where those promoting Rust don't lend any credit to the places where C/C++ has valid strengths, even if due to it's legacy. It doesn't do a great service to either community to constantly pit the two against each other, and to misrepresent the other in a way that's not honest. C++ doesn't exist and continue to evolve just because it's been around forever, there are a number of things leading to it's continued use that should be brought into the discussions. C++ isn't going anywhere. In 20 years you may not be writing in it, but you'll still be calling into it somewhere in the software stack (especially if things continue moving the WebAssembly direction). Even if you're using Python's SciPy today, you're calling into LAPACK written into Fortran.

pjmlp 8y ago
Case in point, most modern OS GUIs are written in managed languages nowadays, even Qt has JavaScript bindings now. Yet, C++ is still there as the binding layer between UI and GPGPU.