5 ms·

JavaScript also has the benefit of a single threaded event loop - that eliminates a whole class of complexity and dealing with schedulers etc. - there is only o

JavaScript also has the benefit of a single threaded event loop - that eliminates a whole class of complexity and dealing with schedulers etc. - there is only one. Async already gets messier in C# for example which also has a GC.

armchairhacker 4y ago
You can have a single threaded event loop in Rust. Just, like everything else, it's an option and you have to specify it explicitly.
- moonchrome 4y ago
  Yes but the API has to be built for multithreaded scheduling.
  - staticassertion 4y ago
    No, you get !Send futures.
  - Gwypaas 4y ago
    This is a nice read on why you likely should prefer a single threaded runtime and enable parallelism through other means. Or decide to pay the synchronization cost. https://maciej.codes/2022-06-09-local-async.html https://maciej.codes/2022-06-09-local-async.html
- dagmx 4y ago
  Yes but the point was that rust has to allow for multi threaded event loops. JavaScript can design around knowing that's not an option
ashish_negi_ 4y ago
if you write harder concurrent program in JS, single threaded event loop does not help. It still has also same concurrency problems. e.g. if there is shared global mutable state: a) in workflow 1 you have, do_some_work_on_global_state; do some IO; in IO callback, finish more do_some_work_on_global_state. b) in workflow 2 .. same like above work on global_state. Now, in IO callback, you don't know if workflow 2 ran and have to handle all possible combinations of global_state above. Replace global_state with common_state and problem still remains. If you don't have common_state between multiple workflows, then it is not a hard concurrency problem and should be easy to do in all languages.
- moonchrome 4y ago
  Sure it does, you don't have to manage on which thread you handle continuations (which you must in multithreaded GUI for example) - there's only one scheduler which simplifies the async API a lot. But even for concurrency - single threaded event loop/cooperative multitasking eliminates a whole class of partial state updates and synchronization primitive/locking errors - it's not even close to preemptive multitasking complexity.

armchairhacker 4y ago

You can have a single threaded event loop in Rust. Just, like everything else, it's an option and you have to specify it explicitly.

moonchrome 4y ago
Yes but the API has to be built for multithreaded scheduling.
- staticassertion 4y ago
  No, you get !Send futures.
- Gwypaas 4y ago
  This is a nice read on why you likely should prefer a single threaded runtime and enable parallelism through other means. Or decide to pay the synchronization cost. https://maciej.codes/2022-06-09-local-async.html https://maciej.codes/2022-06-09-local-async.html
dagmx 4y ago
Yes but the point was that rust has to allow for multi threaded event loops. JavaScript can design around knowing that's not an option

ashish_negi_ 4y ago

if you write harder concurrent program in JS, single threaded event loop does not help. It still has also same concurrency problems. e.g. if there is shared global mutable state: a) in workflow 1 you have, do_some_work_on_global_state; do some IO; in IO callback, finish more do_some_work_on_global_state. b) in workflow 2 .. same like above work on global_state. Now, in IO callback, you don't know if workflow 2 ran and have to handle all possible combinations of global_state above. Replace global_state with common_state and problem still remains. If you don't have common_state between multiple workflows, then it is not a hard concurrency problem and should be easy to do in all languages.

moonchrome 4y ago
Sure it does, you don't have to manage on which thread you handle continuations (which you must in multithreaded GUI for example) - there's only one scheduler which simplifies the async API a lot. But even for concurrency - single threaded event loop/cooperative multitasking eliminates a whole class of partial state updates and synchronization primitive/locking errors - it's not even close to preemptive multitasking complexity.