Steel Bank Common Lisp

Original Article ↗ Hacker News Discussion ↗

Why this submission / SBCL vs other Lisps

  • Some question why SBCL’s homepage is on HN without context, noting it’s a long‑standing project.
  • Others point out there are monthly SBCL releases and ongoing work.
  • SBCL is praised for performance; Embeddable Common Lisp is highlighted as better for embedding, mobile, lightweight hardware, and browser use.

New parallel GC and production issues

  • A migration to SBCL’s newer “parallel-ish” garbage collector shows mixed results: apparent performance gains but also a serious slowdown and a crash from heap exhaustion.
  • Discussion suggests Immix-style GC compacts infrequently, so fragmentation can cause failures even well under the configured heap limit.
  • For workloads mixing short- and long-lived objects, the older copying GC may reduce fragmentation at the cost of longer pauses; dedicated arenas by object lifetime are proposed as a more involved solution.
  • Some reports of outright crashes on the new GC and questions about how well SBCL can detect low-heap conditions.

HN’s move from Racket to SBCL

  • HN originally ran Arc on Racket; large threads were paginated because performance couldn’t handle huge pages.
  • Porting Arc to SBCL removed the need for pagination and greatly improved responsiveness and stability under growing load.
  • An explanation is given for why Racket CS didn’t help: Arc relies on mutable cons; Racket’s immutable/mutable cons representation changed between BC and CS in ways that hurt performance.

Arc-on-SBCL (clarc) and vertical integration

  • HN uses a custom Arc implementation on SBCL (“clarc”), distinct from public Arc-on-SBCL projects.
  • The stack is tightly integrated: language, implementation, and application evolve together, which simplifies development but makes open-sourcing clarc harder and more invasive, especially given HN-specific features and partial language support.

Name, history, and bootstrapping

  • “Steel Bank” references Carnegie (steel) and Mellon (bank), reflecting SBCL’s descent from CMUCL.
  • A second, informal expansion is “Sanely Bootstrappable Common Lisp,” emphasizing that SBCL can be built from multiple Common Lisp implementations, unlike its ancestor.

Tooling, IDEs, and commercial Lisps

  • Many focus on SBCL + Emacs and then complain about tooling; others argue Emacs is simultaneously powerful and painful.
  • Commercial implementations (LispWorks, Allegro) are noted for features such as small standalone binaries, a cross-platform GUI toolkit, mobile runtimes, a Java interface, and rule-based systems, but their licenses and pricing limit casual use.
  • Their IDEs receive mixed reviews: some users find LispWorks acceptable (especially with community plugins), others find both products’ editors dated compared to modern environments.
  • A JetBrains plugin for Common Lisp has been revived, advertised as an option for users who prefer mainstream IDEs; Emacs loyalists push back humorously.

Type system limitations and Coalton

  • SBCL is praised for strong type checking among CL compilers, but its type system is seen as too weak in practice:
    • No way to specialize list element types, which hurts both checking and optimization.
    • Declaiming types everywhere shows how vague they remain compared to languages with richer static types.
  • Some argue CL implementations should be bolder in extending the standard (e.g., recursive types, typed hash tables, typed CLOS slots), even if this deviates from ANSI CL.
  • Coalton is mentioned as a Haskell-like, statically typed language layered on Common Lisp and optimized for SBCL, but it requires explicit wrappers or separate files, and some see it as its own language rather than “CL with types.”

Async, concurrency, and implementation limits

  • One commenter wants a true async/green-thread style runtime integrated into SBCL, arguing that user-level libraries can’t fully match Go-style goroutines or M:N scheduling.
  • Others point to existing CL libraries for concurrency (lparallel, coroutines, async libs, libuv/libev-based servers) and note that many still build on OS threads.
  • There’s disagreement on whether deep runtime changes are necessary versus library approaches; it remains an open, somewhat unclear design space.

Cultural notes, trivia, and experiences

  • Several people express that SBCL and CL “ruined” other languages for them, especially after experiencing its REPL and flexibility.
  • Anecdotes describe SBCL as a gateway into finding programming intellectually interesting (e.g., discovering metaprogramming, then moving on to other expressive languages).
  • Favorite bits of SBCL culture include darkly humorous function names and error messages, and the long lineage from early 1980s Lisp work.