Looks a lot like Swift! Awesome!
Lisette a little language inspired by Rust that compiles to Go
41–50 of 168 posts
Re: Lisette a little language inspired by Rust that compiles to Go
#42Looks 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…
Same. I started writing a high level Rust that was based on typescript.
Then realized Rust wasn't that hard.
Re: Lisette a little language inspired by Rust that compiles to Go
#43Earlier quoted context omitted.
In my experience, what's actually nice is the correctness. The low-levelness is not helpful for most of the software I write, and imposes a constant burden. Rust, of course superbly achieves its goals within its niche! But it is a niche, is my meaning here. What I actually want is code that's correct, but ergonomic to write. So my ideal language (as strange as it sounds) would be Rust with a GC. I don't want to worry…
You can use Ocaml today and achieve all the correctness
> all the correctness
When did OCaml get affine types? Or unique references?
Re: Lisette a little language inspired by Rust that compiles to Go
#44Earlier quoted context omitted.
There are an endless number of modern MLs that do the same thing. That's not a novelty - Rust was novel in making it part of a low-level language.
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 baked jerry-rigged and barely usable nonsense. Not an industrial strength langage with a reliable type system and a strong focus on safety through types.
Re: Lisette a little language inspired by Rust that compiles to Go
#45I'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 require two unwrapping steps, but it becomes a bit awkward anyway. (note: this double-Option is not a thing in Lisette at least as of now)
Lisette also doesn't remove the need to call defer (as opposed to RAII) in the very awkward way Go does. E.g. de facto requiring that you double-close on any file opened for write.
Typescript helps write javascript, but that's because until WASM there was no other language option to actually run in the browser. So even typescript would be a harder sell now that WASM can do it. Basically, why try to make Go more like Rust when Rust is right there? And fair enough, the author may be aiming for somewhere in between. And then there's the issue of existing codebases; not everything is greenfield.
So this seems best suited for existing Go codebases, or when one (for some reason) wants to use the Go runtime (which sure, it's at least nicer than the Java runtime), but with a better language. And it does look like a better language.
So I guess what's not obvious to me (and I mentioned this to the author) is what's the quick start guide to having the next file be in Lisette and not Go. I don't think this is a flaw, but just a matter of filling in some blanks.
[1] https://blog.habets.se/2025/07/Go-is-still-not-good.html
Re: Lisette a little language inspired by Rust that compiles to Go
#46I'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
Re: Lisette a little language inspired by Rust that compiles to Go
#47Eats shoots and leaves.
Re: Lisette a little language inspired by Rust that compiles to Go
#48Earlier quoted context omitted.
OCaml has a lot of other cons though that Rust doesn't have. I would definitely pick Rust over OCaml even for projects that can tolerate a runtime with GC pauses. (And clearly most people agree.)
What cons?
The ecosystem. The language is lovely, but dune/opam is not up to the standard of the Go or Rust build systems, and the set of useful libraries is somewhat skewed. Whenever I write a program in Caml, I gain an hour thanks to the nice language, and then lose two fighting with dune/opam.
There's also the support for concurrency and parallelism, which has started to improve recently, but is still years behind what is available in Go (but still better in my opinion than what is available in Rust).
Re: Lisette a little language inspired by Rust that compiles to Go
#49I'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?
Re: Lisette a little language inspired by Rust that compiles to Go
#50Earlier quoted context omitted.
They are not supposed to produce code that doesn't compile, why would they?
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.