3 ms·
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
by 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 agoJavascript 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 agoNo, 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 agoHave you tried async generator functions?