Edit: This blew up way too huge, I guess there is something about this topic that touches a nerve. A couple of clarifications on my part.

1. My colleagues are damn good developers and the code they write is correct, well tested and performant.
2. I’m not rushing in there and telling people their code is bad. It’s not. It’s just in a very “everything is an object” style, and I really like the canonical Go way of doing things.
3. Im not advocating a rewrite of a huge mature codebase. But I also don’t want to particularly write code in this Java way myself going forward just to fit in.
4. The Java developers “polluting” the Go code was supposed to be a little tongue in cheek but I forgot, Reddit.

Original Post:

I've recently started a job at a new company and my initial thoughts of their code base are pretty depressing.

I'm seeing so many Java, GoF, Uncle Bob, Object Oriented patterns in the code base, many of which I find to be complete anti-patterns in Go. I'm having a really hard time convincing my colleagues that the idiomatic Go way of doing things is better for long term code maintenance than the way the code has currently been organised. I want to hear if anyone here is opinionated enough to present me with some compelling arguments for or against the following "crimes".

• All context.Context are currently being stored as fields in structs.
• All sync.WaitGroups are being stored as fields in structs.
• All channels are being stored as fields in structs.
• All constructor functions return exported interfaces which actually return unexported concrete types. I'm told this is done for encapsulation purposes, otherwise users will not be forced to use the constructor functions. So there is only ever one implementation of an interface, it is implemented by the lower case struct named the same as the exported interface. I really don't like this pattern.
• There are almost no functions in the code. Everything is a method, even if it is on a named empty struct.
• Interfaces, such as repository generally have tons of methods, and components that use the repositories have the same methods, to allow handlers and controllers to mock the components (WHY NOT JUST MOCK THE REPOSITORIES!).
• etc, etc.

I guess as an older Go developer, I'm trying to gatekeep the Go way of doing things, for better or worse. But I think I need a sympathetic ear.

Has anyone else experienced similar Object Oriented takeover of their Go code?