4 ms·

Rust solves some problems of C++ (memory safety for common-cases of code) while introducing new problems (less expressive safe code and harder-to-write unsafe c

Rust solves some problems of C++ (memory safety for common-cases of code) while introducing new problems (less expressive safe code and harder-to-write unsafe code, expanded UB when trying to expose &mut to safe code from raw pointers, or RefCell runtime panics).

saghm 3y ago
I don't disagree about unsafe Rust being trickier than people might realize, but "RefCell runtime panics" bring a "new" problem is a bit of a stretch; it's strictly better than UB, which can also crash. Making a situation that used to be "maybe crash, maybe accidentally continue running and make things far wise than crashing" instead "definitely crash" is a reduction of an existing problem rather than a new one.
- nyanpasu64 3y ago
  RefCell causes runtime panics in cases (holding onto a borrow or borrow_mut() for too long) where C++ has well-defined behavior (two pointers can reference the same memory and both be valid for reads/writes).
  - ttfkam 3y ago
    This statement… > "maybe crash, maybe accidentally continue running and make things far [worse] than crashing" instead "definitely crash" …is functionally indistinguishable from your reply. > (two pointers can reference the same memory and both be valid for reads/writes).
    - menaerus 3y ago
      So, you're taking a "statement" from another person to "prove" that person you're replying to is wrong without adding any substance to your comment? What person you're replying to said is nothing wrong. Conceptually, Rust forbids certain patterns in programming which are otherwise very valid and necessary. And funnily, in some cases, it chooses to terminate or bring down the whole program in runtime because of that.
      - ttfkam 3y ago
        > Conceptually, Rust forbids certain patterns in programming which are otherwise very valid and necessary. Rather than forbid, Rust requires you put logic like this inside unsafe blocks. This limits the number of places you need to look for UB. Hopefully the number of shared writable pointers is not excessive. C++ programs on the other hand are all the equivalent of one big unsafe block. That's the difference, not anything "forbidden" by Rust.
        menaerus 3y ago
        "To look for" is a very vague and imprecise definition because that's not how you actually write or test your software. You don't look for UBs. It doesn't change the fact that you still have to hunt for bugs using ASAN, UBSAN, TSAN or MSAN _runtime_ sanitizers. This false dichotomy is following Rust since ever.
        ttfkam 3y ago
        CloudFlare remade their primary reverse proxy in Rust and had so few development issues, they ended up finding kernel bugs instead when problems arose. I've worked on projects with non-trivial C++ codebases for a variety of companies, large and small, and with some excellent developers who are far more skilled than I likely will ever be. https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/ https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t... A non-trivial C++ codebase with that kind of track record is so rare as to be unheard of, though many can approach it with the various sanitizers plugged into the dev workflow after the fact. C++ has improved dramatically over the last fifteen years, but a lot of stuff simply can't be fixed without breaking backward compatibility, which just isn't going to happen. We've had enough time elapse to see the related rates of CVEs posted for C++ and Rust apps over the last few years. It's not even close. It is absolutely possible to have bugs in a Rust app due to logic error or memory leak. But C++ has those same limitations and so many more unless you tack on a host of add-on analysis tools and still you end up with a result that is not as safe as Rust. Write a web app server in Rust? Sure. As long as I know the problem space, have the dev time allocated, and the need for that efficiency is clear. Write it in C++? Hell no. Not ever again. Not in a million years. Even if the need for efficiency is demonstrated, I have far less confidence in the integrity of that service when connected to the public internet, no matter how skilled the team is. Even Scott Meyers—Scott Fucking Meyers, who wrote acclaimed books on advanced use of C++ we mere mortals came to depend upon—does not have confidence in writing code for it anymore. In just three years, he went from an undisputed authority on the topic to this in 2018: "As you may know, I retired from active involvement in C++ at the end of 2015, and in the ensuing two and a half years, I’ve forgotten enough details of the language that I am no longer able to properly evaluate bug reports regarding the technical aspects of my books. C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind. As a result, all I can do is thank you for your bug report, because I no longer plan to update my books to incorporate technical corrections. Lacking the ability to fairly evaluate whether a bug report is valid, I think this is the only responsible course of action." https://scottmeyers.blogspot.com/2018/09/the-errata-evaluation-problem.html https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati... Neither I nor the folks I have worked with were as skilled as Scott Meyers at his prime, and the majority of us—myself especially—aren't even as good as he was 2.5 years after he stepped away. Perhaps you are. Are you certain that everyone else on your team is? Everyone who comes later that has to maintain those codebases? With Rust, I believe teams have a fighting chance. With C++, I'd just as soon buy lotto scratchers since I'm looking at similar odds. Perhaps I'm just an average software engineer. That's entirely possible, and I'll cop to that. But I'm not alone, and we still have bills to pay and code to write. For the sake of my clients, that'll be in Rust before C++ if I can help it. (And neither if the problem doesn't require their level of efficiency.)
