11 ms·
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
by islon 4y ago
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.
- krzyk 4y agoAnd saved millions of developer minds not having to deal with mind bending async/await. Thanks, I prefer to wait.
- pharmakom 4y agoDo-notation is much simpler than callback hell
- Nullabillity 4y agoYou 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.
- za3faran 4y agoGenuine 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.
- krzyk 4y agoStructured concurrency.
- Nullabillity 4y agoIt'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.
- za3faran 4y agoHow does async/await improve on managing mutable state across threads of execution (tasks/promises/etc?)
- krzyk 4y agoIssue 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.
- _old_dude_ 4y agoDuring 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.