25 ms·

This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn't use the string_view or span without thinking about

This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software. Herb Sutter has concrete proposals to address this issue and Clang already supports them: https://www.infoworld.com/article/3307522/revised-proposal-could-solve-longstanding-c-bugs.html https://www.infoworld.com/article/3307522/revised-proposal-c...

wwright 7y ago
The thing is, Rust has tools that are easier to use _and_ have great performance _and_ prevent security and stability mistakes.
- the_trapper 7y ago
  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.
  - 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.
- likpok 7y ago
  Does rust have a structure to handle something like a stringview?
  - marcianx 7y ago
    Yes, a borrowed string slice `&str`, whose lifetime is tracked precisely by the compiler to avoid use-after-free errors. https://doc.rust-lang.org/book/ch04-03-slices.html#string-slices https://doc.rust-lang.org/book/ch04-03-slices.html#string-sl...
  - masklinn 7y ago
    That's one of the language's primitives: https://doc.rust-lang.org/std/primitive.str.html https://doc.rust-lang.org/std/primitive.str.html
mannykannot 7y ago
std::auto_ptr was fixed one or two times before being replaced. It is a little bit unsettling to see newer features having the same sort of caveats, despite there being a lot of smart people planning the future of the language. I imagine this is due to the way that the existing features combine combinatorially to multiply the complexity of every new feature.
tatersolid 7y ago
> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have different threats, but the industry just needs to run (not walk) away from C/C++ for the majority of use cases.
- AnimalMuppet 7y ago
  Well, it shows that there are aspects of C/C++ which are unsafe. But you don't have to use string_view or span, you know...
  - leshow 7y ago
    It was presented to show the "just use modern c++" counterargument to discussing the unsafety of c++ isn't a great argument. There are modern parts that are still unsafe.
    - AnimalMuppet 7y ago
      Fair enough. But tatersolid seems to be condemning the entire language, which is a step too far for the evidence given.
      - tatersolid 7y ago
        40 years of security vulnerabilities in C and C++ code is plenty of evidence to condemn those languages as unfit for most purposes. The evidence is overwhelming that it is not possible to write non-trivial C or C++ that is safe in the face of adversarial input. Microsoft, Google, Oracle, Linus, etc. have all tried for decades and failed miserably. All the resources and expertise in the world still results in unsafe software when C and C++ are used.
      - int_19h 7y ago

wwright 7y ago

The thing is, Rust has tools that are easier to use _and_ have great performance _and_ prevent security and stability mistakes.

the_trapper 7y ago
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.
- 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.
likpok 7y ago
Does rust have a structure to handle something like a stringview?
- marcianx 7y ago
  Yes, a borrowed string slice `&str`, whose lifetime is tracked precisely by the compiler to avoid use-after-free errors. https://doc.rust-lang.org/book/ch04-03-slices.html#string-slices https://doc.rust-lang.org/book/ch04-03-slices.html#string-sl...
- masklinn 7y ago
  That's one of the language's primitives: https://doc.rust-lang.org/std/primitive.str.html https://doc.rust-lang.org/std/primitive.str.html

mannykannot 7y ago

std::auto_ptr was fixed one or two times before being replaced. It is a little bit unsettling to see newer features having the same sort of caveats, despite there being a lot of smart people planning the future of the language. I imagine this is due to the way that the existing features combine combinatorially to multiply the complexity of every new feature.

tatersolid 7y ago

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have different threats, but the industry just needs to run (not walk) away from C/C++ for the majority of use cases.

AnimalMuppet 7y ago
Well, it shows that there are aspects of C/C++ which are unsafe. But you don't have to use string_view or span, you know...
- leshow 7y ago
  It was presented to show the "just use modern c++" counterargument to discussing the unsafety of c++ isn't a great argument. There are modern parts that are still unsafe.
  - AnimalMuppet 7y ago
    Fair enough. But tatersolid seems to be condemning the entire language, which is a step too far for the evidence given.
    - tatersolid 7y ago
      40 years of security vulnerabilities in C and C++ code is plenty of evidence to condemn those languages as unfit for most purposes. The evidence is overwhelming that it is not possible to write non-trivial C or C++ that is safe in the face of adversarial input. Microsoft, Google, Oracle, Linus, etc. have all tried for decades and failed miserably. All the resources and expertise in the world still results in unsafe software when C and C++ are used.
    - int_19h 7y ago