←back to thread

Constraints in Go

(bitfieldconsulting.com)
210 points gus_leonel | 2 comments | 17 Nov 24 08:44 UTC | HN request time: 1.313s | source
Show context
indulona ◴[17 Nov 24 09:59 UTC] 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 #
1. gregwebs ◴[17 Nov 24 12:24 UTC] No.42163834[source]▶
There’s an existing ecosystem that already works with the constraints of not having generics. If you can write all your code with that, then you won’t need generic much. That ecosystem was created with the sweat of library authors, dealing with not having generics and also with users learning to deal with the limitations and avoid panics.

Generics have been tremendously helpful for me and my team anytime we are not satisfied with the existing ecosystem and need to write our own library code. And as time goes on the libraries that everyone uses will be using generics more.

replies(1): >>42169668 #
2. marcus_holmes ◴[18 Nov 24 04:15 UTC] No.42169668[source]▶
The libraries will, yes. But folks just using the libraries still won't need generics.

If you know your concrete types, they're just not that useful.

Even in home-grown libraries, I find generics to be a convenience rather than a necessity. It's useful to not have my library code so tightly coupled to my non-library code. But it does also come with a cost: every so often I have to check what the library actually does because being loosely coupled meant that iterations in the rest of the system didn't automatically have to involve the library, so the library code can get left behind.