Here is a very common problem with generics... Everyone understands the concept of a tuple/pair. Pretty easy, you have getElement0 and getElement1 methods.
Now a piece of code needs a KeyValue pair used in a map. So, with generics someone says, oh, I already have this pair class, I’ll just use that and declare my types, so Pair<int,string>. This is wrong, you need to write the code for KeyValue that contains a Pair, with KeyValue<int,string> The former would work but then the code is littered with getElement0 instead of getKey It works but much more difficult to understand and maintain. So even when using generics you still need to be able to write understandable code. Having a generic KeyValue pair when working with maps makes the code much more readable and type safe than for example working with sync.Map today. Generics are wonderful when done simply. Because of Gos static compilation and coupled with a user base that doesn’t truly understand the Go performance profile (hint, it is not as fast as Java and never will be because it can’t - but more importantly it doesn’t matter) Go is going to end of with something as complex and obtuse as C++ templates (with concepts). Not a good fit for Gos development community or its long-term viability. Go doesn’t need generics, at least not full featured ones. > On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki <o...@fairbe.org> wrote: > > On Tue, 18 Sep 2018 04:38:55 -0700 (PDT) > ffm2...@web.de wrote: > >> Every average Joe Java boilerplate coder gets along with generics. > Barely, if at all, understanding whats under. > > "Smart Copy Paste ... A book for normal programmers" > https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM > >> But even there you can manage without thinking and just doing >> trial and error if you wanted to. > > OP, I and many others want to defend Gol off this very attitude. > Go is among few contemporary languages that allows me to fully > understand what my resulting binary will do, down to the syscall > level. Thats precious. > > >> I think it will neither be tricky to make use of nor to read the code. > > I claim opposite. All and any Gopher will be expected to cope with hard to > read and yet harder to understand generic code. Even if she herself will > vowed not to use it. In a short while we all will be obeying first Java's > commandment "thou shalt not peek under". > > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
