Are design patterns relevant with Golang?

[itistricky]

I'm really confused on this. My understanding on Golang's intentions and design is that it is an intentionally simple language lacking most of traditional OO features. The language is relying on interfaces (and Generics?) for doing most of the things you'd do with classic OO.

Yet I see job ads requiring and even classes teaching Design Pattterns with Golang. And by inquiry I see that they're not talking about Golang-specific DPs (that would make sense) but about fitting traditional OO DPs (and principles like SOLID) to Golang. Which in turn seems to me like bending the language to something it was not designed for in order to fit into models we developed for traditional OO languages like java and C++.

Unsure what is going on here and what the consensus on best practice is (if any).

[jstx1]

In the very general sense of design patterns - sure, you always need to design your code regardless of the language. Sometimes that's called design principles (https://stackoverflow.com/questions/31317141/whats-the-diffe...).

If you're focusing too much on specific patterns, you might be wasting your time. For example, the O in SOLID is really only relevant for inheritance which Go doesn't have. And even when a concept is relevant to Go, it's questionable how much benefit there is to think about it explicitly. Unless you want to write books and blogposts of course.

[holografix]

Sure are. I suggest you read the freely available (and most excellent) “Game Programming Patterns” by Rob Nystrom.

[hamdouni]

This reminds me of Dave Cheney speech "Solid Go Design"

https://youtube.com/watch?v=zzAdEt3xZ1M

[mytailorisrich]

OOP is a design pattern itself and is not bound to a specific language. Language that have OO features make things much easier but you can do OO in any language you want. Over the years OOP has become the standard and best practice, and is used everywhere. For instance my day job is pure C and do OO design.

In Go, interfaces are an OO feature that allows polymorphism.

Design patterns in general are classic ways to solve common design problems and they can also be applied in many languages.

[sethammons]

checkout youtube for concurrency design patterns. There is a video by Rob Pike and another for advanced patterns by Sameer $LAST_NAME.

[asguy]

> if (err != nil) { return err; }

Yup; definitely a pattern.

[anaganisk]

Is it really much different in practice? Like when lets say using try catch? This may enforce error handling, which in some languages cause panics and shuts down the program entirely. May be its unconventional, but what’s the point of another clone language. Each language has its use case and foot guns.