Personally, Rust only makes sense in scenarios that automatic memory management of any kind is either unwanted, or it is a quixotic battle making the target group think otherwise.

OS kernels, firmware, GPGPU,....

If it is the ML inspired type system, there are plenty of options among compiled managed languages, true Go isn't really on that camp, but whatever.

Or possibly you want to use a language you're familiar with in adjacent spaces (eg tools) or you want to tackle concurrency bugs more directly. There is more to rust than it's

Rust memory management is automatic. Object destructors run when the object exits scope without needing explicit management by the programmer

More like compiler assisted management, with compiler errors when the developer doesn't follow the teacher.

The compiler ensures you are writing memory safe code. Otherwise it rejects that code and helps you see the mistake you made. Why people are so upset when the compiler prevents them from building and shipping unusable code will always baffle me.

There is nothing automatic in that.

Asking a compiler to understand a programmers intent for underspecified mutability is beyond the halting problem.

Theres a huge gap between inefficient and unusable. There’s a lot of usable code out there that leaks memory. I’d argue compilers are hardly pressed by memory usage given the transient nature of their execution.

Saying rust is unusable is pretty extreme. Tons of serious applications and infrastructure have been using it in production for years generating lots of money and preventing CVEs.

Leaking memory is sometimes not a huge issue. Missile allocation is real. Undefined behaviour, seg faults, data races, etc from edge cases slow down development.

The promise of rust isn't that it's super fast to learn but once you have you never deal with a swath of issues ever again.

And that's speaking from a deficit. Rust is an excellent language to do language development. It has arguably the best tooling for it in the ecosystem in my opinion and a vibrant community for it. Some of the most recent languages have foundations in rust. That is likely to continue going forward.

I'd love a language that is a GC'd like go, but with the ML inspired type system, and still an imperative language. OCaml seems to be the closest thing to Rust in that regard, but it's not imperative.

OCaml has if/else, for loops, whiles, mutations, what are you missing?

There are also Swift, F# (Native AOT), Scala (Native, GraalVM, OpenJ9).

Nim is pretty close to that for me. It’s more pascal-ish inherited but has a sophisticated type system including case types similar to ML sum types and compile time.

That language is Swift.

Dealing with references you typically find in a compiler is not a problem for Rust. Arena allocation and indices are your friend.

Flattened asts are also faster than tree/pointer asts.

I wonder if this project can easily be integrated into Deno (built mainly in Rust)?

He also mentioned doing a line-for-line port. Assuming you could somehow manage that, you'd probably end up with something slower than JS (not entirely a joke). I'm a rust fanboy, but have to concede that Go was the be t choice here.

If it was a fresh compiler then the choice would be more difficult.