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.
> Basically, why try to make Go more like Rust when Rust is right there?
Go gives you access to a compute- and memory-efficient concurrent GC that has few or no equivalents elsewhere. It's a great platform for problem domains where GC is truly essential (fiddling with spaghetti-like reference graphs), even though you're giving up the enormous C-FFI ecosystem (unless you use Cgo, which is not really Go in a sense) due to the incompatibilities introduced by Go's weird user-mode stackful fibers approach.
> 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.
No doubt a chatbot would be built faster if using a less strict language. It wasn't until I started working on larger Python codebases (written by good programmers) that I went "oh no, now I see how this is not an appropriate language".
Similar to how even smaller problems are better suited for just writing a bash script.
When you can have the whole program basically in your head, you don't need the guardrails that prevent problems. Similar to how it's easy to keep track of object ownership with pointers in a small and simple C program. There's no fixed size after which you can no longer say "there are no dangling pointers in this C program". (but it's probably smaller than the size where Python becomes a problem)
My experience writing TUI in Go and Rust has been much better in Rust. Though to be fair, the Go TUI libraries may have improved a lot by now, since my Go TUI experience is older than me playing with Rust's ratatui.
I've also found that traversing a third-party codebase in Python is extremely frustrating and requires lots of manual work (with PyCharm) whereas with Rust, it's just 'Go to definition/implementation' every time from the IDE (RustRover). The strong typing is a huge plus when trying to understand code you didn't write (and I'm not talking LLM-generated).
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" becomes indeterminate and GC is thus essential) but they'll be quite clear anyway.
> 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.
> 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.
<selfPromotion>That's why I created my own Option type package in NPM in case it's useful for anyone: https://www.npmjs.com/package/fp-sdk </selfPromotion>
TypeScript tried to accurately model (and expose to language services) the actual behavior of JS with regards to null/undefined. In its early days, TypeScript got a lot of reflexive grief for attempting to make JS not JS. Had the TS team attempted to pave over null/undefined rather than modeling it with the best fidelity they could at the time, I think these criticisms would have been more on the mark.
ReasonML / Melange / Rescript are a wholistic approach to this: The issue with stapling an option or result type into Typescript is that your colleagues and LLMs won't used it (ask me how I know).
Your readme would really benefit from code snippets illustrating the library. The context it currently contains is valuable but it’s more what I’d expect at the bottom of the readme as something more like historical context for why you wrote it.
Yup, in my TODO list (I've only recently published this package). For now you can just check the tests, or a SO answer I wrote a while ago (before I published the idea as an npm package): https://stackoverflow.com/a/78937127/544947
Golang does have a lot of weird flaws/gotchas, but as a language target for a compiler (transpiler) it's actually pretty great!
Syntax is simple and small without too many weird/confusing features, it's cross platform, has a great runtime and GC out of the box, "errors as values" so you can build whatever kind of error mechanism you want on top, green threading, speedy AOT compiler. Footguns that apply when writing Go don't apply so much when just using it as a compile target.
I've been writing a tiny toy functional language targeting Go and it's been really fun.
Go's defer is generally good, but it interacts weirdly with error handling (huge wart on Go language design) and has weird scoping rules (function scoped instead of scope scoped).
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.
To be fair, Go’s async story only works because there’s a prologue compiled into every single function that says “before I execute this function, should another goroutine run instead?” and you pay that cost on every function call. (Granted, that prologue is also used for other features like GC checks and stack size guards, but the point still stands.) Languages that aspire to having zero-cost abstractions can’t make that kind of decision, and so you get function coloring.
I'm not sure this is 100% correct. I haven't researched it but why would they perform such a check at runtime if it is 1)material and 2) can be done at compile time. However, even if it is, Go is only trying to be medium fast / efficient in the same realm as its garbage collected peers (Java and C#).
If you want to look at Rust peer languages though, I do think the direction the Zig team is heading with 0.16 looks like a good direction to me.
> why would they perform such a check at runtime if it is 1)material and 2) can be done at compile time
It can’t be done at compile time because it’s a scheduler. Goroutines are scheduled in userland, they map M:N to “real” threads, so something has to be able to say “this thread needs to switch to a different goroutine”.
There’s two ways of doing this:
- Signal-based preemption: Set an alarm (which requires a syscall) that will interrupt the thread after a timeout, transferring control to the goroutine scheduler
- Insert a check to see if a re-schedule needs to happen, in certain choice parts of the compiled code (ie. At function call entry points.)
Golang used to only do the second one (and you can go back to this behavior with - asyncpreemptoff=1), it’s why there was a well-known issue that if you entered an infinite loop in a goroutine and never called any functions, other goroutines would be starved. They fixed that by implementing signal-based preemption above too, but it’s done on top of the second approach.
Granted, the prologue needs to happen anyway, because go needs to check if the stack needs to grow, on every function call. So there’s basically a “hook” installed into this prologue that is a single branch, saying “if the scheduler needs to switch, jump there now”, and it basically works sort of like an atomic bool the scheduler writes to when it needs to re-schedule a goroutine… Setting it to true causes that function to jump to the scheduler.
Go has done a lot of work to make all of this fast, and you’re right that it only aspires to be a “medium-fast” language, and things like mandatory GC make these sort of prologues round to zero in the scheme of things. But it’s something other languages are fully within their rights to avoid, is my point (and it sounds like you agree.)
It sounds like you know about this / have researched it. Are you saying that any go function, even func add(x,y int) { return x + y}, is going to have such overhead in all situations? Why wouldn't Go just inline this for instance when it can? It seems like such an obvious optimization.
If go chooses to inline a function in general, then it doesn’t need to add the prologue to the inlined code, no. The prologue applies to all functions that remain after the inlining is done.
There’s also functions that can be marked as “nosplit” that skip the prologue as well.
But otherwise, it has to be in every function because you might be 1 byte away from the top of go’s (small) stack size, then you call that simple add function, and if the prologue isn’t run the stack will overflow. Go has tiny stacks by default that grow if they need to, with this prologue functioning as the “do I need to split/grow the stack?” check, so it needs to be every function that does it. The scheduler hook is just a single branch that’s part of the prologue, so it’s not that much more expensive if you’re doing the prologue anyway.
Both Borgo and now Lisette seem to act as though (T, error) returns are equivalent to a Result<T, error> sum type, but this is not semantically valid in all cases. The io.Reader interface's Read method, for example, specifies not only that (n!=0, io.EOF) is a valid return pattern, but moreover that it is not even an error condition, just a terminal condition. If you treat the two return values as mutually exclusive, you either can't see that you're supposed to stop reading, or you can't see that some number of valid bytes were placed into the buffer. This is probably well known enough to be handled specifically, but other libraries have been known to make creative use of the non-exclusivity in multiple return values too.
I gave Lisette a run today. I really like it, its a clear improvement to Go.
Here a few things that i noticed.
- Third party Go code support (like go-chi) is a absolute must have. This is THE feature that will possibly sky-rocket Lisette adoption. So something like stubs etc, maybe something like ReScript has for its JS interop (https://rescript-lang.org/docs/manual/external). The cli tool could probably infer and make these stubs semi-easily, as the go typesystem is kind of simple.
- The HM claim did confuse me. It does not infer when matching on an Enum, but i have to manually type the enum type to get the compiler to agree on what is being matched on. Note, this is a HARD problem (ocaml does this probably the best), and maybe outside the scope of Lisette, but maybe tweak the docs if this is the case. (eg. infers somethings, but not all things)
- Can this be adopted gradually? Meaning a part is Go code, and a part generated from Lisette. Something like Haxe perhaps. This ties to issue 1 (3rd party interop)
But so far this is the BEST compile to Go language, and you are onto something. This might get big if the main issues are resolved.
Variant qualification is a name resolution requirement - Lis follows Rust's scoping model where variants are namespaced under the enum. The implementation correctly infers the type, as shown e.g. in the hint `help: Use Shape.Circle to match this variant` My understanding is HM has nothing to say about this; it operates after names are resolved.
Re: Go third-party packages + incremental adoption, I'll do my best! Thanks for the encouragement.
To be fair, I feel like the language is widely criticized for this particular choice and it's not a pattern you tend to see with newer APIs.
It's a really valid FFI concern though! And I feel like superset languages like this live or die on their ability to be integrated smoothly side-by-side with the core language (F#, Scala, Kotlin, Typescript, Rescript)
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.
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.
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.
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.
I switch between languages a lot and I'm currently learning PHP. I've found that syntax similarities can be a hazard. I see "function" and I think I'm writing JavaScript, but then I try to concatenate strings with "+" and I realize I'm actually writing PHP and need to use ".". These challenges are especially noticeable in the early days of learning.
I think "Because (the dev) prefers it that way" is a satisfactory answer. Often, these small languages don't aim to be used in production and become the next big thing. They're made for fun and exploration's sake.
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.
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.
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.
Something that I don't understand about Rust, or these rustylangs, is the insistence of separating structs and methods. Don't get me wrong, I like named-impl blocks, but why are they the only option? Why can't I put an unnamed-impl block inside the struct? Or better yet just define methods on the struct? What's the point of this and why do these rustylangs never seem to change this?
1. Struct fields are really important in Rust because of auto-traits. Your life as a Rust programmer is easier if all fields fit on the screen, because one of them may be the reason your struct is `!Sync` or whatever.
2. Impl blocks can have different generic bounds from the struct itself, which is a nice shorthand for repeating the same generic bounds for a series of related methods. So you need to be able to write multiple per type anyway. It would he confusing if there was an “implied” impl block to look for as well.
3. It helps emphasize that Rust is a language that wants you to think about the shape of your data.
These don't seem like insurmountable challenges though. Unnamed impl blocks could work entirely within requirements. There could also be a lint to warn about any fields that are below trait definitions.
struct Example {
number: i32,
}
impl Example {
fn boo() {
println!("boo! Example::boo() was called!");
}
}
trait Thingy {
fn do_thingy(&self);
}
impl Thingy for Example {
fn do_thingy(&self) {
println!("doing a thing! also, number is {}!", self.number);
}
}
This could be expressed as:
struct Example {
number: i32,
impl {
fn boo() {
println!("boo! Example::boo() was called!");
}
}
impl Thingy {
fn do_thingy(&self) {
println!("doing a thing! also, number is {}!", self.number);
}
}
}
trait Thingy {
fn do_thingy(&self);
}
Keeping related things together is just infinitely more readable, in my opinion. In fact, the confusing nature of "impl <struct>" becoming "impl <trait> for <struct>" is obviated by internal impl blocks. Keeping them separate just seems so artificial, if not downright dogmatic.
I mean, these are in the same file almost all the time anyway, and in that case all it gives you is an extra level of indentation. I don't think it's nicer at all.
It's comments like this that remind me of the conciseness-at-all-costs dogma: that people genuinely treat indentation as some kind of eldritch horror; that they would genuinely prefer "impl X" becoming "impl Y for X" (thus making it difficult to parse at a glance because the target keeps shifting places) over it. It's bewildering.
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
Python has a performance problem. Most people may not need it, but many people do. Languages like Rust and Go are heavily adopted by Python programmers either trying to understand low-level concepts or looking for something more performant.
And this is before we talk about the real selling point, which is enabling portable heterogenous compute.
py2many can compile static python to mojo, apart from rust and golang.
Is it comprehensive? No. But it's deterministic. In the age of LLMs, with sufficient GPU you can either:
* Get the LLM to enhance the transpiler to cover more of the language/stdlib
* Accept the non-determinism for the hard cases
The way mojo solves it is by stuffing two languages into one. There are two ways to write a function for example.
I don't think the cost imposed by a transpiler is worse. In fact, it gets better over time. As the transpiler improves, you stop thinking about the generated code.
It does matter. It already has a pretty active community and thousands of people who follow the development closely, however, most won't commit until the entire language is fully opened... including me.
I think they should say that on their /opensource/mojo website if that's the plan. Rather, they are trying to gesture at "750k lines of open source code", when that code is only meant to be fed into their closed source MAX engine. That's a sleight of hand, bait and switch misdirection, and that's what feels icky to me.
Spy (https://github.com/spylang/spy) is an early version of this kind of thing. I believe it compiles to C though, kinda like Nim. Actually speaking of Nim, that's probably the most mature language in this space, although it's less pythonic than Spy
F# is very similar to python because it's based on indentation instead of curly braces. And with Fable you can transpile it to Rust (or Python even): https://github.com/fable-compiler/fable
This seems awesome. Seems to address many of my armchair complaints about both Go (inexpensive) and Rust (bloated/complex).
I'm curious what compilation times are like? Are there theoretical reasons it'd be order of magnitude slower than Go? I assume it does much less than the rust compiler...
Relatedly, I'd be curious to see some of the things from Rust this doesn't include, ideally in the docs. Eg I assume borrow checking, various data types, maybe async etc are intentionally omitted?
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
This is really cool! Go is so dead simple to learn but it just lacks a few features. I feel this really fills that specific gap.
Go with more expressive types and a bit stricter compiler to prevent footguns would be a killer backend language. Similar to what TypeScript was to JavaScript.
My 2 cents would be to make it work well with TypeScript frontends. I think TypeScript is so popular in backends because 1. you can share types between frontend code and backend code and 2. it's easy for frontend devs to make changes to backend code.
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
Having explored that approach (†), I can tell that generating Go assembly is harder than it seems.
†: I've tried to transpile Rust code through WASM into Go assembly, and I've also explored how to inject trampolines into Go binaries (which involves generating Go assembly too).
That is interesting, but I imagine Rust has features which can not be translated into Go's assembly. This language is specifically designed for Go interop; the logistics wouldn't be the same, though I still expect it to be difficult.
> I imagine Rust has features which can not be translated into Go's assembly
Why would there be? Go’s assembly might be lacking ways to make them optimally efficient, but that’s probably a given either way without an optimizing compiler backend.
Ditto. C# gets a bad rap due to its Windows-exclusive history, but it's now cross platform and has most of the features PL nerds are looking for. Strict nulls, pattern matching, a really mature and easy to use async ecosystem (it invented async/await), even a lot of the low level stuff is there (unsafe{} blocks ala rust and manual memory management where needed).
C# is nice, but it is nowhere near Rust in terms of safety or expressiveness. Thankfully they are finally adding discriminated unions (sum types) and other sorely missing features.
Unsafe in C# is much more dangerous than unsafe in Rust, precisely because it doesn’t actually color a function. It just allows its body to use pointers. This is why you have methods in the CLR called “DangerousFoo()”, and the compiler does nothing to prevent you from calling them.
Rust also has a much steeper learning curve. I can onboard an average developer that's familiar with Typescript and have them be productive in C# in a week.
This one is more subjective, but I also think C# has a more mature and painless web stack.
I love both languages but for me they each fill a different role.
I think this just says that TypeScript and C# are more similar languages than either is to Rust, which I would agree with. Rust's learning curve is not steep at all if you're coming from C or C++.
C# also has a pretty steep learning curve if you have to care about the things where Rust excels, like correctness or maximum efficiency (which typically does not include web stuff). I would even say that Rust is the easiest language in which to approach that level of correctness and efficiency.
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.
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 :)
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 about what string type I'm using. I want it to just work. But I want it to work correctly.
Lisette looks like it's in this exact category! It seems to combine the best aspects of both Rust and Go, which is a very promising endeavour. I'll have to take a proper look :)
Did MoonBit add support for some kind of shared memory concurrency like threads? I remember discovering the language, being very excited about it, and then learning it is single-threaded, which makes it a poor replacement for Rust IMHO.
I believe it's not as much moonbit's limitation as wasm-gc limitation – shared gc structs will have to be supported at low level in wasm-gc first and I don't think there are any concrete proposals for it yet?
They support native target (as well as js target) but wasm one was always the primary one.
Having said that they have (cooperative) async for native target only currently.
Personally I'm looking forward for them to self host it – not sure why they're still holding to ocaml compiler, the language seems sufficient to have moonbit written in moonbit. Together with it I'm waiting for proper open source – currently what the team is doing is a bit like what Meta sometimes does – internal development, no community development, they just dump updates as snapshots from time to time instead of normal, fully open development.
I'm also clinging on my last intel purchase (macbook pro) and unfortunatelly they don't provide intel builds for macOS just arm ones (even though they do for linux), which is a bit of a pain – but I think I'll just buy arm macbook before they'll support intel on macOS (and maybe they'll never do, which is fair). It's a small thing from moonbit perspective, but annoying and limiting a bit for me personally to work remotely only with it.
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.)
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).
For example, multicore OCaml is not free of race conditions.
The GC, while super efficient (pauses are in the milliseconds), is not suitable for hard realtime.
Still, where absolute max performance or realtime are not required, I'd choose OCaml as it is elegant & a pleasure to code in (personal opinion, ymmv).
Poor windows support, confusing and buggy tooling (yeah really), mediocre documentation, global type inference, weird obsession with linked lists leading to performance gotchas, difficult syntax (yeah really), small community.
I can expand on any of those if you disagree with them.
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 systems language without a runtime. But that's not the novel part. You could write horrors in C++ that approximate ML even without language support. There are eldritch libraries where some kind of pattern matching is done via generic lambdas.
The main difference is developper UX. Good tools, good error messages, quality of life. The novelty is making ML not painful.
> 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.
50 years of computing have proved pretty conclusively that less than that is wishful thinking at best. Large C++ programs, even with massive amounts of resources and tooling, can’t even get memory management correct.
No, this is actually nice to be honest. It's not a step backwards imo.
if I can incorporate Lisette into my golang projects for example, (Invoking rust code within Golang to me feels like a larger problem and Invoking C might be easier from my tinkering experiments) I feel like you are viewing this from a pure performance metric but to be honest, most things aren't necessary to be the fastest, the type system of rust/rust-alike languages can be beneficial to people as-it-is
Check out gleam, its based on erlang so it has a runtime involved, people love gleam because it gives them a bit more expressiveness in the type system from what I've heard.
I feel like these experiments are genuinely nice, Also perhaps a project like this can then slowly also invoke tinyGo (there was a recent discussion about it too) and could be compiled into tinyGo in future iterations to have no runtime essentially as well. People who love rust, love it, but most people really find it hard to get-into as compared to golang, I really love golang for its simplicity but I wish to tinker with rust too, so if Lisette combines both of these things and atleast makes me familiar with more rust without having to jump into too many hoops
It looks like more of a Rust-y way to write Go rather than a Go-ish way to run Rust. So I think the question is more about if you would choose it for something you're choosing Go for today, rather than for something you're choosing Rust for today.
borrowing syntax from rust is not what i like to read. Reading Rust code always gives me VisualBasic vibes. In VB you also declare variables like: dim a as Integer. and use let a=a+1
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
> Basically, why try to make Go more like Rust when Rust is right there?
Go gives you access to a compute- and memory-efficient concurrent GC that has few or no equivalents elsewhere. It's a great platform for problem domains where GC is truly essential (fiddling with spaghetti-like reference graphs), even though you're giving up the enormous C-FFI ecosystem (unless you use Cgo, which is not really Go in a sense) due to the incompatibilities introduced by Go's weird user-mode stackful fibers approach.
> 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
No doubt a chatbot would be built faster if using a less strict language. It wasn't until I started working on larger Python codebases (written by good programmers) that I went "oh no, now I see how this is not an appropriate language".
Similar to how even smaller problems are better suited for just writing a bash script.
When you can have the whole program basically in your head, you don't need the guardrails that prevent problems. Similar to how it's easy to keep track of object ownership with pointers in a small and simple C program. There's no fixed size after which you can no longer say "there are no dangling pointers in this C program". (but it's probably smaller than the size where Python becomes a problem)
My experience writing TUI in Go and Rust has been much better in Rust. Though to be fair, the Go TUI libraries may have improved a lot by now, since my Go TUI experience is older than me playing with Rust's ratatui.
I've also found that traversing a third-party codebase in Python is extremely frustrating and requires lots of manual work (with PyCharm) whereas with Rust, it's just 'Go to definition/implementation' every time from the IDE (RustRover). The strong typing is a huge plus when trying to understand code you didn't write (and I'm not talking LLM-generated).
sounds like a ide-noob theme song
[dead]
[flagged]
> 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" becomes indeterminate and GC is thus essential) but they'll be quite clear anyway.
> 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.
Rust does have GC in external crates, one was used for implementing Lua in Rust.
A Lua interpreter written in Rust+GC makes a lot of sense.
A simplified Rust-like language written in, and compiling to, Rust+GC makes a lot of sense too.
A simplified language written in Rust and compiling to Go is a no-go.
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.
[dead]
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.
<selfPromotion>That's why I created my own Option type package in NPM in case it's useful for anyone: https://www.npmjs.com/package/fp-sdk </selfPromotion>
TypeScript tried to accurately model (and expose to language services) the actual behavior of JS with regards to null/undefined. In its early days, TypeScript got a lot of reflexive grief for attempting to make JS not JS. Had the TS team attempted to pave over null/undefined rather than modeling it with the best fidelity they could at the time, I think these criticisms would have been more on the mark.
ReasonML / Melange / Rescript are a wholistic approach to this: The issue with stapling an option or result type into Typescript is that your colleagues and LLMs won't used it (ask me how I know).
how do you know?
Your readme would really benefit from code snippets illustrating the library. The context it currently contains is valuable but it’s more what I’d expect at the bottom of the readme as something more like historical context for why you wrote it.
Yup, in my TODO list (I've only recently published this package). For now you can just check the tests, or a SO answer I wrote a while ago (before I published the idea as an npm package): https://stackoverflow.com/a/78937127/544947
You can enable null safety in TypeScript, seems like a pretty good fix to me.
Its mediocre at best. Like in maths, how would i feel if addition would sometime actully be division. Thats hiw bad it is.
Well, isn’t division just substractive addition?
Where did we lose you? we're talking about two flavours of null, not one.
How would TS fix null in JS without violating its core principles of adhering to EcmaScript standards and being a superset of JS?
Maybe spit warnings when undefined is used? In the same way it does for when you use typeScript in a type-loose way.
But yeah it's a fair point. Sometimes I think I should just write my own lang (a subset of typescript), in the same fashion that Lisette dev has done.
You can already do this with strict type checking enabled and the NonNullable type.
You can't enforce it in any normal codebase because null is used extensively in the third party libraries you'll have to use for most projects.
"A typed nil pointer is not a nil pointer."
Golang does have a lot of weird flaws/gotchas, but as a language target for a compiler (transpiler) it's actually pretty great!
Syntax is simple and small without too many weird/confusing features, it's cross platform, has a great runtime and GC out of the box, "errors as values" so you can build whatever kind of error mechanism you want on top, green threading, speedy AOT compiler. Footguns that apply when writing Go don't apply so much when just using it as a compile target.
I've been writing a tiny toy functional language targeting Go and it's been really fun.
Go's defer is generally good, but it interacts weirdly with error handling (huge wart on Go language design) and has weird scoping rules (function scoped instead of scope scoped).
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.
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.
Other languages have ill considered shortcomings. Rust has ambitious shortcomings.
Go's async story is great, as there is no function coloring at all. That being said, I don't like Go's syntax very much. The runtime is great though.
To be fair, Go’s async story only works because there’s a prologue compiled into every single function that says “before I execute this function, should another goroutine run instead?” and you pay that cost on every function call. (Granted, that prologue is also used for other features like GC checks and stack size guards, but the point still stands.) Languages that aspire to having zero-cost abstractions can’t make that kind of decision, and so you get function coloring.
I'm not sure this is 100% correct. I haven't researched it but why would they perform such a check at runtime if it is 1)material and 2) can be done at compile time. However, even if it is, Go is only trying to be medium fast / efficient in the same realm as its garbage collected peers (Java and C#).
If you want to look at Rust peer languages though, I do think the direction the Zig team is heading with 0.16 looks like a good direction to me.
> why would they perform such a check at runtime if it is 1)material and 2) can be done at compile time
It can’t be done at compile time because it’s a scheduler. Goroutines are scheduled in userland, they map M:N to “real” threads, so something has to be able to say “this thread needs to switch to a different goroutine”.
There’s two ways of doing this:
- Signal-based preemption: Set an alarm (which requires a syscall) that will interrupt the thread after a timeout, transferring control to the goroutine scheduler
- Insert a check to see if a re-schedule needs to happen, in certain choice parts of the compiled code (ie. At function call entry points.)
Golang used to only do the second one (and you can go back to this behavior with - asyncpreemptoff=1), it’s why there was a well-known issue that if you entered an infinite loop in a goroutine and never called any functions, other goroutines would be starved. They fixed that by implementing signal-based preemption above too, but it’s done on top of the second approach.
Granted, the prologue needs to happen anyway, because go needs to check if the stack needs to grow, on every function call. So there’s basically a “hook” installed into this prologue that is a single branch, saying “if the scheduler needs to switch, jump there now”, and it basically works sort of like an atomic bool the scheduler writes to when it needs to re-schedule a goroutine… Setting it to true causes that function to jump to the scheduler.
Go has done a lot of work to make all of this fast, and you’re right that it only aspires to be a “medium-fast” language, and things like mandatory GC make these sort of prologues round to zero in the scheme of things. But it’s something other languages are fully within their rights to avoid, is my point (and it sounds like you agree.)
It sounds like you know about this / have researched it. Are you saying that any go function, even func add(x,y int) { return x + y}, is going to have such overhead in all situations? Why wouldn't Go just inline this for instance when it can? It seems like such an obvious optimization.
If go chooses to inline a function in general, then it doesn’t need to add the prologue to the inlined code, no. The prologue applies to all functions that remain after the inlining is done.
There’s also functions that can be marked as “nosplit” that skip the prologue as well.
But otherwise, it has to be in every function because you might be 1 byte away from the top of go’s (small) stack size, then you call that simple add function, and if the prologue isn’t run the stack will overflow. Go has tiny stacks by default that grow if they need to, with this prologue functioning as the “do I need to split/grow the stack?” check, so it needs to be every function that does it. The scheduler hook is just a single branch that’s part of the prologue, so it’s not that much more expensive if you’re doing the prologue anyway.
Before typescript we had Haxe, and its still a "better language". But i guess marketing won, and worse it better. Shrug.
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)...
Both Borgo and now Lisette seem to act as though (T, error) returns are equivalent to a Result<T, error> sum type, but this is not semantically valid in all cases. The io.Reader interface's Read method, for example, specifies not only that (n!=0, io.EOF) is a valid return pattern, but moreover that it is not even an error condition, just a terminal condition. If you treat the two return values as mutually exclusive, you either can't see that you're supposed to stop reading, or you can't see that some number of valid bytes were placed into the buffer. This is probably well known enough to be handled specifically, but other libraries have been known to make creative use of the non-exclusivity in multiple return values too.
You are right, and thank you for pointing this out. I've opened an issue:
https://github.com/ivov/lisette/issues/12
I have a few approaches in mind and will be addressing this soon.
I gave Lisette a run today. I really like it, its a clear improvement to Go.
Here a few things that i noticed.
- Third party Go code support (like go-chi) is a absolute must have. This is THE feature that will possibly sky-rocket Lisette adoption. So something like stubs etc, maybe something like ReScript has for its JS interop (https://rescript-lang.org/docs/manual/external). The cli tool could probably infer and make these stubs semi-easily, as the go typesystem is kind of simple.
- The HM claim did confuse me. It does not infer when matching on an Enum, but i have to manually type the enum type to get the compiler to agree on what is being matched on. Note, this is a HARD problem (ocaml does this probably the best), and maybe outside the scope of Lisette, but maybe tweak the docs if this is the case. (eg. infers somethings, but not all things)
- Can this be adopted gradually? Meaning a part is Go code, and a part generated from Lisette. Something like Haxe perhaps. This ties to issue 1 (3rd party interop)
But so far this is the BEST compile to Go language, and you are onto something. This might get big if the main issues are resolved.
Thanks for trying it out!
Variant qualification is a name resolution requirement - Lis follows Rust's scoping model where variants are namespaced under the enum. The implementation correctly infers the type, as shown e.g. in the hint `help: Use Shape.Circle to match this variant` My understanding is HM has nothing to say about this; it operates after names are resolved.
Re: Go third-party packages + incremental adoption, I'll do my best! Thanks for the encouragement.
To be fair, I feel like the language is widely criticized for this particular choice and it's not a pattern you tend to see with newer APIs.
It's a really valid FFI concern though! And I feel like superset languages like this live or die on their ability to be integrated smoothly side-by-side with the core language (F#, Scala, Kotlin, Typescript, Rescript)
To be honest you could easily mark this as an additional (adt) type if that suits you better. Its a halting situation no matter how you twist it.
Also: goeval https://github.com/dolmen-go/goeval
How do compile errors propagate back from the target language to the source language?
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.
Go has apparently got //line directives, and this project uses them.
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.
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.
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
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.
I switch between languages a lot and I'm currently learning PHP. I've found that syntax similarities can be a hazard. I see "function" and I think I'm writing JavaScript, but then I try to concatenate strings with "+" and I realize I'm actually writing PHP and need to use ".". These challenges are especially noticeable in the early days of learning.
Skip php, its a useless shitty lang to learn in 2026.
Because it's inspired by Rust, but doesn't try to be Rust? And it's aimed at Go developers?
Yea I think this is targeted at Go devs. Im in the target audience and I like it, not sure id ever use it, but I like it.
Rust devs continued belief that they're the center of the universe is amusing.
I think "Because (the dev) prefers it that way" is a satisfactory answer. Often, these small languages don't aim to be used in production and become the next big thing. They're made for fun and exploration's sake.
Same. I started writing a high level Rust that was based on typescript.
Then realized Rust wasn't that hard.
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.
Its rust like. There is no borrow checking etc. Rust syntax is verbose so why copy it nilly willy when you dont need to.
Look at gleam, its a fresh take on nice dxp
It does not matter, you (rust devs) won't use anything else either way and other people just don't care
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.
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.
Something that I don't understand about Rust, or these rustylangs, is the insistence of separating structs and methods. Don't get me wrong, I like named-impl blocks, but why are they the only option? Why can't I put an unnamed-impl block inside the struct? Or better yet just define methods on the struct? What's the point of this and why do these rustylangs never seem to change this?
There are several reasons.
1. Struct fields are really important in Rust because of auto-traits. Your life as a Rust programmer is easier if all fields fit on the screen, because one of them may be the reason your struct is `!Sync` or whatever.
2. Impl blocks can have different generic bounds from the struct itself, which is a nice shorthand for repeating the same generic bounds for a series of related methods. So you need to be able to write multiple per type anyway. It would he confusing if there was an “implied” impl block to look for as well.
3. It helps emphasize that Rust is a language that wants you to think about the shape of your data.
These don't seem like insurmountable challenges though. Unnamed impl blocks could work entirely within requirements. There could also be a lint to warn about any fields that are below trait definitions.
This could be expressed as: Keeping related things together is just infinitely more readable, in my opinion. In fact, the confusing nature of "impl <struct>" becoming "impl <trait> for <struct>" is obviated by internal impl blocks. Keeping them separate just seems so artificial, if not downright dogmatic.I mean, these are in the same file almost all the time anyway, and in that case all it gives you is an extra level of indentation. I don't think it's nicer at all.
It's comments like this that remind me of the conciseness-at-all-costs dogma: that people genuinely treat indentation as some kind of eldritch horror; that they would genuinely prefer "impl X" becoming "impl Y for X" (thus making it difficult to parse at a glance because the target keeps shifting places) over it. It's bewildering.
Dunno. Impl block are very similar to Go methods. I dont think one if better than the other.
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.
The compiler will be open-sourced in a few months.
There is a question of what benefit would it bring even if its open sourced?
Static python can transpile to mojo. I haven't seen an argument on what concepts can only be expressed in mojo and not static python?
Borrow checker? For sure. But I'm not convinced most people need it.
Mojo therefore is a great intermediate programming language to transpile to. Same level of abstraction as golang and rust.
Python has a performance problem. Most people may not need it, but many people do. Languages like Rust and Go are heavily adopted by Python programmers either trying to understand low-level concepts or looking for something more performant.
And this is before we talk about the real selling point, which is enabling portable heterogenous compute.
This is why transpilers exist.
py2many can compile static python to mojo, apart from rust and golang.
Is it comprehensive? No. But it's deterministic. In the age of LLMs, with sufficient GPU you can either:
The way mojo solves it is by stuffing two languages into one. There are two ways to write a function for example.I don't think the cost imposed by a transpiler is worse. In fact, it gets better over time. As the transpiler improves, you stop thinking about the generated code.
At this point, it might be moot. Too many people are assuming it's still a closed-source thing and will dismiss it.
Due to the closed source nature, every mojo announcement I see I think "whatever, next"
If the actual intent is to open-source, just do it, dump out whatever you have into a repo, call it 'beta'
It does matter. It already has a pretty active community and thousands of people who follow the development closely, however, most won't commit until the entire language is fully opened... including me.
Valuable technologies are not so easily dismissed
I think they should say that on their /opensource/mojo website if that's the plan. Rather, they are trying to gesture at "750k lines of open source code", when that code is only meant to be fed into their closed source MAX engine. That's a sleight of hand, bait and switch misdirection, and that's what feels icky to me.
Spy (https://github.com/spylang/spy) is an early version of this kind of thing. I believe it compiles to C though, kinda like Nim. Actually speaking of Nim, that's probably the most mature language in this space, although it's less pythonic than Spy
Nim looks a lot like Python with a first-class type system and compiles to many different targets, including wasm and C.
Static python as described in this skill.
https://github.com/py2many/static-python-skill
Here you are. https://github.com/google/grumpy
Last commit was 9 years ago though, so targets Python 2.7.
Amazing people still keep discovering it. And google search fails to surface working implementations.
"Python to rust transpiler" -> pyrs (py2many is a successor) "Python to go transpiler" -> pytago
Grumpy was written around a time when people thought golang would replace python. Google stopped supporting it a decade ago.
Even the 2022 project by a high school student got more SEO
https://github.com/py2many/py2many/issues/518
F# is very similar to python because it's based on indentation instead of curly braces. And with Fable you can transpile it to Rust (or Python even): https://github.com/fable-compiler/fable
What benefit would it bring? There's already https://cython.org/
Cython uses C-API. This one doesn't.
You want to use the Go runtime for example
This seems awesome. Seems to address many of my armchair complaints about both Go (inexpensive) and Rust (bloated/complex).
I'm curious what compilation times are like? Are there theoretical reasons it'd be order of magnitude slower than Go? I assume it does much less than the rust compiler...
Relatedly, I'd be curious to see some of the things from Rust this doesn't include, ideally in the docs. Eg I assume borrow checking, various data types, maybe async etc are intentionally omitted?
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
This is really cool! Go is so dead simple to learn but it just lacks a few features. I feel this really fills that specific gap.
Go with more expressive types and a bit stricter compiler to prevent footguns would be a killer backend language. Similar to what TypeScript was to JavaScript.
My 2 cents would be to make it work well with TypeScript frontends. I think TypeScript is so popular in backends because 1. you can share types between frontend code and backend code and 2. it's easy for frontend devs to make changes to backend code.
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
Having explored that approach (†), I can tell that generating Go assembly is harder than it seems.
†: I've tried to transpile Rust code through WASM into Go assembly, and I've also explored how to inject trampolines into Go binaries (which involves generating Go assembly too).
That is interesting, but I imagine Rust has features which can not be translated into Go's assembly. This language is specifically designed for Go interop; the logistics wouldn't be the same, though I still expect it to be difficult.
> I imagine Rust has features which can not be translated into Go's assembly
Why would there be? Go’s assembly might be lacking ways to make them optimally efficient, but that’s probably a given either way without an optimizing compiler backend.
I’m sold just for proper enumeration support.
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.
Horrible news for me, I quite like the idea and syntax, but it also reminds me of my wife which I am currently divorcing.
Not sure I'd like the constant reminder.
This is what go should have been, instead of a mess it is today
Well that's why I decided to go C# for general purpose stuff
Ditto. C# gets a bad rap due to its Windows-exclusive history, but it's now cross platform and has most of the features PL nerds are looking for. Strict nulls, pattern matching, a really mature and easy to use async ecosystem (it invented async/await), even a lot of the low level stuff is there (unsafe{} blocks ala rust and manual memory management where needed).
C# is nice, but it is nowhere near Rust in terms of safety or expressiveness. Thankfully they are finally adding discriminated unions (sum types) and other sorely missing features.
Unsafe in C# is much more dangerous than unsafe in Rust, precisely because it doesn’t actually color a function. It just allows its body to use pointers. This is why you have methods in the CLR called “DangerousFoo()”, and the compiler does nothing to prevent you from calling them.
Rust also has a much steeper learning curve. I can onboard an average developer that's familiar with Typescript and have them be productive in C# in a week.
This one is more subjective, but I also think C# has a more mature and painless web stack.
I love both languages but for me they each fill a different role.
I think this just says that TypeScript and C# are more similar languages than either is to Rust, which I would agree with. Rust's learning curve is not steep at all if you're coming from C or C++.
C# also has a pretty steep learning curve if you have to care about the things where Rust excels, like correctness or maximum efficiency (which typically does not include web stuff). I would even say that Rust is the easiest language in which to approach that level of correctness and efficiency.
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.
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.
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...
Looks beautiful! Any plans to make it self compile?
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?
Because it offers things where Go today doesn’t and never will?
Go is epitome of simplicity. Why on earth would you want to put another abstraction on top of it?
There is Solod project that is Go subset that compiles into C that is more interesting https://github.com/solod-dev/solod
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 :)
Are you a bot?
Nah made the same comment on r/golang
Eats shoots and leaves.
Oh look, a better syntax than the Go team could design!
Nuh uh
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.
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 about what string type I'm using. I want it to just work. But I want it to work correctly.
Lisette looks like it's in this exact category! It seems to combine the best aspects of both Rust and Go, which is a very promising endeavour. I'll have to take a proper look :)
MoonBit [0] is the best/future complete/active “rust with gc”.
[0] https://www.moonbitlang.com
Did MoonBit add support for some kind of shared memory concurrency like threads? I remember discovering the language, being very excited about it, and then learning it is single-threaded, which makes it a poor replacement for Rust IMHO.
I believe it's not as much moonbit's limitation as wasm-gc limitation – shared gc structs will have to be supported at low level in wasm-gc first and I don't think there are any concrete proposals for it yet?
They support native target (as well as js target) but wasm one was always the primary one.
Having said that they have (cooperative) async for native target only currently.
Personally I'm looking forward for them to self host it – not sure why they're still holding to ocaml compiler, the language seems sufficient to have moonbit written in moonbit. Together with it I'm waiting for proper open source – currently what the team is doing is a bit like what Meta sometimes does – internal development, no community development, they just dump updates as snapshots from time to time instead of normal, fully open development.
I'm also clinging on my last intel purchase (macbook pro) and unfortunatelly they don't provide intel builds for macOS just arm ones (even though they do for linux), which is a bit of a pain – but I think I'll just buy arm macbook before they'll support intel on macOS (and maybe they'll never do, which is fair). It's a small thing from moonbit perspective, but annoying and limiting a bit for me personally to work remotely only with it.
You can use Ocaml today and achieve all the correctness
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).
For example, multicore OCaml is not free of race conditions. The GC, while super efficient (pauses are in the milliseconds), is not suitable for hard realtime.
Still, where absolute max performance or realtime are not required, I'd choose OCaml as it is elegant & a pleasure to code in (personal opinion, ymmv).
Poor windows support, confusing and buggy tooling (yeah really), mediocre documentation, global type inference, weird obsession with linked lists leading to performance gotchas, difficult syntax (yeah really), small community.
I can expand on any of those if you disagree with them.
> all the correctness
When did OCaml get affine types? Or unique references?
https://oxcaml.org/
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 systems language without a runtime. But that's not the novel part. You could write horrors in C++ that approximate ML even without language support. There are eldritch libraries where some kind of pattern matching is done via generic lambdas.
The main difference is developper UX. Good tools, good error messages, quality of life. The novelty is making ML not painful.
> 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.
Memory safety is not the same a scorrectness and more advanced type is also not the same thing as correctness.
50 years of computing have proved pretty conclusively that less than that is wishful thinking at best. Large C++ programs, even with massive amounts of resources and tooling, can’t even get memory management correct.
That Rust gives you correctness is very misleading claim.
These are all great qualities of rust, but they would not have been enough to make a dent.
Being memory safe without being managed is what makes rust a truly novel and interesting language for which it rightfully gets the hype.
No, this is actually nice to be honest. It's not a step backwards imo.
if I can incorporate Lisette into my golang projects for example, (Invoking rust code within Golang to me feels like a larger problem and Invoking C might be easier from my tinkering experiments) I feel like you are viewing this from a pure performance metric but to be honest, most things aren't necessary to be the fastest, the type system of rust/rust-alike languages can be beneficial to people as-it-is
Check out gleam, its based on erlang so it has a runtime involved, people love gleam because it gives them a bit more expressiveness in the type system from what I've heard.
I feel like these experiments are genuinely nice, Also perhaps a project like this can then slowly also invoke tinyGo (there was a recent discussion about it too) and could be compiled into tinyGo in future iterations to have no runtime essentially as well. People who love rust, love it, but most people really find it hard to get-into as compared to golang, I really love golang for its simplicity but I wish to tinker with rust too, so if Lisette combines both of these things and atleast makes me familiar with more rust without having to jump into too many hoops
It looks like more of a Rust-y way to write Go rather than a Go-ish way to run Rust. So I think the question is more about if you would choose it for something you're choosing Go for today, rather than for something you're choosing Rust for today.
[dead]
[dead]
Looks a lot like Swift! Awesome!
Please commit your CLAUDE.md
[dead]
[flagged]
[dead]
borrowing syntax from rust is not what i like to read. Reading Rust code always gives me VisualBasic vibes. In VB you also declare variables like: dim a as Integer. and use let a=a+1