I had to hack the CSS a bit to make it readable, but I agree with the author. Particularly, I like his comments on Go's attitude towards OOP. As a Ruby hacker,

I had to hack the CSS a bit to make it readable, but I agree with the author. Particularly, I like his comments on Go's attitude towards OOP. As a Ruby hacker, I find that everyone on my team really likes to build a class and think of the instances as real physical objects. That's to be expected because it's how we were all taught to think of classes/objects/OOP in general. Objects in your code are not physical objects. You don't have to carry them around with you and pass them back and forth and up and down. You can build new objects that are specific to your functions. I find that Go encourages me to build structures that are relevant to the situation instead of classes that are broadly scoped concepts. I also feel this way when I work with C, but I like it better in Go due to the receiver syntax. It's true that my problems in my Ruby apps are my own (and my team's) damn fault. We should be better at single responsibility. Still, Go's approach to OOP encourages single responsibility and other good practices. I don't understand what's boring about that. I for one get a real thrill when I write some Go code then go over it and think "damn, that's just not going to break..."