Hacker News Reader

Comment by lastangryman | Hacker News Reader

IMO, Go is capable of supporting OOP style code, but is not an OOP language. Coming to Go from more dogmatic OOP languages is such a breath of fresh air. If you just need a struct, you can have a struct. If you want a package scoped standalone function, you don't need to invent some made up "class" to attach it to. As the article shows, you can implement OOP style code and use OOP paradigms when they make sense. With Go, they emerge more naturally from the code as you are not trying to force them in from the start.

These are probably trivial things to a lot of people but after being brought up on Java, and working in rather OOP-heavy frameworks for years, it's liberating.

View on HN

I don't think you can call a language object-oriented if it doesn't support some form of inheritance and dynamic dispatch. And for Golang that's simply not the case. You can embed data structures into other structures but the main difference to e.g. C++ is that you don't have proper RTTI (run-time type information) that would do a dynamic dispatch of struct methods, so you can't do anything interesting (i.e. you can embed an "Animal" struct in a "Dog" struct but if you define the ".MakeNoise()" method on the Animal struct and have that call a ".myNoise()" method on the struct to e.g. produce "Woof" or "Meow" then even if you override ".myNoise()" in the "Dog" struct the "Animal" struct will still call its own ".myNoise()" method, as there's no dynamic call table like in C++). People will probably say that's by design but I'd then argue again that's not object-orientation as you can do these things with C structs as well and no one would call C an object-oriented language.

I think traits are a big improvement on inheritance, do you count those as as some form of inheritance? In this case I can agree with you.

Personally, when I have to use it, I make abstract classes or better, interfaces. I avoid direct inheritance like the plague. But I've worked on personalized Jenkins where I had to inherit classes from weird modules, so maybe I got burned and my experience isn't the average experience (also, I hate Java now).

In my understanding traits (I guess you mean as defined in Rust?) are more powerful than interfaces in the sense that you can define them for objects from the outside, but I don't see how you could use them to build dynamic-dispatch like functionality? Not an expert on traits at all though.

I think traits and interfaces are more supportive of a composition-like programming style, one might call that object-oriented but I still think it misses several key concepts of classical object-oriented languages.

In Go, interfaces are used for dynamic dispatch. No need to the the whole ".MakeNoise() calls .myNoise()" dance, just implement ".MakeNoise()" on each type directly:

    type Animal interface {
        MakeNoise()
    }

    type Dog struct{}

    func (Dog) MakeNoise() {
        fmt.Println("Woof!")
    }

    type Cat struct{}

    func (Cat) MakeNoise() {
        fmt.Println("Meow.")
    }

    func MakeNoises(as ...Animal) {
        for _, a := range as {
            a.MakeNoise()
        }
    }

    func main() {
        d := Dog{}
        c := Cat{}
        MakeNoises(d, c)
    }

That's not what I described above. Object-orientation means that you can override behavior of a base class in a derived class and have the base class be "aware" of that overridden functionality at runtime. You could probably argue that interfaces allow composition and thereby an object-oriented style, I don't think that's what most people would understand as object-oriented programming, though.

> Object-orientation means that you can override behavior of a base class in a derived class while maintaining base functionality, and have the base class be "aware" of that overridden functionality at runtime.

No, that's not an inherent property of OOP, that's a property of C++.

To be OOP, you must support inheritance (which Go does, through struct embedding) and polymorphism (which Go also does, through interfaces). The polymorphic inheritance you're talking about is strictly a C++-specific implementation detail.

Struct embedding is simple composition, not inheritance. If you embed an "Animal" in a "Dog" struct, the "Animal" struct doesn't have any means to find out it's a "Dog", i.e. it can never find out at runtime that it's embedded in a "Dog" object or rely on functionality defined in the "Dog" object (unless you write specific helper functionality for that). You can do Golang-style composition via union structs in C as well, but that doesn't make C an object-oriented language. Of course you can build a vtable in C or Golang to make object-orientation work (C++ came to being like that), but again it's not a concept the language itself supports.

> Struct embedding is simple composition, not inheritance.

In C++, composition differs from inheritance because when you embed an object inside another object, you cannot call its method directly, but through a wrapper:

    class Dog {
        Animal a;
        bool IsAlive() {
            return this->a.IsAlive()
        }
    }

However, in Go, you can call their methods directly:

    type Dog struct {
        Animal
    }

    func main() {
        Dog.IsAlive()
    }

So the distinction itself isn't really meaningful. In Go, composition is inheritance.

How else do you define inheritance, if not as ability to call methods of the inherited type?

> If you embed an "Animal" in a "Dog" struct, the "Animal" struct doesn't have any means to find out it's a "Dog", i.e. it can never find out at runtime that it's embedded in a "Dog" object or rely on functionality defined in the "Dog" object