- torstenvl 3y ago
  RefCell runtime panics are UB. All of Rust consists of behavior for which the international standard imposes no requirements. The set of requirements imposed on Rust by international standard is a null set. I'm sorry for being pedantic, but it's important to distinguish between UB generally (which would normally be termed "implementation-defined" in common parlance if that weren't already a term of art) and memory safety specifically. We don't get CVEs because a C source file didn't end in a newline. I suspect we rarely get CVEs because someone failed to add -ftrapv when they should have. We get CVEs primarily due to OOB memory access.
  - kibwen 3y ago
    > All of Rust consists of behavior for which the international standard imposes no requirements. This is quite the... unique way of defining "undefined behavior". Rust is currently implementation-defined. That doesn't even remotely mean its behavior is undefined in theory. And it certainly doesn't mean that "all of Rust" is UB in any practical, real-world sense. In practice, your average Rust program is more well-defined than nearly every C codebase, in terms of what invariants the compiler is allowed to assume about the code for the sake of performing transformations (which is what UB actually means, rather than "is there an international standard").
    - torstenvl 3y ago
      It isn't unique. That is the one and only definition of "undefined behavior" as a term of art. Many cases of UB in C are perfectly well defined at the implementation level. Some are not, for reasons ranging from lack of a demand signal, to the need for an expensive runtime, to compiler writers wanting to squeeze out every last drop of performance.

saghm 3y ago

I don't disagree about unsafe Rust being trickier than people might realize, but "RefCell runtime panics" bring a "new" problem is a bit of a stretch; it's strictly better than UB, which can also crash. Making a situation that used to be "maybe crash, maybe accidentally continue running and make things far wise than crashing" instead "definitely crash" is a reduction of an existing problem rather than a new one.

nyanpasu64 3y ago
RefCell causes runtime panics in cases (holding onto a borrow or borrow_mut() for too long) where C++ has well-defined behavior (two pointers can reference the same memory and both be valid for reads/writes).
- ttfkam 3y ago
  This statement… > "maybe crash, maybe accidentally continue running and make things far [worse] than crashing" instead "definitely crash" …is functionally indistinguishable from your reply. > (two pointers can reference the same memory and both be valid for reads/writes).
  - menaerus 3y ago
    So, you're taking a "statement" from another person to "prove" that person you're replying to is wrong without adding any substance to your comment? What person you're replying to said is nothing wrong. Conceptually, Rust forbids certain patterns in programming which are otherwise very valid and necessary. And funnily, in some cases, it chooses to terminate or bring down the whole program in runtime because of that.
    - ttfkam 3y ago
      > Conceptually, Rust forbids certain patterns in programming which are otherwise very valid and necessary. Rather than forbid, Rust requires you put logic like this inside unsafe blocks. This limits the number of places you need to look for UB. Hopefully the number of shared writable pointers is not excessive. C++ programs on the other hand are all the equivalent of one big unsafe block. That's the difference, not anything "forbidden" by Rust.
      - menaerus 3y ago
        "To look for" is a very vague and imprecise definition because that's not how you actually write or test your software. You don't look for UBs. It doesn't change the fact that you still have to hunt for bugs using ASAN, UBSAN, TSAN or MSAN _runtime_ sanitizers. This false dichotomy is following Rust since ever.
        ttfkam 3y ago
        CloudFlare remade their primary reverse proxy in Rust and had so few development issues, they ended up finding kernel bugs instead when problems arose. I've worked on projects with non-trivial C++ codebases for a variety of companies, large and small, and with some excellent developers who are far more skilled than I likely will ever be. https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/ https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t... A non-trivial C++ codebase with that kind of track record is so rare as to be unheard of, though many can approach it with the various sanitizers plugged into the dev workflow after the fact. C++ has improved dramatically over the last fifteen years, but a lot of stuff simply can't be fixed without breaking backward compatibility, which just isn't going to happen. We've had enough time elapse to see the related rates of CVEs posted for C++ and Rust apps over the last few years. It's not even close. It is absolutely possible to have bugs in a Rust app due to logic error or memory leak. But C++ has those same limitations and so many more unless you tack on a host of add-on analysis tools and still you end up with a result that is not as safe as Rust. Write a web app server in Rust? Sure. As long as I know the problem space, have the dev time allocated, and the need for that efficiency is clear. Write it in C++? Hell no. Not ever again. Not in a million years. Even if the need for efficiency is demonstrated, I have far less confidence in the integrity of that service when connected to the public internet, no matter how skilled the team is. Even Scott Meyers—Scott Fucking Meyers, who wrote acclaimed books on advanced use of C++ we mere mortals came to depend upon—does not have confidence in writing code for it anymore. In just three years, he went from an undisputed authority on the topic to this in 2018: "As you may know, I retired from active involvement in C++ at the end of 2015, and in the ensuing two and a half years, I’ve forgotten enough details of the language that I am no longer able to properly evaluate bug reports regarding the technical aspects of my books. C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind. As a result, all I can do is thank you for your bug report, because I no longer plan to update my books to incorporate technical corrections. Lacking the ability to fairly evaluate whether a bug report is valid, I think this is the only responsible course of action." https://scottmeyers.blogspot.com/2018/09/the-errata-evaluation-problem.html https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati... Neither I nor the folks I have worked with were as skilled as Scott Meyers at his prime, and the majority of us—myself especially—aren't even as good as he was 2.5 years after he stepped away. Perhaps you are. Are you certain that everyone else on your team is? Everyone who comes later that has to maintain those codebases? With Rust, I believe teams have a fighting chance. With C++, I'd just as soon buy lotto scratchers since I'm looking at similar odds. Perhaps I'm just an average software engineer. That's entirely possible, and I'll cop to that. But I'm not alone, and we still have bills to pay and code to write. For the sake of my clients, that'll be in Rust before C++ if I can help it. (And neither if the problem doesn't require their level of efficiency.)
