6 ms·
For me the real advantage is not on performance but on the programming model. I have been tinkering with Loom (and clojure) and the idea of "just" calling some
by mping 6y ago
For me the real advantage is not on performance but on the programming model. I have been tinkering with Loom (and clojure) and the idea of "just" calling some library without worrying about blocking is refreshing. That means that for the most of it, you can write your code without worrying too much about some kind of callbacks or async support from your library and it just works.
Of course, for those with extreme performance requirements, they will probably have their own custom scheduler and concurrency/parallelism mechanisms but for the vast majority of jvm users out there I think Loom will be a great thing. If Loom integrates with GraalVM/native-image it would be even nicer.
- lackbeard 6y agoI think the vast majority of JVM users won't even need Loom. OS threads perform well enough for most use cases. You can go a very long way with just a ThreadPoolExecutor.
- closeparen 6y agoNo one “needs” Loom; you can always write in callback oriented style. The point is it will free you from that.