I\u2019ve always had a love\u00adhate relationship when it comes to learning new languages. On the one hand, languages are so fundamental to what we do, that even small changes can have measurable impact. That aha moment when something clicks can have a lasting effect on how you program and can redefine your expectations of other languages. On the downside, language design is fairly incremental. Learning new keywords, type system, and coding styles, as well as new libraries, communities and paradigms, is a lot of work that seems hard to justify. Compared to everything else we have to learn, new languages often feel like a poor investment of our time.<\/p>\n
That said, we have to move forward. We have to be willing to take incremental steps because, again, languages are the foundation of what we do. Though the changes are often incremental, they tend to have a wide scope and they impact productivity, readability, performance, testability, dependency management, error handling, documentation, profiling, communities, standard libraries, and so on. Is there a positive way to say death by a thousand cuts?<\/p>\n
That leaves us with an important question: why Go? For me, there are two compelling reasons. The first is that it\u2019s a relatively simple language with a relatively simple standard library. In a lot of ways, the incremental nature of Go is to simplify some of the complexity we\u2019ve seen being added to languages over the last couple of decades. The other reason is that for many developers, it will complement your existing arsenal.<\/p>\n
Go was built as a system language (e.g., operating systems<\/a>, device drivers<\/a>) and thus aimed at C<\/a> and C++<\/a> developers. According to the Go team, and which is certainly true of me, application developers, not system developers, have become the primary Go users. Why? I can\u2019t speak authoritatively for system developers, but for those of us building websites, services, desktop applications and the like, it partially comes down to the emerging need for a class of systems that sit somewhere in between low\u00adlevel system applications and higher\u00adlevel applications.<\/p>\n Maybe it\u2019s a messaging, caching, computational\u00adheavy data analysis, command line interface, logging or monitoring. I don\u2019t know what label to give it, but over the course of my career, as systems continue to grow in complexity and as concurrency frequently measures in the tens of thousands, there\u2019s clearly been a growing need for custom infrastructure\u00adtype systems. You can build such systems with Ruby or Python or something else (and many people do), but these types of systems can benefit from a more rigid type system and greater performance. Similarly, you can use Go to build websites (and many people do), but I still prefer, by a wide margin, the expressiveness of Node or Ruby for such systems.<\/p>\n There are other areas where Go excels. For example, there are no dependencies when running a compiled Go program. You don\u2019t have to worry if your users have Ruby or the JVM installed, and if so, what version. For this reason, Go is becoming increasingly popular as a language for command\u00adline interface programs and other types of utility programs you need to distribute (e.g., a log collector).<\/p>\n