9 ms·

More of a comparison between WebAssembly and JavaScript, really. That the WebAssembly was compiled from Rust is not especially meaningful here.

Banana699 4y ago
The language whose compiler generated the code is relevant, as it often constrains what the generated code look like in broad terms.
maverwa 4y ago
Not sure, it could also be viewed as a comparison of ahead-of-time compilation vs. just-in-time compilation (I guess the code paths are hot enough to be completely "jit-ed" here), and then the compiler isnt irrelevant at all. But havent looked into the details on how much difference that alone makes in this case. I think its also a testament on how fast JS has gotten.
yatac42 4y ago
I wouldn't say the source language is not meaningful. If you wrote an ahead-of-time JavaScript-to-WebAssembly compiler and benchmarked the WASM generated by that, it would probably be a lot slower than the WASM generated by the Rust compiler, no?
- throwaway894345 4y ago
  Has anyone compiled v8 to WASM so we can finally run JS in the browser? ;)
  - mrtesthah 4y ago
    please don’t give them more ideas
  - hunterb123 4y ago
    v8 is a JIT engine, WASM would not support it. JavaScriptCore has been compiled to WASM though: https://mbbill.github.io/JSC.js/ https://mbbill.github.io/JSC.js/ People usually ask why, the answer is usually for fun or for sandboxed plugins.
    - amluto 4y ago
      I imagine that, if one were feeling extremely masochistic, one could generate WASM, JIT-style, and load it as needed. The result may not perform well.
    - throwaway894345 4y ago
      I assumed the JIT would emit WASM.
usrusr 4y ago
True, but if you where in a front-end project doing JS with some WASM parts that happened to use Rust for the WASM, you'd probably not ask yourself "JS or WASM?", you'd ask yourself "JS or Rust?" when deciding where to put some logic. And I'm not sure if we can assume that all languages that offer compilation to WASM would be roughly "rust fast": I wouldn't be surprised if we already had some examples that aren't really good matches for that tight inner loop case you might want to wasmify. Perhaps there are already some that just want to get the "runs in browser" checkbox ticked?
hazn 4y ago
The fact that it was written in Rust (or any other non-VM lang) is meaningful because programs written in a Language that needs a VM (All the GC'd languages for example) need the vm to be shipped as well. Thus, making the WASM-program larger and slower.
- atwood22 4y ago
  Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.
  - ipsi 4y ago
    Maybe Runtime or Runtime System is a better word than VM? Go has _something_ that manages Go routines and GC and so on.
    - deleted 4y ago
      [deleted]
    - jhgb 4y ago
      You'd need a runtime for managing green threads even if you didn't have a language with GC.
    - tialaramex 4y ago
      Sure, but Rust can have a runtime, and presumably Rust on WASM does. If you don't have a runtime in Rust you only get core. https://doc.rust-lang.org/core/ https://doc.rust-lang.org/core/ This has obvious effects (you don't have an allocator so you can't have String) and more subtle effects (your slices don't have a sort() method! However they do have a sort_unstable() method) but while it's probably a reasonable environment for the firmware inside a custom $25 gizmo it's not a very comfortable one for general purpose programming. To deliver a bit more, for example an allocator, you're bringing in a bunch of platform specific code, which, just like the Garbage Collector for Go, you did not write.
      - 4y ago
stared 4y ago
From the user-experience perspective, it matters that it is Rust. Unless you directly write WASM code, which is rarely (ever) the case. Rust is a language that compiles to WASM. Sure, there are other options to compile to WASM, but they differ by interface (programming language, library, tooling) and (likely to a lesser degree) - performance.
- teucris 4y ago
  Given the title I had expected this to be a comparison between the js and rust in terms of development, not performance. I learned nothing new about rust by visiting this page. All I learned was that compiled WASM is faster than js.
  - marcosdumay 4y ago
    > All I learned was that compiled WASM is faster than js. You learned that Rust compiled into WASM is faster than JS. That won't be the case for every language. (We had an example yesterday on the front-page where it wasn't. Ironically, its title implied that it was a generic comparison with WASM.)
- IncRnd 4y ago
  > From the user-experience perspective, it matters that it is Rust. From the user-experience perspective, none of the page loads without javascript, so it is all javascript from a customer's perspective.