I'm not quite clear on what you mean. How exactly does this work in C++? How do you "detect" it's a Dog on runtime, or "rely" on functionality defined in Dog?

If you can provide code example, that'd make things much easier for me to understand.

C++ has that syntax under the name "unnamed" or "anonymous" fields. It's trivial syntactic sugar. That's unlikely to be called inheritance though.

If you redefine OOP as functional composition then almost every language passes as object-oriented, including C. To me that simply doesn't make any sense though, and I don't think it's what people would understand as object-oriented in the context of a programming language. Inheritance is a two-way relationship, i.e. if "Dog" overrides functionality in "Animal" then an internal method defined in "Animal" that calls that functionality would be dispatched to the overridden one defined in "Dog". That simply doesn't happen in Golang, hence it does not implement inheritance. C++ e.g. uses vtables for that.

> Inheritance is a two-way relationship, i.e. if "Dog" overrides functionality in "Animal" then an internal method defined in "Animal" that calls that functionality would be dispatched to the overridden one defined in "Dog".

I disagree, I think that's actually bundling the concept of polymorphism with the concept of inheritance. Okay, C++ does it, but is there any other reason why inheritance must support polymorphic methods in order to be "real" inheritance?

C++ uses virtual classes to achieve polymorphism through inheritance. Go simply uses interfaces. I don't see any reason why Go's approach would be "less OOP" than C++.

That’s just structural typing..

This is really strange, since pretty much all modern languages bundle structural inheritance and polymorphism together; it's definitely not just a C++ oddity, it's a pretty fundamental aspect of Java, JS, PHP, Python, ... I suppose polymorphic inheritance bundled together isn't a requirement of OO-style coding, but without it you have no concept of scope and without that you really can't say a language itself is Object Oriented.

> it's definitely not just a C++ oddity, it's a pretty fundamental aspect of Java, JS, PHP, Python, ...

Yes, but I'd argue that's because all those languages just blindly copied what the massively successful C++ was doing at the time. Nobody gave it a second thought.

From the perspective of language capability, polymorphic inheritance doesn't give you anything that you cannot achieve with polymorphism and inheritance alone. In fact, there was no polymorphism outside of virtual methods in C++. If you want polymorphism, you have to implement it through virtual methods, there's just no other way.

I don't speak Go. Is there some magic here that lets Dog and Cat know that they're implementing Animal? Or are you just informing MakeNoises(as ...Animal) that it will be receiving something that should implement Animal, with no compile-time type checking?

Being able to specify that an argument conforms to an interface is not what's generally meant by "object oriented". Interfaces are really only a formality. What matters is inheritance.

> Is there some magic here that lets Dog and Cat know that they're implementing Animal?

No there isn't and that's the point. Say you're building a lib and someone else wants to reuse it and its methods and extract functionality into a more generic interface; as the original author you don't need to go and modify your lib to accommodate for every single third party dev out there.

Basically, the interface might be in another package, and that's fine.

> with no compile-time type checking?

The compiler will still check if Dog and Cat implement the interface, because at compile time everything is known.

But then Dog and Cat need to both contain [edit] explicitly reproduce, verbatim [/edit] all the common functions of "Animal" - even if they're exactly the same? Just so someone later can take Dog and reuse it without implementing Animal?

You can use struct embedding to accomplish that if you need it (Embed Dog / Animal in a new struct which adds/modifies functionality).

Though this is used fairly rarely in Go.

Animal is an interface: it has no "common functions", they're just definitions.

If you need a common function, what you want is another structure, say Pet, and use structure embedding

    type Pet struct {
        func IsCute() bool {return yes}
    }

    type Dog struct {
        Pet # note how it is not named
    }

    func (Dog) MakeNoise() {
        fmt.Println("Woof!")
    }


    func main() {
        d := Dog{}
        d.IsCute() # yes
     
        # A third party lib
        type Chihuaha struct {
            Dog
        }

        c := Chihuaha {}
        c.IsCute() # yes
        c.MakeNoise() # Woof!
     }

Go has duck-typed interfaces.

It will make sure that only values implementing Animal will ever be used as an Animal anywhere. It's fully statically type-checked.

It's arguably one of the defining features of Go in general, and is what shapes much of the idiomatic code style.

> Is there some magic here that lets Dog and Cat know that they're implementing Animal?

In this case, Animal is an interface - which means, a set of methods. The Animal interface in the example contains only a method "MakeNoise()". Any type (struct) that implements the method "MakeNoise()" implements the interface, and can be used whenever Animal is required.

Interfaces do not provide inheritance either. A language without inheritance in my opinion isn't OOP. Otherwise, you can call C an OOP language, too, because you can write C programs in OOP style. Some people do that but it's not a reasonable way to define OOP. Structure composition is not inheritance.

