Lisette a little language inspired by Rust that compiles to Go

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.