
Getting specific about generics - grey-area
https://emilymaier.net/words/getting-specific-about-generics/
======
guscost
This is the best outline of the Go generics issue I've seen. As an outsider to
the language (for now), thanks for writing this.

What's the current conversation on sharing binary code? Unless I'm missing
something, this is fundamentally incompatible with generic functions that are
optimized at compile time. Either the compiled version has to have
implementations for "every valid type" or the shared code must be recompiled
at the time it is consumed, right?

It looks like the Go ecosystem tends to discourage distributing precompiled
binary packages, so maybe this is not a real issue.

~~~
grok2
Going meta regarding tech articles, I find that it is easy to read some text-
heavy articles (this being one of them) while my eyes glaze over other text-
heavy articles (I couldn't easily follow Dave Cheney's article on the same
topic of Go generics a few days back, though with a slightly different focus
and much shorter). I've wondered what is it about specific
pages/articles/writing that make them flow nicely and make it easy to read --
is it the layout of the page (font/font-size/other styling) or is it how the
writing flows together or is it a factor of how much thought the author put
into presenting what they are thinking or is it me (time of day, interests,
etc). Maybe it is just everything!

~~~
guscost
While the typesetting helps here, I think a lot is due to the writing style.
Writing easy-to-read content is difficult, and it’s usually not that obvious
when you’re reading it, because you’re absorbing the concepts rather than
struggling with the language.

------
atombender
The author promotes code generation as a practical solution to some problems —
but doesn't mention the huge drawbacks for generics, which is why it's
generally not used.

The reason is that while you can generate a specific implementation when you
need it, all the _client_ code will still be using non-generic code. You can't
write a function that takes a Set(T) as argument, returns Set(T) as a return
value, or receives a Set(T) from a called function — unless you make _that_
part of your code generation pipeline. So the code generation becomes viral,
infecting each piece of code that wants to be generic. The entire language
needs to be transpiled.

You could lower the barrier considerably by supporting some kind of pluggable
preprocessing ("//go:preprocess my_generics_syntax_plugin"), but you'd still
run into the problem with combining packages from multiple sources that all
wanted to share the same generic types. They would all have to be transpiled
the same way.

~~~
jasonwatkinspdx
Within go this is not an issue, because go dependencies are source based.
Outside of go, assuming compiling a c compat lib, is more tricky, but I don't
immediately see why go generics can't reduce to the intuitive pattern you'd
get from selective/sparse template instantiation in your dependency before
it's included.

~~~
atombender
They're source-based, but that still requires that the caller (calling into a
package that's using generated code for generics) use the exact same
transpiration tech to generate its own code; if it doesn't, it can only
interface with the concrete instances of the generic types (e.g. Set_int or
whatever).

------
knocte
She mentions the C approach, C++ approach and Java approach. But I think she
should have added the C# approach: taking all the advantages of the Java
approach, without the slowness of casting.

~~~
owenjonesuk
I think the author is a woman, from the name Emily.

~~~
knocte
fixed, thanks

------
skybrian
Pointing to inlining and saying "problem solved" isn't really a solution
because inlining can lead to code bloat just like templates can. They amount
to generating the same thing at runtime.

For this to be an implementation detail, the compiler needs to be able to
choose not to inline sometimes.