I personally wished Go had full OOP, ideally with multiple dispatch. It's what I miss most from CommonLisp and Racket when I write Go. The only arguments against it I've seen so far were rather silly and patronizing arguments along the lines of "we have to protect the programmers."

A language is OO if it supports two things:

* Encapsulation: Bundling data and functions syntactically together (in which case they're commonly called classes and methods)

* Dynamic dispatch: Calling a method may call a different function implementation depending on the runtime type of the class instance

But that's it.

C++ inheritence is actually two features (at least), which you seem to be conflating: it supports dynamic dispatch through virtual methods, but also allows using the implementation of base class methods in derived classes (whether virtual or not). But only the first part is actually needed to be called object oriented. Even VBA is technically OO because its use of COM interfaces allows dynamic dispatch - even though it doesn't support inheriting method implementations at all.

(A couple of notes: If a language only supports encapsulation but not dynamic dispatch then it's "object based" rather than object oriented. And, when encapsulation is supported, the language usually also supports data hiding (that's public/protected/private in C++ speak) but technically that's a separate thing.

> A language is OO if it supports two things

Yes, but only in your personal opinion. I disagree. As I've said clearly, for me a language is not OOP without inheritance. Go is not an OOP language. This is important for me because I like Go and think it's a great non-OOP language. In contrast, if Go was an OOP language, then it would be a really bad one - no traits, no mixins, no classes, no multiple inheritance, no multiple dispatch, no true dynamic method dispatch (see below), etc. Besides, treating Go as if it was an OOP language often leads to horrible Jave-in-Go programming style.

Btw, I wasn't talking about C++ inheritance, I had things like CommonLisp CLOS and Ada's tagged types in mind. CL's OOP is among the most powerful because it has multiple dynamic dispatch and a metaobject protocol. Go lacks both, and it also doesn't really have dynamic dispatch. Dynamic dispatch means that superclass and subclass methods can be called at runtime depending on what is needed. You cannot call various superclass methods of a Go struct because Go structs do not have a type hierarchy/superclasses as there is no concept of inheritance. You sometimes get something that looks similar because of the duck typing (which is dynamic, but it's still not a full method dispatch) and because you can downcast at runtime using .(type). But that's still not the same as dynamic dispatch in an OOP language. Here is an explanation of the difference: [1]

However, if you insist on imposing your definition as the one and only right one, then that's okay for me. In that case, Go is the most limited and crippled OOP language I've ever used, and so be it.

[1] https://stackoverflow.com/questions/49114057/idiomatic-way-t...

I suppose we've got bogged down in semantics here (in fairness that's the point of the original article). I agree that Go is not a good language for OO and that's fine because it's not meant to be.

But definitions aren't really a matter of opinion. If it's my opinion that apples count as a variety of orange, then that doesn't make me right. Instead, they're defined by what is widely understood by that term. I'm not saying what I've written is authoritative but it was what I was taught at university by someone who was around and academically active when OO languages were being invented (that course had a lot of SmallTalk D-: ) and certainly is a much closer match to how I've usually seen it used since compared to yours.

BTW I'm primarily a C++ (and Python and C#) developer, I hardly know Go, so I have no axe to grind here.

> Dynamic dispatch means that superclass and subclass methods can be called at runtime depending on what is needed.

No it doesn't: it doesn't require the notion of superclass and subclass. Using an interface to call a method still counts as dynamic dispatch.

> Here is an explanation of the difference: [1]

The thing is, the question asks "does Go support dynamic dispatch" but the answers are about the subtly different question "does Go support this particular type of dynamic dispatch". The second answer even says that "Go ... interfaces are its only form of polymorphism". Runtime polymorphism is a form of dynamic dispatch! (The only form I know to be honest but I don't claim to be an expert and don't have your experience of lisp-like languages.) The first answer talks about inheritence but never mentions dynamic dispatch at all. If you reduce the whole question down to two totally separate structs (none of that weird Go inheritence / composition stuff) with only one method each, both implementing the same interface, and you called the method through the interface, then that would be dynamic dispatch. Of course, it's not the dynamic dispatch the question poster wanted. And it's not inheritence (although I think that term is much more ambiguous but I still wouldn't dispute it).

Fair enough, there is no doubt you can have some sort of dynamic dispatch without inheritance. I'm more skeptical about your definition of OOP. That seems silly from a historical perspective, and they really shouldn't have taught you that at university. Historically, dynamic dispatch was invented and used for full-fledged OOP systems, so much that you'd expect from the feature "dynamic dispatch" the ability to determine an object's class at runtime and dispatch methods based on it. Smalltalk is a good example, it has full support for inheritance and exactly the kind of dynamic dispatch I described, like practically every other OOP language that has ever been invented. They merely differ in whether they allow single dynamic dispatch or have multiple dynamic dispatch like e.g. CLOS. As far as I know, Go's crippled version of structure composition without inheritance is fairly new, and, as much as I like Go, is a rather annoying and artificial limitation. Even modern Pascal has full OOP.

Then you find real golang code littered with things like

    var _ Animal = (*Cat)(nil)
    var _ Animal = (*Dog)(nil)

and you're back to the same place with more verbosity, and with much more difficulty when trying to figure out which types implement which interfaces. Much more load on IDEs as well.

Maybe am missing some nuance in the above comment, but can't the above be achieved in Go with an interface:

type Animal interface { MakeNoise() }

Link to an implementation of scenario: https://go.dev/play/p/bSAFr9i4ex3

See above, interfaces won't solve that problem unfortunately.

Inheritance has nothing to do with oop, oop was about message passing. Most big oop languages seem to discourage inheritance in favor of composition, how can inheritance be a requirement?

On the other side, message passing and dynamic dispatch are strictly related and you can do that with golang interfaces!

So yes, it does support full oop, what it doesn't support is class-based programming.

Does it matter at this point? Oop hasn't solved any of the big problems it claimed and fp did not either.

https://news.ycombinator.com/item?id=11966570

https://en.wikipedia.org/wiki/Object-oriented_programming?wp...

That’s just the Alan Kay definition - just because he coined the term, it is not at all how it is used nowadays.

OOP as commonly understood requires some form of inheritance.

I don't agree on this statement: the wikipedia page for oop strictly distinguish between the two, given how widespread wikipedia is, that can be considered a valid source for this definition. That page distinguishes between oop and class-based programming

I believe it's called multi paradigm languages - most I've used are like that (C++, Kotlin, JavaScript, Python, ...). The only dogmatic OOP languages I can think of are Java (where it is IMHO nastily done), Ruby and Smalltalk (in both of which I never felt the burden of OOP boilerplate).

I think it's a Java problem, not an OOP problem.

A static method is basically a “standalone” function with a namespace only. You can static import it and do whatever you want.

Java is a multi-paradigm language, and is absolutely on a different level of expressivity compared to Go.

EDIT: Java is really not what people remember from 20 years ago. You can write as functional code as you wish stopping just before Monads. It’s type system is also a different league than Go’s. So it has OOP, imperative and FP.

Since most early Java adopters were Smalltalk shops, I fail to see the difference.

I used Smalltalk/V before Java came to be, by the way.

Yes, good point. I worked in a lot in PHP though and interesting that a lot of the changes it has went through the last 15 years seem to have been "inspired" by Java. A lot of frameworks (Laravel, Symfony, Zend) seem to lean heavily on OOP style, and it's easy (or it was for me anyway) to fall in to the trap of everything must be a class and if not you are doing it wrong, even if the language does not require OOP. Design Patterns, Refactoring, Clean Code, it feels like a lot of my "industry journey" if you like was built on an assumption that everything started with OOP. Go, for me, was the first language I've used in a while that truly detached itself from all that dogma, not just in it's features but it's overall principles and ethos.

Java's "problem" is more cultural and historical than technical. Modern Java has lots of support for functional and multi-paradigm programming. However most non-trivial Java codebases are quite old and don't take advantage of these newer features, plus most Java programmers were trained in the traditional Super-OOP style of Java programming and still program and advocate for that style of programming.

> Coming to Go from more dogmatic OOP languages is such a breath of fresh air.

There are only a few (two?) dogmatic OOP languages in common use. Every other language that supports OOP has better OO support than Go, as well as:

> If you just need a struct, you can have a struct. If you want a package scoped standalone function, you don't need to invent some made up "class" to attach it to.

While I like Go, a lot of Go code could be simplified by having keyword-supported OO (a 'class' keyword, maybe).

It's better to have inheritance and not need it, than need inheritance and not have it because it is applicable in a lot more places than "composition over inheritance" fanboys would have you believe.

> If you want a package scoped standalone function, you don't need to invent some made up "class" to attach it to.

It's a matter of language construct organization. There are bare behaviors - functions, there is bare state - PODs, and then there are collections of state and behavior - classes. You can have these three distinct constructs, or you can have all them be subcases of class (or some other mix).

It's just that we are used to having distinct primitive and collection data types, but nothing (sans terseness) stops language from having all data be some form of collection, even if it is a single-member collection.

It can as much as every Turing-complete language can support any programming model given enough abstraction.

Worth reading Felleisen’s paper “on the expressive power of programming languages” (or watch this talk https://youtu.be/43XaZEn2aLc) which argues that if a language A has a feature that would require global refactoring to implement in language B, then A is more expressive than B.

Sure, I was just being sarcastic on parent’s claim not meaning too much ad absurdum.

Nonetheless, thanks for the paper/video, will look into them!

With records now available in Java and C#, not only can you do the same there, but you get even more assurances such as overloaded `.equals()` and `.hashCode()`.

Reply on news.ycombinator.com