Go Merrony

A Journey... I've been on a bit of an odyssey trying out various languages in case there is something out there that might suit me better than Go .  After considering many others - and actually trying out C# , F# , and Kotlin - my feeling is that I will not be abandoning Go in the short-to-medium term (although I may well delve deeper into Kotlin). However, as with many journeys, much of the benefit comes from the travelling itself rather than achieving a destination.  For the purposes of this exercise I ported a little utility of mine which unpacks a legacy file storage format to each of the aforementioned languages and tried hard to write idiomatically in each one.  Doing this inevitably leads one to question the structure of the original code and also any ingrained habits that might have passed their use-by date. ...and An Outcome If I am sticking with Go, I really ought to think about trying to write 'better' Go. A Case in Point One of my pet peeves about

After a couple of years programming in Go the honeymoon is definitely over.  I have thousands of lines of Go code sitting on Github now and I don't think I will be abandoning it, but it's time for a little rant. There is a lot to like about Go - above all its simplicity.  But this simplicity comes at a cost; some apparently uncomplicated things have been omitted from the language and these tend to increase significantly the SLOC of Go programs and packages. Missing Features Enumerations Although these can superficially be simulated with constants, doing so does not give you the safety of having the compiler warn you when you omit a case in a switch statement.  It seems to me that this is precisely the kind of programming error that the Go authors claimed to want to eliminate with the language. Consts in Structs Time and again I have found myself wanting to write something like type someT struct {   const maxThings = 20   ... } ...more lines of code required.

Part of my effort to maintain the Data General 32-bit minicomputer legacy has included writing free, open-source terminal emulators for the DASHER-series character terminals. I now have three such emulators: DasherQ - written in C++ and Qt - the original, maintained; DasherJ - written in Java and JavaFX - kinda deprecated; DasherG - written in Go using the Go-GTK GUI package - the latest incarnation. Although functionally very similar (all provide serial and telnet access, DASHER commands, and DASHER function key handling), each has its pros and cons. DasherQ relies on the Qt library, which is truly multi-platform and it runs just fine on Windows, Raspbian and many desktop Linuxes. The drawbacks (from my point of view) are code complexity and keeping up with changes in Qt - twice in the relatively short lifetime of DasherQ it has suffered bit-rot due to changes in Qt. As I delve deeper into Go I also find that I am less inclined to maintain C++ code. DasherJ was really

In any craft the best results are usually achieved by using the right tool for the job, so the Rosetta Code site is an invaluable resource for thoughtful programmers. There you can compare attempts at solving problems ('tasks') idiomatically in many different languages. I thought some of the gaps in the Go coverage should be addressed… I started off with Smith Numbers - just by rewriting the existing C version in Go. It's interesting to compare the versions side-by-side; it seems clear that the Go version is less cluttered and therefore a little quicker to comprehend. Next Calendar , a classic task I haven't considered since college days. I wrote that from scratch, populating a data structure first, then displaying it. On to Combinations and Permutations where use of the standard math/big library made things very easy. Again, it's interesting to compare the readability of the code with some of the other languages implementing this task. For the A

…how and why to use them   Here I discuss my use-case for variant types in Go , how to implement them, and the pattern I have established for their safe use. I have included some real-world code rather than the traditional Go “animal farm” examples but for the short version skip to the TD;DR at the end. Background I am working on a large spare-time project which currently consists of a little over 7000 lines of Go, I expect that to double before it is released. I started off inspired by an extant Java project which had related aims, but the Java style was very idiosyncratic and I found the code hard to read. For historical reasons I flirted with PL/1 , and that might have been a goer if only it were a little more mature; unfortunately I hit bugs in the compiler which I didn't want to work around. Then I converted the code to good old plain C which was fine until I wanted platform-neutral threads and filesystem I/O. I know there are libraries to solve these problems, b