Hacker News Reader

Comment by SEJeff | Hacker News Reader

FWIW, the generics proposal was accepted:

https://github.com/golang/go/issues/43651

This will make a generic "slices" package much more trivial to write.

Finally! I honestly think that any statically-typed language without some minimal facility for generics - even C macros will do - isn't fit for purpose. I used Java and C# before the generics were introduced and you can't pay me enough to go back to that.

I think the reason Go is usable compared to early Java is because it does have generics for the builtin types -- slices (growable arrays), maps, and channels -- and for the builtin functions that operate on these types. And you can get really far with just slices and maps (which double as sets). You just can't add your own generic types or functions.

Error checking/handling is still a pain. Maybe generics will make that easier? Result type when?

How does a Result type making error handling easier? More reliable, sure, I buy that. But I write a bit of Rust these days, and error handling is definitely not easier. It's actually kind of an enormous pain in the ass, and it certainly seems to involve more lines of code than it does in Go (not just in my code, but in all the libraries I've read).

I've not had that problem. I would love to see the question mark operator in go because I think it is an elegant way to avoid a ton of boilerplate while still remaining a tad explicit about where errors can occur.

The most common thing you want to do with an error is bubble it up. IME Result types strike the least-bad compromise between making that too intrusive (if err != nil clutter) and making it too subtle (exceptions i.e. magic invisible control flow).

(I don't think Rust is the best example of result types; it's missing a lot of tools for working with them because Rust doesn't have HKT and functions aren't quite first-class because of their lifetime checker, so instead of using ordinary functions you end up using ad-hoc macros or language special cases like ?. Since Go is garbage collected they wouldn't have that problem)

Easier in that I don't have to force my team to use a static analysis tool just so people don't silently ignore errors.

CI works, but I have to set it up. For every project. And fix anything that was not developed with golangci-lint.

Hasn't there been several error handling proposals already?

Yes, and all have been rejected thus far. Finding the right balance for those things seems to be hard.

See:

Problem statement: https://go.googlesource.com/proposal/+/master/design/go2draf...

Proposal one: https://go.googlesource.com/proposal/+/master/design/go2draf...

Proposal two: https://go.googlesource.com/proposal/+/master/design/32437-t...

Reply on news.ycombinator.com