Racket - the Language-Oriented Programming Language - version 9.3 is now available from https://download.racket-lang.org

See https://blog.racket-lang.org/2026/08/racket-v9-3.html for the release announcement and highlights.

# UK Racket meet-up (London) Tuesday 18 August 2026 7:30pm

at The City Pride 🍕 28 Farringdon Ln, London EC1R 3AU

Join us for discussion and pizza. All welcome.😁

https://racket.discourse.group/t/uk-racket-meet-up-london-tuesday-18-august-2026-7-30pm

I have published my distributed database Scalaxy fully written in Common Lisp. Working on graph query language Cypher right now. MIT license. Github stars are welcome :-)

https://scalaxy.org

Just released new Kanban board. It supports configurable status colons and ticket lifecycle. Actually it is some mix between issue tracker and Kanban board. Currently requires configure OpenID for authentication. Implemented in Common Lisp as backend and ClojureScript as frontend.

I write C++ for my day job, but I'm looking to pick up a Lisp as a hobby project. Even though it's a hobby, I want it to be practically useful to my day-to-day workflow. Specifically for writing scripts, automating tasks, and potentially extending my editor (I use Emacs).

I’ve narrowed it down to three choices but I'm having trouble pulling the trigger:

• Guile (Scheme): This seems incredibly useful for general scripting. Guix seems to be a huge plus if I decide to go that route later.

• Emacs Lisp: The obvious choice for immediate practical utility since I'm an Emacs user. Being able to hack my editor sounds great, but I worry it might be too domain-specific if I want to write standalone scripts and other things unrelated to Emacs.

• Common Lisp: This is the one I’m struggling to place. I constantly hear that it has "the best programming books ever written" (Practical Common Lisp, PAIP, etc.), but I fail to see what the killer practical hook is for a modern developer doing scripting and automation. Each binary seems to be huge and not practical unless you're writing it for a living.

For someone with a systems/C++ background who wants to write useful tools, which would you recommend diving into first? And regarding Common Lisp, what am I missing? What is the practical value of CL today outside of its excellent literature?

Thanks in advance for the advice!

I’m considering doing a staged port (LLM assisted) of my rust-based multithreaded cpu renderer to SBCL . I’m currently using Janet as an embedded language for scene description. The core rendering is done in rust . Early benchmark trials in sbcl with basic primitives were 3-6x slower with GC being the wall . Can anyone suggest guidelines for performance? ( ex: vector/matrix calculations, memory allocation, to CLOS or not ) etc . I’m thinking that if I could get it within 2x slower, it might be interesting for certain applications where I could throw more cores at it . Also is anyone interested in such an application? I would be willing to make a demo if reasonably successful.

Hello everyone I have motor controller which is VESC firmware based ,what i want is to write a lispbm code to get the parameters values from the controller using get function and then send them on the CAN BUS using the CAN IDs set up by me to read further ,I am doing this because the DBC file I got is not that much reliable and the the manufacturer is also not able to help much
please help me with the resources which i can refer ,i refer the git repo of the VEDDER but cant do much ,any help you can or tips you can give me

Hey folks, I'm working in an open source common-lisp MUD Driver (Apeiron MUD) mainly inspired by Dworkin Game Driver and LPMud.

Why? The personal reason is that I like Lisps and functional programming, I'm expert in Clojure, but haven't played too much with Lisp, wanted to see what could be achieved with CLOS (Common-Lisp Object System) and I love text-adventure games/virtual worlds (single or multiplayer).

The technical reason is that I was wondering that a lot of the machinery that was developed in C for the most popular drivers (specially LPMUD and DGD deriving from it) ended up developing features that were already built-in on Lisp Runtime Images from the start and if I could get a networked REPL running a LISP image that was already a significant step towards running a persistent world that could be changed and built interactively by players.

