Really nice to see this talk, and that the Go team are considering how best to introduce breaking changes, and also consulting with users of Go about what they'd like to see change and what problems they've encountered. One of the things I love about Go is how stable it is (which is probably a lot of hard work behind the scenes). It's boring, as I think Brad said in some talk, which is exactly what you want in a language (as opposed to libraries or apps, which can be a bit more adventurous).
It does seem Russ is trying to solicit problems rather than proposed solutions at this stage - always the hardest part of
I'm a little mystified as to why Generics are so contentious and excite the madding crowd so much over at reddit or HN on this topic. At the moment it might be partly that people have decided somehow the Go developers are hostile to generics rather than simply cautious about them (I think it's the latter). The built in functions acting on containers do feel like a bit of an ugly special case - just enough generic functions to get the job done I imagine was the thinking when they were put in, but why not let end users create generic functions? Nowadays this is expected, and in most languages (not C++) works quite well if used sparingly. I wonder if their hesitation is partly what if it is not used sparingly?
Things I'd like to see addressed:
Errors - would be nice to see better error types (encapsulating possible error and value), and neater returns (get rid of if err == nil {return nil,nil,nil,err})
Nil - wish they hadn't put it in, too late now though I suppose
Maybe get rid of the distinction between []byte and string
Containers - would be nice to see some facility for making better
containers which can act on many types, mapping a slice of type [] - sounds like they are considering
some form of generics to handle this.
Cleaner stdlib - again lots of things that could be tidied and then fixed in user code with gofix.
Russ on Generics from the reddit thread on this story:
Re generics: A few people have misinterpreted the part of my talk mentioning generics as saying I don't know any possible use cases for generics, sometimes followed up by talking about how important type-safe containers are. Obviously I know about type-safe containers.
The point in that paragraph, which was brief due to time reasons, was that if you don't have specific use cases in front of you, you can't tell whether the design covers them. Even "type-safe containers" is not very specific. If all we need is type-safe map/set/etc then a very basic polymorphism is OK and we can skip generic methods.
Mostly though I'd like my Go 1 code to just run with Go 2, without a massive painful migration for all those big projects and libraries that are already written in Go 1. Sounds great that they're considering backporting any changes they can, which is great.
This is fun to play around with, given the very fast compile times of go though I haven't found it a huge problem to just write the code I want then iterate by running it quickly all at once - having to import a lirbary in order to get an interactive repl and change the code on the fly seems a little gross, though it is a really fun interesting hack.
Has anyone tried using this? I'm interested in having smaller docker images. When you get to this stage though you do wonder if you need docker at all to containerise something which is just one binary without significant dependencies.
This is pretty crazy. Perhaps no more crazy than running desktop operating systems on servers with huge amounts of software which just isn't required for the tiny go services running on them. CoreOS is another similar idea (for servers), and has auto-update.
This is a fairly balanced overview - he uses both, but appreciates Go because it's a bit simpler. Scala sounds interesting and far more concise than Go, but I'd be worried about whether my future self would understand what I'd written 6 months ago.
Great work on liveblogging, I'm definitely feeling some fomo from not being there and seeing the twitter feeds.
Really nice to see this talk, and that the Go team are considering how best to introduce breaking changes, and also consulting with users of Go about what they'd like to see change and what problems they've encountered. One of the things I love about Go is how stable it is (which is probably a lot of hard work behind the scenes). It's boring, as I think Brad said in some talk, which is exactly what you want in a language (as opposed to libraries or apps, which can be a bit more adventurous).
It does seem Russ is trying to solicit problems rather than proposed solutions at this stage - always the hardest part of
I'm a little mystified as to why Generics are so contentious and excite the madding crowd so much over at reddit or HN on this topic. At the moment it might be partly that people have decided somehow the Go developers are hostile to generics rather than simply cautious about them (I think it's the latter). The built in functions acting on containers do feel like a bit of an ugly special case - just enough generic functions to get the job done I imagine was the thinking when they were put in, but why not let end users create generic functions? Nowadays this is expected, and in most languages (not C++) works quite well if used sparingly. I wonder if their hesitation is partly what if it is not used sparingly?
Things I'd like to see addressed:
containers which can act on many types, mapping a slice of type [] - sounds like they are considering
some form of generics to handle this.
Russ on Generics from the reddit thread on this story:
Mostly though I'd like my Go 1 code to just run with Go 2, without a massive painful migration for all those big projects and libraries that are already written in Go 1. Sounds great that they're considering backporting any changes they can, which is great.This is fun to play around with, given the very fast compile times of go though I haven't found it a huge problem to just write the code I want then iterate by running it quickly all at once - having to import a lirbary in order to get an interactive repl and change the code on the fly seems a little gross, though it is a really fun interesting hack.
From 2015, but still interesting.
Has anyone tried using this? I'm interested in having smaller docker images. When you get to this stage though you do wonder if you need docker at all to containerise something which is just one binary without significant dependencies.
On the subject of generics in Go, this is useful reading as it lays out all the possible solutions/pitfalls: https://github.com/golang/proposal/blob/master/design/15292-generics.md
This is pretty crazy. Perhaps no more crazy than running desktop operating systems on servers with huge amounts of software which just isn't required for the tiny go services running on them. CoreOS is another similar idea (for servers), and has auto-update.
Dupe and was posted with no title, so downvoting.
This is a fairly balanced overview - he uses both, but appreciates Go because it's a bit simpler. Scala sounds interesting and far more concise than Go, but I'd be worried about whether my future self would understand what I'd written 6 months ago.