undefined | Better HN

0 pointstybit5y ago0 comments

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.

0 comments

3 comments · 1 top-level

jayd165y ago· 2 in thread

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.

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

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

1 more reply

j / k navigate · click thread line to collapse