Is Go an Object Oriented language?

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.

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.

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

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.

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)
}

Very good article. I like Golang. The more I work with Golang I feel like is too opinionated but that is the beauty of the language I guess.

Nice article!
Q: How would you do dependency injection without structs?

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

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

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

Just know Go language is Object-base ...