3 ms·

They mostly solve the same problems, albeit in very different ways. Loom is primarily about making threads cheaper, async await is primarily working around thre

by tybit 6y ago

They mostly solve the same problems, albeit in very different ways. Loom is primarily about making threads cheaper, async await is primarily working around threads being too expensive.

jayd16 6y ago
Implicit scheduling like Loom doesn't solve the problem of working with thread based synchronization such as what you often see in UI. You want a paradigm that lets the user easily define what runs on the main/ui thread and what runs else where. Loom's goal is implicit suspension without thinking about threads. Its a different use case. Backend engineers seem unaware of the problems async/await solves.
- thu2111 6y ago
  Using coroutines on a UI thread is a recipe for horrible bugs. I've done it, I wouldn't do it again unless I had to (i.e. all JS in the browser is forced to work this way so there it's pointless to resist). The right approach is what JavaFX or Swing do: make it easy to schedule a lambda onto the UI thread from any background thread. Whilst that lambda executes, events are not dispatched. Where things get painful is where you try to make a single chunk of code look blocking whilst it's actually not. The user can insert arbitrary events into the middle of your code the moment you do an 'await' and you have to plan for that. In practice, I've not found the typical UI toolkit paradigm to ever be a problem. If your UI starts to stutter, it's time to move something to a background thread. It forces you to admit that the UI and work are genuinely running in parallel and consider cancellation semantics, work/results handoff, etc. And of course you properly use multi-core systems.
  - jayd16 6y ago
    To some degree its a style choice but most (all?) of the languages used for UI use some kind of the UI thread paradigm with a way to run code on and off of that thread. Not everything called a coroutine is designed for UI interaction. Kotlin's are better suited than Goroutines. As you admit your self, js and others have settled on this style and one has to assume its for a good reason. Async/await solves the problem of posting execution to another thread, getting a result, and easily and efficiently waiting for that result on exactly the thread you need. It'll be interesting when or if someone uses Loom in the UI space.
    - thu2111 6y ago
      With JS the reason isn't really all that good - it's because it's expensive and difficult to make JavaScript and browser engines thread safe (or any dynamic scripting language). If it's hard to make the language genuinely multi-threaded then you end up stuck with callbacks and a standard library that uses a totally broken design to try and be as single-threaded as possible. It's basically Windows 3.1 all over again, but in 2021 instead of 1991. Quite sad :( Async/await in the browser at least is unrelated to threading (unless you mean hypothetical helper threads inside the browser). You don't get any choice about where the handle the callback. It's always on the single rendering thread.

by tybit 6y ago

They mostly solve the same problems, albeit in very different ways. Loom is primarily about making threads cheaper, async await is primarily working around threads being too expensive.

jayd16 6y ago

Implicit scheduling like Loom doesn't solve the problem of working with thread based synchronization such as what you often see in UI. You want a paradigm that lets the user easily define what runs on the main/ui thread and what runs else where. Loom's goal is implicit suspension without thinking about threads. Its a different use case. Backend engineers seem unaware of the problems async/await solves.

thu2111 6y ago
Using coroutines on a UI thread is a recipe for horrible bugs. I've done it, I wouldn't do it again unless I had to (i.e. all JS in the browser is forced to work this way so there it's pointless to resist). The right approach is what JavaFX or Swing do: make it easy to schedule a lambda onto the UI thread from any background thread. Whilst that lambda executes, events are not dispatched. Where things get painful is where you try to make a single chunk of code look blocking whilst it's actually not. The user can insert arbitrary events into the middle of your code the moment you do an 'await' and you have to plan for that. In practice, I've not found the typical UI toolkit paradigm to ever be a problem. If your UI starts to stutter, it's time to move something to a background thread. It forces you to admit that the UI and work are genuinely running in parallel and consider cancellation semantics, work/results handoff, etc. And of course you properly use multi-core systems.
- jayd16 6y ago
  To some degree its a style choice but most (all?) of the languages used for UI use some kind of the UI thread paradigm with a way to run code on and off of that thread. Not everything called a coroutine is designed for UI interaction. Kotlin's are better suited than Goroutines. As you admit your self, js and others have settled on this style and one has to assume its for a good reason. Async/await solves the problem of posting execution to another thread, getting a result, and easily and efficiently waiting for that result on exactly the thread you need. It'll be interesting when or if someone uses Loom in the UI space.
  - thu2111 6y ago
    With JS the reason isn't really all that good - it's because it's expensive and difficult to make JavaScript and browser engines thread safe (or any dynamic scripting language). If it's hard to make the language genuinely multi-threaded then you end up stuck with callbacks and a standard library that uses a totally broken design to try and be as single-threaded as possible. It's basically Windows 3.1 all over again, but in 2021 instead of 1991. Quite sad :( Async/await in the browser at least is unrelated to threading (unless you mean hypothetical helper threads inside the browser). You don't get any choice about where the handle the callback. It's always on the single rendering thread.