Go 1.18 Released With Generics, Fully Integrated Fuzzing, ~20% Performance Improvements

[bug77]

Rust has other differences in error handling that is better ergonomically (? operator) or more powerful (thiserror, anyhow etc). Go is not bad, just very verbose.

That's correct, for Result<T> and Rust. But Optional<T>(and Java) is still just as verbose as a tuple. Come to think of it, it's actually worse than a tuple, because Optional<T> doen't actually return the error.

Just to be clear: Go's error handling is verbose. When naively writing code, I ended up with half of the lines of code dealing with errors. But I still found the language productive despite that.

[RahulSundaram]

That's correct, for Result<T> and Rust. But Optional<T>(and Java) is still just as verbose as a tuple. Come to think of it, it's actually worse than a tuple, because Optional<T> doen't actually return the error.

Optional <T> is not really comparable to the standard error handling paths for other languages, so I left that out of the discussion. With minor language tweaks it is feasible to reduce the verbosity and there has been multiple proposals including one that was widely expected to be part of Go 2 but unfortunately wasn't adopted. I am still hoping this will improve in a future release. Result<T> is still superior IMO because it is a stronger type but Go in general has adopted a more weakly typed system so it won't be a large knock once they address the verbosity with some sort of syntax sugar.

[bug77]

Optional <T> is not really comparable to the standard error handling paths for other languages, so I left that out of the discussion. With minor language tweaks it is feasible to reduce the verbosity and there has been multiple proposals including one that was widely expected to be part of Go 2 but unfortunately wasn't adopted. I am still hoping this will improve in a future release. Result<T> is still superior IMO because it is a stronger type but Go in general has adopted a more weakly typed system so it won't be a large knock once they address the verbosity with some sort of syntax sugar.

Fair enough. Just like generics*, I'm all for doing it right rather than doing it fast.
At the same time, I realize that some missing features is the price we pay for Go's pretty impressive compile speeds. So I really don't have a problem living with a few kinks. After all, I've been living with Java since its 1.1 release

* Go's generics were also supposed to land in Go 2, but it turned out they could be implemented without breaking backwards compatibility and landed in 1.18 instead.