In our entire codebase, Go's generics have been used, like, 3 times, even though they were introduced almost 3 years ago. It's unsurprising: generics are most useful for writing your own custom containers, and generally, most projects don't need their own custom containers. It felt somewhat anticlimactic, considering all the anticipation.
Re:Go Should Sometimes Be a No-Go
by therealdrag0 on Saturday December 14, 2024 @03:04PM
(#42419096)
You often don’t need custom containers, but you need containers! I shouldn’t have to write my own custom method to map or for each over a list of items, etc.
You use it everyday, yet have not figured out that it has had generics for almost 3 years?
Re:Go Should Sometimes Be a No-Go
by retrodaredevil on Saturday December 14, 2024 @06:52AM
(#42416467)
Its generics aren't as advanced as Java's or any other language with generics for that matter. Plus most things are now only adding support for generics, so there's a fragmented ecosystem of code before and after generics were introduced.
Re:Go Should Sometimes Be a No-Go
by erik_seaberg on Saturday December 14, 2024 @04:19PM
(#42419530)
This. It's so frustrating that sync.Map isn't generic and reusing the builtin map API is impossible.
Its actually a good question on who needs generics. It makes code unreadable and was never really useful in commercial products.
Re:Go Should Sometimes Be a No-Go
by BreakfastB0b on Saturday December 14, 2024 @05:42AM
(#42416148)
Try writing Go without generics. No typed maps, arrays, slices, channels or function types. Only `interface{}`. Go always had generics, you just weren’t allowed to write your own until recently.
When you can have Go where the boilerplate is so bad you literally have to rely on generating source code files in order to maintain a sane level of productivity.
I use idiomatic Go every day and it's like being back in the 90s.