After 11 years, the Go compiler finally officially supports generics!

Recently, according to foreign media reports, in a PR of the latest submission and merger of the Go project code repository, the Go language has been enabled by default in cmd/compile -G=3. According to the description, the PR has changed the default value of -G flag of cmd/compile from 0 to 3, and can use the new type2 type checker and support type parameters, officially enabling support for generics.

In consideration of default behavior changes (for example, the known changes to the type2 type checker), the Go compiler enables -G=3 by default. The generic changes are officially enabled and the regression testing tool is also updated. In addition, although -G=3 has been enabled by default, the -G=0 mode is currently still being tested.

Since its birth in 2009, the programming language Go developed by Google has been developed for 11 years. With many advantages (such as faster than Python, more concise than Java, and GC that C++ does not have), the Go compiler has always been favored by developers or programmers in technology companies. Of course, in recent years, Go has also increasingly appeared in industries such as finance and media.

As a successful open source project, the number of people who use the Go compiler is growing every year. In the past few years, surveys conducted by a wide range of Go developers have shown that generics have always been regarded as the real key to Go. Even from the discussion in 2010 until now, there are some feedback and suggestions on the Go generics draft.

Why is there no generic type in the Go language?

Before that, many people thought that the Go language might never join generics. So, why hasn't Go language been generic so far? Nowadays, the Go compiler enables -G=3 by default, and generics are officially enabled. So how is the problem that has been troubled for many years solved?

I believe that friends who know the Go language standard library will find interesting problems in the following code:

package sort

func Float64s(a []float64)
func Strings(a []string)
func Ints(a []int)
...

In the above-mentioned functions provided in the sort package, although they have very similar underlying logic and functions, they need to provide multiple external functions when the input types are different. At this time, if you can use generics like Java, you can greatly reduce the repetitive code and logic, and also provide programmers with stronger expressive skills, reducing workload and improving efficiency.

Relevant survey data shows that due to the generic dilemma, the Google Go programming language development team had to face the choice of development efficiency, compilation speed, and running speed. At the same time, due to the flaws in the previous Go language solution, the Go team also believes that the support for generics is not compact enough, so generics have not been added to the first few versions of the Go language.

About the development of Go language generics

For a long time, the "push" work on Go language generics has been going on.

In November 2009, Google officially released the Go language to the world in the form of open source. The following year, Ian Lance Taylor submitted a proposal to add generics to Go, but at that time the proposal was kept as an example and was not adopted. After that, in March 2012, Go 1 was officially released, and the generic proposal was raised again.

In the next few years, due to the "generic dilemma" faced by Go mentioned above, related proposals have been considered and in the process of being resolved. It was not until July 2019 when Ian Lance Taylor gave a speech on "Why Generics?" at Gophercon 2019 that he officially submitted a draft of collaborative generic design.

Last June, this generic design draft was updated, and it was finally predicted that it could be seen in this year's Go 1.17 version.

From January of this year, Ian Lance Taylor initiated a proposal to add generics, to the official release of the generic proposal in March, and then the Go compiler was officially launched-G=3 to support generics. It took many years for the broad Go developer community The Go language's generic problem has finally been realized.

Finally, avoid generic abuse

To this day, in the use of language code compilers, generics are a very "evolutionary" feature, which can not only improve development efficiency, but also effectively help developers reduce unnecessary duplication of work.

But like any editing language, the Go language's generics are enabled, and the "generic abuse" in the subsequent development process also needs attention.

I believe that for every programmer, when they find a large number of nested generics in the code, they will be "like a big enemy". Although it is not like the large number of templates in the standard library like C++, the generic features of the Go language also allow the use of type constraints, which produces "mysterious" logic like Java, which will have a lot of impact on the efficiency of code compilation.

Therefore, after the introduction of generic features, how will the Go language handle the "function renaming" logic to help effectively solve the types, functions, and methods in the source code? We will wait and see.

For more details about Go, please follow:
https://go-review.googlesource.com/c/go/+/343732/