5 ms·

Rust will not replace C++. Everything is thrown out the window, including developer productivity in order to provide the 'zero overhead runtime guarantee' featu

by jasmer 4y ago

Rust will not replace C++. Everything is thrown out the window, including developer productivity in order to provide the 'zero overhead runtime guarantee' feature. The code ends up quite laborious, and it's just not suitable for many things, and it doesn't play so easily with C. Most projects do not require what Rust provides at the cost it provides it at. C++ people really wants a C++ that is clean, modern, parsable, without all the legacy cruft. Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better.

pcwalton 4y ago
> Most projects do not require what Rust provides at the cost it provides it at. If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023. > Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better. This is the literal definition of vaporware, without a specific plan for how "newer iterations" will do it better. People have been searching for silver bullets for years in this space and nobody has really found a way to improve on the balance Rust has found without introducing garbage collection of some kind. I personally don't believe a "better borrow checker" can exist without GC (which is not such a bad thing, by the way--in my experience, C++ and Rust developers tend to be unfairly dismissive of garbage collection).
- lll-o-lll 4y ago
  Swift is memory safe. It’s the better C++ I want, just out of reach because Apple. There is at least one memory safe alternative to Rust that doesn’t require a GC. I’ve made this argument before but here we go again. GC is great and works better and faster than reference counting in most cases, but there are degenerate cases and they matter on phones. One degenerate case is memory pressure. A GC running out of memory will perform terribly. Another case is bounded latency. Most obvious with hard real-time, but also a problem for any system where a long GC pause will lead to failure modes or user dissatisfaction. RC allows for predictable (albeit slower) performance. So if we can agree that “no GC” is preferable in a constrained environment like a phone, but you still want memory safety, then you are left with “is Swift or Rust better for productivity?” It’s pretty obvious that the answer is resoundingly “Swift”.
  - zozbot234 4y ago
    Ubiquitous ARC has even worse performance than tracing GC. Only Rust gives you complete memory safety with fine-grained control over memory management strategy.
    - lll-o-lll 4y ago
      Swift has some tricks to make things faster than naive ARC, but the point is that you trade a little speed for deterministic behavior. The post I was replying to was making the argument I see frequently. That if not Rust, you should go GC. This is simply wrong. The degenerate GC cases can be avoided with Swift. It’s better for a phone application in nearly every case. If it wasn’t bound to Apple, I’d say it’d be a better choice than Rust in 90% of the places Rust is used. Rust has its place, but the idea that it’s the obvious and only replacement for C++ is overblown. A language like Swift seems like a better path forward.
    - pjmlp 4y ago
      Rust isn't the only one with affine types, only the one that has managed more mindshare.
      - Jweb_Guru 4y ago
        None of the other languages you're thinking of are particularly usable as industrial strength languages for general purpose programming, for reasons that go way beyond mindshare.
        pjmlp 4y ago
        Mind reader?
        Jweb_Guru 4y ago
        I don't need to be a mind reader because I know which languages other than Rust support sound affine types. They broadly fall into three categories: * Languages with comprehensive support for affine types, but that are otherwise too limited to be really useful for general purpose programming. Usually this is due to a lack of industry support. * Languages with bolted on support for affine types where you can't get consistent performance benefits out of code written in that style and it's very difficult to write and compose code written in that style. * Complex languages with advanced type systems that can emulate affine types, and are extremely powerful, but are borderline unusable for any purpose. Like I said, whichever of those three language categories you're thinking of, my reasoning applies. No mind reading necessary! I understand though that you believe safe concurrency has been solved since Modula 3 because you can just lock every object while it's in use (why didn't anyone else think of that?), so maybe you don't really appreciate the vast gulf in usability between affine types in these kinds of languages and in Rust.
- jasmer 4y ago
  Most C++ apps are mostly memory safe and that's just fine. It's ridiculous to suggest that this secondary artifact concern is raised to primacy for all projects. Rust V1 is a vastly complicated and verbose language, slow to make, slow to write, difficult to integrate, which offers really only one glorious feature that's not important to such a degree for most projects. To suggest wanting something better has nothing to do with vapourware. Hypersensitivity over a compiler might be a sure sign in a cult!
  - pcwalton 4y ago
    > Most C++ apps are mostly memory safe and that's just fine. It's ridiculous to suggest that this secondary artifact concern is raised to primacy for all projects. It's demonstrably not "just fine", as the steady stream of security issues that hurt real people will attest to. It's also important to remember that C++ is an extreme outlier here: the majority of programs written in 2023 are in memory-safe languages. Memory safety is not some weird new thing; it's the norm everywhere but in C and C++, usage of which declines every year.
    - galangalalgol 4y ago
      I think Jasmer has a good point about c++ users wanting a safe enforced subset. I jave suggested a cpp23{} to denote code where the compiler is free to break anything older and enforce best modern practices. Its like a version of safe{} vs unsafe{} I don't agree that rust is particularly difficult to use, and certainly not verbose. My productivity level is not as high as pytorch or matlab, but it is already on par with c++17 and I've been using that for ~5yrs (c++ for 30yrs) and I've only been using rust for work projects for a year. Lastly I agree that memory safety isn't a small thing. 70% of security vulnerabilities MS and google find they say are memory safety related. 70% of the financial losses due to security vulnerabilities is... A really big number. And rust, unlike a GC language like java, go, swift, or c#, isn't just memory safe, the borrow checker adds thread safety and more generally safe access to any resource, like file or network io. That is a huge benefit in any domain, and the cognitive overhead just isn't that high.

