[NightMKoder]

I haven’t tried this framework, but just looking at some examples, the web sockets and sse seem a bit out of place. In a Loom world you’d expect these to use channels or queues or something similar in a loop - not callbacks. Callback hell is what virtual threads try to avoid. I’m not sure if loom has any primitives like go’s multi-channel select that might make this workable though.

In either case Loom and frameworks that use it are super exciting! I’m looking forward to removing the 20 different thread pools we need to avoid deadlocks and just using the common one in our Clojure apps.

[uup]

Having recently implemented a WebSocket service in Go, the Javalin way seems preferable. This is what a similar Go version would look like:

    wsHandler := func(w http.ResponseWriter, r \*http.Request) {
        conn, err := upgrader.Upgrade(w, r)
        if err != nil {
            w.SendStatus(http.StatusInternalServerError)
            return
        }

        ctx, ctxCancel := context.WithCancel(context.Background())
        var wg sync.WaitGroup

        wg.Add(1)
        go func() {
            defer sync.Done()

            for {
                msg, err := conn.ReadMessage()
                if err != nil {
                    return
                }
            }
        }()

        msgPipe := make(chan []byte, 1024)
        wg.Add(1)
        go func() {
            defer wg.Done()
            for {
                select {
                case <-ctx.Done():
                    return
                case msg := <- msgPipe
                    if err := conn.WriteMessage(msg); err != nil { return }
                }
            }
        }()

        go func() {
            <- ctx.Done()
            wg.Wait()
            close(msgPipe)
        }()
    }

I like Go, but I found writing WebSocket code very annoying.

[pron]

We don't have selectable channels yet, but they're not needed as much in Java as they are in Go, because often multiple channels are used to signal cancellation, whereas in Java there's a standard mechanism for cancellation (Thread.interrupt() at the low level, with Future.cancel being higher level, and JEP 428's structured concurrency being higher level still https://openjdk.org/jeps/428).