I agree with everything. Compiled, GC language was weirdly missing. Also, I think that exceptions are not a particularly good error handling solution. But it’s weird to have a GC abstraction and goroutines built-in, yet not have support for any other abstraction for programmers. Just seems not well thought through language from the start.

True. But I would argue it makes more sense comparing python to rust than go to rust. Scope of use cases for python is more similar to rust. Other than that - sure, you can compare Haskell and x86 assembly too, though it would be of little use.

I’m not proficient enough in Go to say how good or bad it is, but I have tried it in the past and it made and immediately not like it. Verbose syntax, no null safety or any error handling, no templates at that time, people literally copy/pasted the code of containers for different data types and did find/replace on it. The only feature that was kind of convenient is goroutines. For my money, Kotlin and even Java were more modern looking and would prefer them to go any day. Also not apples to apples comparison, but far more similar than rust.

Is it just me or does comparing go and rust make very little sense? Other than being popular and relatively new, they have almost nothing else in common. Rust is multi domain language design to be as versatile as possible, very intentionally limited with a set of carefully chosen constraints. Not intended to be particularly easy or quick to use, by design. Go is very clearly web-biased, centered for backend, microservices, not universal by design. Syntax very C like, verbose, feels low level, but actually batteries included. Really, the only thing in common with rust is that it is very popular with developers, but again for very different reasons. People who like rust often hate go and vice versa. You can tell by the comments in this thread too.