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.
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.
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.
