Hy 1.0 – Lisp dialect for Python

Original Article ↗ Hacker News Discussion ↗

Hy 1.0, a Lisp dialect that compiles to Python’s abstract syntax tree, has reached its first stable release after more than a decade of development, prompting renewed interest from both long-time users and newcomers. Commenters highlight Hy’s main appeal as bringing powerful Lisp-style macros, REPL-driven workflows, and a more uniform, expression-oriented syntax to the Python ecosystem while maintaining near-complete semantic parity and interoperability with Python. Others weigh the trade-offs versus Clojure and other Lisps, pointing to startup overhead, tooling gaps, and the question of whether Lisp syntax and metaprogramming justify an extra compilation layer on top of Python.

Overall reception & maturity

  • Many commenters express excitement and respect for the 1.0 release and decade-long maintenance.
  • Several report past use in side projects, DSLs, and even a book, and are motivated to revisit Hy now that it’s “stable.”
  • Some note that recent releases have been source-stable (no breaking changes from 0.29).

Relationship to Python and other Lisps

  • Hy is a Lisp that compiles s-expressions to Python’s AST, which Python then compiles to bytecode.
  • It’s tightly coupled to Python (more like CoffeeScript→JS than Clojure→Java) with full interop in both directions.
  • Compared to Clojure: Clojure has persistent immutable data structures and compiles directly to JVM bytecode; Hy shares Python’s mutable, side-effect–friendly semantics.
  • Other Python-targeting Lisps/FP languages (Basilisp, Coconut) are mentioned as alternatives with different design goals.

Language features and advantages

  • Hy adds Lisp-style macros and reader macros, arbitrary compile-time computation, and removes the Python distinction between statements and expressions.
  • Extra conveniences: more flexible anonymous functions, richer for loops, relaxed identifier charset, and extended operator arities.
  • Dynamic binding isn’t built in but is easy to macro in.
  • The language has intentionally moved toward being a thin syntactic layer over Python, dropping non-essential deviations (e.g., special boolean spellings, extra “Lispy” sugar).

Tooling, REPL, and distribution

  • Hy has its own REPL and can embed a REPL inside running code; debugging generally uses Python’s exception model and tools.
  • No Common Lisp–style condition system or breakloop; partial but untested pdb support.
  • No standalone single-binary distribution; workarounds include Python “single-file” tools and uvx [email protected].
  • Good Emacs support; IDLE and PyCharm lack first-class integration; other editors need updated syntax highlighting.

Performance, typing, and production concerns

  • Compilation from Hy to Python AST can take a few seconds for large programs, but runtime performance should match Python since the output is normal bytecode.
  • Startup may incur extra cost when caches are cold; otherwise overhead is minimal.
  • Python’s static type checkers generally need generated Python source (via hy2py); they don’t operate directly on Hy code.
  • Downsides noted: extra compilation layer, weaker tooling ecosystem, coworker unfamiliarity; upside is retaining full access to the Python ecosystem with Lisp-style metaprogramming.

Lisp syntax and macro system debate

  • Some find Lisp syntax verbose and unreadable; others argue the uniform s-expression structure aids refactoring, structural editing, and metaprogramming.
  • Discussion contrasts unhygienic Common Lisp–style macros (which Hy uses) with hygienic Scheme/Racket-style systems; trade-offs between power, safety, and ease-of-use are debated.
  • Several comments stress that macros are “power tools”: extremely powerful but easier to misuse without hygiene, yet central to Lisp’s appeal.