[millstone]

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]

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]

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]

> 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]

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]

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]

You do have to use PhantomData, otherwise it won't compile:

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

> 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=600a1ca784ee7df02351e58df43...

[woah]

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