5 ms·

I don't think safety is driving Rust's ascent. For example, WASM has more momentum with Rust than with C++. But WASM is already sandboxed, and does not support

I don't think safety is driving Rust's ascent. For example, WASM has more momentum with Rust than with C++. But WASM is already sandboxed, and does not support threads; so what is Rust bringing to the WASM table? I think it's a monoculture phenomenon. Rust has a website and a pitch; C++ does not. Rust has a single compiler and one way to do things; C++ is overly diverse. Rust has learned from npm, etc. and has made package management first-class with a single package manager; C++ has not. Rust is just a much more familiar experience for developers coming from other monoculture languages.

adwn 6y ago
> what is Rust bringing to the WASM table? Unless you have to interface with a lot of mostly-header/header-only libraries written in C or C++, Rust is just so much more productive to work with than C or C++, even if you don't have to worry about memory unsafety.
- millstone 6y ago
  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...
  - 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
rng_civ 6y ago
> But WASM is already sandboxed Sandboxing only secures the boundary between the WASM interpreter and the embedding application (typically the browser). You can still perform significant exploits within the sandbox. See [0] IIRC, low-level languages need to maintain a shadow stack in the heap because WASM has no native support for stack variable pointers and without ASLR, we're inching dangerously close to classic buffer overflow attacks. Rust still buys you safety in that regard. [0] https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...
- millstone 6y ago
  Sorry but that's baloney. Web developers are not choosing Rust/WASM because of security concerns with C++/WASM. The whole point of WASM is to enable untrusted code. Instead I believe they are choosing Rust/WASM because of the Rust ecosystem: familiar package management, tutorials, other resources.
  - pas 6y ago
    > whole point of WASM is to enable untrusted code. ... ? The web is already full of untrusted JS. WASM is for performance. The added extra security is just the cherry on top.

adwn 6y ago

> what is Rust bringing to the WASM table? Unless you have to interface with a lot of mostly-header/header-only libraries written in C or C++, Rust is just so much more productive to work with than C or C++, even if you don't have to worry about memory unsafety.

millstone 6y ago
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...
- 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

rng_civ 6y ago

> But WASM is already sandboxed Sandboxing only secures the boundary between the WASM interpreter and the embedding application (typically the browser). You can still perform significant exploits within the sandbox. See [0] IIRC, low-level languages need to maintain a shadow stack in the heap because WASM has no native support for stack variable pointers and without ASLR, we're inching dangerously close to classic buffer overflow attacks. Rust still buys you safety in that regard. [0] https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...

millstone 6y ago
Sorry but that's baloney. Web developers are not choosing Rust/WASM because of security concerns with C++/WASM. The whole point of WASM is to enable untrusted code. Instead I believe they are choosing Rust/WASM because of the Rust ecosystem: familiar package management, tutorials, other resources.
- pas 6y ago
  > whole point of WASM is to enable untrusted code. ... ? The web is already full of untrusted JS. WASM is for performance. The added extra security is just the cherry on top.