dotGo, microservices & simplicity
Jun 26, 2016 · 3 minute read · Commentsgolang
Recently, I watched all the recorded talks from last year’s (2015) dotGo conference as a way to learn something new about the language and where it is heading. You can watch 17 different talks on many aspects of the language, but there are two talks which stand out.
The first one is Peter Bourgon’s talk about microservices and the tooling available for building them. Go is a backend language and often gets applied to the behind-the-scene processing which overlaps with a possible domain of microservices.
I’m not sure how are his thoughts perceived in the wider community, but his description of the tooling necessary to develop a serious service based system sounds sensible. To put his thought into action, he maintains a project called Gokit which is a collection of libraries, patterns, comments, examples, and a bit of original code for developing microservices. It includes design pattern implementations like circuit breaker and rate limiting, logging libraries, tracing support, or instrumentation systems' support. The talk is nice and clear and definitely worth the 17 minutes of your time.
The second talk I want to highlight is by Go’s co-author Rob Pike about simplicity. As with other talks, Rob Pike brings issues from the development of Go language to the attention of its users. In this instance, his focus is on features which got implemented and those which won’t. The talk is excellent for anyone wishing that Go had feature X; it also doubles as a clear reminder of the benefits of the language which might sometimes be hard to express.
The core idea is simplicity of maintenance: if there’s only one way to do X, it’s easier for maintainers to understand what the code does. It might not be as succinct as other languages could be, but there is no hesitation about how to achieve the goal (there is only one way to loop over things). At the same time, this allows the developers of the language to focus on designing this one feature with all its repercussions, implementing it correctly and efficiently, and then maintaining it.
Other languages tend to bloat over time, swelling with new shiny features which often grow as a direct competition to existing features. This process raises the entry barrier for newcomers and leads to never-ending flame wars. As languages assimilate new features, they resemble each other more and more (at least at a glance, the devilish details are in the corner cases). A toolbox of specialized equipment gets replaced by a single universal tool which probably won’t do everything as well as specialized tools would and, more importantly, robs us of different perspectives which are closely tied to different languages and their paradigms.
As a complement, Pike illustrates how the perceived simplicity of Go hides complexity of implementation. These examples include garbage collection, concurrency, or interfaces. An astounding amount of work went into these fundamental issues, but he concludes that this complexity is worth the trouble, because it gets hidden behind an interface making the use of the language simple — and that is the goal of Go.
We're looking for developers to help us save energy
If you're interested in what we do and you would like to help us save energy, drop us a line at jobs@enectiva.cz.