5 ms·

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

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.

fhd2 3y ago
I believe it's called multi paradigm languages - most I've used are like that (C++, Kotlin, JavaScript, Python, ...). The only dogmatic OOP languages I can think of are Java (where it is IMHO nastily done), Ruby and Smalltalk (in both of which I never felt the burden of OOP boilerplate). I think it's a Java problem, not an OOP problem.
- kaba0 3y ago
  A static method is basically a “standalone” function with a namespace only. You can static import it and do whatever you want. Java is a multi-paradigm language, and is absolutely on a different level of expressivity compared to Go. EDIT: Java is really not what people remember from 20 years ago. You can write as functional code as you wish stopping just before Monads. It’s type system is also a different league than Go’s. So it has OOP, imperative and FP.
- pjmlp 3y ago
  Since most early Java adopters were Smalltalk shops, I fail to see the difference. I used Smalltalk/V before Java came to be, by the way.
- lastangryman 3y ago
  Yes, good point. I worked in a lot in PHP though and interesting that a lot of the changes it has went through the last 15 years seem to have been "inspired" by Java. A lot of frameworks (Laravel, Symfony, Zend) seem to lean heavily on OOP style, and it's easy (or it was for me anyway) to fall in to the trap of everything must be a class and if not you are doing it wrong, even if the language does not require OOP. Design Patterns, Refactoring, Clean Code, it feels like a lot of my "industry journey" if you like was built on an assumption that everything started with OOP. Go, for me, was the first language I've used in a while that truly detached itself from all that dogma, not just in it's features but it's overall principles and ethos.
- dagw 3y ago
  Java's "problem" is more cultural and historical than technical. Modern Java has lots of support for functional and multi-paradigm programming. However most non-trivial Java codebases are quite old and don't take advantage of these newer features, plus most Java programmers were trained in the traditional Super-OOP style of Java programming and still program and advocate for that style of programming.
ThePhysicist 3y ago
I don't think you can call a language object-oriented if it doesn't support some form of inheritance and dynamic dispatch. And for Golang that's simply not the case. You can embed data structures into other structures but the main difference to e.g. C++ is that you don't have proper RTTI (run-time type information) that would do a dynamic dispatch of struct methods, so you can't do anything interesting (i.e. you can embed an "Animal" struct in a "Dog" struct but if you define the ".MakeNoise()" method on the Animal struct and have that call a ".myNoise()" method on the struct to e.g. produce "Woof" or "Meow" then even if you override ".myNoise()" in the "Dog" struct the "Animal" struct will still call its own ".myNoise()" method, as there's no dynamic call table like in C++). People will probably say that's by design but I'd then argue again that's not object-orientation as you can do these things with C structs as well and no one would call C an object-oriented language.
- orwin 3y ago
  I think traits are a big improvement on inheritance, do you count those as as some form of inheritance? In this case I can agree with you. Personally, when I have to use it, I make abstract classes or better, interfaces. I avoid direct inheritance like the plague. But I've worked on personalized Jenkins where I had to inherit classes from weird modules, so maybe I got burned and my experience isn't the average experience (also, I hate Java now).
  - ThePhysicist 3y ago
    In my understanding traits (I guess you mean as defined in Rust?) are more powerful than interfaces in the sense that you can define them for objects from the outside, but I don't see how you could use them to build dynamic-dispatch like functionality? Not an expert on traits at all though. I think traits and interfaces are more supportive of a composition-like programming style, one might call that object-oriented but I still think it misses several key concepts of classical object-oriented languages.
- bheadmaster 3y ago
  In Go, interfaces are used for dynamic dispatch. No need to the the whole ".MakeNoise() calls .myNoise()" dance, just implement ".MakeNoise()" on each type directly: type Animal interface { MakeNoise() } type Dog struct{} func (Dog) MakeNoise() { fmt.Println("Woof!") } type Cat struct{} func (Cat) MakeNoise() { fmt.Println("Meow.") } func MakeNoises(as ...Animal) { for _, a := range as { a.MakeNoise() } } func main() { d := Dog{} c := Cat{} MakeNoises(d, c) }
