Learning Golang, Day 9 – Go's Empty Interface.

My intention as I sat down to study at one of the local cafes, today, was to learn more about Go’s Empty Interface. I was learning about it, yesterday, but it didn’t make a whole lot of sense then. So instead of moving on with a sliver of an understanding, it seemed worth studying it longer.

I started googling on the topic and began reading through the first couple of links, focusing on one by Flavio Copes. His explanation, while more detailed that that on the Go Tour, was still not complete enough for me to fully grasp the concept.

However, I did appreciate them more broadly, by talking about Go implementing Structural Typing. If you’re not familiar with the term, here’s the core of it:

A structural type system (or property-based type system) is a major class of type systems in which type compatibility and equivalence are determined by the type’s actual structure or definition and not by other characteristics such as its name or place of declaration. Structural systems are used to determine if types are equivalent and whether a type is a subtype of another. It contrasts with nominative systems, where comparisons are based on the names of the types or explicit declarations, and duck typing, in which only the part of the structure accessed at runtime is checked for compatibility.

In structural typing, an element is considered to be compatible with another if, for each feature within the second element’s type, a corresponding and identical feature exists in the first element’s type. Some languages may differ on the details, such as whether the features must match in name. This definition is not symmetric, and includes subtype compatibility. Two types are considered to be identical if each is compatible with the other.

This was fascinating on so many levels; partly because I’m so used to working with nominally-typed languages, such as PHP and Java, and partly because I was now gaining a deeper, better grasp of the concepts behind the languages that I’ve been using.

I can’t express enough how enabling this kind of knowledge is. I feel that, through having it, I can make much more informed and meaningful decisions when writing code.

At this point, however, I went off on a bit of a tangent, as I found links to so many more topics that I wanted to learn about, such as Abductive and Deductive reasoning, duck typing, and Duck testing. I think I easily spent the next 15 minutes learning about these concepts and not Go directly.

That’s not a bad thing, and these kinds of tangentially related topics can often help. However, I did want the 30 minutes to be as directly related to Go as possible.

Anyway, I digress. Did I satisfy my desire to learn about what Go’s Empty Interface is? Not quite. But as soon as I’ve read an excellent article on the topic, by Vincent Blanchon, a few times, I think I’ll have it down.

He shared this quote, which was a good start:

An interface is two things: it is a set of methods, but it is also a type. The interface{} type is the interface that has no methods. Since there is no implements keyword, all types implement at least zero methods, and satisfying an interface is done automatically, all types satisfy the empty interface.

He then went on to say:

A method with an empty interface as argument can therefore accept any type. Go will proceed to a conversion to an interface type to serve this function.

And after that, he started discussing the internals of the Empty Interface, such as that an interface is composed of two words:

a pointer to information about the type stored
a pointer to the associated data

Have a read of the article to get the full story. Suffice to say that I, at this point, I feel comfortable enough to use them, even if they don’t fully make sense, yet.

See you, Monday!