3 ms·

I'd kill for common lisp with transparent green threads. It would be so great. As you noted once you use them you can never really go back. Of course, it will n

I'd kill for common lisp with transparent green threads. It would be so great. As you noted once you use them you can never really go back. Of course, it will never happen because it can only be done in the compiler/runtime, not in a library, and the standard is frozen in stone, so that's that. I've got some hope for clojure with that at least, thanks to it being jvm hosted.

bcrosby95 3y ago
Hope no more - Java 21 will have virtual threads: https://openjdk.org/projects/jdk/21/ https://openjdk.org/projects/jdk/21/ Speaking of, I have yet to test how agents with virtual threads perform vs core.async for my use cases.
varjag 3y ago
Back in the 1990s the usual in CL implementations was green threads. Everyone kinda wished for POSIX threads support instead, which was eventually gained on most runtimes. You can still see the glimpse of them as atavisms in old code and documentation.
- Blackthorn 3y ago
  I indeed saw this years ago mentioned in clozurecl's documentation. I was very upset that all the support for it got ripped out of the language, because as shown with https://blog.linuxplumbersconf.org/2013/ocw/proposals/1653 https://blog.linuxplumbersconf.org/2013/ocw/proposals/1653 (which inspired what is now making its way into Java) this is the way to go for performant solutions with very very high thread counts.
  - varjag 3y ago
    shrug I personally hate cooperative multitasking, and so far never ran into a problem that couldn't be scaled with system threads and use of select/poll. But am sure Google sees its uses.
    - pdimitar 3y ago
      Web backends. BEAM VM's green threads work excellently for it, you can handle bursty workloads transparently and all you will pay for it is slightly increased latency (and I really mean slightly). I know, many people claim Ruby [on Rails] and Python [Django] do the same but I've seen APM dashboards of such projects and those of Elixir [Phoenix] and Golang [various, most recently GoFiber] apps and the difference is pretty stark. But if you mean the golden path of select/poll then yeah, hard to beat those on their own turf of course.

bcrosby95 3y ago

Hope no more - Java 21 will have virtual threads: https://openjdk.org/projects/jdk/21/ https://openjdk.org/projects/jdk/21/ Speaking of, I have yet to test how agents with virtual threads perform vs core.async for my use cases.

varjag 3y ago

Back in the 1990s the usual in CL implementations was green threads. Everyone kinda wished for POSIX threads support instead, which was eventually gained on most runtimes. You can still see the glimpse of them as atavisms in old code and documentation.

Blackthorn 3y ago
I indeed saw this years ago mentioned in clozurecl's documentation. I was very upset that all the support for it got ripped out of the language, because as shown with https://blog.linuxplumbersconf.org/2013/ocw/proposals/1653 https://blog.linuxplumbersconf.org/2013/ocw/proposals/1653 (which inspired what is now making its way into Java) this is the way to go for performant solutions with very very high thread counts.
- varjag 3y ago
  shrug I personally hate cooperative multitasking, and so far never ran into a problem that couldn't be scaled with system threads and use of select/poll. But am sure Google sees its uses.
  - pdimitar 3y ago
    Web backends. BEAM VM's green threads work excellently for it, you can handle bursty workloads transparently and all you will pay for it is slightly increased latency (and I really mean slightly). I know, many people claim Ruby [on Rails] and Python [Django] do the same but I've seen APM dashboards of such projects and those of Elixir [Phoenix] and Golang [various, most recently GoFiber] apps and the difference is pretty stark. But if you mean the golden path of select/poll then yeah, hard to beat those on their own turf of course.