▲ 17 ▼ Video: The Future Of Go - talk by @rob_pike and Q&A
Talk at the Sydney Go Meetup Group in 2017
Part 2 video of the continuing Q&A has some interesting questions/answers
Register to comment or vote on this story
Talk at the Sydney Go Meetup Group in 2017
Feels a bit frustrating that they're so vague about plans for Go 2, but I guess they just don't know yet what they want to include, and are trying to get an idea of what needs to be fixed. Looking back at my experience of Go the most important thing for me is that it's stable and the go1 promise, so I hope there will be a go2 promise and that go2 will concentrate on making sure the transition is painless by rewriting go1 projects seamlessly to use go2 idioms. Introducing generics would of course make that far more difficult, will be interesting to see what they come up with.
So this is similar to the talk from Russ - they don't want a wish-list of features or problems chosen to illustrate a feature you have decided you want, but a list of concrete problems with ecosystem, libraries, language which people who actually use Go have found when using it.
So give them well described problems, not solutions.
As an example you could say I want generics, but it's pretty pointless and an example of providing a solution not a problem. Better to say - containers in go suck because x,y,z, we want to use a red black tree for 10 diff types and it's painful, we generate go code and it's painful, I want to use range on my own types etc, or unboxing typed arrays is painful, or I want better error handling, option types etc, because that lets them see what flavour of generics (from the many possible choices) are actually required, and which bits of the language/tooling etc need improved, specific to go.
My bet is they will go with some form of generics in Go 2, the question that is completely open is what form it will take, which will be affected by exactly what problems they have described to them. Nobody is obliged to waste their time doing that, but if you want to influence the Go team, I'd suggest doing exactly what cloudflare did after the monotonic clock issue - describe the problem and why the current solutions don't work. They actually mention that in the talk and Q&A here and say their initial instinct on the clock was wrong, and seeing the concrete problem helped.
Lack of generics has not stopped my using go professionally (or you), and in my experience has been a minor wart rather than a blocker (this may vary for you). For me it's not a huge problem, I'd rather see errors cleaned up.
There's also a long q&a at the end which in a way is more interesting than the talk and ranges over a lot of topics from json speed to external package repos, packaging, use of go for mobile.
Yes. This is like getting a bug report on an app - you don't want to hear what the user thinks the solution to their problem is, you want to hear what the problem is, so that you can look at it and relate it to other problems, consider the implications of each solution, and finally come up with a solution that might solve several problems, without causing any more elsewhere. Coming up with possible solutions without understanding the problem properly is too easy.