# Lisette: Rust-like programming with a Go compiler backend

> Lisette is a small programming language, implemented in Rust, that compiles to Go. It combines static typing and pattern matching with direct access to Go packages, generated Go output, and editor integration, but its README does not provide a complete installation walkthrough.

**ivov/lisette** — A little language inspired by Rust that compiles to Go

- Repository: https://github.com/ivov/lisette
- Website: https://lisette.run
- Stars: 1,603 · Forks: 38
- Language: Rust
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/ivov-lisette

## The Go backend Lisette is designed to expose

Lisette addresses a specific gap between Go and statically typed languages with Rust-style structure. Developers can write with algebraic data types, expression-oriented code, and explicit error handling while compiling to Go instead of requiring a separate runtime or native-code toolchain. The generated artifact can therefore remain within an existing Go-centered build and deployment process. That is a concrete advantage for teams whose application code already depends on packages under `encoding/json`, `fmt`, `os`, and other parts of the Go ecosystem.

The intended audience appears to be programmers comfortable with Rust-like syntax but interested in Go interoperability. Lisette is not simply a Rust compiler configured to emit Go. The repository is a Rust workspace with dedicated crates for syntax, semantics, passes, diagnostics, formatting, emission, standard-library support, dependencies, the CLI, and LSP support. Based on that repository layout, language processing is divided into distinct compiler concerns rather than hidden inside one command.

This approach also gives Go users a different source-level model. Lisette presents `Option` instead of `nil` and zero values in its examples, and its `Result` return type supports explicit failure paths. A missing flag value is represented as `None`, while file and JSON operations can propagate errors with `?`. Those choices shift absent values and failures into typed forms instead of treating both as an untyped zero result.

## Type checking, pattern matching, and Option semantics

The README identifies Lisette as having a Hindley-Milner type system, algebraic data types, and pattern matching. The shape example shows an enum whose variants carry either one value or named fields. Matching that value branches on `Circle(r)` or `Rectangle { width, height }`, allowing callers to destructure the relevant data while calculating the result. This syntax gives the language a compact representation for states that Go normally models through tagged structures and separate fields.

The generated behavior is tied to familiar Go execution, but Lisette does not use Go's `nil` and zero-value default in the examples on its homepage. `Map.get` returns a value that is matched as `Some(score)` or `None`. The same approach applies to `flag.Lookup`, where an existing definition contains a `DefValue` and a missing definition produces the explicit `None` branch.

That restriction does not prove that every Go API is equally safe or ergonomic inside Lisette. The linked Safety page may cover additional rules, but the README does not provide a complete list. An engineer evaluating existing Go dependencies needs to inspect that documentation rather than infer full compatibility from the small interop examples. The README also does not explain how arbitrary generic Go types, package-level mutability, initialization rules, or nil-compatible Go contracts are translated.

## Go package imports and `?` error propagation

Lisette uses quoted Go imports such as `go:os`, `go:encoding/json`, and `go:fmt`. Its `load_config` example reads a file with `os.ReadFile`, passes its output to `json.Unmarshal`, and places `?` after both calls. The operator propagates an error while the successful function returns `Result<Cfg, error>`. Calling code then matches the result as `Ok(config)` or `Err(e)`.

This is more specific than saying only that Lisette supports interoperability. The example crosses Lisette types and Go package functions, passes a Lisette data structure to `json.Unmarshal`, and prints a Go-side error through `fmt.Println`. It therefore demonstrates a source-level route for using standard Go packages directly, rather than merely exposing generated Go through a separate wrapper.

The repository includes a `bindgen/` directory and a Go language/toolchain area, but their internal behavior is not described in the README. It would be unsafe to claim which packages are generated, how unsupported signatures are rejected, or whether all Go modules can be imported without adaptation. The documentation does not give such an inventory. That omission matters because direct interop is a central feature of the project and should be checked against the real APIs a team expects to consume.

## Pipelines, channels, and generated concurrency

Lisette adds a `|>` pipeline operator to its Rust-like syntax. The README starts with a string containing spaces, sends it through `strings.TrimSpace`, lowercases it, replaces spaces with hyphens, and assigns the result to `slug`. This is function composition expressed as a sequence, although the README example does not include the `strings` import needed to make it complete by itself.

Concurrency follows Go concepts rather than introducing a separate Lisette runtime. The channel example creates `Channel.new<string>()`, splits it into `tx` and `rx`, starts a `task`, sends `"hello"`, closes the sender, and receives the message as `Some(msg)`. Closing the channel leads to the `None` branch. The important distinction is that Lisette wraps these operations in typed source syntax while retaining channels, goroutine-like tasks, and close-aware receives.

The README does not explain task scheduling, panic behavior, send semantics after close, cancellation, or error handling inside concurrent tasks. Nor does it document whether generated Go preserves source-level task ordering in every case. Those are not routine details to skip when evaluating a language, especially for services built around concurrent I/O. Direct Go code presents fewer translation questions in this area because the concurrency constructs and runtime semantics are the same in source and output.

## CLI, diagnostics, formatting, and editor access

The README presents Lisette as a developer tool as well as a language grammar. It lists a linter, formatter, more than 500 diagnostics, a fast incremental compiler, readable Go output, and an LSP for VSCode, Neovim, Zed, and GoLand. The workspace supports these features with separate crates named `lisette-diagnostics`, `lisette-format`, `lisette-emit`, and `lisette-lsp`. The presence of `editors/` also indicates project-specific editor assets.

The repository's `justfile` provides contributor and maintainer commands. A release compiler build is defined as follows:

```bash
cargo build --release
```

