Go 2 and the future of Go
We’re back! Panelists Mat Ryer, Johnny Boursiquot, Jaana B. Dogan, and Mark Bates discuss Go 2, the future of Go, what they like and don’t like, and what they would add or remove.
Matched from the episode's transcript 👇
Jaana Dogan: I have really minor requests, such as I wanna see some of the shadowing issues are made illegal. You know that there’s some convenience variable name err := sometimes allows you to error shadow errors. I wanna see some of them actually being more consistent, rather than us allowing them to be shadowed.
I also don’t like naked returns. I wish they were entirely gone. I really like to call out the variable names when I’m returning things. People think that it’s a little bit verbose, but we have some tools that actually ought to fill some of those places, so I think it’s not really worth to have this second-guess, or make it so indirectional. I wish that we were more consistent with naked returns.
The select statement is one of the other things that I wish we could have spent some more time on… Because it’s doing a lot of random things, and I wish that there was some sort of maybe a priority, or something. A very typical case is, you know, if my channel is closed, for example, I don’t necessarily care much about what else is going on in that select. There are some very common patterns, and it’s just so hard to figure out the right pattern, and use select in an easy way, because the select statement is really complicated.
[07:57] If we have time, I have some opinions on what packages I think need to be gone from 2.0. A typical example of this is the expvar
package. It’s like a straight copy of the [unintelligible 00:08:08.22] at Google, and I don’t think that it’s a really scalable approach. It uses global state, the number of variables is growing really quickly, the output format is human-readable but not necessarily a good representation; it doesn’t really provide a good way to represent structured values… And it’s really expensive to parse and format, so I don’t think it’s worth it at all. And there’s some packages that we wanna get rid of, like the container/
packages, the rpc-related package, which has been deprecated…
net/http
also has a lot of organically-grown features, and the ResponseWriter has this sort of optional interfaces. If you think about the initial http package, even HTTP/2 was not around when it first came around… And over time it started to provide some features through optional implementing some of the interfaces, that is added to the package at a later time… And I really want 2.0 to kind of like clean that up, and make it easier for library makers, as well as the user, as they’re engaging with the ResponseWriter.