7 ms·

However Rust is single vendor and single implementation, has a much smaller community and ecosystem than C++, is not standardized, and does not support all of t

However Rust is single vendor and single implementation, has a much smaller community and ecosystem than C++, is not standardized, and does not support all of the platforms and use cases that C++ does.

wwright 7y ago
That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)
- the_trapper 7y ago
  Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.
  - swiftcoder 7y ago
    It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations. That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are not performance-critical, and can perfectly well be served by garbage collected languages like Java/C#/Go.
    - ncmncm 7y ago
      It is a legitimate C killer. C++, not so much.
      - rcxdude 7y ago
        people who liked C (and didn't like C++) are more likely to move to go. Rust has a healthy community of ex and current C++ programmers.
        ncmncm 7y ago
        People who don't like GC will not move to Go.
        majewsky 7y ago
        I don't like GC (on an ideological level), but I still write most stuff in Go because I'm so insanely productive in it. Will probably use more Rust once async/await is there and mature enough.
    - galangalalgol 7y ago
      Cargo is the problem for those organizations. People who worry about security and safety often develop on airgapped networks. You can go nostd for small stuff. For bigger stuff you could mirror crates.io but that isn't a well supported workflow and it's a lot o code from a lot of randos. The notion of a blessed subset would help get more buy in from that community. Even still, rustup isn't working on airgapped Dev nets and it's a nice feature especially if you are crosscompiling.
      - 0815test 7y ago
        Cargo now supports airgapped use (no crates.io, no github) since the latest release.
        galangalalgol 7y ago
        Awesome! Can you provide some documentation to get me started? I have been unable to find any.
      - swiftcoder 7y ago
        Thankfully Cargo is an optional component. We've replaced Cargo for internal use (all dependencies checked into the monorepo and compiled with Buck).
  - arcticbull 7y ago
    C++ has a huge learning curve too though, the difference is it lets you write whatever you want. The learning curve is to write correct C++. It’s deceptive, it’s like skiing vs snowboarding. Skiing you pick up fast but to get good is damn hard and few bother. Snowboarding is damn hard to pick up but then it’s pretty easy to become really good.
    - pjmlp 7y ago
      I guess that is why I enjoy Snowboard and never bothered with skiing. :)
    - dagw 7y ago
      then it’s pretty easy to become really good. To modify this I'd say that becoming reasonably good is pretty easy (and I'd agree easier than skiing). To be become really good takes a long time and a lot of dedication and the difference in difficulty between skiing and snowboarding disappears. Same as with programming, some languages make it easier to go from 0 to your first app, some make it easier to write solid production ready code that earns you a paycheck, but becoming really good is always hard and independent of the language you're using.
  - 0815test 7y ago
    > Rust's learning curve isn't exactly a shallow one either. I don't know how people can be so sure of this. We know essentially nothing about how to teach or learn Rust effectively, it's something that the community is just starting to look at. However, one thing we do know is that the detailed support that the Rust compiler provides to the novice programmer is quite simply unparalleled in other mainstream languages. It's basically the ultimate T.A.
    - wwright 7y ago
      I’m not sure I’d use as strong language as you (though I personally love the rust compiler’s messages), but I will say it’s gotta count that it doesn’t automatically and silently generate instance methods that explicitly break the memory model (cough rule of three…)
phkahler 7y ago
Fair points, but none of them are inherent to the language itself.
- paulddraper 7y ago
  The thing is....people don't run "the language itself".
geofft 7y ago
All of those problems are long-term solved by using more Rust, whereas none of C++'s problems are long-term solved by using more C++. (Personally, I don't find single-vendor or lack of standardization a problem in practice, and I've never written C++ for a platform Rust doesn't support.)
- Vogtinator 7y ago
  Both of them can be solved by giving it more time, but C++ is currently way ahead.
  - geofft 7y ago
    I'm not sure that's true. Giving C++ 30 years has resulted in the things identified in the article. (In particular, giving auto_ptr 20+ years hasn't resulted in anything that really fixes the problem.) It is not clear to me that it's moving in the right direction, so I don't think more time will help. C++ is definitely ahead in popularity but is neither ahead not obviously aimed in the right direction in safety. Giving Rust about ten years has resulted in significant growth in popularity and tooling, including attempts to write new implementations of the language (e.g., mrustc), so given more time and in particular given more production users, it seems reasonable to expect it will figure all those things out.
  - whyever 7y ago
    I don't think that C++'s memory safety issues can be solved by giving it more time.
_bxg1 7y ago
But a community and an ecosystem can be built over time (and are being built for Rust incredibly rapidly). Whereas a problematic language can't really be "fixed", it can only be added to.
dpc_pw 7y ago
Except for stuff like "trusting trust", I find no need for "multiple vendors of Rust toolchains". It only comes handy when the language itself is not truly open source, and is in itself a form of a product. Building on that " is not standardized," is not a problem, because one Open Source implementation is de facto the standard. Which I find much better than forever fixing your code, working around incompatibilities, bugs, etc. in compilers from different versions. Which leaves "does not support all of the platforms and use cases that C++ does" which is indeed true.
- m_mueller 7y ago
  Use cases and compiler options go hand in hand. Every implementation is a trade-off and different fields demand different trade-offs.
- nimrody 7y ago
  Sometimes different vendors provide some benefits. For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang. So for numerical applications C++ may make more sense than Rust. Rust does have the advantage of being based on an LLVM backend. So perhaps different vendors can compete by writing more efficient backends that are applicable to both C++ and Rust (but you probably lose some information when skipping the compiler front end)
  - madisfun 7y ago
    > For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang. I'm not an expert, but I believe that Intel could have implemented their hardware-specific optimizations in any other compiler framework (either gcc or clang). In this case multiple language implementations, while commercially viable, are not beneficial to all users.
otikik 7y ago
I am going to postulate here that a language standard which includes undefined behaviour is not really a standard.

wwright 7y ago

That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)

