Why no generics in Go?

Question

this answer you will find here: http://golang.org/doc/faq#generics

Why does Go not have generic types?

Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.

Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.

This remains an open issue.

Go 2

There is a draft design for generics at https://blog.golang.org/go2draft.

Go 1

Russ Cox, one of the Go veterans wrote a blog post entitled The Generic Dilemma, in which he asks

…do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

Slow programmers being the result of no generics, slow compilers are caused by C++ like generics and slow execution times stem from the boxing-unboxing approach that Java uses.

The fourth possibility not mentioned in the blog is going the C# route. Generating the specialized code like in C++, but at runtime when it is needed. I really like it, but Go is very unlike C# so this is probably not applicable at all…

I should mention that using the popular Java 1.4 like technique of generic programming in go that casts to interface{} suffers from exactly the same problems as boxing-unboxing (because that's what we are doing), besides the loss of compile time type safety. For small types (like ints) Go optimizes the interface{} type so that a list of ints that were cast to interface{} occupies a contiguous area of memory and takes only twice as much space as normal ints. There is still the overhead of runtime checks while casting from interface{}, though. Reference.

All projects that add generic support to go (there is several of them and all are interesting) uniformly go the C++ route of compile time code generation.

To add to and update the excellent answers by @Vinzenz and @user7610.

Although it's far from certain, after over a decade of work it looks like a design for parametric polymorphism, what is colloquially but misleadingly called generics, is coming in the next year or two. It was a very hard problem to find a design that works within the existing language and feels as if it belongs, but Ian Taylor invested a phenomenal amount of energy into the problem and it looks like the answer is now in reach. See https://evrone.com/rob-pike-interview.

"Type Parameters - Draft Design" supports the use of type parameters where you can read functions that handle incoming parameters without depending on the type specified in the function declaration. See https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md.

For example, the PrintSlice function receives a slice of integers or strings and prints it. See https://www.jetbrains.com/help/go/how-to-use-type-parameters-for-generic-programming.html.

package main

import "fmt"

func PrintSlice(type T)(s []T) {
    for _, v := range s {

        fmt.Print(v)
    }
}

func main() {
    PrintSlice([]int{1, 2, 3, 4, 5, 6, 7, 8, 9})
    PrintSlice([]string{"a", "b", "c", "d"})
}

You can test this example here https://go2goplay.golang.org/p/I09qwKNjxoq. This playground works just like the usual Go playground, but it supports generic code. See https://blog.golang.org/generics-next-step.

Parametric polymorphism basically means 'this function or data structure works identically with any type". That's what we also call generics. Eg the length of an array doesn't depend on what's in the array. See https://news.ycombinator.com/item?id=23560798.

The earliest that generics could be added to Go would be the Go 1.17 release, scheduled for August 2021. See https://blog.golang.org/generics-next-step.

Actually, according to this post:

Many people have concluded (incorrectly) that the Go team’s position is “Go will never have generics.” On the contrary, we understand the potential generics have, both to make Go far more flexible and powerful and to make Go far more complicated. If we are to add generics, we want to do it in a way that gets as much flexibility and power with as little added complexity as possible.