Hy 1.0 – Lisp dialect for Python

Original Article ↗ Hacker News Discussion ↗

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.