HN

Comments (92)

• Menu

  thomashabets2
  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<Option<http.Handler>>. 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
• Menu

  virtualritz
  Looks 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 knowledge doesn't transfer to writing Rust 1:1/naturally?Also: int but float64?Edit: typos
• Menu

  baranul
  There are several languages that compile to Go, trying to be a better a Go. Off the top of my head: XGo (https://github.com/goplus), Borgo (https://github.com/borgo-lang/borgo), Soppo (https://github.com/halcyonnouveau/soppo)...
• osigurdson
  I'd always liked the Go runtime but the language is pretty clunky imo and I don't think they will ever improve it (because they don't think anything is wrong with it). However, you have to really dislike the language to use a transpiler.
• Menu

  emanuele-em
  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.
• Menu

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

  melodyogonna
  I'm wondering about the logistics of making this integrate with Go at the assembly/object file level rather than at source code level. What if it compiled to Go's assembly rather than to Go source code
• jasdfwasd
  Could large data types be problematic for the prelude types Option/Result/Tuple? They don't store as pointer and every receiver is by value.
• Menu

  smokel
  This is great news for those of us looking for baby names. So far my list includes: Pascal, Ada, Dylan, Crystal, Lisa, Julia, Ruby, and now Lisette.
• Menu

  oncallthrow
  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
• sail0rm00n
  I’m sold just for proper enumeration support.
• phplovesong
  Go has an awesome runtime, but at the same time has a very limited typesystem, and is missing features like exhaustive pattern matching, adts and uninitted values in structs.Lisette brings you the best of both worlds.
• Menu

  ksec
  On the surface this looks great. Seems to hit the sweet spot in a lot of areas.I know it is Rust inspired, but why write it in Rust and not Go?
• rbbydotdev
  Looks beautiful! Any plans to make it self compile?
• Menu

  bestouff
  For "classic" Rust what's actually nice is that no runtime is needed, so this looks like a step backwards.What would be actually nice is running async Rust on the Go green threads runtime.
• bhwoo48
  Love the idea of bringing Rust ergonomics to the Go runtime. As someone currently building infra-automation tools (Dockit), the trade-off between Rust's safety and Go's simplicity is always a hot topic. This project addresses it in a very cool way. Will definitely follow the development
• stevefan1999
  Well that's why I decided to go C# for general purpose stuff
• tempaccount420
  Please commit your CLAUDE.md
• Menu

  kubb
  Oh look, a better syntax than the Go team could design!
• emehex
  Looks a lot like Swift! Awesome!
• bluebarbet
  Eats shoots and leaves.
• rednafi
  Go syntax and the Go runtime would be the perfect combo for me. Oh well...I love Rust for what it is, but for most of my projects, I can’t justify the added complexity. Sure, there are a bunch of things I miss from the Rust world when I’m working on large-scale distsys services in Go, but introducing Rust in that space would be a recipe for disaster.I guess the Go team knows that if they start adding everyone’s favorite Rust features, the language would become unrecognizable. So we’re not getting terser error-handling syntax or enums. Having union types would be nice too.But I work in platform engineering, so my needs are quite different from someone writing business logic in Go. I understand that having a more expressive syntax is nice when you’re writing complex business code, but in reality, that almost always comes with a complexity/fragility tradeoff. That’s part of the reason no one wants to use Rust to write their business logic, despite it being so much more expressive.For distsys, programming ergonomics matter far less compared to robustness and introspectability. So the Go runtime with Go syntax is perfect for this. But of course, that’s not true for all use cases.Sorry for the rant - completely uncalled for. This is a cool project nonetheless :)
• KaiLetov
  [dead]
• weiyong1024
  [dead]