Bit negative. I agree on some points (e.g. error checks on enums); other points, you simply have to learn to adapt to (initialization). The rest are (very) cosmetic preferences (overloading brackets; the compiler doesn't inform about typos).
The biggest negative for me the author overlooked is the lack of non-nullable types. The positive thing the author doesn't mention is that it's easy to write in, nor that threading is really easy.
> The biggest negative for me the author overlooked is the lack of non-nullable types.
I did mention the pervasiveness of nil and the lack of sum types as negatives.
> The positive thing the author doesn't mention is that it's easy to write in
I didn't mention this because I think the "ease of writing" is superficial; thinking through edge cases is something that frequently consumes a lot more time than literally typing the code out.
Also, given that the compiler doesn't really give any useful suggestions when your code is wrong (something that happens more often when you're less experienced in a language, like I was here), ease of writing takes a significant hit.
> nor that threading is really easy.
I didn't cover this because I haven't had the chance to work on much code using goroutines, and I've tried to ground the post in what I have actual experience with.
In Rust the edge cases are often more apparent because you're often forced to at least acknowledge them. So while you do have to put thought into handling them, you don't have to spend much thought finding or worrying about missing them.
Compared to Go, Rust makes many kinds of edge cases mechanically discoverable. You cannot forget them.
As in Go, you can of course handle them poorly, and sometimes this is an ergonomic win. E.g. it's basically always trivial to panic (same as missing some critical cases in Go) or return the wrong value (literally all other cases in Go).
The primary difference isn't how you handle them, it's if you are aware that there are edge cases. Go is extremely lax here.
What are you trying to communicate here? That releasing one of the most popular languages in the industry without sum types is a form of original sin, and if they ever added enums and a match statement, you're be more right to hate the language? Some of the logic in these threads is just baffling to me.
Maybe? Generics were the most egregious absence, since it's challenging to express some constructs in a static language without them. Nullable types are another issue that other modern languages (e.g., C# and TypeScript) are trying to solve, but we it's a difficult issue to tackle when nil is already pervasive in the language.
I think generics are a great addition to the language, and I'd love to see sum types (which would allow Option to circumvent nullable types), but I think that's much less likely.
The biggest negative for me the author overlooked is the lack of non-nullable types. The positive thing the author doesn't mention is that it's easy to write in, nor that threading is really easy.