This command builds the Cargo workspace for contributors who already have the repository and Rust toolchain. It is not documented as the installation procedure for a new Lisette user. The workspace declares Rust `1.97` as its minimum version and edition `2024`, while the README badge identifies Go `1.26.7` for the compiled target toolchain. Exact prerequisites still need confirmation in the Quickstart because the README does not spell out their installation or PATH setup.

Readable generated Go is relevant to debugging and code review. It gives maintainers an inspectable compiler boundary, but it does not mean Lisette programs are simply Go source files. Engineers adopting it should expect to work with a versioned language syntax, generated output, and Go dependencies. Language changes can therefore affect compilation and formatting behavior in ways that direct Go development avoids.

## Installation limits and a first interop exercise

The README links to `https://lisette.run/docs/intro/quickstart/` as the place to set up a Lisette project, but the quickstart content and end-user installation commands are not included there for inspection. It would be misleading to invent a package manager, shell command, executable name, or initialization flag. Based on the repository files, `cargo build --release` is a contributor build command, not proof that it installs an end-user compiler on a clean machine.

A useful first exercise, once the documented setup is complete, is to compile a program containing an enum and pattern match. The following source is copied from the README, although it defines no entry point and therefore is a language fragment rather than a complete runnable program:

```rust
enum Shape {
  Circle(float64),
  Rectangle { width: float64, height: float64 },
}

fn area(shape: Shape) -> float64 {
  match shape {
    Circle(r) => 3.14 * r * r,
    Rectangle { width, height } => width * height,
  }
}
```

This checks enum parsing, variant payloads, field destructuring, and type inference. The next focused check should exercise Go interop rather than remain inside the language-only example. The configuration fragment demonstrates the intended path:

```rust
fn load_config(path: string) -> Result<Cfg, error> {
  let data = os.ReadFile(path)?
  let mut config = Cfg { port: 8080, debug: false }
  json.Unmarshal(data, &config)?
  Ok(config)
}
```

The excerpt omits `Cfg`, `start`, and its imports, so it cannot serve as a complete application. That incompleteness is a documentation constraint, not necessarily a compiler defect. It also shows why the linked Quickstart and Reference need review before migration.

## Lisette versus writing Go directly

Direct Go is the clearest real alternative. A team choosing Go source bypasses Lisette's compiler, generated-code review, language-version upgrades, and translation of Lisette patterns into Go constructs. Go also provides the referenced ecosystem directly. For a service dominated by Go libraries, that direct path can be easier to reason about because the source language and runtime contract are not separated by another compiler layer.

Lisette changes the source experience rather than replacing Go. It adds a Hindley-Milner type system, algebraic data types, expression-oriented structure, `Option`, pipelines, `try` blocks, and Rust-like syntax. It then emits readable Go and presents selected Go concepts through Lisette syntax. That extra language can be worthwhile when shared enum variants and typed absence remove repetitive Go plumbing, especially if the generated Go remains acceptable to the surrounding toolchain.

The trade-off is explicit. Direct Go has one source model. Lisette adds a pre-compilation step and a compatibility surface between its type model, Go package signatures, generated code, formatter, diagnostics, and LSP. The README does not state language stability guarantees, compatibility policy, generated-code diff guarantees, or performance measurements. It also does not document rollback or migration between Lisette versions. Those omissions prevent a justified production adoption claim despite the recent release cadence.

## Release cadence, MIT terms, and adoption cost

The repository is not archived. Its last push was on 2026-10-12, and releases named `lisette-v0.12.4`, `lisette-v0.12.3`, and `lisette-v0.12.2` were published on 2026-10-11, 2026-09-27, and 2026-09-18. That cadence shows recent project activity. It does not by itself establish backward compatibility or suitability for production workloads.

The package is distributed under the MIT license. For an engineer, the immediate licensing consequence is that the project uses a permissive license rather than a copyleft license. The README and `Cargo.toml` identify MIT, but neither replaces review of the actual `LICENSE` file for the complete terms and notice obligations. No legal conclusion should be drawn from the short identifier alone.

Adoption cost has several components. Building the compiler from source requires a compatible Rust toolchain because the workspace declares Rust `1.97`. Running compiled programs belongs to the Go side of the toolchain, for which the README identifies Go `1.26.7`. Users may also need to track language changes, regenerate output, maintain Go module dependencies, and reconcile LSP or formatter changes. The `justfile` includes self-upgrade test coverage for the `lisette` binary, but its presence does not establish how upgrades are distributed or whether downgrade is supported.

## Conclusion

Lisette fits developers who want Rust-like syntax and static checking while retaining Go libraries and Go build output. It is a poor choice for someone who needs a fully documented setup today, predictable language stability, or evidence that every feature shown in the README is production ready. Before adoption, inspect the linked Quickstart, compile a small program that imports `go:os`, and confirm that release `0.12.4` covers the language and Go ecosystem features required by the project.

## FAQ

### What programming model does Lisette use?

Lisette uses a Hindley-Milner type system, algebraic data types, pattern matching, and immutable-by-default expressions. Its source syntax is Rust-like, with `|>` pipelines and `try` blocks.

### Does Lisette compile to Go?

Yes. Lisette is implemented as a Rust codebase and compiles language programs to readable Go. It also provides direct import syntax such as `go:os` and `go:encoding/json`.

### Which tools does Lisette provide for development?

The README lists a formatter, linter, more than 500 diagnostics, an incremental compiler, and an LSP for VSCode, Neovim, Zed, and GoLand.

## Sources

- [ivov/lisette on GitHub](https://github.com/ivov/lisette)
- [License: MIT](https://github.com/ivov/lisette/blob/main/LICENSE)
- [Project website](https://lisette.run)
- [README](https://github.com/ivov/lisette/blob/main/README.md)
- [Releases](https://github.com/ivov/lisette/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ivov-lisette