cl-gserver VS Common-Lisp-Actors

> static strong typing

Alright, here is it: https://github.com/coalton-lang/coalton/

> small efficient native binaries

The numbers are: with SBCL's core-compression, a web app with dozens on dependencies will weight ±30 to 40MB. This includes the compiler, the debugger, etc. Without core compression, we reach ±150MB.

> The actor runtime?

the actor library: https://github.com/mdbergmann/cl-gserver

> couldn't find a way to make money with it. I suspect many other programmers are in my boat.

Alright. Some do, that's life. Yes, some companies go with CL even in 2023 (https://lisp-journey.gitlab.io/blog/lisp-interview-kina/, they released https://github.com/KinaKnowledge/juno-lang lately; Feetr (finance): https://twitter.com/feetr_io/status/1587182923911991303)

https://github.com/azzamsa/awesome-lisp-companies/

> Give us an HTTP (1.x & 2.0) and WebSockets libraries

How so? We have those libraries. HTTP/2: https://github.com/zellerin/http2/

https://github.com/CodyReichert/awesome-cl

It's nice to see the CL ecosystem evolving. SBCL sees regular updates with new optimizations. The editor support is getting better: [Vim, Atom, Sublime, VSCode… have good to very good support](https://lispcookbook.github.io/cl-cookbook/editor-support.ht...), & Jupyter notebook, the Lem editor… and a new lisper started a CL editor based on Tauri: [Parrot](https://github.com/fonol/parrot). Cool projects emerge ([lisp-stats](https://github.com/Lisp-Stat/lisp-stat/), the [Sento / cl-gserver](https://github.com/mdbergmann/cl-gserver) actors library, the Kons-9 3D graphics library, the CLOG web-gui…)

> 50MB

With compression (zstd now), SBCL binaries weigh ±25MB. Start-up time is super fast. I built a standalone binary for my web app, it is straightforward to start it on the background and access it from an Electron window.

what's nice in CL is that we can choose. We have a nice actor-style library now (https://github.com/mdbergmann/cl-gserver).

You might be interested in cl-gserver0.

Version 1.9 of cl-gserver adds low weight timeouts for async ask operations with the help of timer wheels. https://github.com/mdbergmann/cl-gserver

Have a look at the tests here: https://github.com/mdbergmann/cl-gserver/blob/master/tests/hash-agent-test.lisp

I have seen cl-gearman used in the wild (for example for Ultralisp), there is lfarm (distributing work across machines, on top of lparallel and usocket), "jobs" and "workers" makes me think cl-gserver (Erlang-inspired GenServer, actors pattern)… not really answering, throwing ideas in case you didn't see them, and furnish this discussion a bit :]

There are very, very competent concurrency libraries already. I pointed you to them already. They serve as primitives to roll your own solutions -- You can get most of the functionality of Erlang actors (and virtually all of the important parts regarding concurrency) with threading (green or OS), CSP channels, and writing a few macros. Go look at a lot of the actor libraries you mentioned that are "long dead" and you'll notice they do A LOT with just a few hundred lines of code. This one gets basic functionality with just straight threading primitives in 131 lines.

As an alternative I was considering actors, f.ex. https://github.com/naveensundarg/Common-Lisp-Actors ,which seems simple enough. But the actor paradigm seems to require that all my code lives in actors. While I could make an actor that receives a message from the websocket listener when a message is incoming, it's a bit of a cumbersome setup compared to the linear looking code above. Since the message coming in will be decoupled from the request asking for the data, so it feels awkward. But maybe I'm thinking about it all wrong.