Recent searches
Search options
Administered by:
"Go is neither an OOP language nor an FP language.
What is it, then?"
Someone asked me this today. My answer:
If you have an OO background, the first step is to see Go as "OOP without inheritance". (That's a good thing, as inheritance complicates programming a lot while achieving little.)
The second step is to think of Go as a "language of verbs". Don't think, "what object do I need to assign that task to?", but rather, simply ask, "What has to be done?" In other words, functions play a much more important role than objects (that are mostly "data types with methods").
The standard library is a good example of what that means. Many packages have top-level functions. Objects are kept simple and can be understood by looking at their data type, fields (if it's a struct), and methods.
No inheritance tree to climb, no overloading to inspect in order to find out what that code in front of your eyes does.
The beauty of simplicity.
@christophberger #Inheritance in #OOP was a promise of code reuse to software industry managers. It's the least boilerplate way of extending work done by developer A who is not working on that code anymore by developer B who just arrived.
In theory dev A would "complete" at least the abstract base classes and get it right once and dev B, C, D etc. after A wouldn't have to worry about the base. Saves money and enables flexible hiring.
It didn't work because if you're not a super strict government agency which even plans procedures of taking a dump, "getting it right" the first time is always a far away goal. And oftentimes modifying a base class means excessive refactoring of derived classes.