4 ms·
> I hate working on unfamiliar Go projects. Copy pasted code everywhere. And everyone builds their own abstractions because there aren't enough. Arguably, if t
by solatic 6y ago
> I hate working on unfamiliar Go projects. Copy pasted code everywhere. And everyone builds their own abstractions because there aren't enough.
Arguably, if the project requires lots of abstractions and copy-pasted code, then the project shouldn't be written in Go. Just because you can, technically speaking, write object-oriented code in Go does not mean that it is ergonomic to do so or a recommended use-case for the language. Projects that benefit from object-oriented design should stick to languages with first-class support for it.
- cy_hauser 6y agoI don't disagree with your conclusion but I don't see it following from the quoted premise. What was your thought chain to get from the quoted text to OO stuff?
- solatic 6y agoThere'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.
- cy_hauser 6y agoStill don't get the connection in the way you do. Maybe I'm so used to OO stuff that I just gloss over it. > a language that doesn't support dynamic dispatch. Go's interfaces do support this enough that I consider it worth at least mentioning. https://en.wikipedia.org/wiki/Dynamic_dispatch#Go_and_Rust_implementation https://en.wikipedia.org/wiki/Dynamic_dispatch#Go_and_Rust_i...