If Go2 wants to happen it needs to happen right now while the language adoption is still low. I personally think there won't be any Go2 or it will be admission of design failure from their maintainers who kept swearing to developpers "You don't need that with Go".<p>The Go mailing list is full of improvments requested by developers that the Go team refuses to hear, and most of them would still allow legacy code to run. So it doesn't make sense to suggest there will be a Go2 to begin with. the Go team is absolutely resistant to changes.<p>I suggested for instance to new container types like sets, and a way to write type safe parametric functions without adding generics AKA allowing developers to write their own container types. So you could have generic functions at the package level like :<p><pre><code> func Foo<T>(bar :[]T)T
func Bar<T,V>(baz func(T)V)
</code></pre>
used that way :<p><pre><code> var x int = Foo<int>([]int{0,2})
</code></pre>
No user defined generic container type has been introduced (ie no Struct<T>{} ) , and the code is type safe at compile time. It would be a nice trade off. It would take care of 80% of generic use cases (like writing array,slice,sets,queue generic methods only once instead of copying and pasting for each type) and would eliminate the majority of methods using unsafe catch-all interface{} .<p>I always found it strange that Go designers don't understand the fact that developers want to write compile time type safe code, while the formers are adding reflection features to the language (1.7 allows adhoc struct type creation), that are not compile time safe. Nobody wants generics for the sake of it. While compilation speed is one of the goals of Go, runtime performance should also be one, and reflection disallow any compile time optimization thus introduces a performace hit.<p>People suggesting the use of Go generate to transform Go code into a different Go code are just writing their own compiler extension without knowing it which leads to language fragmentation as they introduce 3rd party dependencies in the compilation step.<p>I think at that point anybody who is dissatisfied with Go type system should stop using it, as it completely unlikely to change dramatically in the future. There won't be any "Go2". It's too bad, because Go has a few nice ideas, like implicit interfaces and struct/interface embedding that are a nice way to do object composition.
This seems plausible to me, but Rob is known for being pretty hostile to clever ideas for "fixing" Go.<p>I really like the idea of using make instead of new, following the familiar ergonomics of the function ("create a variable of this type").
A thoughtful articles, but funnily enough, the thing that I like most about it is not the main proposal, but the recognition that the standard library needs improvement. One of the things that I find most offputting about Go is the aggressive insistence that some folks have that the standard library is all you need.
tl;dr "combine code written in Go 1.0 and a proposed Go 2.0 in one program using the package level as the boundary between language versions"<p>Thumbs up from me.