8 ms·

>> webassembly is faster than javascript > Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm

>> webassembly is faster than javascript > Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm lately. Yes, it is faster than javascript, but not by all that much. I think even if it is faster in general, you might lose all that advantage as soon as you have to cross the WASM <-> JS boundary and have to create new object instances (and associated garbage) that you never would have needed to create if you had used only one language. Therefore moving to WASM for performance reasons on a project which crosses the language boundaries very often due to browser API access doesn't seem too promising to me.

loxs 6y ago
I am writing an app that needs worker threads both on the backend and also on the frontend (because of some heavy processing of large amounts of "objects") and my experience with TS so far is very poor. JS runtimes are just not suitable for heavy concurrent/parallel processing. Serialization/deserialization overhead between threads is probably (much) worse than it would be if the worker threads were in Rust. It's not a matter of speed here. It's a matter of enabling certain types of programs which are borderline impossible with pure JS runtimes. So I will probably move most of the logic to Rust
- Matthias247 6y ago
  Javascript runtimes do fine with concurrent operations, but obviously are not intended for parallelism. On the WASM side: Does WASM support real threads yet? Otherwise moving to Rust wouldn't really help you? If it's just "WebWorker" like multiple runtimes, you might still pay serialization costs to move objects between workers.
  - loxs 6y ago
    No, JS runtimes don't do "fine" with concurrent operations, unless you are "waiting". If you are doing heavy processing, the whole service freezes. That's indeed the primary reason I need worker threads. Erlang's runtime does "fine" with its preemptive concurrency model, JS runtimes are a joke in this regard.
    - IggleSniggle 6y ago
      Have you tried async generator functions?

loxs 6y ago

I am writing an app that needs worker threads both on the backend and also on the frontend (because of some heavy processing of large amounts of "objects") and my experience with TS so far is very poor. JS runtimes are just not suitable for heavy concurrent/parallel processing. Serialization/deserialization overhead between threads is probably (much) worse than it would be if the worker threads were in Rust. It's not a matter of speed here. It's a matter of enabling certain types of programs which are borderline impossible with pure JS runtimes. So I will probably move most of the logic to Rust

Matthias247 6y ago
Javascript runtimes do fine with concurrent operations, but obviously are not intended for parallelism. On the WASM side: Does WASM support real threads yet? Otherwise moving to Rust wouldn't really help you? If it's just "WebWorker" like multiple runtimes, you might still pay serialization costs to move objects between workers.
- loxs 6y ago
  No, JS runtimes don't do "fine" with concurrent operations, unless you are "waiting". If you are doing heavy processing, the whole service freezes. That's indeed the primary reason I need worker threads. Erlang's runtime does "fine" with its preemptive concurrency model, JS runtimes are a joke in this regard.
  - IggleSniggle 6y ago
    Have you tried async generator functions?