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.


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.


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.

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.

Oh, boy! Grammar policing on a dev forum. I likes it! 😘


Do not communicate by sharing memory; instead, share memory by communicating
The number 1 feature of GoLang is the exact opposite definition of what OOP stands for.

That's a very narrow definition of what OOP stands for. In fact, the way Alan Kay imagined OOP was much more in line with what Go does vs for example Java:

  • I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful).

  • I wanted to get rid of data. The B5000 almost did this via its almost unbelievable HW architecture. I realized that the cell/whole-computer metaphor would get rid of data, and that "<-" would be just another message token (it took me quite a while to think this out because I really thought of all these symbols as names for functions and procedures.

  • My math background made me realize that each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful. The term "polymorphism" was imposed much later (I think by Peter Wegner) and it isn't quite valid, since it really comes from the nomenclature of functions, and I wanted quite a bit more than functions. I made up a term "genericity" for dealing with generic behaviors in a quasi-algebraic form.

  • I didn't like the way Simula I or Simula 67 did inheritance (though I thought Nygaard and Dahl were just tremendous thinkers and designers). So I decided to leave out inheritance as a built-in feature until I understood it better.

Overall I'd say you focus on Java and C++, leaving out many things about OOP like prototypical (Self, NewSpeak, JS) vs class-based inheritance (most others), structural typing (Go's interfaces are an example for that and e.g. OCaml, Scala, and Elm offer similar mechanisms), runtime polymorphism (multi methods in CLOS or Clojure etc), not making a distinction between "primitive" and boxed types etc. So the real question you're answering is more like "Is Go an object-oriented language in the Java/C++ style?", which may not be the best question to ask:

I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind

-- Alan Kay, OOPSLA '97


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++.


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

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.

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.


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 , 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.


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


Great work on updating the original piece! I hope this deep dive gave you an appreciation for OOP in it's original and wider sense :)

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. "


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 (

type Integer int

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

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


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.


What's a "normal OO language"? A distinction between primitive types and objects is certainly not one of the defining criteria and Ruby for example happily let's you add methods to integers (both as a global monkey patch or locally via a refinement, which is probably closer to what Go achieves through type aliasing).

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!


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.


What go retains is polymorphism and its own flavor of duck typing.

That "own flavor of duck typing" is called structural typing. While they achieve similar things, there are some differences.


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.


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.

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! :)



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.


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.


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


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.


yea... haha. But only at the beginning I would say. Once you crack the ideas behind is all straight forward, fast development :)


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


Thx Dan. Like you would normally do, pass it to a function!

Classic DEV Post from Oct 7 '18

What's the difference between a library and a framework?

Having a look at this comment by @kayis from another thread, I'm wondering if ...

Lukas Lukac
I help developers to master blockchain via UML Diagrams, GoLang and Web3.js via my BlocksByLukas Twitter-chain