I have mixed feelings about this roadmap. On the one hand it's refreshing to see that they are not pushing new features recklessly and rather focus on core improvements. On the other hand, I think many would agree that the language is ripe for a little bit of innovation at this point.
Obligatory comment regarding generics. God I can't wait - if they add generics and a decent package manager, I'm gonna be pushing hard for Go at our shop.
What sort of "decent package manger" do you mean? `go get` is pretty solid as far as I can tell, the only thing it's missing is the ability to lock to a particular version...
It's missing the ability to publish or lock to a particular version, which is a game breaker for shops with >5 people, and the go maintainers don't seem to see it as a problem, making it a permanent game breaker.
I saw some posts on the mailing list where their position wasn't that it isn't a problem, but that no obviously-right solution is yet known, so it's better to let it shake out in third-party land for now, which seems reasonable. (That's all from memory, so salt appropriately.)
FWIW, I have been using godeps and it seems nice so far. I'd definitely recommend taking a look.
godep or glide, though hackish, appear interesting. The CoreOS devs have also been contributing back to godep for that reason [1], which is a plus. There's also a good discussion here [2] on that very topic.
Last I checked godep, the only thing I didn't like was the weird things you had to do with your project layout, but the way ahead is promising (and maybe it's not so bad now). Certainly it's much better than gopkg.in.
Though I do agree. It would be nice to have this sort of tooling as part of the Go distribution.
But it requires the use of interface{}, which reduces the usefulness of the type system, and you still can't do (what I guess must be crazy) stuff like return a slice.
