While "fuck generics" might be a low-resolution characterization, it's not entirely inaccurate, and the efforts of Taylor (and perhaps others) notwithstanding, as long as anyone is writing things like "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," there's reason to believe it's apt enough.
As other respondents to the GP comment show, it's not at all hard to come up with that ostensibly elusive picture if you're attending to it. So I suppose the obvious takeaway is that they're still not really attending to it. Which is fine, Go clearly has its niche and its fans, and people who don't want a pretty good Blub have other options.
This is frustrating. Substituting an insult for politely declining (while leaving the door open) is not "low-resolution" or "apt enough", it's almost entirely inaccurate. Politeness matters.
"low resolution" is a perfectly accurate description of "fuck generics", which like any two-word phrase can't entirely capture the attitude of the golang team, but nevertheless does seem to capture something of gestalt of their approach.
Finer resolution would be if fusiongyro had characterized the golang team as saying "fuck off developers who want generics," which wouldn't have been as polite as the phrase "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," but whose semantics are otherwise equivalent.
No. Unless someone finds a quote, the low order bit is that they didn't use the word "fuck" or any other swear word at all. You can't use the word "fuck" to accurately quote someone who didn't use that word.
He's explicitly rude. Sets up a strawman argument with the developer who can't imagine programming without generics. Mocks the people who want generics. Gasps in faux disbelief that it could be solved by types.
And then, when he goes in for the kill, to show once and for all that generics are pointless garbage:
He attacks type hierarchies and inheritance... completely missing the point by conflating parametric polymorphism and subtype polymorphism.
I think "Fuck generics" does a decent job of summarazing the rudeness, misinformation and ill-thought out arguments that the article contains about generics.
If you think you know how I ought to spend my time, come over and mow my lawn while I expound on the problems of dev entitlement culture.
I'm fine with RSC, Commander Pike, and those other benevolent dictators continuing to make much better decisions that I certainly ever would and more importantly to be super careful with what they add to the language. I write Swift, JS, objC, and Go. Go is the preferred language because it's simple and I have the entire SDK in my head.
I use Go a lot. I can't say i've ever run into not having generics being a huge deal.
Let's face it, for most programmers out there, generics is for type safe collections. If slices and maps weren't built into Go then i'd prolly have moved to something else.
That said i'd like to see more built in data structures
>You can't use the word "fuck" to accurately quote someone who didn't use that word.
Actually you very much can. It's the perfect word to describe certain attitudes, even if the person didn't use the word. It just translates to "who cares", "we don't need no stinking Generics", etc.
Bringing TOOWTDI from the realm of Python and Go to English, I see.
I suppose the argument I'm making does indeed depend on the premise that essential semantics of "fuck" can be conveyed in other ways. If you like, we could explore this by example.
My impression has always been that the Go core team is very open to the possible addition of generics, but also very wary of the very real downsides that generics have. Nothing I've ever seen from Rob or other core team members contradicts that. I'm open to citations if you can give any.
In contrast, a lot of Go users and proponents seem to be vehemently against generics, for wildly differing reasons. Some seem to be against them just for the lulz, others for crazy conspiracy theory or obscure philosophical reasons.
Me, I miss generics sometimes, but not enough to get riled up about it. I hope the Go folks come up with a clean, simple, and efficient way to get them, but until then I'm happy with the features Go has.
Yeah, god forbid someone is not absolute in their statements, but gives the benefit of the doubt. I'd say it only counts as "weasel" word when you don't say what you mean to say or want to hide your true intention/reality. But, for all the "maybe" etc, the parent made clear what he thinks: that the Go team doesn't care about Generics. He's not going two ways about it, for this to qualify as "weasel" wording.
>My impression has always been that the Go core team is very open to the possible addition of generics, but also very wary of the very real downsides that generics have.
Ten years on, and just some a handful of posts and "proposals" (not bigger than 1000-2000 words) written, for something that should have been there for the start (and for other languages with even less resources, like Julia, Nim, Rust, Crystal, Haxe, etc, has been), does not look like "very open".
I'd get the "We have a certain philosophy about Go, with which Generics don't match". Or "we don't like them, deal with it". But this back and forth, and ifs and buts ad inifinutum borders on the passive-aggresive treatment of the issue.
The "very real downsides" are the same old engineering tradeoffs every language had to make. "We'll only add them when we can have our cake and eat it too" is a weasel approach.
>Nothing I've ever seen from Rob or other core team members contradicts that. I'm open to citations if you can give any.
If by citations you mean "all talk but no walk" -- and even the talk being always hesitant and amounting to "we'll see", "if there is some magic way" (and the perennial "we're always open to it"), then yes, that has been a constant for a decade.
Now, I've just written ~3-5K lines of Go, and my company has just a few K or 10K lines of Go in production (mostly a C shop). But while I like a lot (static compilation for easy deployment, concurrency, standard library, go fmt, etc), one of the things that stops me using it more is the Generics situation.
I always assumed the Go developers were more worried about the effect of this feature on compilation time than binary size. After all, Go shipped static binaries only for years. But making the type checker more intelligent is going to imply more time spent type checking. It could also add time to parsing unless they choose the syntax carefully.
Do generics really add much compilation time? They sure do in C++ but that is because type checking C++ generics is based on substitution into the method body, which can have other generic calls inside of, which can lead to an exponential cascade and therefore exponential time compilation. Modern generics do not do that: a generic method invocation can be checked based on the type signature of the method alone.
For code generation you can do what Java does and erase generics (i.e. ignore them), in which case it will be no slower than code generation for manually erased code, which is what programmers have to write now. For good run-time performance you'd want to do specialisation, which may take longer but not much longer if the compiler is clever enough not to recompile the same method many times. C# does that and its implementation is actually fast enough for a JIT, let alone ahead of time compilation.
Even if you don't care about binary bloat (and I do care), it can introduce some of the same problems as dynamic typing.
If I am debugging some C++, and I find myself looking at templated function, then I can't easily see what types the template parameters are. Also it becomes hard to navigate to method calls etc.
C++ is a particularly bad example, because template metaprogramming is essentially typeless. But any form of polymorphism introduces these problems to some extent.
To be fair, that includes the run-time polymorphism already available in Go. Thus if generics allow us to replace some `interface{}` hacks with properly typed middle-men (even if they compile down to `interface{}`) then that would be genuine benefit.
Since C++ monomorphises every single template instantiation in a program, your debugger certainly should be able to tell you what the type parameters for that instance were!
A sufficiently smart linker will make that harder by removing functions that, byte for byte, are identical to one they already included in the executable ("identical code folding"; both gcc's gold linker and visual studio support that).
In my line of work I am very rarerly actully looking at a running executable with an interactive degger.
More often I am navigating through source code comparing it to logs, stack traces and other evidence that I can grab of what went wrong in production.
The source-level is important, because although I said "debugging" in my comment, what that very often comes to is first figuring out the intent of some other engineers from the thing they wrote -- and what they wrote is the source code, not the program state.
As other respondents to the GP comment show, it's not at all hard to come up with that ostensibly elusive picture if you're attending to it. So I suppose the obvious takeaway is that they're still not really attending to it. Which is fine, Go clearly has its niche and its fans, and people who don't want a pretty good Blub have other options.