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

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.

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.

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