So recently gave a talk at about and he mentions that in order to get feature in Go, we must first show enough of why its a problem, so it gets attention from the Go team, helping them understand our point of view, we need to convince them that is a real problem and that is the best possible solution. Russ Cox Gophercon “ The Future of Go ”, X examples Y (the community’s) Y X probably To accomplish that, we need to create the so called , basically posts about the described above. So here we are. Experience Reports Also, I would like to point out that this post does cover any concrete implementation examples but rather give a brief look at what some pkgs of the may look like if something like generics were implemented. NOT stdlib The Problem I like to describe the problem as: The lack of generics / way of declaring dynamic behavior while keeping type safety, forces the users to grow their code base by either: The use of code generation that just makes the code way more unreadable for the end-user and creates confusion due to various functions with similar names instead of having just one. — Sacrifice code readability and API complexity for type safety — tools The use of to avoid numerous functions with similar names but at the cost of type casting/assertion almost everywhere. — Sacrifice type safety for readability and reduced user API — interface{} (empty interfaces) In either case we’re making use of code that doesn’t actually belongs to our applications’s core logic, but rather acts like the glue that’s needed for pretty much every project. A little example I know what you’re thinking, just hold on for a second, this is from the pkg and it serves as a perfect example for the second from above. If we look deeper into the code that deals with that variable we encounter something like this… “This is not from the stdlib…” discordgo case handler Not so pretty, right? And there are to handle a , and just so it stays in mind, here the pkg maintainers decided to expose 1 function and leave the of type checking for themselves instead of exposing to the user. And all of that to add a handler. 37 more cases just single variable hard work 44 different functions with similar names simple The stdlib In the stdlib you can find some pkgs that could reduce their API’s immensely if and just if something like generics existed for Go, examples: sync/atomic Contains 29 pkg funcs with names like , , where could be , , , and so on . . . Add T CompareAndSwap T T Int32 Int64 Uint32 Uint64 Almost literally the whole pkg API would be: That just went from to . 29 functions with larger names just 5 with shorter names sync.Map (Go 1.9+) Yep, this awesome concurrent map is coming! with everywhere . . . interface{} In this case, the benefit is type safety since the API is simple enough. only math/rand Very similar to the case, instead of what about: sync/atomic Int, Intn, Int31, Int31n Same treatment goes for the type. rand.Rand math/big Maybe convert the , and types into a general type and compute the operations depending on the generic. Float Int Rat Number And some others applicable cases are: container/list container/heap container/ring could be more, just haven’t done enough research I also think that for example, let’s say we have this pretty common piece of code: I believe if there were generics this kind of operations could be improved /optimized at compile time since the compiler what the format of the data looks like. Example below. knows Same for all encoding/decoding stuff such as , is not included since all records are always returned in which means no reflection/type assertion at all. encoding/xml encoding/csv [][]string What I’m trying to say is that the stdlib be reduced and simplified in numerous places with the help of generics, and of course third-party pkgs as well. I hope this post at least serves as a clear example of what can be done with generics. CAN
