Ecma has made some advances in making Javascript better suitable for multithreading(webworkers) for quite a while now. Would there be any plans to take advantage of this and perhaps a little of Rust vast power to make Javascript Achilees heel(horrible concurrency) less of a problem?
Deno already have Worker
s fyi. I don't think I fully understand your implication of "Rust vast power" here. Do you have a good example to demonstrate this (that could not be resolved with Workers)?
I was thinking on Rust multithreading instead of native JS multithreading.
Running multiple instances of Rust Deno runtime to boost execution time on high demanding JS processes.
Just an idea, though.
Rust side processes take advantage of that, as well as the way V8 handles what it can handle, but there isn't a lot you can do with JavaScript because of the need to have a main event loop. Multi-threading is more than just going faster, you have to have you memory access thread safe as well, and code has to be written to be aware of that, and there is no way to do such a thing outside of web workers in JavaScript, which Deno supports.
Ok guys, :(
You can already run workers in Deno in parallel.
Currently async ops are executed on the same thread as the issuing Isolate - however I鈥檓 quite sure we can improve this and execute async ops in different threads. This could result in important latency improvements for ops which have a lot of compute - like TLS. I will start this work soon.
@ry but when you do that please don't do that for workers as i can then not expect anymore what is going on when my workers start to create addition th's
Most helpful comment
You can already run workers in Deno in parallel.
Currently async ops are executed on the same thread as the issuing Isolate - however I鈥檓 quite sure we can improve this and execute async ops in different threads. This could result in important latency improvements for ops which have a lot of compute - like TLS. I will start this work soon.