Details can be found at issue: github.com/golang/go/i… “, this issue has been approved and generics will be supported in the 1.18 version of Go.
Go hope is designed as a can be easy to run continuously for a long time the server-side language (refer to this article in detail talks.golang.org/2012/splash…
Now that the language is more mature, you can start thinking about generic design. But there are some caveats.
Generics are convenient, but they come at the expense of a complex type system and runtime design. You can’t have your cake and eat it. We haven’t thought of a balanced solution yet, but we keep thinking about it.
At the same time, Go has built-in maps and slices. elements in these containers can be interface{} interfaces (using explicit unboxing). This is actually similar to generics.
As the topic continues to be discussed, you can take a look at some of the previous failed attempts to implement generics in Go github.com/golang/go/i…
PS: What are generics? For example, the element in a hashMap is a generic. If it is not specified, it can be any value, but once we specify the specific type of the generic when we new, it cannot be changed. Interface does not need to specify the specific type of a new map. When using a new map, Go must add a bunch of assertions, which is very cumbersome.
1.The scalability of the enterprise2.A) essential B) essential C) essential D) essential3.Caveat Precautions4.Be explicit, explicit, explicit5.Buildi - in the built-inCopy the code