I've read the entire page and still don't know whether or not I can import Go modules in this language, which seems rather important
The first example suggests yes.
Lisette a little language inspired by Rust that compiles to Go
61–70 of 168 posts
Re: Lisette a little language inspired by Rust that compiles to Go
#62Please commit your CLAUDE.md
Re: Lisette a little language inspired by Rust that compiles to Go
#63Earlier quoted context omitted.
These are just syntax differences, which not only are easy to learn but I believe aren't the primary goal of the language, which is to bring the benefits of Rust's type system to Go. As for int and float64, this comes from Go's number type names. There's int, int64, and float64, but no float. It's similar to how Rust has isize but no fsize.
> It's similar to how Rust has isize but no fsize. isize is the type for signed memory offsets, fsize is completely nonsensical.
[deleted]
Re: Lisette a little language inspired by Rust that compiles to Go
#64Looks great. But I can't help wondering: If it is similar to Rust why not make it the the same as Rust where it feature-matches? Why import "foo.bar" instead of use foo::bar? Why Bar.Baz => instead of Bar::Baz =>? What are you achieving here? Why make it subtlety different so someone who knows Rust has to learn yet another language? And someone who doesn't know Rust learns a language that is different enough that the…
Writing actual Rust for any GC language (including Golang) would ultimately be quite weird. You'd have to entirely change the way memory is modeled, to account for the restrictions GC introduces. It's similar to the restrictions introduced by having multiple address spaces, except even weirder because every object is its own tiny address space and a reference is just an address space descriptor.
Re: Lisette a little language inspired by Rust that compiles to Go
#65Earlier quoted context omitted.
Really? Almost every example imports something from Go, and it states "interoperability with the Go ecosystem" (or similar, from memory).
That isn’t the same thing. Indeed, upon reading further, it appears there is no way to import non-stdlib go modules.
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...
Re: Lisette a little language inspired by Rust that compiles to Go
#66I'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…
> 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
Re: Lisette a little language inspired by Rust that compiles to Go
#67I'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…
Rust's async story is much less ergonomic than go's -- mostly because of lack of garbage collection. That might be a good reason by itself?
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 contexts is interesting. I initially thought it would be awkward, but it works well in practice. Except of course when you need to call a blocking API that doesn't take context.
And in environments where you can run a multitasking runtime, that's pretty cool. Rust's async is more ambitious, but has its drawbacks.
Go's concurrency story (I wouldn't call it an async story) is way more yolo, as is the rest of the Go language. And in my experience that Go yolo tends to blow up in more hilarious ways once the system is complex enough.
Re: Lisette a little language inspired by Rust that compiles to Go
#68Earlier quoted context omitted.
I don't think being low level is the main innovation, really. There are several things Rust did right over traditional ML. Explicitly caring about learnability and the "weirdness budget". Having great error messages that don't require a course in category theory (many ML) or 800kB of scrollback buffer (C++) to understand. Having great tools. Excellent documentation. Being friendly to new users. Yes, it's also a syste…
> Yes, it's also a systems language without a runtime. But that's not the novel part. Low level strong correctness was absolutely a novel part. In fact it’s exactly why many people glommed onto early rust, and why it was lowered on the stack. Although learnability and weirdness budgets were also extremely novel in low level contexts which had been subsumed by C and C++. > horrors in C++ Yes, horrors in C++. Half bake…
Memory safety is not the same a scorrectness and more advanced type is also not the same thing as correctness.
Re: Lisette a little language inspired by Rust that compiles to Go
#69Really 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. 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.
Re: Lisette a little language inspired by Rust that compiles to Go
#70Could large data types be problematic for the prelude types Option/Result/Tuple? They don't store as pointer and every receiver is by value.