What about the API after generics? Go developers should pay attention


What about the API after generics? Go developers should pay attention

Hello, I’m fried fish.

Some time ago, the community suddenly exploded, mainly quoted by major mediaGoGo: don’t change the libraries in 1.18 proposed by Rob pike, the father of language.

What about the API after generics? Go developers should pay attention

Many social media have followed up and believe that rob pike is hard against gogeneric paradigmofAPIreform!

If readers only read the title, there may be some misunderstandings. In fact, the meaning expressed is related to the matters discussed by the go community recently, which should be taken together.

For this reason, let’s have a look at the transformation project of go generic API. What’s going on?

present situation

It will be November 2021, and even Shenzhen will become cold… According to the release cycle of go language, the release of go1.18 will be around February 2022.

What about the API after generics? Go developers should pay attention

Now, we only have three months for Ian lance Taylor, Robert Griesemer and other leaders to discuss the details of generics, further improve the implementation and achieve production availability.

The implementation progress of throwing out go generics is not to mention. Now we have encountered a big problem. That is “how to update the generic API” after implementing the generic.

This includes several aspects: existing standard library, open source library, new standard library, etc. Different libraries are maintained by different people.

But there is a big problem here, as shown in the figure below:

What about the API after generics? Go developers should pay attention

Russ Cox raised the question of “how to update APIs for genetics” in September. At that time, it was obvious that there was no consensus on this area. From the records of the discussion in November, a final clear consensus on how to do it has not been reached (preliminary, no formal reply).

However, there is a problem. The go community is very enthusiastic about the urgency of generics. Proposals for various generic standard libraries have been put forward, pushing designers forward.


In combination, rob pike is more like: suggesting and reminding the go community and core development team to “take it easy”. Go1.18 wants to support generics and complete the transformation of the library, but it has to pay a small price. After all, there are many details.

The core arguments cited are:

In a version, there are too many things to do for generics, standard libraries, etc., which may be mistaken.

  • Without the experience of using new types in go, it can not provide a strong basis for its design.
  • The promise of go1 compatibility, the cost of making mistakes in any detail is very high, and we have to wait, observe and learn.
  • It is very close to a proverb: “don’t eat fat people in one breath”. Moreover, without relevant experience, it is only detailed reasoning and rehearsal, which needs promotion.

In Go issues, some people also make complaints about the 1.18 types of generic implementations. There are no other supporting standard libraries. What is the generic meaning of go1.18?


Although the final decision has not been made, according to the discussion process and the number of community approval (?), it is as follows:

What about the API after generics? Go developers should pay attention

New libraries for slice, map, channel, etc. will still be designed, built, tested and used later.

These libraries are not available for production. They will be placed in the golang / X / exp warehouse and can be used. They are only used as experimental libraries at this stage, and there is no compatibility guarantee.

What about the API after generics? Go developers should pay attention

The experimental library will change, adjust and develop in one or two cycles. Developers in the go community can try to use it in order to accept more opinions.

According to the user’s feedback, they will be updated through experience and analysis, and they will be moved to the main warehouse to reach the level available for formal production.


In today’s article, we analyze why rob pike should adjust the standard library API after go generics.

To this end, we understand the go core team’s concerns about “how to update APIs for genetics” and the passion of the existing community. In a comprehensive view, we give suggestions on gradually evolving generic solutions.

It can be seen from this that the production of go complete generics (including supporting libraries) is available, and may go through several go versions, which makes many people look forward to

Recommended Today

On the mutation mechanism of Clickhouse (with source code analysis)

Recently studied a bit of CH code.I found an interesting word, mutation.The word Google has the meaning of mutation, but more relevant articles translate this as “revision”. The previous article analyzed background_ pool_ Size parameter.This parameter is related to the background asynchronous worker pool merge.The asynchronous merge and mutation work in Clickhouse kernel is completed […]