← Back to context

Comment by bestouff

14 hours ago

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.

22 comments

bestouff

Reply
andai  14 hours ago

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

  • gf000  14 hours ago

    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.

    • tux3  14 hours ago

      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.

      5 replies →

furyofantares  12 hours ago

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.

Imustaskforhelp  14 hours ago

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