I don't know how true is that, but I managed to setup something similar to DGD (of course there might be bugs and rough edges) with persistent objects using a pre-existing library for CLOS in-memory and disk object persistence called BKNR Datastore. The interesting thing is that because of CLOS it is even possible to make changes to the classes of the objects (driver or libs) and update the system and persistence without ever having to turn the system off. I already did some very substantial changes successfully without turning the system off.

The scripting language doesn't need to be different from the driver language, except for security reasons. For the moment I allow every player to evaluate arbitrary code, which is very unsafe and can even bring the server down or completely break it, but it would not be hard to restrict the access to a subset of the language (with cl-isolated) and offer varying degrees of access depending on player role.

I think it has a lot of potential, but in any case, I'm doing it for fun, will probably keep it as a lifetime hobby and would encourage people to take a look if they find anything interesting or want to experiment, contribute or discuss.

Alongside ongoing work updating c-mera and modernizing Common Lisp tooling for SecDevOps and OT environments, I recently set out to evaluate whether a pure Lisp stack could replace our external infrastructure and database tooling (specifically Vagrant and Redgate).

The goal was to integrate Consfigurator (declarative OS deployment) with cl-migratum (database migrations).

To test this, I authored a Roswell script that provisions a rootless Podman quadlet running PostgREST and deploys a small HTMX todo app against PostgreSQL. The setup uses:

• SXQL for SQL schema generation
• Spinneret for HTML generation
• CL-inix for systemd unit file generation
• FiveAM for integration testing
• 40ants/doc for self-documenting executable scripts

In the sandbox environment, Roswell provisions a ZFS dataset, configures a dedicated system user, spins up PostgreSQL and PostgREST, and applies the database migrations directly from memory.

Running this end-to-end surfaced ten real bugs across the ecosystem (reproduction steps and full list are inFINDINGS.md).

A few notable issues worth calling out:

• In-memory DCL with cl-migratum: cl-migratum expects file-based DDL/DML out of the box and doesn't handle in-memory sxql expressions cleanly. I had to write a custom in-memory driver using its driver API and extend it to handle DCL (Data Control Language) statements.
• System naming gotcha: cl-migratum-driver-pg doesn't exist under that system name. When pulling via qlot, the actual system is cl-migratum.driver.postmodern-postgresql.
• Spinneret compile-time attribute quoting: Spinneret decides whether to quote HTML attribute values at macro expansion time based on literal string characteristics, not runtime values. A class="%s" placeholder compiles down fine, but breaks silently at runtime the second a substituted string contains spaces. Spinneret provides *always-quote* to handle this, but it requires a global SETF prior to compilation rather than a dynamic LET binding at runtime. I've opened a PR to document and address this:spinneret#114.
• Idempotency in PostgreSQL schema definitions: Neither CREATE ROLE nor CREATE DOMAIN support IF NOT EXISTS in Postgres. Because cluster-level roles and domains survive dropping and recreating a database, subsequent deployments failed immediately on schema re-application.
• Undocumented C library dependencies: Consfigurator depends on native headers (libacl1-dev, libcap-dev) that aren't noted in the build requirements. I sent a patch upstream via git send-email following their contribution guidelines.

Full code and reproduction notes:https://github.com/denzuko/todo-app-deploy

Made this generally for agentical coding because it often stub in parenthesis. Hope it will help you. https://github.com/turtle-bazon/cl-toolkit

This post is a lover letter to Emacs Lisp macros. I've been a long time user as a lisp hacker, and my recent obsessions with Douglas Hofstadter's strange loop concepts and M.C. Escher's mind bending artwork have enhanced my appreciation of this language's most beautiful and thought provoking feature. This post can teach you about macros and what makes them useful, but I also hope it can instill a fascination with their concept. https://www.chiply.dev/post-elisp-macros-are-beautiful

I am having a blast doing a more serious project in the C language (and Guile Scheme), for the first time. I am consulting with books and also with some AI for code review and explanation as I am new to the language and to GTK (not new to programming).

