Live data from Hacker News

Lisette a little language inspired by Rust that compiles to Go

lisette.run

91–100 of 168 posts

Re: Lisette a little language inspired by Rust that compiles to Go

#91

A programming language similar to Python that compiles to Rust or Go will be amazing.

Mojo is a language with Pythonic syntax that compiles to fast machine code built by the creator of Swift: https://www.modular.com/open-source/mojo

Hold up... did I miss something, is Mojo open sourced now?

Edit: No it is still not open source. There are still same promises of open sourcing eventually, but there is no source despite the URL and the website claiming it's an open language. What's "open" here is "MAX AI kernels", not Mojo. They refer to this as "750k lines of open source code" https://github.com/modular/modular/tree/main/max/kernels

This feels icky to me.

Re: Lisette a little language inspired by Rust that compiles to Go

#92
post #71

I've chatted a bit with the author, but not actually tried the language. It looks very interesting, and a clear improvement. I'm not particularly quiet about not liking Go[1]. I do think there may be a limit to how far it can be improved, though. Like typed nil means that a variable of an interface type (say coming from pure Go code) should enter Lisette as Option >. Sure, one can match on Some(Some(h)) to not requir…

From your blog entry: > Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL Thanks for raising this kind of things in such a comprehensible way. Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem. That's why I creat…

"A typed nil pointer is not a nil pointer."

Re: Lisette a little language inspired by Rust that compiles to Go

#93

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 wonder…

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. Th…

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)?

Re: Lisette a little language inspired by Rust that compiles to Go

#94
post #71

Earlier quoted context omitted.

From your blog entry: > Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL Thanks for raising this kind of things in such a comprehensible way. Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem. That's why I creat…

You can enable null safety in TypeScript, seems like a pretty good fix to me.

Where did we lose you? we're talking about two flavours of null, not one.

Re: Lisette a little language inspired by Rust that compiles to Go

#96
post #66

Earlier quoted context omitted.

> Basically, why try to make Go more like Rust when Rust is right there? The avg developer moves a lot faster in a GC language. I recently tried making a chatbot in both Rust and Python, and even with some experience in Rust I was much faster in Python. Go is also great for making quick lil CLI things like this https://github.com/sa-/wordle-tui

> moves a lot faster in a GC language Only in the old "move fast and break things" sense. RAII augmented with modern borrow checking is not really any syntactically heavier than GC, and the underlying semantics of memory allocations and lifecycles is something that you need to be aware of for good design. There are some exceptions (problems that must be modeled with general reference graphs, where the "lifecycle" bec…

> Only in the old "move fast and break things" sense

No, definitely not only in that sense. GC is a boon to productivity no matter how you slice it, for projects of all sizes.

I think the idea that this is not the case, perhaps stems from the fact that Rust specifically has a better type system than Java specifically, so that becomes the default comparison. But not every GC language is Java. They don't all have lax type systems where you have to tiptoe around nulls. Many are quite strict and are definitely not "move fast and break things" type if languages.

Re: Lisette a little language inspired by Rust that compiles to Go

#98
post #50

Earlier quoted context omitted.

Debugger positions on the other hand are a pain with these things.

Uh yes, that's what I meant ;) In C/C++ you have the #line preprocessor directive. It would be nice if Go had something similar.

Go has apparently got //line directives, and this project uses them.

Re: Lisette a little language inspired by Rust that compiles to Go

#99

Earlier quoted context omitted.

> moves a lot faster in a GC language Only in the old "move fast and break things" sense. RAII augmented with modern borrow checking is not really any syntactically heavier than GC, and the underlying semantics of memory allocations and lifecycles is something that you need to be aware of for good design. There are some exceptions (problems that must be modeled with general reference graphs, where the "lifecycle" bec…

> Only in the old "move fast and break things" sense No, definitely not only in that sense. GC is a boon to productivity no matter how you slice it, for projects of all sizes. I think the idea that this is not the case, perhaps stems from the fact that Rust specifically has a better type system than Java specifically, so that becomes the default comparison. But not every GC language is Java. They don't all have lax t…

Well if you think Java doesn't have a sufficiently good type system, then surely Go is even further from one?

Not saying those are the only two GC languages, just circling back to the post spawning these comments.

Re: Lisette a little language inspired by Rust that compiles to Go

#100
post #81

Earlier quoted context omitted.

Does Go actually have an async story? I know that question risks starting a semantic debate, so let me be more specific. Go allows creating lightweight threads to the point where it's a good pattern to just spin off goroutines left and right to your heart's content. That's more of a concurrency primitive than async. Sure, you combine it with a channel, and you've created an async future. The explicit passing of conte…

For one, I am glad I don't have to color my functions like your typical async.

I agree that this is the big problem with Rust's async story.

But like I said, in my opinion this compares with Go not having an async story at all.

Post reply on HN