In a recent talk, Russ Cox asked Go developers to write about problems they’ve run into with Go in an attempt to help steer the design process for Go 2. In this post, I would like to attempt to do so by explaining some of the issues I have with Go’s interfaces. To start with, I think it’s best if I explain the problem I think that Go’s interfaces solve before explaining where I think they fail.

I recently helped my brother move a number of directories to their own hard drives on a new Linux system, and he requested that I make a guide so that he can do it again if he needs to. So, here’s a guide. Some Things to Note There are lots of other guides out there for how to do this kind of thing, but none of them achieve quite what he wanted.

I would like to take this opportunity to announce Signage. I recently (Yesterday, actually.) stumbled accross the White House’s signed legislation list. I thought it was neat, but I was quite disappointed to find that it doesn’t seem to have an RSS feed. So I wrote one. Signage is in two parts: A package that provides a very simple API for fetching and scraping the lists of legislation from the whitehouse.

There’s a situation that, while it doesn’t happen too commonly, annoys me when it does happen. Someone comes to Reddit, or golang-nuts, or somewhere else, and asks about the often repeated refrain about composition vs. inheritance. Sometimes, they get the right answer. Sometimes, someone makes some out-of-nowhere remark about embedding. The problem is that embedding is not in and of itself composition. It can be used in composition, but composition is not a syntactic or behavioral choice in the language; it’s a design pattern.

The release of Go 1.8 inches steadily closer, bringing with it many interesting and useful features and improvements, including shorter compilation times, an even faster GC, and, my personal favorite, initial support for plugins. Plugins, essentially Go’s version of C’s dlopen() and related functions, are an interesting one. The ability to dynamically load packages at run-time has been one of my most wanted features in Go since I first figured out how interfaces work.

So, for the last couple of months I’ve been working on a project for school which has required me to use MonoDevelop. I first used MonoDevelop around 9 or 10 years ago or so when I was using C# fairly regularly. Back then, I remember MonoDevelop being a fairly competent, if somewhat limited feature-wise, Linux and GTK# alternative to Visual Studio Express and Windows.Forms, so I wasn’t particularly worried about using it for this project, despite not having used it in a while.

Apparently, I should have been.

Just in case any of you are actually in the U.S., Happy Thanksgiving to all the Russian-proxy spambots. How about a video?