by jasmer 4y ago

pcwalton 4y ago

> Most projects do not require what Rust provides at the cost it provides it at. If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023. > Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better. This is the literal definition of vaporware, without a specific plan for how "newer iterations" will do it better. People have been searching for silver bullets for years in this space and nobody has really found a way to improve on the balance Rust has found without introducing garbage collection of some kind. I personally don't believe a "better borrow checker" can exist without GC (which is not such a bad thing, by the way--in my experience, C++ and Rust developers tend to be unfairly dismissive of garbage collection).

lll-o-lll 4y ago
Swift is memory safe. It’s the better C++ I want, just out of reach because Apple. There is at least one memory safe alternative to Rust that doesn’t require a GC. I’ve made this argument before but here we go again. GC is great and works better and faster than reference counting in most cases, but there are degenerate cases and they matter on phones. One degenerate case is memory pressure. A GC running out of memory will perform terribly. Another case is bounded latency. Most obvious with hard real-time, but also a problem for any system where a long GC pause will lead to failure modes or user dissatisfaction. RC allows for predictable (albeit slower) performance. So if we can agree that “no GC” is preferable in a constrained environment like a phone, but you still want memory safety, then you are left with “is Swift or Rust better for productivity?” It’s pretty obvious that the answer is resoundingly “Swift”.
- zozbot234 4y ago
  Ubiquitous ARC has even worse performance than tracing GC. Only Rust gives you complete memory safety with fine-grained control over memory management strategy.
  - lll-o-lll 4y ago
    Swift has some tricks to make things faster than naive ARC, but the point is that you trade a little speed for deterministic behavior. The post I was replying to was making the argument I see frequently. That if not Rust, you should go GC. This is simply wrong. The degenerate GC cases can be avoided with Swift. It’s better for a phone application in nearly every case. If it wasn’t bound to Apple, I’d say it’d be a better choice than Rust in 90% of the places Rust is used. Rust has its place, but the idea that it’s the obvious and only replacement for C++ is overblown. A language like Swift seems like a better path forward.
  - pjmlp 4y ago
    Rust isn't the only one with affine types, only the one that has managed more mindshare.
    - Jweb_Guru 4y ago
      None of the other languages you're thinking of are particularly usable as industrial strength languages for general purpose programming, for reasons that go way beyond mindshare.
      - pjmlp 4y ago
        Mind reader?
        Jweb_Guru 4y ago
        I don't need to be a mind reader because I know which languages other than Rust support sound affine types. They broadly fall into three categories: * Languages with comprehensive support for affine types, but that are otherwise too limited to be really useful for general purpose programming. Usually this is due to a lack of industry support. * Languages with bolted on support for affine types where you can't get consistent performance benefits out of code written in that style and it's very difficult to write and compose code written in that style. * Complex languages with advanced type systems that can emulate affine types, and are extremely powerful, but are borderline unusable for any purpose. Like I said, whichever of those three language categories you're thinking of, my reasoning applies. No mind reading necessary! I understand though that you believe safe concurrency has been solved since Modula 3 because you can just lock every object while it's in use (why didn't anyone else think of that?), so maybe you don't really appreciate the vast gulf in usability between affine types in these kinds of languages and in Rust.
jasmer 4y ago
Most C++ apps are mostly memory safe and that's just fine. It's ridiculous to suggest that this secondary artifact concern is raised to primacy for all projects. Rust V1 is a vastly complicated and verbose language, slow to make, slow to write, difficult to integrate, which offers really only one glorious feature that's not important to such a degree for most projects. To suggest wanting something better has nothing to do with vapourware. Hypersensitivity over a compiler might be a sure sign in a cult!
- pcwalton 4y ago
  > Most C++ apps are mostly memory safe and that's just fine. It's ridiculous to suggest that this secondary artifact concern is raised to primacy for all projects. It's demonstrably not "just fine", as the steady stream of security issues that hurt real people will attest to. It's also important to remember that C++ is an extreme outlier here: the majority of programs written in 2023 are in memory-safe languages. Memory safety is not some weird new thing; it's the norm everywhere but in C and C++, usage of which declines every year.
  - galangalalgol 4y ago
    I think Jasmer has a good point about c++ users wanting a safe enforced subset. I jave suggested a cpp23{} to denote code where the compiler is free to break anything older and enforce best modern practices. Its like a version of safe{} vs unsafe{} I don't agree that rust is particularly difficult to use, and certainly not verbose. My productivity level is not as high as pytorch or matlab, but it is already on par with c++17 and I've been using that for ~5yrs (c++ for 30yrs) and I've only been using rust for work projects for a year. Lastly I agree that memory safety isn't a small thing. 70% of security vulnerabilities MS and google find they say are memory safety related. 70% of the financial losses due to security vulnerabilities is... A really big number. And rust, unlike a GC language like java, go, swift, or c#, isn't just memory safe, the borrow checker adds thread safety and more generally safe access to any resource, like file or network io. That is a huge benefit in any domain, and the cognitive overhead just isn't that high.