golang OO removal, benefits. over python?

[Ian Kelly]

On Sun, Mar 9, 2014 at 10:49 PM, flebber <flebber.crue at gmail.com> wrote:
> I was wondering if a better programmer than I could explain if the removal of OO features in golang really does offer an great benefit over python.
>
> An article I was reading ran through a brief overview of golang in respect of OO features http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/

The description of how Go structs work is accurate from what I know of
it, but I think the author goes astray in claiming that this is not
OOP.

If you look at how C++ compiles inherited classes, it works in
basically the same way.  The SmallBox class in C++ is essentially a
struct with its fields laid out in a specific order and some methods
that operate on it.  A BigBox class that inherits from SmallBox will
first lay out the SmallBox fields in the same way that SmallBox does,
and then add the fields specific to BigBox after.  Draw an imaginary
line around the SmallBox fields, and you have the same setup as the Go
example: a SmallBox nested within a BigBox.  SmallBox methods will
only operate on the portion of BigBox that is within the imaginary
line (i.e. the SmallBox) and don't need to have any knowledge that the
SmallBox is part of a larger data structure.  BigBox methods can
operate on the entire BigBox and can call SmallBox methods when
desired.

The author points out that nested structures can be made optional by
including a pointer to the structure instead of the structure itself.
Again you can do the exact same thing in C++; in OOP this is usually
described as a "has-a" relationship.  Most languages don't support the
syntactic sugar that makes this look almost identical to inheritance
in Go, but that's all it is.

The biggest difference between the two is that Go doesn't have any
concept of virtual methods.  A call of a SmallBox method on a SmallBox
object, whether part of a larger object or not, will always call that
SmallBox method.  Whereas a call to a C++ method that is compiled as a
virtual method will actually call the method associated with the
superstructure, regardless of the static type the method was called
on.  Go gets around this by using interfaces.  An interface that is
satisfied by SmallBox will usually automatically be satisfied by
BigBox also, and calls to interface methods are dispatched
dynamically.  As a result, object-oriented Go code will typically work
with interfaces rather than specifying actual classes, which is not
too different from how Java code is typically written.

Incidentally, I rather like the design of Go interfaces.  They are
essentially Python's duck typing made explicit, divorcing interface
implementation from formal inheritance.  On the whole though I think
that the language is not yet mature enough to be able to seriously
compete with more established languages like Python or Java.