3 ms·

This seems like the opposite of what I would expect. I'd think any good C or C++ programmer would reason about lifetimes in their programs on a regular basis. W

by gue5t 11y ago

This seems like the opposite of what I would expect. I'd think any good C or C++ programmer would reason about lifetimes in their programs on a regular basis. When I first came across Rust I was so happy to see a language codify the conventions around ownership and mutation that had previously been relegated to comments, naming patterns, and a rough consensus around what "const" meant. I would expect the people bouncing off of borrowck to be those coming from GC'd languages where where and how long a value lives aren't things most programmers think about. Programmers coming to Rust from this environment have to learn about the fundamental concepts of lifetimes and in-memory representation/storage at the same time as they learn the limitations and reasoning model of borrowck. Without having seen the mistakes they're being prevented from making, I can imagine trying to fix borrow errors would feel more like a game of appease-the-adversarial-checker than a safety harness catching you when you slip up. The only reason I see to keep writing C++ is the impedance gap between Rust and C++ making it less than pleasant to convert a large C++ codebase to Rust gradually. On top of name-mangling/linking concerns, Rust encourages composition and static method dispatch whereas it's rare to find a large C++ project not using inheritance and vtables extensively. You'd probably just end up going through the C ABI for all interop which is hard to argue would increase code quality compared to simply sticking to pure C++.

pcwalton 11y ago
I'd hope so, but in practice I see a lot of C++ people bouncing off Rust's memory management for two reasons: (1) The most common one: They think that they can write C++ safely with no memory management issues, and that people who don't are just bad programmers. This has been empirically refuted over and over again and I think there's no successful way to defend this idea, but it's a very appealing position on the face of it, so it's something I hear a lot. (2) The less commonly expressed, but much more legitimate one: Memory management problems just aren't the biggest issues they deal with. I hear this from game developers from time to time (e.g. Jonathan Blow, though he's not by any means the only one). This is, in my mind, a totally legitimate position. Viewed in this light, C++'s memory management primitives are simple ways to eliminate the most obvious errors, which helps prevent some (not all) crashes and vulnerabilities from reaching production. Rust is entirely a move in the wrong direction for these projects, because it adds nontrivial cognitive overhead. Interestingly, people rarely ever describe reason (2) in those words, probably because the idea that you would opt in to less safety makes people queasy. But that doesn't make sense to me; it's legitimate to want less safety if your app doesn't require it. (I do think, of course, that reason (2) is not legitimate if less safety makes your app vulnerable to e.g. remote code execution by network attackers and RCE would result in the leak of sensitive data or other game-over scenarios.) I've actually been a proponent of solving (2) by adding easier ways to write unsafe code in Rust. But (2) is not a commonly-expressed position, so there's been little community interest in solving it (which I'm fine with).

by gue5t 11y ago

pcwalton 11y ago

I'd hope so, but in practice I see a lot of C++ people bouncing off Rust's memory management for two reasons: (1) The most common one: They think that they can write C++ safely with no memory management issues, and that people who don't are just bad programmers. This has been empirically refuted over and over again and I think there's no successful way to defend this idea, but it's a very appealing position on the face of it, so it's something I hear a lot. (2) The less commonly expressed, but much more legitimate one: Memory management problems just aren't the biggest issues they deal with. I hear this from game developers from time to time (e.g. Jonathan Blow, though he's not by any means the only one). This is, in my mind, a totally legitimate position. Viewed in this light, C++'s memory management primitives are simple ways to eliminate the most obvious errors, which helps prevent some (not all) crashes and vulnerabilities from reaching production. Rust is entirely a move in the wrong direction for these projects, because it adds nontrivial cognitive overhead. Interestingly, people rarely ever describe reason (2) in those words, probably because the idea that you would opt in to less safety makes people queasy. But that doesn't make sense to me; it's legitimate to want less safety if your app doesn't require it. (I do think, of course, that reason (2) is not legitimate if less safety makes your app vulnerable to e.g. remote code execution by network attackers and RCE would result in the leak of sensitive data or other game-over scenarios.) I've actually been a proponent of solving (2) by adding easier ways to write unsafe code in Rust. But (2) is not a commonly-expressed position, so there's been little community interest in solving it (which I'm fine with).