Hacker News Reader

Comment by islon | Hacker News Reader

I guess he's talking about project loom (fibers, go style concurrency) which IMHO is a much better solution than async/await, but yeah... took some 10 years to arrive.

View on HN

During the last 10 years, the Java ecosystem has heavily invested in reactive APIs, so it's not like if Java devs have no option.

And IMO, the semantics of any reactive APIs is better than just providing await.

Await serializes the async calls instead of running them concurrently. And too few C# devs are aware of/using the Task API.

And saved millions of developer minds not having to deal with mind bending async/await.

Thanks, I prefer to wait.

Do-notation is much simpler than callback hell

You could have had the Loom experience 20 years ago by just spawning OS threads. Of course, there's a reason that this was discouraged... threads quickly turn into a nightmare to manage safely, especially when they need to interact.

Genuine question, how is managing cross interacting virtual threads any different or easier than managing interacting threads? I say this and I am greatly looking forward to using Loom in production. It's definitely the correct way to go as opposed to async/await.

It's not. That's the problem with the thread API that Loom is so dead set on preserving, and the big improvement that promises/async/await provide over threads.

How does async/await improve on managing mutable state across threads of execution (tasks/promises/etc?)

Structured concurrency.

Issue with os threads is that their number is limited. Not the issue with communication. Futures are good enough for that, if you need more then structured concurrency.

Reply on news.ycombinator.com