That is very interesting! I was listening to a podcast recently all about helidon/nima. Sounds very exciting!

it's a very interesting project indeed. There are a few others kicking the tires of loom (ex vertx) but nima is a fresh take on it and they have big goals. Plus the fact it's built by oracle (with access to loom devs directly) is quite encouraging.

glad to see it! Do you have plans to add support for WebSockets?

Yes that will come next

http-kit’s api there is something to maybe take inspiration from, I find it nice & simple

Http kits API has problems with back pressure iirc?

@U09LZR36F It does? That’s good to know. Although, is it a problem with the API or the implementation of it? I think @U5H74UNSF maybe means the UI, rather.

I think it wasn't possible to solve because of the API

Ah, interesting.

@U11EL3P9U Sounds interesting, could you share the podcast/episode?

@U06B8J0AJ sure, here you go

That was an interesting podcast. I’ve seen different opinions on the impact of native green threads on Clojure here and there. Some seem to mean that core.async is enough, and that this will have no impact on us. That seems a little dubious for me. Clojure has always tried to tap into the underlying platform where possible, and ignoring the most monumental shift in the JVM for a long, long time would be shortsighted imo. Nevertheless, I suppose we’ll end up exposed to it one way or another anyway, regardless of core.async, via libraries like this one, or via the new incarnation of Jetty etc,

core.async will still be relevant, loom doesn't give you (by itself) any way to do some tricky composition with fibers. There's "Structured Concurrency" but it's still in flux I think (haven't look at it in a while), think about the kind of stuff we do now with alt! and channels in general. So I think we're more likely to see some level of integration with loom in core.async (a/thread variant, re-implementation of go or go variant based on it, stuff like that).

Loom and and the JVM green threads aren’t the same thing, though. I understand Loom as basically a structured concurrency solution on top of the JVM green threads, so essentially an alternative to core.async. I guess I may have misinterpreted the online discussions if those were talked about interchangeably.

"structured concurrency" has a strong meaning. vthreads is one thing, and sc a continuation of the work to allow to use vthreads (& co) with the common patterns we use in the "async" world, (err handling, tasks interruptions etc). They are actually 2 different jep that make loom (so far)

Yeah, this is why I feel like green/virtual threads is a “wow” moment for the JVM, while my impression of Loom so far is kind of “well, nice for Java users!”

I don’t really know that this is true, but I feel like interoperability should better when green thread solutions speak the same low-level language, essentially, rather than relying on custom solutions for each implementation. It seems like they have something coming to stop file system operations from hogging the underlying OS thread (I wasn’t even aware that this was an issue previously). I’m guessing that this will presume JVM-native green threads though.