finally! Go 1.18 will support generics, come and hear what Russ Cox, the core technical team of Go, said

Recently, Russ Cox, technical director of the Go language core development team, sent a public email to the golang-dev group, announcing that "If there are no surprises, Go 1.18 will support generics." It is reported that Go 1.18 will be released in early 2022.

I still remember that in early October, this site just reported that Rob Pike, the "Father of Go Language," on github about "It is not recommended to use generics in the Go 1.18 standard library" issue. At that time, Rob Pike was worried that "Go 1.18 carries too many changes and is prone to errors", so it is recommended to wait for observation and move forward steadily.

And yesterday, October 28th, Russ Cox issued another article on Rob Pike's issue, introducing the current progress and subsequent support strategies of Go 1.18 version and generics, which finally determined the direction of the Go core team in the next phase- In other words, if nothing goes wrong, Go 1.18 will support generics.

The significance of adding generics to the Go team

As the most important change since Go was released, Russ Cox briefly explained in this public email what the addition of generics means to the Go team and users.

Russ Cox said that any new Go features, whether it is a language or a library, are uncertain, including uncertainty about how to use them, how not to use them, and what tiny bugs have passed the existing test set. Generics cannot avoid this uncertainty, especially because generics are a large new feature, so its uncertainty will be greater.

At the same time, the generic code originally released by the team-especially the maps and slices packages through the proposal program-will first be placed in golang.org/x/exp, but backward compatibility is not guaranteed. Russ Cox said that once he has more experience in the future, he will hope to promote some of these packages to the standard library (except for the constraints package, which will be added to the Go 1.18 standard library as the basis for writing some generic code. )

Russ Cox emphasized that Go 1.18 has the same promise of backward compatibility as other Go 1.x versions, "it will not break code built with Go 1.18, including code that uses generics. In the worst case, if we find Go There are some fatal problems with the semantics of 1.18, and they need to be changed (for example, in Go 1.19), we will use the go version indicator of the go.mod file to determine whether the source file in the module uses Go 1.18 or Go 1.19+ Semantics. (We don't expect this to be necessary!)"

For many package authors who are eager to adopt generics, Russ Cox suggests that "If you are updating your package to use generics, please consider isolating the new generic APIs into your own files and use Go for them. 1.18 build tag (//go:build go1.18) so that Go 1.17 users can continue to build and use non-generic parts."

It is worth noting that third-party tools may not fully support generics when Go 1.18 is released. Currently, the Go core team is communicating with the authors of many third-party tools, trying to ensure that they get the appropriate updates, but they all have their own schedule.

Regarding the question "Why not add generics to Go 1.18?", Russ Cox explained that the only way to reduce uncertainty is to make them available by default.

"When we added the vendor mechanism as an option in the Go 1.5 version, we found that almost no one actually used it until the Go 1.6 version turned it on by default. So the Go 1.5 version did not reduce our uncertainty about the use of the vendor by Go developers. On the other hand, the Go 1.5 version undoubtedly divides the ecosystem into two parts: "code that runs under standard Go" and "code that runs after vendoring is enabled." We hope to avoid this result as much as possible here."

Why does Go language need generics?

For a long time, the industry's discussion on the topic of Go language generics has been very intense, and the Go team has been hesitant to add generics because they hope to find a good solution.

We know that functional programming is a very popular programming paradigm, which is built or supported in many types of assembly language. As for the Go language, although it is not a functional language, it does provide a set of features that allow functional programming (a considerable number of open source Go libraries provide feature sets).

The language support of functional programming ranges from only supporting functional paradigm (such as Haskell) to multi-paradigm + first-class support (such as Scala, Elixir) to multi-paradigm + partial support (such as Javascript, Go). In the latter category of languages, functional programming is generally supported by the use of community-created libraries that replicate some or all of the functions in the standard libraries of the first two languages.

Go language belongs to the last category, it can realize the functional programming in the following figure:

In the Go language ecosystem, there are already many functional programming libraries, which differ in popularity, functions, and ergonomics.

Although some of these functions have been supported, such as first-level and higher-order functions and enabling functional programming, it still lacks a key feature-generics.

Without generics, Go language function libraries and applications will be forced to follow two paths:

1. Type safety + use case specific. The library that chooses this method implements a type-safe design, but can only handle certain predefined types. Since custom types or structures cannot be used, the types of problems that these libraries can be applied to are limited. Of course these two types are safe, but only apply to predefined types.

2. Type insecurity + use case agnostic. The library that chooses this method realizes a design that is not type safe but can be applied to any use case. These libraries use custom types and structures, but they need to be weighed. If they are not implemented correctly, the application will face the risk of runtime crashes. These two design options provide two similar options, "Limited Utilities or Runtime Panic Risk". Therefore, the easiest and most common choice is not to use functional programming libraries with imperative styles.

So now, with the arrival of Go version 1.18, the Go team has officially announced that generics will finally be added to implement new functional programming solutions in the Go language.

Since the news that Go 1.18 "supports generics" spread, some foreign media have immediately compiled some libraries based on Go generics (Go 1.18), which can be added to the slice package for developers to use. But we hereby suggest that you all hope that everything will be based on official information.