Encouraging New Golang Developers

I’m cross posting a reply I made on reddit today, encouraging a junior developer to learn Go, because I wanted to hold onto the reply.  I find this is a cyclic conversation with junior developers and we need to be better as a community in encouraging development at all levels (even for our senior IT folks), and particularly of under-represented populations in IT.

There’s no particular problem about being a junior PHP developer that would make learning Go difficult. Don’t try to learn Go as PHP, learn Go as Go and you’ll be fine.

It’s hard to tell what is going on in someones mind but when I see this kind of question asked by junior developers it’s often some version of questioning if they can handle the complexity or anxiety over percieved relative difficulties of languages. So through my career I’ve heard a lot of “I’m only a [Python|Ruby|php|perl] developer, I’ve always been intimidated by [Java|C++|C#|and now Go], do you think I can learn it”. IF this is the case than I strongly encourage you to learn it. There’s no magic to any language, it’s just time and some endurance to get unstuck when you do, and you will.

When people say software engineering is hard, I think it’s percieved incorrectly. It’s not that it’s complex (which it is), but that it’s very difficult to live with the pressure of that compexity over long periods of time. Nobody realizes everything they need to about Software Engineering all at once, it takes dedication and time. Go is no different.

So if any of that applies then all I can say is keep with it and don’t be daunted by your perception of Go. If you stay with it to get past some of the new conceptual models in comparison to PHP, I think you’ll find it surprisingly easy.

In your specific case I think Go will be a great language to learn in addition to PHP in that it will introduce you to more core language theory concepts. Also you’ll have a go to language for when PHP is too slow, or not an appropriate fit.

Anyway, best of luck and I hope you pursue it and find it a good experience

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?