5 ms·

How do you find Rust to be so much more productive than C++? I find C++ more productive. In C++ I mainly fight with template error messages. In Rust, I fight w

How do you find Rust to be so much more productive than C++? I find C++ more productive. In C++ I mainly fight with template error messages. In Rust, I fight with typechecked generics, inserting & and '_ here or there, adding and deleting imports, refactoring to add Some and Ok - tons of nonsense housekeeping. These features have value but are quite a slog when writing code.

adwn 6y ago
Those "tons of nonsense housekeeping" help me detect and avoid bugs. Memory unsafety is not the only category of incorrect code – a bug is a bug, even if it doesn't enable an attacker to gain access to your system. Some of the kinds of bugs that are much easier to accidentally write in C++ than in Rust are: use-after-free, use-after-move, out-of-bounds array accesses, data races and other synchronization errors. I want my code to be correct, even if it runs in a sandbox.
- millstone 6y ago
  I agree. In Rust I write correct code slowly. "Productive" I am not. But the great strengths of Rust, like memory and thread safety, are blunted in WASM, which is already memory-safe and thread-crippled. So Rust's success in WASM must be due to other factors.
  - adwn 6y ago
    > I agree. In Rust I write correct code slowly. "Productive" I am not. I'm confused by that statement. Do you not care whether your code works correctly? Do you consider finding and fixing bugs to be separate from writing code?
    - millstone 6y ago
      Rust has lots of nonsense with zero practical benefit. Examples: PhantomData, higher-ranked trait bounds, "upstream crates may add a new impl". I have satisfied the compiler but no bugs were prevented. It's just busywork.
      - pas 6y ago
        You don't have to use PhantomData. > "upstream crates may add a new impl" I have satisfied the compiler but no bugs were prevented. Trial-and-error debugging which version causes a bug is busywork, preventing it right when someone introduces the potential problem is at best annoying, but very fast compared to the alternative.
        millstone 6y ago
        You do have to use PhantomData, otherwise it won't compile: https://play.rust-lang.org/?gist=84883cb7cdd09acdcd919888cef04e59 https://play.rust-lang.org/?gist=84883cb7cdd09acdcd919888cef... It's especially bad if your type is an enum, since there's no obvious place to put the PhantomData: https://github.com/rust-lang/rust/issues/32739 https://github.com/rust-lang/rust/issues/32739 > Trial-and-error debugging which version causes a bug is busywork, preventing it right when someone introduces the potential problem is at best annoying It's a silly limitation. For example, u64 and u128 are not From<usize> because...well I have no idea. But you can't make them From, because Rust wants to reserve the right to make them From in the future. And you can't write a function that assumes they are NOT From, for the same reason. So it's pointlessly hard to write generics over integers. I encounter lots of weird holes like this. https://play.rust-lang.org/?gist=600a1ca784ee7df02351e58df4303b34 https://play.rust-lang.org/?gist=600a1ca784ee7df02351e58df43...
        pas 6y ago
        I meant that you are not forced to use generics, you can use composition, boxing, dyn, etc. (And unsafe too, but PhantomData seems simpler.) > For example, u64 and u128 are not From<usize> because...well I have no idea. Because usize is not known statically, it's target arch dependent. Yes, it's silly, but that's how technical safety works. (Also, just as a silly technical counter example the AS/400 virtual instruction set has 128 bit sized pointers.) There's no question about the need for more ergonomics. That's what this whole post is about after all. For example in some cases where currently PhantomData is needed the intent of the programmer can be easily and unambiguously figured out, but for this folks need to be at least sufficiently certain that this makes things easier, makes code readable, doesn't constraint later language evolution, etc. (If I understand correctly some associated trait bound enhancements will lead to more readable code, less PhantomData.)
woah 6y ago
How are Some and Ok nonsense housekeeping? These things are fundamental parts of your program’s logic. Without them you are playing Russian roulette with runtime errors

adwn 6y ago

Those "tons of nonsense housekeeping" help me detect and avoid bugs. Memory unsafety is not the only category of incorrect code – a bug is a bug, even if it doesn't enable an attacker to gain access to your system. Some of the kinds of bugs that are much easier to accidentally write in C++ than in Rust are: use-after-free, use-after-move, out-of-bounds array accesses, data races and other synchronization errors. I want my code to be correct, even if it runs in a sandbox.

millstone 6y ago
I agree. In Rust I write correct code slowly. "Productive" I am not. But the great strengths of Rust, like memory and thread safety, are blunted in WASM, which is already memory-safe and thread-crippled. So Rust's success in WASM must be due to other factors.
- adwn 6y ago
  > I agree. In Rust I write correct code slowly. "Productive" I am not. I'm confused by that statement. Do you not care whether your code works correctly? Do you consider finding and fixing bugs to be separate from writing code?
  - millstone 6y ago
    Rust has lots of nonsense with zero practical benefit. Examples: PhantomData, higher-ranked trait bounds, "upstream crates may add a new impl". I have satisfied the compiler but no bugs were prevented. It's just busywork.
    - pas 6y ago
      You don't have to use PhantomData. > "upstream crates may add a new impl" I have satisfied the compiler but no bugs were prevented. Trial-and-error debugging which version causes a bug is busywork, preventing it right when someone introduces the potential problem is at best annoying, but very fast compared to the alternative.
      - millstone 6y ago
        You do have to use PhantomData, otherwise it won't compile: https://play.rust-lang.org/?gist=84883cb7cdd09acdcd919888cef04e59 https://play.rust-lang.org/?gist=84883cb7cdd09acdcd919888cef... It's especially bad if your type is an enum, since there's no obvious place to put the PhantomData: https://github.com/rust-lang/rust/issues/32739 https://github.com/rust-lang/rust/issues/32739 > Trial-and-error debugging which version causes a bug is busywork, preventing it right when someone introduces the potential problem is at best annoying It's a silly limitation. For example, u64 and u128 are not From<usize> because...well I have no idea. But you can't make them From, because Rust wants to reserve the right to make them From in the future. And you can't write a function that assumes they are NOT From, for the same reason. So it's pointlessly hard to write generics over integers. I encounter lots of weird holes like this. https://play.rust-lang.org/?gist=600a1ca784ee7df02351e58df4303b34 https://play.rust-lang.org/?gist=600a1ca784ee7df02351e58df43...
        pas 6y ago
        I meant that you are not forced to use generics, you can use composition, boxing, dyn, etc. (And unsafe too, but PhantomData seems simpler.) > For example, u64 and u128 are not From<usize> because...well I have no idea. Because usize is not known statically, it's target arch dependent. Yes, it's silly, but that's how technical safety works. (Also, just as a silly technical counter example the AS/400 virtual instruction set has 128 bit sized pointers.) There's no question about the need for more ergonomics. That's what this whole post is about after all. For example in some cases where currently PhantomData is needed the intent of the programmer can be easily and unambiguously figured out, but for this folks need to be at least sufficiently certain that this makes things easier, makes code readable, doesn't constraint later language evolution, etc. (If I understand correctly some associated trait bound enhancements will lead to more readable code, less PhantomData.)

woah 6y ago

How are Some and Ok nonsense housekeeping? These things are fundamental parts of your program’s logic. Without them you are playing Russian roulette with runtime errors