Hacker News

> 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

> 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.

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>

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?

Before typescript we had Haxe, and its still a "better language". But i guess marketing won, and worse it better. Shrug.

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.

How do compile errors propagate back from the target language to the source language?

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.

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.

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

Because it's inspired by Rust, but doesn't try to be Rust? And it's aimed at Go developers?

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.

Dunno. Impl block are very similar to Go methods. I dont think one if better than the other.

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.

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

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.

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/

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

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

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.

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

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

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.

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

Because it offers things where Go today doesn’t and never will?

Nuh uh