Why I like generics in golang

(article originally written on my blog in French)

I was reading again the excellent article from Ian Taylon and Robert Grisemeer (The next step for generics) and I couldn't help thinking that I love the way we're heading. In fact, I love so much those new generics that I've decided to write an article to claim it.

With the latest drafts published, you should all have a precise idea about what the generics will look like in the next version of Go. So rather than writing another technical review about the changes, I'll rather state why I like those generics because it's the exact same reasons why I like the language.

I like generics because they're simple

As type parameters are special parameters, they're now handle as parameters (after the function name) but in an optional distinct list starting with the 'type' keyword and located before the usual parameters list.

func Process(type T)(s []T) {
    // do something with the slice of T
}

The call is similar to a standard call, specifying the type just before the parameters list.

Process(int)([]int{1, 2, 3})

In some cases (when all the types are used for the input parameter types and not in the body) the compiler is even able to deduce the type from the parameter types.

Constraints are now defined through interface type (no more contracts). For example, if we want the type T to implement String() we just have to add the Stringer interface constraint.

// Stringer is a type constraint that requires a String method.
// The String method should return a string representation of the value.
type Stringer interface {
    String() string
}

func Process(type T Stringer)(s []T) {
    // do something with the slice of T, and call String() on slice elements
}

And if we want to put a constraint on an operator, we can now use base types in an interface type by prefixing the list of base types with 'type'.

// Ordered is a type constraint that matches any ordered type.
// An ordered type is one that supports the <, <=, >, and >= operators.
type Ordered interface {
    type int, int8, int16, int32, int64,
        uint, uint8, uint16, uint32, uint64, uintptr,
        float32, float64,
        string
}

And to make your life even simple, a new type constraint 'comparable' is now available to handle '==' and '!=' operators

// Index returns the index of x in s, or -1 if not found.
func Process(type T comparable)(s []T)  {
    // Now you can compare elements of slice even if they're struct or array
}

Simple, isn't it?

I like generics because I like Gophers' community spirit

But beyond the feature added to the language, what I like with those new generics, is that the way they were added adhere to the community spirit.

you have to remember that generics were the 3rd point (with dependencies/package and errors handling) considered as the most important to improve according to 2016 Go users survey and 2017 one.

The fact that language evolution has been initiated based on the community feedback (rather than on choices made by a "benevolent dictator for life") is already great.

The pace at which the features were introduced is also an interesting metric:

• Modules handling (introduced in version 1.11 in 2018)
• Errors handling (introduced in version 1.13 in 2019)
• Generic introduction (executed in version 1.15 due for end of 2020)

As we see, the release pace is quite fast but not rushed.

I like generics because I like Go's philosophy

Lastly, I like generics because they comply with the Go's philosophy.
(since the Go Brand Book published in 2018, I'd rather use the word values)

• Simple: As seen above those generic is simple (bye bye contracts) with few language modifications.

• Efficient: With every draft, performance has been a constraint and the last one manage to allow you to choose between faster compilation and slower execution and the contrary.

• Thoughtful: Because instead of implementing generics based on another language, the community took its time to design one complying to the spirit of the language, to write drafts, to discuss them, to improve what can be improved and do it again to reach an implementation which complies to the language objectives and spirit without sacrificing to performance.

I like generics because it's practical

Go being a pragmatic language, you can already test this generic implementation on go2go playground

But as I tend to be optimistic and enthusiastic, maybe I got carried away, so let me ask you: And you, What do you think about this generics implementation?