8 ms·

Introducing Go 2.0

58 points by spacey 10y ago

zigzigzag 10y ago
This title is pretty misleading. There's no Go 2.0, it's just a bunch of miscellaneous thoughts on how a Go 2.0 might work or look.
- user5994461 10y ago
  First line: "Just so we’re clear, this post is a thought experiment, not any form of commitment to deliver Go 2.0 in any time frame. While I personally believe there will be a Go 2.0 in the future, I’m in no position to influence its creation; hence, this post is mere speculation."
joneholland 10y ago
This is exactly how .net added generics in 2.0
stirner 10y ago
This seems plausible to me, but Rob is known for being pretty hostile to clever ideas for "fixing" Go. I really like the idea of using make instead of new, following the familiar ergonomics of the function ("create a variable of this type").
lgierth 10y ago
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" Thumbs up from me.
- vorg 10y ago
  Cheney also writes: "The lessons of Python 3 (and Perl 6) are prescient; ignore backward compatibility at your peril." I believe Perl 6 can embed and/or call Perl 5 code, similar to the proposed Go 1/Go 2, but that hasn't helped its uptake.
aikah 10y ago
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". 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. 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 : func Foo<T>(bar :[]T)T func Bar<T,V>(baz func(T)V) used that way : var x int = Foo<int>([]int{0,2}) 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{} . 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. 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. 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.
- echlebek 10y ago
  This comment isn't very kind to the Go developers, and it makes a lot of assumptions about what they know. The Go developers understand what generics are, and why people want them. They realize that generics would enable programmers to write less code, and in some cases keep them from relying on reflection. Something else that's well understood are the tradeoffs necessary to implement generics. All of the facets of this are discussed here: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... Anyways, it seems like all of the comment's stated use cases are accounted for. Arrays and slices are already generic. Queues are available in blocking and non-blocking flavours via channels, which are generic. Sets are available via maps, which are generic. The builtins get you 99% of the way there. The developers decided that the remaining 1% of use cases were not worth the trade-offs of implementing generics. Go consistently makes trade-offs that favour simplicity, compilation speed, and not hiding runtime costs. Depending who you are, you may or may not value that more than the ability to write code that uses generics. I agree that people who want generics should not use Go, but I don't agree with painting the Go team in the way that this comment does.
sjellis 10y ago
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.
deleted 10y ago
[deleted]

58 points by spacey 10y ago

This title is pretty misleading. There's no Go 2.0, it's just a bunch of miscellaneous thoughts on how a Go 2.0 might work or look.

user5994461 10y ago
First line: "Just so we’re clear, this post is a thought experiment, not any form of commitment to deliver Go 2.0 in any time frame. While I personally believe there will be a Go 2.0 in the future, I’m in no position to influence its creation; hence, this post is mere speculation."

joneholland 10y ago

This is exactly how .net added generics in 2.0

stirner 10y ago

This seems plausible to me, but Rob is known for being pretty hostile to clever ideas for "fixing" Go. I really like the idea of using make instead of new, following the familiar ergonomics of the function ("create a variable of this type").

lgierth 10y ago

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" Thumbs up from me.

vorg 10y ago
Cheney also writes: "The lessons of Python 3 (and Perl 6) are prescient; ignore backward compatibility at your peril." I believe Perl 6 can embed and/or call Perl 5 code, similar to the proposed Go 1/Go 2, but that hasn't helped its uptake.

aikah 10y ago

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". 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. 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 : func Foo<T>(bar :[]T)T func Bar<T,V>(baz func(T)V) used that way : var x int = Foo<int>([]int{0,2}) 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{} . 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. 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. 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.

echlebek 10y ago
This comment isn't very kind to the Go developers, and it makes a lot of assumptions about what they know. The Go developers understand what generics are, and why people want them. They realize that generics would enable programmers to write less code, and in some cases keep them from relying on reflection. Something else that's well understood are the tradeoffs necessary to implement generics. All of the facets of this are discussed here: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... Anyways, it seems like all of the comment's stated use cases are accounted for. Arrays and slices are already generic. Queues are available in blocking and non-blocking flavours via channels, which are generic. Sets are available via maps, which are generic. The builtins get you 99% of the way there. The developers decided that the remaining 1% of use cases were not worth the trade-offs of implementing generics. Go consistently makes trade-offs that favour simplicity, compilation speed, and not hiding runtime costs. Depending who you are, you may or may not value that more than the ability to write code that uses generics. I agree that people who want generics should not use Go, but I don't agree with painting the Go team in the way that this comment does.

sjellis 10y ago

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.

deleted 10y ago

[deleted]