2 ms·

> While JS engines are an engineering marvel, they just cannot compete with bare metal compiled code, and the JS single-thread model really doesn't help. This

> While JS engines are an engineering marvel, they just cannot compete with bare metal compiled code, and the JS single-thread model really doesn't help. This has nothing to do with it. When was the last time your browser locked up in Google Docs which is also primarily JS-driven? Event loops are great and solve all kinds of concurrency hazards. If you need more parallelism, then spin off another event loop to do separate processing tasks. There's no reason each email composition window can't be its own event loop, for instance.

tlamponi 3y ago
> This has nothing to do with it. When was the last time your browser locked up in Google Docs which is also primarily JS-driven? I don't use Google Docs, but I often get slow JS-ridden sites, also I never said this is the sole reason it's slow, at the end I even mentioned that it can be fixed with JS too – still rust is 10x faster and more efficient (better power usage on laptops), naturally one can code in both language such that it sucks independently – still, rust makes it harder to hold it wrong. > There's no reason each email composition window can't be its own event loop, for instance. Yeah, never said the contrary but a) still will be faster if done in rust or something like that (I use both JS and rust a lot, so I got at least _some_ experience with those different ecosystems) and b) it doesn't help if you do IO and hang in kernel D state then the whole thread hangs, including any IO loop. Rust's prime async framework tokio has solutions for that, being a work-stealing executor it can detect this from another thread and move unrelated futures to other threads and continue execution there. Sure, maybe one can shoestring that together with JS, but it's not making things more maintainable (as was the original goal), as JS gives you no access/synchronisation guarantees.
- tentacleuno 3y ago
  Doesn't JavaScript's Atomics API provide synchronisation primitives?

tlamponi 3y ago

> This has nothing to do with it. When was the last time your browser locked up in Google Docs which is also primarily JS-driven? I don't use Google Docs, but I often get slow JS-ridden sites, also I never said this is the sole reason it's slow, at the end I even mentioned that it can be fixed with JS too – still rust is 10x faster and more efficient (better power usage on laptops), naturally one can code in both language such that it sucks independently – still, rust makes it harder to hold it wrong. > There's no reason each email composition window can't be its own event loop, for instance. Yeah, never said the contrary but a) still will be faster if done in rust or something like that (I use both JS and rust a lot, so I got at least _some_ experience with those different ecosystems) and b) it doesn't help if you do IO and hang in kernel D state then the whole thread hangs, including any IO loop. Rust's prime async framework tokio has solutions for that, being a work-stealing executor it can detect this from another thread and move unrelated futures to other threads and continue execution there. Sure, maybe one can shoestring that together with JS, but it's not making things more maintainable (as was the original goal), as JS gives you no access/synchronisation guarantees.

tentacleuno 3y ago
Doesn't JavaScript's Atomics API provide synchronisation primitives?