Hello, I’m fried fish.
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?
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.
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:
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:
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.
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