Been hacking on a side project in Go, after coming from a career of nearly exclusively using OO languages, with a little bit of functional here and there. And o

Been hacking on a side project in Go, after coming from a career of nearly exclusively using OO languages, with a little bit of functional here and there. And of course enjoying all of the new functional features that nearly every big language has been racing to implement these days. At first there I had some quirks, along the lines of "how do I get thing X from A to B", or "these things are similar how do I share code between them". Everytime this happened I couldn't help but go through a process of solving the problem in OO and then unwrapping it into a non-OO solution. Which doesn't always turn out well. Eventually, once I became comfortable with Go, I got to the point where I just code things in the most obvious way possible. This struct has these fields. This function takes x and produces y. I dont try to take a big picture view of the software as a whole, Im just solving a bunch of small localized problems one after the other. Then I refactor periodically to get rid of anything completely stupid, and make sure the big picture looks ok. The name of the language is quite fitting, you just go. Whereas in OO, for me at least, it feels like im constantly bouncing all around the abstraction layers of your program. Any change I make here in class X could affect these other classes. Class A is dependent on Y, but so is class B. How do I share it between them? Maybe dependency injection? Subclasses? Do I refactor to an abstract class? Wait, should it be an abstract class or an interface, what's the difference again? Is this generic enough? I only need to use this in this one place, but I'll make it generic because "best practices". What if I might need this other subclass eventually but it's not on the spec right now? I'm obviously exaggerating, but I think most of us have been there. I find I often end up in a competition against myself about being more clever or more reusable with my OO code. Our job is already hard enough when you have to decide and reason about algorithms, data structures, concurrency etc. The extra layer of code patterns usually just obscures things. I'm not a complete hater though. Using a well designed OO library can be an absolute delight (PyTorch being a great example). But OO is the kind of thing were its not just garbage in garbage out. The garbage multiplies and creates even more garbage.