←back to thread

Constraints in Go

(bitfieldconsulting.com)
210 points gus_leonel | 2 comments | | HN request time: 0.431s | source
Show context
indulona ◴[] No.42163167[source]
i have been writing Go exclusively for 5+ years and to this day i use generics only in a dedicated library that works with arrays(slices in Go world) and provides basic functionality like pop, push, shift, reverse, filter and so on.

Other than that, generics have not really solved an actual problem for me in the real world. Nice to have, but too mush fuss about nothing relevant.

replies(10): >>42163189 #>>42163244 #>>42163415 #>>42163694 #>>42163834 #>>42164296 #>>42164983 #>>42165141 #>>42165270 #>>42165680 #
Groxx ◴[] No.42165141[source]
That's kinda the point. Generics are mostly a library concern, improving end-user experience and performance. End-user creation of generic types is relatively rare, and you can use them in very simple ways and that's almost always good enough because you don't need them to be maximally correct, only good enough.

For libraries (that adopt generics): yes they can be complicated. But using them is mostly zero-effort and gets rid of a ton of reflection.

replies(1): >>42166190 #
1. slimsag ◴[] No.42166190[source]
Unfortunately not everyone shares that opinion of their restricted use-cases.

I've seen ~100 line HTTP handler methods that are implemented using generics and then a bunch of type-specific parameters inevitably get added when the codepaths start to diverge and now you've got a giant spaghetti ball of generics to untangle, for what was originally just trying to deduplicate a few hundred lines of code.

replies(1): >>42166854 #
2. Groxx ◴[] No.42166854[source]
tbh I'll still take it over a similar Gordian knot with interfaces. At least you can tell the restrictions are met at compile time, rather than silently failing at runtime because you (and/or someone else in the past) didn't notice one edge case lodged somewhere surprising.