4 ms·
C# dev here so please forgive my ignorance. Is it fair to say that Loom intends to build a more efficient and transparent async/await system for the JVM?
by xanth 5y ago
C# dev here so please forgive my ignorance. Is it fair to say that Loom intends to build a more efficient and transparent async/await system for the JVM?
- Skinney 5y agoI guess it would be fair to say that Loom brings the benefits of async/await without any change in language syntax, and by being compatible with your run-of-the-mill threads
- jayd16 5y agoYou're going to have a lot of replies that simply say yes but they're different tools and they have different use cases. The implicit threading of Loom works well for things like transparently dealing with IO without blocking an OS thread. For things like posting back to a UI thread, you'll still need explicit handling not unlike async/await. It seems like Java is taking a scoped approach. https://wiki.openjdk.java.net/display/loom/Structured+Concurrency https://wiki.openjdk.java.net/display/loom/Structured+Concur...
- marwis 5y agoIt says that you can implement your own scheduler for virtual threads so presumably you can make one that schedules back to UI loop.
- pjmlp 5y agoLoom avoids the coloured issue where we have to do Task.Run(() => ....) to avoid polluting the whole call stack with async Task<T>.