juno-lang
cl-gserver
| juno-lang | cl-gserver | |
|---|---|---|
| 4 | 12 | |
| 120 | 192 | |
| 0.0% | - | |
| 9.2 | 8.0 | |
| about 1 month ago | about 1 month ago | |
| HTML | Common Lisp | |
| GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
juno-lang
-
All Web frontend lisp projects
There was one posted here recently, Juno
-
Why Lisp?
> 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
- Juno and Seedling – self-hosted in-browser Lisp and self-contained IDE
- Juno and Seedling - a self-hosted Lisp that runs in the Browser (or compiled to an executable) with a self contained Lisp based IDE
cl-gserver
-
Why Lisp?
> 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
- Sento: Actor Framework for Common Lisp
- Sento actor framework 3.0 released - no new features, many API changes: cleanups, obstacles removed, and hopefully a more consistent way of doing things.
- New version of the Sento Actor Framework released with a few new goodies in future handling. Nicer syntax and futures can now be mapped.
-
Between Two Lisps (2020)
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.
-
LEM - What If Emacs Was Multithreaded
what's nice in CL is that we can choose. We have a nice actor-style library now (https://github.com/mdbergmann/cl-gserver).
-
Moving from the BEAM to Common Lisp: What are my concurrency options?
You might be interested in cl-gserver0.
-
Low weight timeouts async `ask` operations
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
-
CL hash-table thread-safety
Have a look at the tests here: https://github.com/mdbergmann/cl-gserver/blob/master/tests/hash-agent-test.lisp
-
Curiosity: scheduler choices for lispy microservice architecture.
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 :]
What are some alternatives?
ptpython - A better Python REPL
Common-Lisp-Actors - An actor system for Common Lisp.
awesome-cl - A curated list of awesome Common Lisp frameworks, libraries and other shiny stuff.
opendylan - Open Dylan compiler and IDE
green-threads - A lightweight thread / cooperative multitasking library for Common Lisp.
Akka.net - Canonical actor model implementation for .NET with local + distributed actors in C# and F#.
http2 - HTTP/2 implementation in Common Lisp
lfarm - Distribute work across machines using the lparallel API.
s2 - A data-binding function for the DOM.
core.match - An optimized pattern matching library for Clojure
lisp-stat - Lisp-Stat main system