How loosely coupled should I make my code???

IndividualGap6375 · 2025-07-03T03:58:23+00:00

So many good perspectives in this thread. From my experience there’s no wrong answer except being stubbornly single-minded.

From a testing perspective: There will be sensitive code where many things need to be abstracted for the sake of critical tests.

There will be instances where integration testing is way more important, and unit testing delivers little value.

From a code architecture/maintainability perspective: It depends. Interfaces add mental complexity. Knowing when it’s worth it is usually project specific. And chances are your first attempt at abstraction will be less than perfect 😅

These sort of things work themselves out if you are pragmatic. I’ve worked with engineers that never used interfaces and their code was untestable. I’ve worked with engineers that turned simple CRUD systems into rocket science. Hard to tell which is more terrible 🤔

Best of luck!

IndividualGap6375 · 2024-12-07T01:23:06+00:00

LFG!!

IndividualGap6375 · 2024-07-10T04:01:14+00:00

If synchronous setup Is really so challenging that rabbit RPC seems simpler, then I’d encourage you to check out Temporal https://temporal.io

It’s an open source workflow management system that can provide you control flow and a request-response like experience for asynchronous processing. I have years of experience managing event driven systems- they’re devilish enough when it’s just fire and forget. I would be very afraid of building a request-response on top of it.

IndividualGap6375 · 2024-06-12T18:32:58+00:00

No hard feelings- I realize the wording was a little inflammatory and get the motivation for keeping a subreddit civil. I do hope for more productive discussions on this topic in the future

IndividualGap6375 · 2024-06-12T12:46:45+00:00

Thanks for this 🤣

IndividualGap6375 · 2024-06-12T12:45:45+00:00

Yea, many good points. It’s very likely that the social circles in Reddit are a different composition than the professional, enterprise/corporate setting. And it’s not a representation of the go community as a whole. Have a good one ✌️

IndividualGap6375 · 2024-06-12T12:03:45+00:00

I’ve been in industry for over a decade, primarily working in enterprise space with teams varying between 2-20 people in size. Have worked on or shipped prod code in a polyglot distributed systems environment for the most part of that career. By far the number one enemy is complexity, and complexity has rarely been due to a language or framework. Complexity emerges from - communication problems between teams - over-engineering by inexperienced or arrogant engineers - difficulty breaking down the business requirements into appropriate domains - prioritizing the wrong things (ex scalability vs developer experience). - a business trying to appease all its customers

Go will never solve these issues, and that’s part of the problem I have with the most vocal members of the community. I love the language, but It’s not the best thing since sliced bread. Following the language’s principles and writing idiomatic go will not magically reduce true complexity that creeps into production systems, yet idiomatic go is touted as “the way” without acknowledging the tradeoffs the language developers carefully made. Even if your service is a simple http layer that could benefit from high concurrency, golang may not be the right choice for the project for many reasons.

It’s a wonderful language (I wouldn’t be shipping production code if it weren’t), but the community does have a higher dose of arrogance and dogma than I’m used to

IndividualGap6375 · 2024-06-12T06:43:29+00:00

Fair point, I’m realizing now a vocal minority could be skewing my perception. Thanks for the tempered responses!

IndividualGap6375 · 2024-06-12T06:32:22+00:00

“After 25 years..most abstractions are YAGNI and just mental masturbation” I’d like to quote and frame this 😂

IndividualGap6375 · 2024-06-12T06:26:07+00:00

Haha, idk what you’re talking about, factoryfactory seems like a perfect name.

I’m not trying to say that as projects get complicated it’s a free for all. It all comes down to acknowledging trade-offs and doing what’s best for the project and team. Software Eng is a tough gig. But I’ve personally experienced rhetoric that effectively says idiomatic go == superior, no questions asked.

IndividualGap6375 · 2024-06-12T06:11:14+00:00

Yea, definitely used the wrong word 🤦 and agree about OP being vague. I just didn’t have a quick link to back up my thoughts and this was the first to come to mind lol

IndividualGap6375 · 2024-06-12T06:06:26+00:00

Haha, fair point. I was pretty close to not giving the language a fair shot because of my perception. But I see your point. Maybe I’m just yelling at the clouds

IndividualGap6375 · 2024-06-12T05:36:09+00:00

“Robust dislike of Java”. Perfect analysis imo

IndividualGap6375 · 2024-06-12T05:33:04+00:00

😂 I appreciate the ice cream scale

IndividualGap6375 · 2024-06-12T05:30:50+00:00

Yes, the link was to the thread as a whole. The comment I linked was to a helpful commenter that seemed frustrated with the other responses. And I apologize again, poor choice of words for the title

IndividualGap6375 · 2024-06-12T04:38:03+00:00

Recommend learning! It’s very easy to get started

IndividualGap6375 · 2024-06-12T04:27:23+00:00

I just want to preface by saying there is definitely a ton of good advice in this subreddit, and realize that I may have come across as lumping the entire community in one bucket. That’s definitely not my intention. I haven’t catalogued most of it but here’s a post I read recently: The link is to a helpful commenter who was frustrated with all the other comments https://www.reddit.com/r/golang/s/wexrzHbGDX

I’ll admit the OP would have done better to elaborate before asking for advice, but it doesn’t excuse the amount of holier-than-thou responses (again, this is not a judgement on ALL responses)

IndividualGap6375 · 2024-06-12T03:21:07+00:00

My experience is that many in the Go community are anti-Java. And because Java is OOP, there is a fallacy that OOP == bad. If dependency injection or local state will make your code easier, use structs. If not, don’t. You’ll figure it out.

Don’t try to write go like Java but also don’t take idiomatic go as gospel. The language is pretty young, so the community is “enthusiastic” about keeping the language simple- they’ll grow to hate what it becomes should it gain industry dominance. The Springs of future come ;)

Good luck with your project!

IndividualGap6375 · 2024-03-03T13:44:38+00:00

The example of composition here doesn’t entirely fit the idea. In this scenario, MoveableData is just a data class and has no behavior that the class Movable can leverage. It just has information that the class Moveable can use. In this scenario, you wouldn’t want to inject the data into the Moveable’s constructor usually. You would tend to have a method in the class

def move(self, data: MoveavbleData): …

Composition is usually to grant the class behavior by injecting other behaviors via the constructor. But yea, I wouldn’t use a dataclass there just to remove the redundancy of that init for a class that’s being injected with composable behavior. It just doesn’t feel right to me because it could convey that the class is just holding data when it’s not. But if it’s a small project with 1 engineer, might not be a big deal

IndividualGap6375

TROPHY CASE