5 ms·

FWIW, the generics proposal was accepted: https://github.com/golang/go/issues/43651 https://github.com/golang/go/issues/43651 This will make a generic "slices

by SEJeff 6y ago

FWIW, the generics proposal was accepted: https://github.com/golang/go/issues/43651 https://github.com/golang/go/issues/43651 This will make a generic "slices" package much more trivial to write.

CameronNemo 6y ago
Error checking/handling is still a pain. Maybe generics will make that easier? Result type when?
- tptacek 6y ago
  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).
  - jjnoakes 6y ago
    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.
  - lmm 6y ago
    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)
  - CameronNemo 6y ago
    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.
- ampdepolymerase 6y ago
  Hasn't there been several error handling proposals already?
  - kyrra 6y ago
    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/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... Proposal one: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md https://go.googlesource.com/proposal/+/master/design/go2draf... Proposal two: https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md https://go.googlesource.com/proposal/+/master/design/32437-t...
Pxtl 6y ago
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.
- benhoyt 6y ago
  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.

by SEJeff 6y ago

FWIW, the generics proposal was accepted: https://github.com/golang/go/issues/43651 https://github.com/golang/go/issues/43651 This will make a generic "slices" package much more trivial to write.

CameronNemo 6y ago

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

tptacek 6y ago
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).
- jjnoakes 6y ago
  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.
- lmm 6y ago
  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)
- CameronNemo 6y ago
  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.
ampdepolymerase 6y ago
Hasn't there been several error handling proposals already?
- kyrra 6y ago
  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/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... Proposal one: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md https://go.googlesource.com/proposal/+/master/design/go2draf... Proposal two: https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md https://go.googlesource.com/proposal/+/master/design/32437-t...

Pxtl 6y ago

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.

benhoyt 6y ago
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.