Here I try to share my journey understanding how Go approaches object orientation and how in the end it seems much more object oriented than most “traditional” object oriented languages.
On a previous post I explored the idea of expressing everything just with functions, and that Go objects are actually just a safe way to express a set of functions that always go together with the same closure and may operate on same state.
Are you in the mood for a stroll inside Go’s type system ? If you are already familiarized with it, this post can be funny for you, or just plain stupid.
If you have no idea how types and interfaces are implemented on Go, you may learn something, I sure did :-)
Since I worked with handwritten type systems in C, like the one found in glib GObjects, I’m always curious on how languages implement the concept of type safety on a machine that actually only has numbers.
I started to understand Go’s object model easier when I accepted that there is no objects at all, there is just sets of functions that can operate on common state, with some sugar sprinkled on top.
Perhaps you are thinking “shut up, of course there are objects in Go” or “sets of functions that operates on common state is the definition of an object”, well, you are probably right.
I can’t see a difference between a set of related functions operating on the same state and an object, at least thinking on the objects that I’m used to.
