GO is simple decomposition of OOP, class was split into structure (with composition) and interface(with multiple inheritance without implicit definition what interfaces can can coop with structure). Go only restricted that you cannot define virtual methods.
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")).
Go's minimalist object-oriented approach (interfaces, embedding types within types, and associating functions with named types) is small, simple, and effective
Go has made many decisions that i'm not happy about.
If they did one thing exactly right on the language level, it's the [lack of] OOP: interfaces in their implementations, and no inheritance, overridden methods, covariance / contravariance games, etc.
You can of course write in Java in that style: only extend interfaces, never inherit classes. But many libraries, including the standard library, actively refuse to cooperate.
Thanks for the comments. I take your point about OO, but I was aiming at producing a broad overview of Go which necessarily means simplifying in some parts. To 90% of developers today brought up on strongly typed languages such as Java and C#, OO means single inheritance type hierarchies.
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.
Go OO is like Java only they took stuff away. They took away class extension and they took away the requirement that you declare interface implentations. So if you have all of the functions required for an interface then you implement the interface, no need to be more complicated.
So it's hard to see why people from an OO background (assuming an OO background like Java or c++) would have a problem with it. It's like that only simpler.
FWIW, I think that removing inheritance is a major strength of Go. Interfaces and composition give you most or all of what you want and get you in a lot less trouble.
Java-style OO is a model where one can and should take the good, dispose of the bad, and improve on what falls in between. Go types and interfaces do a good job of this IMO--like Java classes, Go types can include a defined data structure and methods, but unlike Java classes, there's no inheritance. Like Java interfaces, Go interfaces let you type-check against multiple types that have the same outwards-facing behavior, but unlike Java interfaces, you don't have to actually declare that a type fulfills an interface as you define it. These are all pretty obvious improvements IMO.
From the FAQ: " Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, not just structs."
http://golang.org/doc/go_faq.html#Is_Go_an_object-oriented_l...
The lack of type hierarchy makes code easier to understand.
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.
I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance.
The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent without all the complications on C++ and that most OO oriented languages forbid because of that complication.
Go is a very original language in this aspect as well as with concurrency. Understanding and mastering these properties goes beyond simple syntax analysis.
To me the most remarkable property of Go is its simplicity. As I explained to a friend who is a strong advocate of D, the difference with other programming language is the same as dealing with a spoken language of 1000 words instead of 10,000 words. It's true that the language with 10,000 words is more expressive and richer. But the effort required to learn, read and write a language of 1000 words is much lower than a with a language of 10000 words. I'm beyond 50 years old, and too me this makes a huge difference. The best way to express it is that with Go programming is fun again. I hope that Go will preserve this simplicity. At the beginning Java was simple too. They later killed it to the point I don't want to deal with Java code anymore.
reply