Comparing a language using garbage collection to one tackling the hard problem of providing memory safety without it doesn't make much sense. Rust is a low-level systems programming language while Go is in a different niche. If you don't need a low-level language, don't use Rust.
By the way, Go isn't memory safe either, since it has data races (like Java, unlike Rust) and doesn't prevent them from causing memory corruption (unlike Java) due to not designing it with statically verified safety for this or paying the performance cost of doing it dynamically.
1
4
This Tweet was deleted by the Tweet author. Learn more
That's not memory unsafe in Go though. It's not good language design, but that describes a lot more than the approach to option types in Go. That's a long conversation since there's so much of it and it's easy to be specific about it rather than tweeting without real substance.
This Tweet was deleted by the Tweet author. Learn more
I definitely agree, but I consider that an easy problem as part of designing any decent language. It doesn't necessarily require supporting user defined sum / union types but omitting that is pretty bad especially when many far less valuable / widely used features get included.
Providing memory safety in a highly usable general purpose language without resorting to garbage collection is a very difficult research problem that was tackled by Rust. The fact it's considered a practical language at all is an enormous success due to that design constraint.
On the other hand, not making every single reference nullable is not hard. Doing it via general purpose sum types makes a lot of sense, but it could also be done in the spirit of Go by hard-wiring support for non-nullable and nullable references rather than a reusable concept.