the_trapper 7y ago
Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.
- swiftcoder 7y ago
  It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations. That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are not performance-critical, and can perfectly well be served by garbage collected languages like Java/C#/Go.
  - ncmncm 7y ago
    It is a legitimate C killer. C++, not so much.
    - rcxdude 7y ago
      people who liked C (and didn't like C++) are more likely to move to go. Rust has a healthy community of ex and current C++ programmers.
      - ncmncm 7y ago
        People who don't like GC will not move to Go.
        majewsky 7y ago
        I don't like GC (on an ideological level), but I still write most stuff in Go because I'm so insanely productive in it. Will probably use more Rust once async/await is there and mature enough.
  - galangalalgol 7y ago
    Cargo is the problem for those organizations. People who worry about security and safety often develop on airgapped networks. You can go nostd for small stuff. For bigger stuff you could mirror crates.io but that isn't a well supported workflow and it's a lot o code from a lot of randos. The notion of a blessed subset would help get more buy in from that community. Even still, rustup isn't working on airgapped Dev nets and it's a nice feature especially if you are crosscompiling.
    - 0815test 7y ago
      Cargo now supports airgapped use (no crates.io, no github) since the latest release.
      - galangalalgol 7y ago
        Awesome! Can you provide some documentation to get me started? I have been unable to find any.
    - swiftcoder 7y ago
      Thankfully Cargo is an optional component. We've replaced Cargo for internal use (all dependencies checked into the monorepo and compiled with Buck).
- arcticbull 7y ago
  C++ has a huge learning curve too though, the difference is it lets you write whatever you want. The learning curve is to write correct C++. It’s deceptive, it’s like skiing vs snowboarding. Skiing you pick up fast but to get good is damn hard and few bother. Snowboarding is damn hard to pick up but then it’s pretty easy to become really good.
  - pjmlp 7y ago
    I guess that is why I enjoy Snowboard and never bothered with skiing. :)
  - dagw 7y ago
    then it’s pretty easy to become really good. To modify this I'd say that becoming reasonably good is pretty easy (and I'd agree easier than skiing). To be become really good takes a long time and a lot of dedication and the difference in difficulty between skiing and snowboarding disappears. Same as with programming, some languages make it easier to go from 0 to your first app, some make it easier to write solid production ready code that earns you a paycheck, but becoming really good is always hard and independent of the language you're using.
- 0815test 7y ago
  > Rust's learning curve isn't exactly a shallow one either. I don't know how people can be so sure of this. We know essentially nothing about how to teach or learn Rust effectively, it's something that the community is just starting to look at. However, one thing we do know is that the detailed support that the Rust compiler provides to the novice programmer is quite simply unparalleled in other mainstream languages. It's basically the ultimate T.A.
  - wwright 7y ago
    I’m not sure I’d use as strong language as you (though I personally love the rust compiler’s messages), but I will say it’s gotta count that it doesn’t automatically and silently generate instance methods that explicitly break the memory model (cough rule of three…)

phkahler 7y ago

Fair points, but none of them are inherent to the language itself.

paulddraper 7y ago
The thing is....people don't run "the language itself".

geofft 7y ago

All of those problems are long-term solved by using more Rust, whereas none of C++'s problems are long-term solved by using more C++. (Personally, I don't find single-vendor or lack of standardization a problem in practice, and I've never written C++ for a platform Rust doesn't support.)

Vogtinator 7y ago
Both of them can be solved by giving it more time, but C++ is currently way ahead.
- geofft 7y ago
  I'm not sure that's true. Giving C++ 30 years has resulted in the things identified in the article. (In particular, giving auto_ptr 20+ years hasn't resulted in anything that really fixes the problem.) It is not clear to me that it's moving in the right direction, so I don't think more time will help. C++ is definitely ahead in popularity but is neither ahead not obviously aimed in the right direction in safety. Giving Rust about ten years has resulted in significant growth in popularity and tooling, including attempts to write new implementations of the language (e.g., mrustc), so given more time and in particular given more production users, it seems reasonable to expect it will figure all those things out.
- whyever 7y ago
  I don't think that C++'s memory safety issues can be solved by giving it more time.

_bxg1 7y ago

But a community and an ecosystem can be built over time (and are being built for Rust incredibly rapidly). Whereas a problematic language can't really be "fixed", it can only be added to.

dpc_pw 7y ago

Except for stuff like "trusting trust", I find no need for "multiple vendors of Rust toolchains". It only comes handy when the language itself is not truly open source, and is in itself a form of a product. Building on that " is not standardized," is not a problem, because one Open Source implementation is de facto the standard. Which I find much better than forever fixing your code, working around incompatibilities, bugs, etc. in compilers from different versions. Which leaves "does not support all of the platforms and use cases that C++ does" which is indeed true.

m_mueller 7y ago
Use cases and compiler options go hand in hand. Every implementation is a trade-off and different fields demand different trade-offs.
nimrody 7y ago
Sometimes different vendors provide some benefits. For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang. So for numerical applications C++ may make more sense than Rust. Rust does have the advantage of being based on an LLVM backend. So perhaps different vendors can compete by writing more efficient backends that are applicable to both C++ and Rust (but you probably lose some information when skipping the compiler front end)
- madisfun 7y ago
  > For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang. I'm not an expert, but I believe that Intel could have implemented their hardware-specific optimizations in any other compiler framework (either gcc or clang). In this case multiple language implementations, while commercially viable, are not beneficial to all users.

otikik 7y ago

I am going to postulate here that a language standard which includes undefined behaviour is not really a standard.