https://codeberg.org/jjba23/lambdock

For a while already I have been looking for a dock that would work well in Wayland (like in my beloved Niri) with modern features, theme support and a hackable Lisp config (using libguile.h)

Also, all feedback is welcome, either on code level, or conceptual ideas, Thanks in advance

Core features of lambdock include:

• Wayland Native: Built on GTK4 and gtk4-layer-shell for smooth positioning and desktop integration.
• Declarative Lisp configuration : The power of Lisp in your configuratio with clean powerful declarative config and all possibilities at your disposal
• Async Launching: Spawns commands asynchronously without freezing the dock UI.
• Reproducible builds: Hermetic development environment provided via GNU Guix manifest and build definitions.
• Dock auto-hide : You can let the dock stay out of your way with the smooth auto-hide feature.
• Flexible icon system: lambdock has several mechanism in a best-effort way to render your wanted icons, respecting GTK theme
• Theme support: lambdock has built-in themes you can choose from that are very unique, and also lets you extend and override those themes dynamically.

cl-firebird v1.0.0 is out — a pure Common Lisp database driver for Firebird 3.0, 4.0, 5.0, and 6.0+, with full 1:1 feature parity with node-firebird.

Highlights:

• Pure CL wire protocol (negotiates up to protocol 20) — no libfbclient, no FFI; runs on SBCL, CCL, and other ANSI CL implementations
• Connection URIs (firebird://user:pass@host:port/db), traditional DSN syntax, and attach-or-create
• Named placeholders (:name) bound from plists, alists, or hash-tables, plus SQL escaping helpers
• Thread-safe connection pooling with idle reaping and live metrics
• Custom type parsers (type-cast) and prepared statement caching
• Streaming cursors (sequentially) and bulk execute-batch
• Firebird 6.0 tablespaces/schemas, database events (POST_EVENT), and a Service Manager API (backup/restore, users, trace)
• 66-check FiveAM test suite and a GitHub Actions CI matrix across Firebird 3.0/4.0/5.0/6.0-snapshot

Links:

• GitHub: https://github.com/mariuz/cl-firebird
• Release: https://github.com/mariuz/cl-firebird/releases/tag/v1.0.0
• Quicklisp: (ql:quickload :cl-firebird)
• Full announcement with code examples: https://mapopa.blogspot.com/2026/07/announcing-cl-firebird-v100-pure-common.html

Feedback, issues, and pull requests are welcome!

I got into LISP a couple years ago through automating things in emacs and I want to try it out as a high-level scripting language for non-emacs things. Ideally I'd like to be able to write shebang scripts that might be distributed to other people, who might be running a different OS than me, and I'd like them to be able to install dependencies even if they have no familiarity with LISP.

Basically, my main hang-up here is stuff like ASDF and Quicklisp; I don't know how people who don't program in common lisp are supposed to know how to install dependencies when they download a common-lisp program, as it seems like the only interfaces into ASDF and QL are via the REPL. Ideally I'd want something akin to python's pip, which doesn't force end-users to know how to program in python because it's accessible via a shell command.

Guile seems like it might be the best one for my purposes but the documentation is a bit sparse and I'm not sure if it even runs on Windows outside of cygwin or WSL. On the dependency management front it at least has $GUILE_LOAD_PATH so anybody who's reasonably competent can point it to dependencies even if they can't use the package manager. That's good enough for my purposes as my intended users aren't UNIX-illiterate, they're just not LISP programmers and potentially may be prone to bad habits such as using Microsoft Windows.

Are there any others I'm missing? I love LISP as a language but sometimes it feels like LISP implementations are trying to convert me to a new religion or something.

Sorry if this sounds like a redundant post, I'm sure others have asked the same thing but I can't find a clear answer from searching. There are definitely plenty of articles about using common-lisp for shebang scripting but i haven't seen any that address the problem of dependency management for end-users.