You are right, and thank you for pointing this out. I've opened an issue:

https://github.com/ivov/lisette/issues/12

I have a few approaches in mind and will be addressing this soon.

I gave Lisette a run today. I really like it, its a clear improvement to Go.

Here a few things that i noticed.

- Third party Go code support (like go-chi) is a absolute must have. This is THE feature that will possibly sky-rocket Lisette adoption. So something like stubs etc, maybe something like ReScript has for its JS interop (https://rescript-lang.org/docs/manual/external). The cli tool could probably infer and make these stubs semi-easily, as the go typesystem is kind of simple.

- The HM claim did confuse me. It does not infer when matching on an Enum, but i have to manually type the enum type to get the compiler to agree on what is being matched on. Note, this is a HARD problem (ocaml does this probably the best), and maybe outside the scope of Lisette, but maybe tweak the docs if this is the case. (eg. infers somethings, but not all things)

- Can this be adopted gradually? Meaning a part is Go code, and a part generated from Lisette. Something like Haxe perhaps. This ties to issue 1 (3rd party interop)

But so far this is the BEST compile to Go language, and you are onto something. This might get big if the main issues are resolved.

Thanks for trying it out!

Variant qualification is a name resolution requirement - Lis follows Rust's scoping model where variants are namespaced under the enum. The implementation correctly infers the type, as shown e.g. in the hint `help: Use Shape.Circle to match this variant` My understanding is HM has nothing to say about this; it operates after names are resolved.

Re: Go third-party packages + incremental adoption, I'll do my best! Thanks for the encouragement.

Thanks for your kind words :)

The CLI command `lis run` supports a `--debug` flag to insert `//line source.lis:21:5` directives into the generated Go, so stack traces from runtime errors point back to the original Lisette source positions. The LSP handles compile-time errors, which reference `.lis` files by definition.

Calling Lisette from existing Go is not yet supported and is the harder direction, as you noted. This is on my mind, but the more immediate priority is enabling users to import any Go third-party package from Lisette.

Lisette began as an exploration, but I intend to make it production-ready.

I noticed the project is less than a month old, and you've generated over 300k lines of code here. I'm guessing most of this was written by agents, yes?

I'm asking because your goal is to make it production ready, so what are you doing to assure people this is more than just another vibe coded language (of which there are countless examples by now)?

Thanks for asking! The core of the compiler should be close to 50k LoC, with most of the rest being tests. The project is much older than git history suggests - I started a fresh repository for the initial release after several months of experiments and false starts to find the right direction. LLMs certainly helped e.g. with mechanical tasks like generating tests and refactors where changes cascaded throughout the pipeline, and I also relied on them to understand Hindley-Milner type inference, Lindig for the formatter, and Maranget for exhaustiveness checking.

Thanks for the response but I'm sorry to say it's not reassuring, but does more to worry me because you didn't answer the question.

Like I said, these LLM-driven language projects have proliferated recently, and they follow a common pattern:

- Dump hundreds of thousands of lines of lines into a blank repo with a new repo.

- Throw up a polished-looking LLM generated website (they all look the same).

- Post about the project on a bunch of tech sites like HN.

- Claim it's a real project with deep roots despite there being no evidence.

Here's another one:

https://www.reddit.com/r/ProgrammingLanguages/comments/1sa1a...

These things are so common that r/programminglanguages had to ban them, because they were being posted constantly. So my concern is: what differentiates your project from the sea of others exactly like it, which as I've been following them? Usually the main dev grows bored with it quickly when the agent starts having trouble building features and the project is silently abandoned.

Abandoned open-source projects with poor code quality are nothing new.

The merits of any project are yours to evaluate.

To me, I see some encouraging thoughtfulness here. However, again, it's true most projects like this don't achieve liftoff.

Support for Go third-party packages is not part of this first release, but the tooling to generate bindings for Go packages (which enables imports from the Go stdlib) is already in place[1]. Extending it to support third-party packages is on the roadmap.

[1] https://github.com/ivov/lisette/blob/main/tools/bindgen/READ...

Thank you for your writings! Your "Learn in Public" gist inspired me to do so: https://ivov.dev/

nice! the key is to start and keep going and going and going and going :) you'll figure it out as you go.