torstenvl 3y ago
RefCell runtime panics are UB. All of Rust consists of behavior for which the international standard imposes no requirements. The set of requirements imposed on Rust by international standard is a null set. I'm sorry for being pedantic, but it's important to distinguish between UB generally (which would normally be termed "implementation-defined" in common parlance if that weren't already a term of art) and memory safety specifically. We don't get CVEs because a C source file didn't end in a newline. I suspect we rarely get CVEs because someone failed to add -ftrapv when they should have. We get CVEs primarily due to OOB memory access.
- kibwen 3y ago
  > All of Rust consists of behavior for which the international standard imposes no requirements. This is quite the... unique way of defining "undefined behavior". Rust is currently implementation-defined. That doesn't even remotely mean its behavior is undefined in theory. And it certainly doesn't mean that "all of Rust" is UB in any practical, real-world sense. In practice, your average Rust program is more well-defined than nearly every C codebase, in terms of what invariants the compiler is allowed to assume about the code for the sake of performing transformations (which is what UB actually means, rather than "is there an international standard").
  - torstenvl 3y ago
    It isn't unique. That is the one and only definition of "undefined behavior" as a term of art. Many cases of UB in C are perfectly well defined at the implementation level. Some are not, for reasons ranging from lack of a demand signal, to the need for an expensive runtime, to compiler writers wanting to squeeze out every last drop of performance.