Go: It's about engineering, not type systems

about | archive


[ 2014-May-12 11:29 ]

I've become a huge fan of Go (aka Golang for search engines), but it is hard to express why. I haven't been this enthusiastic about a language since I learned Python in 2004. When I try to answer why Go might be better than Java, Python, or JavaScript, my answers are weak. The best reason I can come up with is that it solves software engineering issues the designers encountered while working with C++, Java, and Python at Google. There is no "killer feature," and nothing that you can't do in other languages. However, Go just feels like it makes writing software more convenient. While I haven't had the chance to use it on a "large" project yet, I think there are two primary advantages: Go is statically typed but "feels" like a dynamically typed language, and it makes it easier to use third-party code.

Statically typed but dynamic feel

I've written about how statically typed languages are better for large projects, so I won't re-iterate that argument here. However, at least in C++ and Java, the required types certainly make programs more verbose, and the time between fixing one error, and getting the next can be long and frustrating. There are three features that make Go's type checks less annoying:

Easy to use third-party code

Using third-party code is annoying in every language. You need to decide if the effort required to use the code is less than the time savings you will get from not implementing it yourself. This process is absolutely horrible in C++, where you need to deal with configuration headers, compiler flags and include paths. Its much easier in Java, but you still need to either manually download a massive collection of JAR files, or understand Maven or Ivy. Go isn't perfect, but does reduce the required effort.

Conclusion

About half of these advantages are properties of the language itself, and the other half are properties of the supporting tools. I think this is an important part of what makes Go magic: the designers were concerned about the entire software development process, and not just how to write a function.