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.
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.
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.
Go's minimalist object-oriented approach (interfaces, embedding types within types, and associating functions with named types) is small, simple, and effective
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.
From a high level programming in Go looks to me
to be very like programming with Microsoft's
COM. It's interface oriented, no inheritance. You could say that
this is the purest form of OO if you take Alan
Kay's viewpoint that the emphasis should be on
the messages and not the object. In COM you
have QueryInterface and in Go you have interface
matching and casting. QueryInterface or an
interface cast is like a hinge between dynamic
and static typing. You get great flexibility but still
preserve your abstractions in that you never
depend on an implementation.
Of course you can
do this in, say, java by using instanceof to match
against an interface but the difference with COM
and Go is that it is a primary mechanism and so
the code written in the language tends to use this
pattern a lot. i.e. It's encouraged.
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")).
I really like go. It's very succinct, clean and orthogonal, yet is enormously powerful. The amazing compilation speed and concurrency primitives are the icing on the cake.
I especially like the lack of a type hierarchy. I have come to think that type hierarchical structures are somewhat brittle - you create these initially correct representations, however when something changes or isn't quite right suddenly you either have to rewrite your hierarchy which is potentially a lot of work, or hack it up whereby it ends up not only incorrect but also misleading.
In go, you get implicit, dynamic interfaces whereby you define an interface and get duck typing against it without having to explicitly indicate that types implement it. The capabilities of a type determine its abstraction, nothing more.
I really like go. It's very succinct, clean and orthogonal, yet is enormously powerful. The amazing compilation speed and concurrency primitives are the icing on the cake.
I especially like the lack of a type hierarchy. I have come to think that type hierarchical structures are somewhat brittle - you create these initially correct representations, however when something changes or isn't quite right suddenly you either have to rewrite your hierarchy which is potentially a lot of work, or hack it up whereby it ends up not only incorrect but also misleading.
In go, you get implicit, dynamic interfaces whereby you define an interface and get duck typing against it without having to explicitly indicate that types implement it. The capabilities of a type determine its abstraction, nothing more.
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.
Bold, delicious digression from oop - there literally is no relation between objects by identity, only by behaviour via interfaces - not your usual crappy java/c#/etc. interfaces, but rather 'true' interfaces, which are implicitly implemented by dint of a type fulfilling them. This is surprisingly powerful and the simplicity of it helps move you away from thinking about complexities you get with oop that have nothing to do with the problem at hand.
Extremely fast compiles - you miss this when you go back to languages that compile more slowly. It allows for rapid prototyping and trying stuff out without having to worry about a massive build time. Check out this vid - [1].
Great concurrency support - concurrency is primitive in go via go-routines.
Sensible, simple, clean syntax.
The list goes on... yeah I need to do a blog post here :)
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.
In my opinion, if Go does one thing exactly right, it's the "OOP". That is, interfaces and explicit receiver arguments in functions. Interfaces are extendable, classes are not, because there are no classes per se, let alone abstract classes.
Maybe conforming to an interface without explicitly declaring it (like you declare an instance of a typeclass in Haskell) may look like a controversial decision. I still think it does more good by removing boilerplate than bad by accepting an object as conforming to an interface in a rare case when you did not mean it.
There are certainly ways to write confusing code in Go too, no inheritance is just one cause of confusion subtracted.
IMO interfaces are best used sparingly (but I prefer them to Java and do like them, never found them confusing), callbacks are best avoided if possible, and yes dependency management has only recently improved.
> Is Go an object-oriented language? Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy.
Classless prototype languages like JavaScript and Self also lack explicit type hierarchies, and they are still considered object-oriented.
> The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general.
There was a OO ML language called Moby [1] that had something similar. Just because the objects were structural didn't mean they weren't objects, though encapsulated communication (calling another object's private methods in the proper scope) is definitely more complicated.
> 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, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).
You mean like extension methods in C#?
> Also, the lack of type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.
They are basically claiming that Go is not C++ or Java, not that Go is not object-oriented, of which the design space is much broader.
In my opinion, there is nothing interesting in Go, and it doesn't seem like a language I would want to use.
Could you elaborate more about type systems? I don't have a definite opinion about Go's type systems so far, and it surely has it quirks, but TBH, I like the concepts. In particular, the complete separation of data types (structs) and behaviour types (interfaces) is something that I've never actually seen before.
reply