3 ms·

And they shouldn't...let's move forward... to WASM (Web Assembly)! Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to W

And they shouldn't...let's move forward... to WASM (Web Assembly)! Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to WASM. https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly-guide-411066a69fde#.r8qex53c3 https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly...

gsnedders 10y ago
Except, like, JS isn't going to die any time soon, and realistically, implementing a new JS or WASM VM isn't actually that interesting to do: the big risk in a JITing VM that Rust cannot save you from is behaviour of your JITed code, which makes memory safety far harder to enforce.
- Cshelton 10y ago
  Right, JS isn't going anywhere. But once WASM is able to run everywhere, anybody attempting to make high performance web apps would ideally want to write it in WASM. A lot of what JS does on the web is plenty fast and won't really benefit much from JS being multi-threaded/faster. Sites using JS to run simple scripts or to fire api calls/etc. will continue to use JS, no reason to use WASM. Also, I believe WASM is truly compiled code and not JIT ran? I may be wrong...but pretty sure that was the whole point of creating it. Native app performance in the browser... that will take a big bite out of the app stores that take a good cut of revenue and control what can and can not be in the store. And sure, WASM can also have memory safety problems, especially with C/C++ being the primary languages to target WASM from. But that's also where Rust would shine, making it much more safe when compiled to WASM.
  - gsnedders 10y ago
    WASM isn't machine code: if it were, it wouldn't be universal which is a fundamental requirement of the web. (Well, okay, it's compiled code—it is, after all, compiled from C/C++/etc., but in the same way JS is compiled to byte code in VMs today.) As such, there's a further compilation step needed from WASM to machine code to get near-native performance out of it. The existing WASM implementations do a mixture of JITing code at load-time and JITing code at first-call, depending on the size of the WASM blob, AFAIK. The gain performance wise over asm.js is primarily in parse-time, as far as I'm aware. WASM VM itself is perfectly possible to be memory safe: WASM code cannot read outside of the memory allocated to it (and malloc/free are implemented on top of that memory allocated to the VM, hence there's memory safety at the VM level). The big problems come when you need to guarantee your JIT code doesn't violate memory safety, and that's something Rust's type system cannot (currently) solve. You need guarantees that the generated code will never have any memory access errors, and will never race for memory reads/writes, because it's running with the privilege of the VM, not the limited powers of the WASM code running within it.

gsnedders 10y ago

Except, like, JS isn't going to die any time soon, and realistically, implementing a new JS or WASM VM isn't actually that interesting to do: the big risk in a JITing VM that Rust cannot save you from is behaviour of your JITed code, which makes memory safety far harder to enforce.

Cshelton 10y ago
Right, JS isn't going anywhere. But once WASM is able to run everywhere, anybody attempting to make high performance web apps would ideally want to write it in WASM. A lot of what JS does on the web is plenty fast and won't really benefit much from JS being multi-threaded/faster. Sites using JS to run simple scripts or to fire api calls/etc. will continue to use JS, no reason to use WASM. Also, I believe WASM is truly compiled code and not JIT ran? I may be wrong...but pretty sure that was the whole point of creating it. Native app performance in the browser... that will take a big bite out of the app stores that take a good cut of revenue and control what can and can not be in the store. And sure, WASM can also have memory safety problems, especially with C/C++ being the primary languages to target WASM from. But that's also where Rust would shine, making it much more safe when compiled to WASM.
- gsnedders 10y ago
  WASM isn't machine code: if it were, it wouldn't be universal which is a fundamental requirement of the web. (Well, okay, it's compiled code—it is, after all, compiled from C/C++/etc., but in the same way JS is compiled to byte code in VMs today.) As such, there's a further compilation step needed from WASM to machine code to get near-native performance out of it. The existing WASM implementations do a mixture of JITing code at load-time and JITing code at first-call, depending on the size of the WASM blob, AFAIK. The gain performance wise over asm.js is primarily in parse-time, as far as I'm aware. WASM VM itself is perfectly possible to be memory safe: WASM code cannot read outside of the memory allocated to it (and malloc/free are implemented on top of that memory allocated to the VM, hence there's memory safety at the VM level). The big problems come when you need to guarantee your JIT code doesn't violate memory safety, and that's something Rust's type system cannot (currently) solve. You need guarantees that the generated code will never have any memory access errors, and will never race for memory reads/writes, because it's running with the privilege of the VM, not the limited powers of the WASM code running within it.