No Time To Play

A first look at the Go programming language

by on Jan.12, 2017, under Off-topic

It’s not easy to keep up with new developments in IT, especially when you work long hours, or for that matter when you no longer learn quite as easily as you used to when you were twenty. So far I was lucky to pick my technologies well: expertise in Python, HTML5 and even Java (for now) has only grown more marketable in recent years. It still felt like falling into a rut as of late, and moreover I kept stumbling across projects written in the Go programming language. After some hesitation, I decided to take the plunge, and it turns out I can still learn a new programming language in a couple of days. Go me!

And what a language it is.

Go is mostly targeted at server-side software, which makes it less relevant for games unless you’re doing multiplayer. Then again, it’s just as good for command-line apps (think tools), and there’s a healthy choice of libraries for text-based user interfaces that don’t require separate DLLs.

But what’s it like, exactly?

  • It compiles to native code like C++;
  • has garbage collection like Java;
  • the package system resembles Python modules;
  • the object system resembles the one in Haskell;
  • control structure syntax is like in Perl 6.

I’d say Go is an odd duck of a language, except it’s more of a platypus. Good to see programming language designers having some guts, after decades of slavishly imitating C.

In the way of downsides, the elephant in the room is of course the lack of proper exceptions, which just seems odd for a modern programming language. But look at it this way: in a compiler, is a source file with syntax errors really an exception? Is it truly unexpected? I’d say it’s business as usual. Too many programmers use exceptions as a crutch, and don’t even get me started about doing flow control with them. The real problem here is code becoming verbose and muddled when you have to check for errors at every step. But hey, at least exception haters can shut up now and enjoy their absence.

A smaller problem is the lack of assertions, which are really useful in the 1% of cases when you really want to assert something instead of simply checking, and other quibbles are surfacing during work: I keep forgetting to create variables instead of simply assigning to them, since it’s a slightly different operator, or to propagate errors properly when I’m not dealing with them on a local level. I also keep expecting automatic semicolon insertion to bite me in the behind like it tends to in Javascript, but it hasn’t happened yet, so there’s that.

Upsides are more numerous and important. Fine-grained numeric types for performance tuning. A static type system that doesn’t get in the way. Type inference. Dynamic typing on request via the empty interface and type assertions. (How many other languages have type assertions? Only C++, and only for templates — through various kludges.) It’s not as good as generics, but it provides a lot more flexibility than critics of the language like to claim.

Moreover, the language is small and clean. It took me one afternoon to take the official tour, and another day to half-read, half-skim a textbook — Learning Go if anyone’s interested. The next morning, I was able to code a “Hello, world!” correctly from memory on first try, and two days later I’m already productive. Compared to the intricacies you have to learn before even trying to use C++, for instance, or the overwhelming size of the Java standard library, this is a breath of fresh air. Most documentation does seem to omit useful details, such as multiline strings and function argument unpacking, but the reference manual has you covered.

I’d draw a conclusion, but it’s too early before completing even one project successfully in Go. That said, unpleasant surprises seem unlikely at this point, and now I have another tool on my belt, one that opens up new opportunities. Take a look.

Creative Commons License
A first look at the Go programming language by Felix Pleşoianu is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.


2 Comments for this entry

  • fluffy

    I enjoyed working with Go when I was trying it out for a project, but at the time it had a few performance characteristics that didn’t quite work out for what I was trying it for. It also lacked any reasonable way of doing multi-indexed data structures, and calling into a an external C library to provide that functionality had a huge performance gotcha in how they handled multithreaded access to the linked stack concept.

    This was all back in the 1.x days (1.1, I think) and the project itself has no relevance to me anymore. I might go back and revisit Go at some point, although I don’t really work in any of the problem domains it seems suited for at the moment.

    • Felix

      Well, the language is at version 1.7.4 now (1.8 coming next month), so I imagine things have improved since you last tried it. But yeah, I ran into a similar problem where my choice of architecture turned out to be a poor fit for the language, resulting in overly verbose code (performance is still decent, though, if hardly anything to write home about). But that just means it’s not suitable for just any project — which is true of any programming language ever, and I already have an idea of how to make better use of it next time.

Leave a Reply

Posts by date

January 2017
« Dec   Feb »

Posts by month