One of the quiz exercises at the Golang meetup yesterday demonstrated probaby my favourite idiom of the language - Do not communicate by sharing memory; instead, share memory by communicating. Its nice to be reminded of this simple and powerful idea over and over again.
My first direct encounter with Golang came when debugging a network
service at $work. This was the first time I had to read Go code
beyond the simplest of examples and to my great surprise I found it to
be a fairly straightforward undertaking. For sure the quality of the
code and descriptive comments were a big part of this positive
experience, but the code itself felt easy on the eyes (even though it
employs a few unusual (to my eyes) syntactical elements) and light on
the brain. This wouldn’t have been a surprise had I been aware that
both Ken Thompson and Rob
Pike of the
Unix fame were involved in
creating the language.
Pretty much since the creation of Unix in 1969, people fostered a certain philosphy around it. This formed an idealogical foundation for Unix itself and influenced many things related to it, such as the C programming language and various tools and utilities that were written to be used on Unix. It also influenced, and continues to do so, several generations of software engineers, who in turn applied the philosophy to their projects. This is rare in the software world. Ever heard the phrase Make each program do one thing well? That comes from Douglas McIlroy, one of the early Unix engineers who invented the pipe. How about Write programs to work together? Or Write programs to handle text streams, because that is a universal interface? Yes, these go back to the very early days of Unix too. Do you think Tim Berners-Lee and Henrik Frystyk Nielsen had the idea that programs should handle text streams in the back of their mind when they started work on HTTP protocol two decades later? Maybe.
Fast-forward to more recent times and take microservices for an example - the core idea of microservices is that a service is comprised of many small components, each performing a well-defined function. Sounds familiar? And I just noticed that the Wikipedia page for Microservices states right off the bat that microservices philosophy “essentially equals to the Unix philosophy”.
And that’s not all, for it is in the early days of Unix that open source has its deepest roots, as for a long time Unix code was freely shared, allowing people to peer-review and add their own tools and features as time went by. This lead to the eventual collection and release of the tools as a single distribution.
As Unix approaches its golden jubilee (some time in 2019), its astonishing to see how well the central ideas supporting it have aged, or rather not aged at all, and adapt seamlessly to the challanges of present day engineering. It goes to show what incredible bunch the original Unix hackers were. Hats off to them and I recommend you check out Eric S. Raymond’s The Art of Unix Programming, for more depth into Unix philosophy and excellent software engineering wisdom.
PS: Yeah OK, so Ken & Rob and a few others actually engineered an even better Unix several years later and called it Plan 9. Unfortunately it was both a little too late, people were adopting Unix left right and center, and more importantly Unix was still so much better than anything else around that the promises of an even better OS didn’t get people migrating overnight, or at all in fact. These days Plan 9 is still alive and, while hardly in production use anywhere, has a dedicated hobbyist and researcher following though.