Why IoTone chose Racket, Common Lisp, and Prolog for the AI-centric future of now

Our next generation of software tools — Telemachus, jevracket, mélangej, the Poplog revival and the pop11 Claude skill — is written in Racket, Common Lisp, and Prolog. In 2026, with the industry defaulting to Python for anything that touches AI, that choice gets questioned. This is the full answer: what we gain, what it costs, and why the costs are smaller than they look.

The division of labor

Our working pattern: prototype in Prolog, Pop-11 style; formalize in Racket or Common Lisp. Poplog hosts Prolog and Pop-11 in one image, so a rule system or a search problem gets sketched where relations are the native data type and the compiler answers in microseconds. When a design settles, it gets rewritten in Racket (where contracts, submodules, and raco make a maintainable product — Telemachus and jevracket) or in Common Lisp, where the JVM is the deployment target. The Common Lisp flagship is mélangej — a Common Lisp web framework with a JVM attitude: enterprise-level performance on a thin set of dependencies (28 jars, zero Lisp systems, which keeps security monitoring from becoming its own project), plus the Lisp workflow all the way into production — work in the REPL, hot reload, and push code at agentic speed. Its design was preceded by blow-cl, our experimental revival of a 2009 framework that proved the ABCL-on-the-JVM approach worth building on. More on mélangej in a post of its own.

What we get while we build

The REPL is the methodology, not a toy. All three languages are built around a live image you grow incrementally: redefine a function, the running system updates; raise an error, a condition handler or a Pop-11 mishap returns you to a prompt with the state intact. This has been the Lisp way of working for fifty years — and it turns out to be exactly how an AI agent wants to work too. An agent driving our pop11 skill defines a helper once, gets native code in about ten microseconds, and fires repeat tasks at it for 1–2 ms each, against the ~23 ms a fresh Python process costs. The agent’s mistakes don’t kill the session; its progress checkpoints to a ~200 KB image that restores in 8 ms. Languages designed for interactive, incremental, recoverable development were designed — four decades early — for agentic workflows.

Code is data, and agents read data well. S-expressions and Horn clauses are the two most machine-manipulable program representations ever shipped. Macros, match patterns, and Prolog’s term structure mean our tools can inspect and transform our programs without a parser project. When the “developer” is sometimes a language model, a syntax that is its own AST is a working advantage, not a curiosity.

IDE tooling is a solved problem. Every language in this stack has VSCode and Zed support (Magic Racket, ALIVE/Slyblime-style LSP clients for CL, our own Pop-11 LSP server) — plus Emacs, where the deepest integrations live: SLIME/Sly for Common Lisp, Geiser and racket-mode for Racket, and Telemachus’s own development is documented from Geiser. For pure efficiency, Emacs is the least resource-hungry of the three editors and has more features than VSCode; on the machines where we also run local models, the editor not eating a gigabyte matters.

The GPU does only GPU work. Our systems use the GPU judiciously: model inference — llama-cpp under Telemachus, Gemini in the cloud — gets the accelerator, and everything around it stays on the CPU, where symbolic workloads belong. Unification, search, parsing, rule evaluation, orchestration, and glue are branchy, pointer-chasing, irregular computations; a GPU is the wrong shape for them and a waste of its power budget. Natively compiled CPU code (SBCL, Racket CS’s Chez-derived backend, Poplog) handles that tier fast enough that the GPU queue is never blocked on the scripting layer. The result is a smaller, cheaper machine doing the same job.

The downsides, counted properly

The case against is real and we will not pretend otherwise.

The main one: smaller ecosystems and fewer developers. There is no arguing the raw numbers — Python has orders of magnitude more packages, tutorials, Stack Overflow answers, and hireable developers. Three things cut it down to size for us:

1. Documentation quality beats documentation quantity. Racket’s documentation is widely regarded as among the best of any language; Common Lisp has the HyperSpec and forty years of textbooks; Poplog’s teaching materials were written by the people who used it to teach AI at Sussex — and where the on-ramp was missing we wrote the book ourselves. A small, well-documented ecosystem is tractable in a way a vast, uneven one is not.
2. AI agents change the developer-scarcity math. The question used to be “can we hire ten Racket programmers?” It is now “can one engineer plus an agent that has read the entire corpus be productive?” — and the corpus for these languages, being decades old and stable, is thoroughly in every model’s training data. Our agents write serviceable Racket, Common Lisp, Prolog, and (with the skill’s crash course) Pop-11 today.
3. Decades of prior work is a library too. Common Lisp, Prolog, and Scheme carry the accumulated output of the first fifty years of AI research — planners, theorem provers, constraint solvers, parsers — much of it still runnable. blow-cl is a 2007 framework brought back in weeks, not years, because the substrate held.

