The future is Go’s to lose…

Go Language GopherIt would be hard to miss the splash the Go programming language has made in the software engineering community in the last year.  I’ve worked with it over the last several months and am pretty impressed by it, particularly for how new it is.  That being said though, it would be dishonest to claim that most of the buzz on Go isn’t hype right now and like any new technology headed for the trough of disillusionment, it has a lot of work to do if it’s going to stabilize into something that’s going to deliver on it’s promise.    Go is moving fast and given the state of languages out the right now, it has a unique opportunity to firm up a few things and become what people want it to be.  In other words, this is Go’s game to lose right now.

None of this is new, and the following may not be either but I thought I’d be one of the many voices tossing out some of the things I think Go urgently needs to change to take advantage of the opportunity it currently has.  So in no particular order…

Runes are going to ruin us…

For some reason Go decided to forgo a char (character) type in favor of a byte base Rune.  I’m not a character set guy so I’m sure there are good reasons in somewhere in the multi-byte or composing vs non-composing character bushes, but at the end of the day Runes are characters or at least people want to use them that way.  Getting esoteric with what should be such a fundamentally simple concept just seems like a bad idea to me.  Go does a great job of dealing with things on the byte level so I get the thinking behind Runes but the work it takes to treat a Rune like a char, which is most of the use cases, makes it feel like the language is getting the way to me.

Go Get needs to be more long sighted...

I seems kind of neat at first that you can import a go library using it’s GitHub or bitbucket path and import it with the Go Get command but I can’t imagine how this is going to be a good idea in the long run.  Linking a fundamental feature like imports into a low level language to current fads in repository practices seems like such an amazingly bad idea to me.  What happens in 3 years when we’re all onto the next new social coding platform or any number of other things change.  Go Get is neat but a poor (and dangerous) substitute for a a real dependency management system.  Nobody want’s to recreate maven, but maybe something akin to python’s pip would be a big step forward.

Better Collections and Generics

Anyone working with Go has heard this a million times so I wont go into it too much.  Slices, arrays and maps do generally work in my experience, so much so that the mantra of the community is that if you think you need lists, then you’re probably wrong.   Most of the features I find in common collection types from other languages can be built using these low level data types and the experience of doing it is a nice refresher in what is going on at a language level in many collections. That said though I think it’s sometimes confusing and having to explicitly manage slices gets tedious after awhile, mimicking sets out of ‘map[string]bool’ seems strange as does overuse of use the “interface{}” declaration.  The community debate on this is an interesting one and seems to come down to people expressing a desire for common language features either for clarity or convenience.   As you’ll see in my next point, I think we need to do a better job as a language community at valuing clarity. openness and learning and the division over collections is a small example of this divide to me.

Good community needs to be a core principle

As a new language and a community full of early adopters, which way the personality of the go community is going to trend is still very much in the air.    For my part I really hope to see Go follow the python community model to push openness (doing well there), diversity (hmm not so much) and develop a friendly and welcoming base (jury still out).  A trip to any of the Go communities is a very schizophrenic experience right now and while the culture is shaping up to be generally positive and helpful (play.golang.org is a huge help here), we should be mindful that cultivating a strong community is a very purposeful act.  There are spots where grumpy engineers hang out still, wasting the energy to give snarky answers about wasting their energy that it can drive some people away.  Also the entrenchment around issues like Runes or Collections can quickly escalate debates on that topic to something nobody wants to follow.  I threw out the idea of a community code of conduct similar to the one the python community uses and was immediately attacked by parts of the community.    Who adopts Go and what they bring to the community, at this early stage of language and community development, is going to be almost as important to the future of the language as the evolution of the language itself.  Like the social evolution brought on by GitHub, I hope to see Go bring a similar evolution of the more hard core engineering community and open it up to new and diverse engineers in the community and in turn I hope that evolution helps us all become better engineers.

What’s your take on Go, where it needs to develop or improve or do you think it’s perfect where it is?