Lisette a little language inspired by Rust that compiles to Go

Original Article ↗ Hacker News Discussion ↗

A new language called Lisette aims to bring Rust-like type safety and ergonomics—such as enums, exhaustive pattern matching, and ADTs—to software running on the Go runtime by compiling Lisette code to Go. Commenters are intrigued by its error messages and design goals but raise concerns about long-term maintenance, interoperability with existing Go code (especially third-party modules), and edge cases around Go’s `(value, error)` patterns. The project is seen as potentially valuable for Go ecosystems that want stronger type systems without adopting Rust, though many note that similar GC-based or ML-style languages already occupy parts of this space.

Project goals & language design

  • Lisette aims to combine Go’s runtime (GC, goroutines, tooling) with a Rust-like type system: enums/ADTs, exhaustive pattern matching, and safer handling of “nil”.
  • It is “Rust-inspired” rather than Rust-compatible: syntax and semantics intentionally diverge (e.g., import paths, pattern syntax, number types) and there is no borrow checker.
  • Several commenters see it as “a Rust-y way to write Go” and analogous to TypeScript for JavaScript or Gleam for Erlang.

Tooling, errors, and debugging

  • Error messages and “help” hints are widely praised as thoughtful and beginner-friendly.
  • A --debug flag inserts //line directives so runtime stack traces map back to .lis source; compile-time errors already reference Lisette files.
  • Some note debugger/stack-position mapping is a recurring pain point for “compile-to-Go” languages, but Go’s //line feature helps here.

Go interoperability & ecosystem

  • Lisette can import Go’s standard library through a bindgen tool.
  • Support for third-party Go modules is not yet implemented but is on the roadmap.
  • Calling Lisette from existing Go code is currently unsupported and considered the harder interop direction.
  • One technical concern: desugaring Go’s (T, error) into Result<T, error> is not always semantically correct (e.g., io.Reader patterns); this is acknowledged as an open issue.

Comparisons to Rust, ML, and other languages

  • Some see it as “Rust with a GC” for domains where GC and fast iteration matter more than zero-cost abstractions.
  • Others argue many modern ML-family languages (OCaml, F#, etc.) already occupy this “correctness + GC” space, though they are criticized for tooling, ecosystem gaps, Windows support, and concurrency limitations.
  • Alternatives mentioned: MoonBit, Gleam, Nim, Haxe, various Python-to-X transpilers.

Go runtime vs language debate

  • Strong praise for Go’s runtime (concurrent GC, goroutines, simple deployment) but repeated criticism of:
    • Limited type system (no enums/union types), clunky error handling, awkward defer, and “two flavors of nil”.
  • Some argue Go’s “yolo but robust” concurrency model is superior in ergonomics to Rust’s async and avoids function coloring.
  • Others counter that for large/complex systems, stronger types and RAII-style resource management are worth the additional complexity.

Adoption, skepticism, and viability

  • Multiple commenters are enthusiastic, calling Lisette “what Go should have been” or a sweet spot between Go’s simplicity and Rust’s expressiveness.
  • Skeptics worry it may be another short-lived, LLM-accelerated side project: large codebase, polished site, young repo, uncertain maintenance.
  • Some question the value of layering a new language on top of Go at all, suggesting that if you want Rust-like safety, “just use Rust”; proponents reply that the Go runtime and GC remain compelling reasons.