Go is very opinionated and if you try to shoehorn it into some existing paradigm, you will probably not enjoy the experience. If you follow the happy-path, you'll have a much better time and for me at least, I decided that the things I liked about OOP were actually more elegantly addressed with Go. Notably decomposing inheritance into polymorphism (interfaces and callbacks), composition, and automatic delegation ("struct embedding")).

You don't. Elaborate abstraction is often a mistake.

Which aspects do you like? Personally I have grown to dislike the pointless abstraction and obfuscation introduced by huge inheritance hierarchies, so Go is a breath if fresh air in that regard in just doing away with it all. I haven't missed classes at all.

Go's structs with associated methods and property/method promotion aren't that different from classic OOP. Too much is made of the differences, I think. You can recreate most basic OOP code in Go .... if you really must.

I do think it’s very different; types are not classes and interfaces are not like interfaces in java, obj-c for example, being defined at point of use.

If you try to recreate inheritance in Go it will be frustrating and not very useful.

The shape of the code ends up very different and embedding is not used even half as much as inheritance (which is the default position in most other oop languages). That has profound impacts.

It is basically Component Based Programming, started with Objective-C protocols, Smalltalk categories, Java/.NET interfaces, COM ABI.

inheritance is just like in COM via delegation and struct embedding.

Go supports a slimmed-down version of OOP compared with Java/C# via property and method "promotion". There are no static properties/methods and no abstract classes but you have interfaces with Ruby-esque duck typing. I've omitted generics as that's due in Go 2.0. I find listing methods beneath their corresponding struct definition to be quite adequate when OOP is the best fit .... which isn't that often. I just finished implementing most of the functionality in Matt Zandstra's "PHP Objects, Patterns, Practice", 5th edition, in Go and didn't miss much.

Don't. OOP was/is a mistake.

Golang is OOP, regardless of what some people may claim. It's just missing inheritance, which golang's implementation of composition mimics it close enough.

Composition is not a substitute for inheritance and is used an order of magnitude less in Go code than inheritance in other languages, which touches everything.

It is close enough when coupled with delegation.

That is how component based programming works.

The important point is it is used far less - inheritance is impossible to get away from in most OOP programs, but you can't say the same for embedding in Go programs, it is used, but not as often.

It is only impossible because you cannot throw away standard libraries.

COM/UWP have proven you don't need to have it available.

They get lots of hate due to their underlying complexity, however they are the main Windows APIs since Vista, as COM took over the Longhorn vision.

Go can do encapsulation and polymorphism. Go doesn't do inheritance, of course. Channels can also help simulate message passing and actor-style code. What's missing?

IMO, If you compare Go to an OOP language that runs in a VM there are some things that will fall short but the industry has worked around it. It's not cool to have a beefy Smalltalk or Java VM, with the dynamic runtimes that let you auto-export objects as remote endpoints... you have small binaries exporting HTTP or RPC services running in containers and interfacing with service discovery and fabric systems. The "object orientation" is now at an abstraction sitting above the running binary.

>It's not cool to have a beefy Smalltalk or Java VM, with the dynamic runtimes that let you auto-export objects as remote endpoints... you have small binaries exporting HTTP or RPC services running in containers and interfacing with service discovery and fabric systems. The "object orientation" is now at an abstraction sitting above the running binary.

I'm not sure why an application running in the JVM in a container is any different. Can you elaborate?

Running a JVM application in a container is not all that different to running a Go application in a container. But the design of the JVM runtime and its tooling is vastly different than Go. The JVM is more complex but it can do more things. Go is simpler and can get you to a working product quicker.

If someone asks me to build something and they tell me it will run in docker/kubernetes, have the standard containerized CI pipelines, and communicate with other services over some standard protocol like HTTP; doing it on the JVM is doable and probably easier than ever but I would just think about all the cool JVM features I wouldn't get to use (hot code deploy, runtime modularity tools, all the neat bytecode hacks, even spring which everyone but me seems to hate).

If I don't get to use those features then I would rather grab a language like Go, since it doesn't front load so many runtime complexities. (and if this was 10-15 years ago maybe I'd say "Go doesn't front load so many complexities AND performance penalties")