Go is boring

Go doesn’t do a lot that makes it stand out from other languages, at least not in ways you might expect. It doesn’t have generics for user-defined types. It doesn’t have classes or exceptions either, and it’s quite verbose. To some it feels kind of plain, safe, sometimes backwards, maybe even boring. It certainly has its critics and it’s by no means perfect butit’s precisely because it doesn’t try to do too much that it appeals to so many people. The way I see it, Go is a good example of the KISS principle.

It does stand out because its “surface area” api is relatively small, because it compiles to a single binary, because it makes concurrency easy. It stands out because it’s opinionated about what a programming language should be, but most of all it stands out because it actually embraces simplicity of which the same cannot be said for .Net and Java to name but two alternatives. It lets me “get shit done” quickly and without fuss. Compile times are negligible, the tooling is fantastic, and it’s cross-platform too. No one IDE to rule them all because the choice is yours. I choose SublimeText and GoSublime.

I’m developing our company’s first Go application and the experience has been nothing but positive. It’s the first time in a long time that I can say I’ve really enjoyed a project! I put that down to Go’s philosophy of simplicity rubbing off and therefore encouraging me to keep things simple too. Development feels quick and easy, and despite not being a shiny functional language in the style of say, F# or Scala, the resulting code is remarkably stable and solid. At various points whilst working on this project I’ve jumped between Windows, OS X and Linux too, and there hasn’t been a single obstacle or stumbling block to doing so, everything has just worked.

After primarily considering myself a C#/.Net developer for all these years, I think Go has the potential to become my “weapon” of choice for many tasks. Maybe I’m just jaded from all the over-engineering or frameworks-first approach that is so eminent in .Net and Java land. Maybe I’ve realised that I can achieve the same, more even, without all the heavyweight baggage these platforms bring. And as for cross-platform, do I really want to be considering Mono? I mean, it’s a great effort but there are issues and differences that for me just make it a non-starter.

When I look at it from that point of view, Go really does stand out. As far as I’m concerned it can continue being as boring and as simple as it likes. Maybe I’m boring and simple too or maybe I just want to get things done as easily as possible, and not worry or argue about Monads and Monoids. Those are distractions that just get in the way. I mean, who really, truthfully cares? And perhaps, more pertinently, why should you have to?

In a software world bogged down by ever increasing complexity I find Go very refreshing, and fun too. It lets me do a lot with little effort. It’s a great alternative to current mainstream languages and deserves to do well. Whether it’s exciting or boring, object oriented, functional or neither, is irrelevant. Simplicity, readability, maintainability, scalability. These are all traits that are important to me and probably to you too. On that score Go delivers in spades, and that’s why I like it, boring or not.

Go is boring

Functional isn’t necessarily the cure

For a while now a number of people myself included (but my opinion has shifted slightly) have lamented the state of OOP, not the idea itself but rather how it, for the most part, is often interpreted which usually results in poorly constructed, monolithic and messy applications that nobody enjoys working on.

Though created with the best of intentions to fix perceived failings in the language or paradigm, the huge range of design patterns which was supposed to help the developer create loosely coupled, easy to maintain code has in reality contributed to the complexity, piling abstraction on top of abstraction and adding to the cognitive overload of the already burdened software developer.

It seems though that for some the tide is slowly turning. Functional languages, once the preserve of academia, now appear to be looming on the horizon for many software development shops as the next silver bullet to get them out of the hole they currently find themselves in.

For a while, I was there. I started to embrace the functional paradigm. I briefly played with Scala, then, as a natural progression for a C# developer, I focused on F# and I do like it but I quickly realised that whilst the paradigm and syntax may be vastly different, in the words of Led Zeppelin, the song remains the same.

I see functional programming as more complex and less well understood than OO. I can easily envisage the code -bases that will come of this movement in typical enterprise shops and the result won’t be pretty. The terse syntax and more abstract concepts that can result in some very hard to read code will make things worse not better, especially in the hands of the journeymen programmers who don’t see it as a craft. I dread to think of the “clever” code they’ll come up with. Some of us will have to pick up the pieces.

It’s often said that whilst we can’t avoid essential complexity, we should certainly strive to avoid accidental complexity in our code. Apply that maxim to our programming languages and tools and you might say we’ve failed completely. Whether it be OO and a multitude of frameworks and patterns, or functional programming and its often more complex syntax and concepts and I think it’s fair to say that neither paradigm does much to help stop us from shooting ourselves in the foot. In years to come we may well be hearing the same moans and gripes about functional code-bases that we hear today about OO and then, once again, we’ll be looking for the next big thing to get us out of the mess we’re in.

I guess what I’m trying to say is that just because we may feel that OO is broken, we shouldn’t automatically assume that functional is the answer. Functional is a shift sideways into uncharted waters for a lot of shops with no guarantee things will be better. No language or paradigm can solve all the problems caused by us, the developers. It may well do some things better or easier than OO but before jumping ship we need to get better at simplifying our existing code and resisting the urge to over-engineer. Less abstraction, fewer frameworks, and some common sense might just be enough to get things back on track. And if we can’t manage that in languages and paradigms we know well, what chance do we stand in those we don’t?

Functional isn’t necessarily the cure