friendzis 3y ago
> If you want a package scoped standalone function, you don't need to invent some made up "class" to attach it to. It's a matter of language construct organization. There are bare behaviors - functions, there is bare state - PODs, and then there are collections of state and behavior - classes. You can have these three distinct constructs, or you can have all them be subcases of class (or some other mix). It's just that we are used to having distinct primitive and collection data types, but nothing (sans terseness) stops language from having all data be some form of collection, even if it is a single-member collection.
kaba0 3y ago
It can as much as every Turing-complete language can support any programming model given enough abstraction.
- fanf2 3y ago
  Worth reading Felleisen’s paper “on the expressive power of programming languages” (or watch this talk https://youtu.be/43XaZEn2aLc https://youtu.be/43XaZEn2aLc) which argues that if a language A has a feature that would require global refactoring to implement in language B, then A is more expressive than B.
  - kaba0 3y ago
    Sure, I was just being sarcastic on parent’s claim not meaning too much ad absurdum. Nonetheless, thanks for the paper/video, will look into them!
deleted 3y ago
[deleted]
lelanthran 3y ago
> Coming to Go from more dogmatic OOP languages is such a breath of fresh air. There are only a few (two?) dogmatic OOP languages in common use. Every other language that supports OOP has better OO support than Go, as well as: > 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. While I like Go, a lot of Go code could be simplified by having keyword-supported OO (a 'class' keyword, maybe). It's better to have inheritance and not need it, than need inheritance and not have it because it is applicable in a lot more places than "composition over inheritance" fanboys would have you believe.
za3faran 3y ago
With records now available in Java and C#, not only can you do the same there, but you get even more assurances such as overloaded `.equals()` and `.hashCode()`.

fhd2 3y ago

I believe it's called multi paradigm languages - most I've used are like that (C++, Kotlin, JavaScript, Python, ...). The only dogmatic OOP languages I can think of are Java (where it is IMHO nastily done), Ruby and Smalltalk (in both of which I never felt the burden of OOP boilerplate). I think it's a Java problem, not an OOP problem.

kaba0 3y ago
A static method is basically a “standalone” function with a namespace only. You can static import it and do whatever you want. Java is a multi-paradigm language, and is absolutely on a different level of expressivity compared to Go. EDIT: Java is really not what people remember from 20 years ago. You can write as functional code as you wish stopping just before Monads. It’s type system is also a different league than Go’s. So it has OOP, imperative and FP.
pjmlp 3y ago
Since most early Java adopters were Smalltalk shops, I fail to see the difference. I used Smalltalk/V before Java came to be, by the way.
lastangryman 3y ago
Yes, good point. I worked in a lot in PHP though and interesting that a lot of the changes it has went through the last 15 years seem to have been "inspired" by Java. A lot of frameworks (Laravel, Symfony, Zend) seem to lean heavily on OOP style, and it's easy (or it was for me anyway) to fall in to the trap of everything must be a class and if not you are doing it wrong, even if the language does not require OOP. Design Patterns, Refactoring, Clean Code, it feels like a lot of my "industry journey" if you like was built on an assumption that everything started with OOP. Go, for me, was the first language I've used in a while that truly detached itself from all that dogma, not just in it's features but it's overall principles and ethos.
dagw 3y ago
Java's "problem" is more cultural and historical than technical. Modern Java has lots of support for functional and multi-paradigm programming. However most non-trivial Java codebases are quite old and don't take advantage of these newer features, plus most Java programmers were trained in the traditional Super-OOP style of Java programming and still program and advocate for that style of programming.

ThePhysicist 3y ago

I don't think you can call a language object-oriented if it doesn't support some form of inheritance and dynamic dispatch. And for Golang that's simply not the case. You can embed data structures into other structures but the main difference to e.g. C++ is that you don't have proper RTTI (run-time type information) that would do a dynamic dispatch of struct methods, so you can't do anything interesting (i.e. you can embed an "Animal" struct in a "Dog" struct but if you define the ".MakeNoise()" method on the Animal struct and have that call a ".myNoise()" method on the struct to e.g. produce "Woof" or "Meow" then even if you override ".myNoise()" in the "Dog" struct the "Animal" struct will still call its own ".myNoise()" method, as there's no dynamic call table like in C++). People will probably say that's by design but I'd then argue again that's not object-orientation as you can do these things with C structs as well and no one would call C an object-oriented language.

orwin 3y ago
I think traits are a big improvement on inheritance, do you count those as as some form of inheritance? In this case I can agree with you. Personally, when I have to use it, I make abstract classes or better, interfaces. I avoid direct inheritance like the plague. But I've worked on personalized Jenkins where I had to inherit classes from weird modules, so maybe I got burned and my experience isn't the average experience (also, I hate Java now).
- ThePhysicist 3y ago
  In my understanding traits (I guess you mean as defined in Rust?) are more powerful than interfaces in the sense that you can define them for objects from the outside, but I don't see how you could use them to build dynamic-dispatch like functionality? Not an expert on traits at all though. I think traits and interfaces are more supportive of a composition-like programming style, one might call that object-oriented but I still think it misses several key concepts of classical object-oriented languages.
bheadmaster 3y ago
In Go, interfaces are used for dynamic dispatch. No need to the the whole ".MakeNoise() calls .myNoise()" dance, just implement ".MakeNoise()" on each type directly: type Animal interface { MakeNoise() } type Dog struct{} func (Dog) MakeNoise() { fmt.Println("Woof!") } type Cat struct{} func (Cat) MakeNoise() { fmt.Println("Meow.") } func MakeNoises(as ...Animal) { for _, a := range as { a.MakeNoise() } } func main() { d := Dog{} c := Cat{} MakeNoises(d, c) }

friendzis 3y ago

> If you want a package scoped standalone function, you don't need to invent some made up "class" to attach it to. It's a matter of language construct organization. There are bare behaviors - functions, there is bare state - PODs, and then there are collections of state and behavior - classes. You can have these three distinct constructs, or you can have all them be subcases of class (or some other mix). It's just that we are used to having distinct primitive and collection data types, but nothing (sans terseness) stops language from having all data be some form of collection, even if it is a single-member collection.

kaba0 3y ago

It can as much as every Turing-complete language can support any programming model given enough abstraction.

fanf2 3y ago
Worth reading Felleisen’s paper “on the expressive power of programming languages” (or watch this talk https://youtu.be/43XaZEn2aLc https://youtu.be/43XaZEn2aLc) which argues that if a language A has a feature that would require global refactoring to implement in language B, then A is more expressive than B.
- kaba0 3y ago
  Sure, I was just being sarcastic on parent’s claim not meaning too much ad absurdum. Nonetheless, thanks for the paper/video, will look into them!

deleted 3y ago

[deleted]

lelanthran 3y ago

> Coming to Go from more dogmatic OOP languages is such a breath of fresh air. There are only a few (two?) dogmatic OOP languages in common use. Every other language that supports OOP has better OO support than Go, as well as: > 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. While I like Go, a lot of Go code could be simplified by having keyword-supported OO (a 'class' keyword, maybe). It's better to have inheritance and not need it, than need inheritance and not have it because it is applicable in a lot more places than "composition over inheritance" fanboys would have you believe.

za3faran 3y ago

With records now available in Java and C#, not only can you do the same there, but you get even more assurances such as overloaded `.equals()` and `.hashCode()`.