- deleted 4y ago
  [deleted]

Banana699 4y ago

The language whose compiler generated the code is relevant, as it often constrains what the generated code look like in broad terms.

maverwa 4y ago

Not sure, it could also be viewed as a comparison of ahead-of-time compilation vs. just-in-time compilation (I guess the code paths are hot enough to be completely "jit-ed" here), and then the compiler isnt irrelevant at all. But havent looked into the details on how much difference that alone makes in this case. I think its also a testament on how fast JS has gotten.

yatac42 4y ago

I wouldn't say the source language is not meaningful. If you wrote an ahead-of-time JavaScript-to-WebAssembly compiler and benchmarked the WASM generated by that, it would probably be a lot slower than the WASM generated by the Rust compiler, no?

throwaway894345 4y ago
Has anyone compiled v8 to WASM so we can finally run JS in the browser? ;)
- mrtesthah 4y ago
  please don’t give them more ideas
- hunterb123 4y ago
  v8 is a JIT engine, WASM would not support it. JavaScriptCore has been compiled to WASM though: https://mbbill.github.io/JSC.js/ https://mbbill.github.io/JSC.js/ People usually ask why, the answer is usually for fun or for sandboxed plugins.
  - amluto 4y ago
    I imagine that, if one were feeling extremely masochistic, one could generate WASM, JIT-style, and load it as needed. The result may not perform well.
  - throwaway894345 4y ago
    I assumed the JIT would emit WASM.

usrusr 4y ago

True, but if you where in a front-end project doing JS with some WASM parts that happened to use Rust for the WASM, you'd probably not ask yourself "JS or WASM?", you'd ask yourself "JS or Rust?" when deciding where to put some logic. And I'm not sure if we can assume that all languages that offer compilation to WASM would be roughly "rust fast": I wouldn't be surprised if we already had some examples that aren't really good matches for that tight inner loop case you might want to wasmify. Perhaps there are already some that just want to get the "runs in browser" checkbox ticked?

hazn 4y ago

The fact that it was written in Rust (or any other non-VM lang) is meaningful because programs written in a Language that needs a VM (All the GC'd languages for example) need the vm to be shipped as well. Thus, making the WASM-program larger and slower.

atwood22 4y ago
Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.
- ipsi 4y ago
  Maybe Runtime or Runtime System is a better word than VM? Go has _something_ that manages Go routines and GC and so on.
  - deleted 4y ago
    [deleted]
  - jhgb 4y ago
    You'd need a runtime for managing green threads even if you didn't have a language with GC.
  - tialaramex 4y ago
    Sure, but Rust can have a runtime, and presumably Rust on WASM does. If you don't have a runtime in Rust you only get core. https://doc.rust-lang.org/core/ https://doc.rust-lang.org/core/ This has obvious effects (you don't have an allocator so you can't have String) and more subtle effects (your slices don't have a sort() method! However they do have a sort_unstable() method) but while it's probably a reasonable environment for the firmware inside a custom $25 gizmo it's not a very comfortable one for general purpose programming. To deliver a bit more, for example an allocator, you're bringing in a bunch of platform specific code, which, just like the Garbage Collector for Go, you did not write.
    - 4y ago

stared 4y ago

From the user-experience perspective, it matters that it is Rust. Unless you directly write WASM code, which is rarely (ever) the case. Rust is a language that compiles to WASM. Sure, there are other options to compile to WASM, but they differ by interface (programming language, library, tooling) and (likely to a lesser degree) - performance.

teucris 4y ago
Given the title I had expected this to be a comparison between the js and rust in terms of development, not performance. I learned nothing new about rust by visiting this page. All I learned was that compiled WASM is faster than js.
- marcosdumay 4y ago
  > All I learned was that compiled WASM is faster than js. You learned that Rust compiled into WASM is faster than JS. That won't be the case for every language. (We had an example yesterday on the front-page where it wasn't. Ironically, its title implied that it was a generic comparison with WASM.)
IncRnd 4y ago
> From the user-experience perspective, it matters that it is Rust. From the user-experience perspective, none of the page loads without javascript, so it is all javascript from a customer's perspective.
deleted 4y ago
[deleted]