I think in this context "ad hoc" refers to the context in which that syntax was added. IIRC the original creators were against generics ever being added to Golang, so they wouldn't have thought about their eventual introduction when choosing Go's initial syntax. The result is that the generics that eventually were added feel awkward and "bolted on" to many people.
(I don't have any strong opinions on it personally, because I'm not invested in that particular ecosystem. I'm merely attempting to distil what I've heard from other people.)
This is a truly unreal level of blub paradox and/or brown nosing. It's almost a complete inversion of reality.
Go's maintainers had to be beaten into bolting on a poorly-done implementation of polymorphism over like a decade. I can't imagine anyone who's used any language with polymorphism baked in to the design describing Go's implementation as "exceptionally well designed". If this is a Poe's law thing and you're just joking, then you got me.
Yeah. Go generics are quite crippled. I'm still very, very glad that they exist though - even crippled, they're a vast improvement.
I think they took a... rather extremely-conservative step towards what their generics will eventually be, at which point they'll probably be pretty reasonable. As it stands now they're kinda weird and and very incomplete, though thankfully simple (in behavior).
They did at least leave syntactic and semantic room to improve them though, so I think it'll happen eventually. It was cut off at a safe point. They just need to be brow-beaten further, hopefully this small success won't stop the pressure.
I'm a big fan of Go, have been using it since r59 (pre 1.0), professionally working with it the past ~8 years at one of the earliest companies to adopt it.
The fact that you cannot have a generic method at all, and instead have to rewrite methods as functions.. that seems like a pretty glaring flaw.
I'm happy Go got some form of generics, definitely, but they really do feel bolted on to the language.
I haven’t heard many gripes about the syntax, but I have heard plenty of gripes about how long it took them to add them. Frankly my biggest grievance with Go’s generics is the goofy dictionary implementation that makes performance difficult to reason about. I also think the people who complain the loudest about missing generics were often just unaware that there are other (often simpler) ways to achieve the same thing—it often feels like people were just angry that Go didn’t look exactly like $theirFaveLang. There are definitely some use cases that are improved by generics, but most complaints were about avoiding writing relatively simple loops (iterator chains are more readable in the trivial cases, but quickly become less readable particularly when you need to short circuit on errors and so on—a loop is often cleaner, clearer, and faster to implement).
Yeah, like I said, there are some cases where generics are genuinely helpful. It’s just a small percentage of the code I tend to write (generics have been out for quite a while, and I still avoid them in Go despite my familiarity with languages like Rust, TypeScript, etc that use them extensively).
(I don't have any strong opinions on it personally, because I'm not invested in that particular ecosystem. I'm merely attempting to distil what I've heard from other people.)