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")).
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.
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.
Go's minimalist object-oriented approach (interfaces, embedding types within types, and associating functions with named types) is small, simple, and effective
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.
Go isn't my favourite language, but I disagree with that: a language being being simple does wonders to reduce the possibilities of accidental complexity added by complicated features that are unnecessary for the business.
But of course it's still possible to make a mess: I've seen someone who created an ad-hoc object model (with its own structs, plus multiple inheritance and all) on top of Golang and wrote a few apps in that style. But not having the features in the first place can help.
IMO with Go. Yes, it eschews object-oriented programming. Yet, funnily enough, whenever I use Go, I am noticing that I can work fine with it when thinking about it in an object-oriented way. Structs + methods were all the features I used in object-oriented programming anyway.
People think Go is just like another language. I did when starting Go. And wanted to change many things in Go. After some months I do think Go is fine.
One thing I didn't use was embedded structs, I've used Interface more like in Java and Typescript. Now I use more embedded structs for what I would have used interfaces for and use interfaces more for embedding behaviour inside structs.
Go is weird to me... tries to be low level, but has a GC. I can see it being a good option for someone coming from Java wanting to target more native code, but I'm not personally impressed. Plus `interface {}` ;)
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.
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.
Don't beat yourself up for that. I tried Go sometime back (year or so may be) and found it an awkward language. It probably has its own design philisophy may be that I missed.
Things like lack of generics and type system makes you repeat things quite a lot (e. g. It was pretty impossible to write a true ORM or a DI system in go). I found the interface system quite awkward in that types implicitly implement an interface if they have the same method signature was weird to me. I think method overloading wasn't supported either, if I remember correctly.
I think people who loved Go initially probably came from C. It feels a lot like C with better standard library, memory safety and fast compile times. I like Go for the same reasons actually. But until there's at least some way to write generic code, it's an awkward language to anyone coming from more expressive languages. I program in C# mostly which is an extremely expressive language with classes, interfaces, generics, expression trees, linq, delegates (akin to function pointers). Go is far behind other languages for application development, my two cents. But for systems programmers used to C which is a very small language, Go must be like a transition to paradise :)
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.
There's a difference between using a struct to represent concepts like program configuration or grouped function parameters, and shoehorning OO-native design concepts like the decorator pattern that need inheritance into a language that doesn't support dynamic dispatch. Much of the bad Go code I see comes, yes, from overusing abstractions and lots of copy-pasting, but most of that comes from trying to fit square pegs like OO design into Go's round hole.
reply