Why Does Elisp Suck

Original Article ↗ Hacker News Discussion ↗

Emacs users are reexamining Emacs Lisp, weighing long‑standing flaws like global mutable state, awkward regex syntax, limited threading, and a confusing data model against its strengths as a deeply integrated, live-hackable extension language. Some argue Emacs should eventually be rebuilt on a more modern Lisp (Common Lisp, Guile, or alternatives like Lem) to gain better concurrency, cleaner abstractions, and namespaces, even if that breaks compatibility. Others counter that despite its age and quirks, Emacs Lisp remains pragmatic, fast enough with native compilation, and uniquely powerful for building tools like Magit and org-mode directly inside the editor.

Elisp vs Other Lisps / Languages

  • Many argue Elisp “doesn’t suck”; it’s a pragmatic, Maclisp-influenced Lisp that’s good enough for scripting an editor.
  • Others see it as dated compared to Common Lisp, Scheme, or Clojure, wishing for namespaces, better concurrency, and modern language features.
  • Some say the real pain is not Elisp itself but needing to learn a special-purpose Lisp just to script Emacs.

Emacs Architecture and Data Model

  • Several comments claim the Emacs data model and decades of accreted APIs are the real problem: global mutable state, opaque behavior, and confusing terminology (“windows”, buffers, TRAMP, etc.).
  • Debugging often requires understanding multiple interacting extensions plus Emacs internals, which is seen as a barrier to entry.
  • Others counter that global state is a feature: Emacs is designed to make all internal state inspectable and modifiable.

Threads, Concurrency, Performance

  • A recurring theme: Emacs’ historical lack of true multithreading.
  • Critics note that long-running Elisp blocks the UI; they point to older Lisp systems where multiple REPLs and tools ran concurrently.
  • Defenders argue threading adds complexity and Emacs already has workable async models: external processes, sentinels, timers, while-no-input, limited threads, and native compilation.
  • There’s disagreement on whether richer concurrency is essential or an overcomplication.

Alternative Emacs-like Editors / Rewrites

  • Ideas discussed: a new Emacs on GNU Guile and wlroots; rewriting C parts in Common Lisp; projects like Lem, Nyxt, Cedar.
  • Some praise Lem (Common Lisp, graphical, multithreaded) but note giving up the Elisp ecosystem is hard.
  • VS Code, Zed, Helix, and Neovim are discussed as competitors or complements, but many see none as true Emacs replacements yet.

Language Quirks and Ergonomics

  • Complaints: heavy use of global state, late arrival of lexical scoping, clunky regex syntax (mitigated by the rx DSL), and ad‑hoc, stateful APIs like match data.
  • Libraries like dash.el, s.el, ht.el, and higher-level frameworks (e.g., transient, eieio) are cited as making modern Elisp more pleasant, if also more complex.

Overall Sentiment

  • Split between those who see Elisp/Emacs as aging, messy, and hard to modernize, and those who view it as still the best live-hacking, tool-building environment, with unparalleled integration and mature packages like Magit and org-mode.