Java is the COBOL of my generation and Go is its successor (and other reflections after GopherCon)

By Paul Dix / Use Cases
Apr 30, 2014

Last week I attended GopherCon in Denver, the first ever Golang conference. There were fantastic talks on Go and various projects, but for me the most exciting thing about the conference was meeting enthusiastic people in this nascent developer community. I came away from the event with the feeling that we’re at the beginning of a major groundswell. A massive shift in developer language use that I don’t think we’ve seen since Java came on the scene. Go’s simplicity, performance, concurrency primitives, robust implementation, and easy deployment make it ideal for server side code, web APIs, and potentially much more, which is why I think it has the potential to ultimately supplant Java.

My prediction is much stronger than saying Go will be as popular as Ruby, Python, or Node. I think it’s very likely that will come to pass within a few years. While it may not be as expressive as the dynamic languages, I think its strengths will encourage a migration of many programmers from dynamic languages to Go. Anecdotally, I met and knew many Ruby developers at the conference. The dynamic language refugees are the first wave of adopters.

However, to say that Go will be as big as Java is quite a stretch from saying Go will reach the popularity of the dynamic languages. Java may be downward trending, but Go doesn't even register on the Y axis, while is barely Ruby there. Go would have to be an order of magnitude more popular than Ruby to even get close to Java's popularity.

Why do I even care about popularity? Because popularity means more jobs, more potential hires, and more tools and libraries. Any developer that cares about their demand in the market (and salary potential) and any employer wishing to hire should factor language life-cycle into their language choice. I’m sure there are still COBOL programmers out there, but I wouldn’t want to be one of them if I was looking for a job and I wouldn’t want to be an employer trying to find a competent COBOL programmer or anyone that wanted to learn.

Let's take a look at Go's popularity in isolation. The initial spike is the announcement from Google, but on the right is the beginning of a curve that's starting to look interesting. There were more graphs in talks at the conference that showed Go's uptake in a practically vertical climb for the last few months.

If I were a VC and I could buy options on Go as a language, I’d be seriously looking into it. Since Go is just a language they’ll have to look elsewhere: companies that are betting their tech on Go, open source projects written in Go, developer tools, and infrastructure and hosting. There were plenty of those and more at the conference. Some of the more interesting ones I met and talked to include Cloudflare,Hashicorp, CoreOS, VividCortex, Apcera, Digital Ocean, and even Mozilla is building Heka in Go despite Rust being their “in house” language under development. Then of course there’s us, InfluxDB, but I’m biased.

I remember going to the first RailsConf in Chicago in 2006. In the months leading up to GopherCon I repeatedly told people that I felt like this first Go conference would be very similar: filled with excited technologists working with new stuff on the cusp of something great. I found it to be that, but amplified by a factor of 10. Maybe Go is just farther along than Rails was at that first conference, but I felt as though this thing will easily be bigger than Rails. People are enthusiastic about the language and things built with it. That excitement will feed into a virtuous cycle of more open source, more libraries, more books, more blog posts, and more closed source bringing more demand for Go developers.

If I were a developer getting started today, I’d make a career bet on Go.

I’m a developer and an entrepreneur today and I’m making a major bet on Go. But, there have been other potential contenders to the Java throne in the last 10 years. Why should this one be any different? For the same reasons I listed at the top of this post: simplicity, performance, concurrency, robustness, and deployment. There are potential pitfalls for adoption that I’ll close out with, but let’s look at each of the pros in turn.

First, let’s talk about simplicity. Go is a simple language by design. You can read the spec and other materials on the Golang website and start being productive in a single day. This is a huge strength in terms of adoption. Simple languages are easier to learn. The fantastic side effect of this is that they’re also easier to understand and read. The Go team made it very clear that they optimize for readability. This is a massive win for both newbies and for anyone working in a team or on a long lived project. Readable code is easier to maintain. Scala, a language that at one time I thought would be Java’s successor, is notoriously complex. My own experience working with it for over a year confirmed that at least for me. Simplicity is a massive win for experienced and novice developers alike and I think it’s Go’s greatest strength.

Go’s performance isn’t a big win for Java developers since they’re already doing pretty well. But for us dynamic language refugees, Go’s performance is liberating. No dealing with reverse proxies to send things to multiple processes. Real threading and the ability to take advantage of every core. Async IO, but without all the callbacks. As a developer I don’t even have to try to get thousands of requests per second out of a single Go process. And if you stretch, you’ll get millions per second like Apcera.

Go’s concurrency primitives, namely channels and selects, make it a joy to write code that executes concurrently. Go’s design makes it easier to take advantage of every core and do IO without blocking the entire process. Both of which are big wins for anyone writing server infrastructure code.

The robustness of the Go implementation is truly remarkable given its relative youth. I’ve run production Go code for over a year and any failure I’ve had so far has been entirely due to my own bugs. The language runtime itself has been rock solid. Java can make a claim to this as well, but for those of us in the dynamic community, that has not always been the case. The fact that it’s so reliable now bodes well for future improvements to the runtime.

Then there’s deployment, which is fantastic with Go. Deploying Go code to production is as simple as copying a single binary file up to a server and running it. No reverse proxies, no dependencies to install on the target server, no class paths. Just copy the binary and run. For our work on InfluxDB it’s a big win when compared to what other open source time series databases require to get set up. Simple installs are great when you’re working with open source and that’ll drive many new open source projects to chose Go. We’ve already seen this in the last year with projects like Consul, etcd, Docker, and even CloudFoundry moving to Go.

The real question is, what are the things that can impede Go’s march to dominance? Some developers have noted Go’s lack of features or a few other things: no exceptions, nils instead of options, inability to specify dependency versions, mark and sweep GC, no macros, no generics. My feeling is that almost none of these complaints will be that big of a problem. Go’s idiom for error handling pushes you in the right direction of actually handling errors instead of just bubbling them up to the top of the stack. Nils haven’t stopped plenty of other languages from gaining popularity. Dependency versioning can be handled by tools from the OSS community. Go’s GC will get better over time unless the Go team just decides to hang up their keyboards and go live in the woods.

The one complaint that gives me greatest concern is the lack of generics. I personally haven’t found it to be that big of a deal, but it can be slightly annoying when it comes to things like sorting collections. I love the simplicity of the language without generics, but it’s hard to deny that they make some things easier. But, for better or worse, the Go team has made it clear that generics aren’t coming anytime soon, if at all. So I wonder if this will limit the audience of the language or not. My gut feeling is it won’t, but in order to get to Java’s current popularity level, Go will need to attract some of those developers over to its camp.

Does Java even need to be replaced? Is Go enough of a leap forward to warrant it replacing Java? I don’t think it’s a 10x increase in productivity, but it’s almost certainly an improvement. But more importantly, it IS a 10x increase in happiness for me when compared to developing in Java. And that might be enough, even if the mass of current Java developers never make the change. New developers picking Go instead of Java will be enough to shift the center of gravity over time. The shift will take decades, but if Google and the core Golang team continue to be such fantastic stewards of the language, I can imagine a future in which Go is dominant.

In the meantime, I found the attendees at GopherCon and the Go community in general to be excited, intelligent, and pragmatic developers. And those are exactly the kind of developers that I want to work with, which is why I’m excited to be part of the Go community and to be building open source in the language.