Is Go an Object Oriented language?

UPDATE: I updated the article with provided extra research on OOP therefore I am removing it from here, damn code duplication and continue in the original Medium article please!

---

Comments

[Eljay-Adobe]

Note that KISS means "keep it simple stupid", rather than "keep it simple, stupid".

The former has the stupid referring to it. The latter has the stupid referring to the developer.

The origins of the acronym are in designing something so simple-stupid that it could be fixed in the field, with minimal tools, under combat conditions.

[Lukas Lukac]

Hey Eljay, thx for feedback. Actually, any one of the forms is referring to someone being stupid. I think you misinterpreted it. As far I know, the comma should be there. KISS is an acronym for "Keep it simple, stupid" as a design principle noted by the U.S. Navy in 1960.[1][2] The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design, and that unnecessary complexity should be avoided. en.wikipedia.org/wiki/KISS_principle

[Eljay-Adobe]

As per the URL you linked to, in the Origin section, pointed out that Kelly Johnson, lead engineer at the Lockheed Skunk Works, who coined the term, did not have a comma.

[Lukas Lukac]

You are right! I didn't see the origin section. Good to know there are both alternatives and the without comma is actually the original one.

[Alain Van Hout]

Wikipedia seems to disagree: en.wikipedia.org/wiki/KISS_principle

[Theofanis Despoudis]

You forgot to mention that methods also can be applied to any type and not only Structs. For example this is valid:

package main

import (
    "fmt"
)

type Integer int


func (d Integer)Squared() Integer {
    return d * d
}

func main() {
    fmt.Println("Hello, playground")
    var d Integer = Integer(10).Squared()
    fmt.Println(d)
}

[Lukas Lukac]

That is a great feature indeed you are right but not really forgot. I also didn't mention type functions, Interfaces etc. Maybe in another post :) The main goal is to show the the difference between a classical Struct and a classical Class. Assigning methods to primitive types is a bonus that normal OO languages don't have so not really necessary to compare as there isn't any comparison.

[Thomas Junkツ]

I would agree, that go is not object oriented as Java is. Java is the hardcore example, since classes are its pivot point. But if you compare it to python, which is considered object oriented, you find similar goals.
Python has no data hiding too - it was built for adults ;)

Go sacrifices not only encapsulation but on top even inheritance. Go designers have their lesson learned. Go favors composition over inheritance by design, there is only composition.

What go retains is polymorphism and its own flavor of duck typing.
If it walks like a duck and serveHTTP it must be a Handler of a server. But it could be anything.

I would call Go a pragmatic object oriented programminglanguage, if that wouldn't make a bad acronym.

[Lukas Lukac]

Hey Thomas, I see your point but personally I can't agree Go is object oriented. Inheritance is not that useful, we all learned that therefore is not included in Go design. I would say Go is behaviour driven and has interfaces/typed functions to allow abstraction/extendibility/all kind of useful patterns for maintainable software. That's it. People are forcing the Object Oriented nature on it for no good reason imo.

[Thomas Junkツ]

Coming from the other side, I agree that go is as far from classical object orientation as e.g. Javascript is. And if you bring your OOP luggage with you, you are perhaps having a hard time.

Not to forget to mention, in Go are functions first class citizens and Go has (of course) closures.

It is hard to clearly categorize Go.

But "kind of" is good enough for me as a category.

[Lukas Lukac]

Fair enough. I mean, the official Go resource I quoted in the article also categorized it only as "kind of" so you are not far away from official Go maintainers! :)

[Lukas Lukac]

Hey Michael, thank you for the extensive feedback. I am definitely going to check the link citating Alan Kay and get back to you.

I agree I mainly compare to Java/PHP and C++ because that's the languages majority of developers are coming from when starting with Go and they bring with them the techniques that worked in such a languages.

For now, my main argument is, I left out a lot of things like inheritance, polymorphism etc because they are extensions of Objects but the main purpose of an Object is to represent state. Objects expose their API for communication but they mainly maintain the state.

Go seems to work better stateless imo. and the language is optimised for communication, impulses, clear input/output and such design differs greatly comparing to the way we are used to design, encapsulate Objects.

I don't see how Objects behaviour and assosicated techniques would be beneficial in Go world. I am not saying it can't be done, it can, but it doesn't fit.

I will update the article in the afternoon with your feedback (let me know if you would like to add something more) as well will point out clearly why I compare mainly to Java/C++.

UPDATE:

Actually from the source you provided, Dr. Alan Kay stated:

"OOP to me means only messaging, local retention and protection and

hiding of state-process, and extreme late-binding of all things."

• communication is obvious
• protection and hiding of state-process (encapsulation), and this was my main point. That's what Objects were mainly designed to do, which Structs were not. Therefore I don't consider Go as primarily OO language

[rhymes]

I feel like OOP is more of a pattern/paradigm than a constraint. Some languages have constrained themselves to that single pattern but many (probably Go falls in this category) can be used as OOP, even if they are not constrained to it by design.

An example: the basics of OOP in Python and Ruby are implemented in the C layer. Is C a OOP language? Not really, but you can still use it that way.

[Lukas Lukac]

Sure, fair point and it surely is not black/white binary answer. That's why the official Go doc states: "kind of". The question is, should you? ;) The only way to use Go as OO language is by abusing pointers for everything and that doesn't make too much sense to me.

[rhymes]

ahhaha "should you" is another relative question :D

[Lukas Lukac]

unfortunately :D damn IT.

[Lukas Lukac]

Would you add something more to the article? Actually it really enhances my historical knowledge of OOP evolution. I was always a huge fun of DDD. Although, what I also found are some good points why OOP sucks:

"I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all. "

[Adrian B.G.]

No

Ah wait it was retorical question.

But .. as u said you can achieve some OOP practices and patterns, up to a point.

Ps: here is a talk called "SOLID in Go" to grasp the extent of the OOP concepts in Go.

[Lukas Lukac]

Hey Adrian, thx for recommendation. I saw the talk few months ago actually, Is a nice talk. Even though SOLID is mainly OO concept I think it should be and can be generally applied to Structs as well as Functions. I prefer to apply it mainly on a Function level in Go.

[Lukas Lukac]

Hey Michael, I am not comparing primitive types and objects. I am saying object was designed to have a state and keep it. Struct is not. That's a huge difference. Go is suppose to be mainly stateless and work based on impulses, communication. input/output. Thx for reading!

[Lukas Lukac]

Michael, I updated the Medium article and thanked you for providing the resource. I added also a link to your Twitter for more followers :)

[Lukas Lukac]

@michael , actually, I am still updating the article, want to update it with more information, especially about the idea of "objects" outside of Java world or outside of a Go package. That can be explored way more and is important indeed.

[Lukas Lukac]

Michael, you can check the article now. Let me know what you think. I extended on the history of OOP and connected more dots ;)

[jeann]

Very Interesting your post, I don't know this Golang, Thank you so much!