5 ms·

As ssoneone who used to like C++ but has moved on to rust: There are good things in here, but I am not convinced they go far enough, even if completely implemen

As ssoneone who used to like C++ but has moved on to rust: There are good things in here, but I am not convinced they go far enough, even if completely implemented. The good: I see a new Stroustrup. At the time of the NSA report, he seemed to be in denial about the position C++ was in, security wise. The 'just be carefull'- wont-scale slide seems a much better basis to start the discussion from.He seems to propose something similar to rust editions, allowing problematic parts of the language to be switched off, with an escape hatch similar to unsafe. If this would work out, rewrite it in rust could no longer be needed. There is an upgrade path for C++, and an incentive to use it. The bad: There seems to be still some denial in there. I see rust providing today what he calls a fantasy. In fact, it existed before C with languages like ADA, except the ecosystem just wasnt there. Second problem is the timeline. 3 years for a new language version, then 10 years for the ecosystem to upgrade, then another 10 years until everyone is convinced this new way of working should be better? It seems both an aggressive timeline and a promise it wont happen in my professional lifetime. Also, a path forward is not a commitment, e.g. to completely eradicate undefined behavior outside unsafe blocks. All and all, and I hope I am wrong here, I read this as too little, too late. Rewriting it all from scratch is hard, but erasing the culture of the C++ ecosystem seems a lot harder.

nyanpasu64 3y ago
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.
pjmlp 3y ago
Bjarne Stroustrup's major problem, that people keep forgeting about him is that he isn't a BDFL of C++, rather a very important WG21 member with the vote of one person. So while his opinion is highly regarded by some of the ISO WG21 300+ voters, like in politics, if he doesn't manage to win the majority of the voters, and then the compiler writers (which can always ignore part of ISO, and they sometimes do), it hardly matters. As for the three years, while it may seem a long time, keeping up with six week releases on Rust is also not a panacea, and when Rust eventually gets more than just a reference implementation, like required by law in some industries, it will also slow down. As example in some of those industries, being able to use certified C++14 or C11 toolchains is already a luxury.

nyanpasu64 3y ago

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.

pjmlp 3y ago

Bjarne Stroustrup's major problem, that people keep forgeting about him is that he isn't a BDFL of C++, rather a very important WG21 member with the vote of one person. So while his opinion is highly regarded by some of the ISO WG21 300+ voters, like in politics, if he doesn't manage to win the majority of the voters, and then the compiler writers (which can always ignore part of ISO, and they sometimes do), it hardly matters. As for the three years, while it may seem a long time, keeping up with six week releases on Rust is also not a panacea, and when Rust eventually gets more than just a reference implementation, like required by law in some industries, it will also slow down. As example in some of those industries, being able to use certified C++14 or C11 toolchains is already a luxury.