Lack of enterprise adoption. These languages live in academia and research labs, not in Fortune 500 procurement lists; there is no vendor to call, no Gartner quadrant, no “nobody got fired for choosing it” cover. Two counters. First, that research-lab residency is a fit, not a mismatch: our focus is bleeding-edge technology, and the lab is where the bleeding edge is built — choosing the tools of the lab for lab-grade work is alignment, not risk. Second, and more practically: through ABCL our Common Lisp runs on the JVM, which means true enterprise-level platform support — the threading model, garbage collectors, profilers, monitoring agents, and twenty-five years of operations practice that enterprises already run and already trust. The language is from the lab; the platform under it is the most enterprise-adopted runtime in existence. And the Lisp tradition adds one enterprise feature most stacks can’t match: hot patching — mélangej upgrades a running image instead of restarting it, and a Poplog session checkpoints to a file and resumes where it stopped.

Library breadth, especially for AI, where Python owns everything. Our answer: so what. Python’s AI dominance is a C/C++/CUDA library catalog with Python bindings on top — NumPy, PyTorch, llama-cpp are not Python. We can wrap anything in an FFI, the same as Python does. Poplog’s exload/exacc interface gave us OpenSSL, libcurl, and SQLite shims in an afternoon each; Racket’s ffi/unsafe and CFFI on the Lisp side are mature. Where a binding doesn’t exist we write a hundred lines of shim, once — the same hundred lines the Python package author wrote.

Performance — the toughest one to battle. Toughest because the question is vague and the answer is workload-shaped. So, concretely:

• Poplog: across our measured tasks, 5–20× over CPython — the bench-skill harness has cold Python at 23.0/19.6 ms per task against warm Pop-11 at 1.4/1.6 ms, and the book’s benchmark chapter prints the full table, including the one row Python wins.
• Racket: on the Computer Language Benchmarks Game’s Racket–Python page (archived — the live site has since dropped Racket), Racket entries run from near parity on string-heavy tasks to roughly 20× faster on numeric ones (3.9 s against 91 s on one task); the community’s working rule of thumb is about 5× on number crunching, parity on string-dominated code. Since Racket 9.0’s parallel threads, real shared-memory parallelism is in the picture too.
• Common Lisp: we can quantify this one with our own framework, mélangej — ABCL on Jooby and Netty — whose performance chapter publishes the full six-server benchmark with a re-runnable harness. Compiled to JVM bytecode, mélangej is the fastest of the three Lisps measured: 1.5× Hunchentoot and 1.9× ningle/Clack on throughput, and the cheapest per request at 1.50 CPU-ms against 2.02 and 2.39 — ABCL on the JVM beats SBCL’s native code on this workload, because the workload is string building and the JVM is very good at it. On static content it is within 4% of plain Java (the Lisp is not in the path), and crossing from Netty into ABCL costs 0.026 CPU-ms — noise. SBCL itself remains a fine engine with fast startup (a saved core boots in 27 ms) and, compiled, middle-of-the-pack throughput behind Hunchentoot; its limits are little control over CPU pinning and locking discipline, though threads exist and work. The gap to native code is also stated plainly on that page — 15× behind Java, 31× behind Rust on dynamic rendering — and the chapter prices exactly where it is paid (rendering, not dispatch) and what compilation buys (3.5× over interpreted, with the whole tree compiling in 1.2 seconds).

The pattern across all three: for the symbolic, server-side, orchestration-heavy work these tools do, performance is a point in our favor, not a concession.

Where each ecosystem is going

• Racket is in its most active stretch in years: 9.0 (November 2025) shipped parallel threads as the headline feature; 9.1 (February 2026) added language-family documentation navigation, built for Rhombus, the parallel surface syntax the core team is developing; 9.3 (August 2026) brought Markdown documentation generation and expansion speedups. The direction is clear: more parallelism, and a path for new syntaxes over the same proven runtime — which suits a company that formalizes prototypes into #langs.
• Common Lisp: SBCL ships monthly, and 2026’s releases show where it’s pointed — SB-SIMD on ARM64, AVX-512 on x86-64, faster UTF-8, and SB-MANUAL putting the manual into docstrings for in-image exploration (an agent-friendly move, whether intended or not). ABCL moves slowly (1.9.x) but deliberately, and its value to us is less its own velocity than the JVM’s: every JVM improvement — threading, GC, Netty — is an ABCL improvement, which mélangej’s numbers demonstrate.
• Prolog and Pop-11: ours is the Poplog variant, and that roadmap is one we hold the pen on — four platforms including riscv64, monthly skill releases, native shims for the modern essentials, and the agent tooling (MCP, LSP, saved-image checkpoints) that makes a 1980s AI workbench a 2026 one. Prototyping stays here; the formal versions graduate to Racket and Lisp.

The bet, stated plainly

We are betting that in an AI-centric present, the scarce resources are machine efficiency, interactive development, and manipulable programs — not package count or the size of the hiring pool. Racket, Common Lisp, and Prolog are the languages that spent fifty years optimizing for exactly those three things while the industry optimized for the other two. The agents arrived, the compute bill arrived, and the old bet started paying out.