Here I will provide some context on how the concept of multiplexing (or joining) channels got into my life, how it changed how I design concurrent algorithms and present an implementation of that idea comparing with a more common alternative. I have a feeling that this may be something well known by people who have experience with concurrent algorithms, but since there is a chance that I’m not the only person oblivious to this idea I’m going to try and explain how I discovered it and then had some fun with it and how I think it now helps me, in some cases (it is not a silver bullet), to write simpler concurrent code.

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.