Hacker News Reader

Comment by emanuele-em | Hacker News Reader

Really nice work on this. The error messages alone show a lot of care, the "help" hints feel genuinely useful, not just compiler noise.

I'm curious about the compiled Go output though. The Result desugaring gets pretty verbose, which is totally fine for generated code, but when something breaks at runtime you're probably reading Go, not Lisette. Does the LSP handle mapping errors back to source positions?

Also wondering about calling Lisette from existing Go code (not just the other direction). That feels like the hard part for adoption in a mixed codebase.

Is the goal here to eventually be production-ready or is it more of a language design exploration? Either way it's a cool project.

View on HN

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.

Reply on news.ycombinator.com