Why I like golang: a programming autobiography
The first programming languages I was exposed to in college were Pascal, Lisp, Prolog and C, in this order. I liked C the most. I still remember reading the K&R book and being blown away by its clarity and terseness. I was lucky enough to have an AT-compatible PC at home, so I could try my hand at writing C code in Borland Turbo C.
I started my first job as a programmer in 1993. The very first line of code I wrote was in C++ under MS-DOS. The programming environment was called The Programmer’s Workbench. The application I worked on was GUI-driven, with menus, dialog boxes and all kinds of other widgets, all written from scratch in C++. I’ll never forget the feeling of being overwhelmed by the sheer amount of classes I had to understand and learn in order to do anything at all. A very humbling experience, but one that has served me well throughout my career, when I had to quickly become familiar with existing or ‘legacy’ code.
My next programming environment was Visual C++ under Windows 3.1. A much more powerful arsenal of tools, with Microsoft Foundation Classes at its base (I was so grateful that the source code for the MFC base classes was miraculously available, otherwise life would have been REALLY hard.) Still, a lot of things to learn in order to be productive: how to define a project, how to specify all the compile-time and link-time dependencies, etc. The debugger included in Visual C++ though was amazing, a real life saver. Compiling and linking the code used to take forever, and was responsible I think for the popularity of Minesweeper and Solitaire among programmers.
There was a steep learning curve in going from MS-DOS to Windows, mainly because I had to understand event-driven programming and learn the low-level Windows SDK, which was still needed even though MFC abstracted a lot of it away. Charles Petzold’s book on Windows programming was our bible at the time.
Next I discovered Visual Basic. Although a step back in terms of power and expressivity compared to Visual C++, the productivity I was able to gain by using it blew me away. Looking back, it was my first experience with an interpreted language (other than the toy programs I had written in Basic.) Even programming in MS Access felt good and liberating compared to the rigor of Visual C++.
After a few years of working exclusively with Microsoft tools and environments, I switched to Unix and Linux. Talk about a learning curve, but also about a breath of fresh air! I remember getting a question in an interview about how I view Unix vs. Windows, and I answered that to me Unix is a democracy, while Windows is a dictatorship. It was exhilarating to learn the Unix way of doing things by composing small well defined tools and libraries into powerful programs. Also, Linux was FREE!
I slowly drifted away from being a full-time programmer to being a systems/network engineer. This was in 1998/1999. At that time, I fell in love hard with Perl. Again, an interpreted language was helping my productivity to skyrocket. I felt so much joy in being able to automate most of my tasks using Perl. Oh, how good it felt to stitch together HTML in a Perl CGI script, or to produce automated tabular reports! I devoured the Camel book and I wrote vast amounts of Perl. My regular expression skills were extremely sharp at the time.
Around 2004 I was working as a test engineer and needed a language that was cross-platform, in order to write automated test harnesses that had to run on Windows, Solaris, and HP-UX. I discovered Python. I was still using Perl, but as everybody who used Perl as a language for a medium-sized team, it tends to become write-only, i.e. you can’t read it after a while due to everybody’s different coding style and formatting. I abandoned Perl for Python in a heartbeat. The fact that all code looked the same was a big plus. Python had very strong Windows support, which was essential for me at the time.
Python also came with batteries included! It took some time to learn its standard library, but I loved every minute of it. It rekindled my love for programming, which had become stale to say the least. I became very involved in the Python community, especially in the testing area, and this was also very satisfying. I made a lot of good friends at the many PyCon conferences I participated in.
Sadly, Python stopped being part of my day-to-day job. On the operations side, I was using tools such as Chef and Sensu, which are written in Ruby. I never actually adopted Ruby as my language of choice, but I had to learn enough of it so that I could be proficient with tools written in it. On the development side, the languages I had to support as an Ops guy were again Ruby and also Java. If you ever had to support one application that needs Ruby 1.9.2 and another that needs Ruby 2.0, you’ll understand the pain I had to go through. If you ever had to deal with Java XML configuration files and with maintaining a special tool to manage Java ‘artifacts’, you’ll also understand my pain.
In the beginning of 2015, I took the opportunity of starting from scratch at my current job at Boom! Payments and I introduced Go (aka golang) as the programming language for our backend APIs. Golang brought back once again my joy of programming. I read many other people’s blog posts on how writing golang code is FUN, and I have the exact same feeling. The learning curve is a bit steeper than with other languages, the syntax feels awkward at first, but once you become used to its quirks, golang will raise your productivity to new levels.
I never felt as old as a programmer as when I was reading the other day about somebody’s experience with Go, and how Go was the first compiled language they worked on in their career! I realized that yes, Perl, Python, Ruby and Javascript are probably the only languages that many young programmers have ever used in their careers. Coming back myself from using scripting languages for the last 10 years or so, it feels amazing to be warned of potentially serious bugs in your code at compile time! Right off the bat, golang helps you avoid small but potentially critical mistakes that wouldn’t get caught by in a scripting language, such as misspelled variables, redefined variables, unused variables and imports, etc.
I also love that all golang code looks the same. Similar to Python, but even better because of the gofmt tool included in all good editors. As the Ops guy that I still am, I am thrilled by the fact that scp-ing a binary to a remote server is all that it takes to deploy your golang application. I still use ansible to configure my servers, but deploying an application (aka golang binary) via a simple Jenkins job has never been easier.
I realize now that golang is near to my heart because it combines the best of two worlds: the world of K&R C, which is what I studied in college, and the world of Python, around which most of my recent career has been centered. Golang feels like a scripting language, but with the elegance and speed of C. Now, if only I could use a debugger similar to the one I used to have in Visual C++!
