Remix clone Hacker News

Hard disagree on this. Large production apps that use channels have very subtle bugs that cause all kinds of annoying issues that only come up under load in prod. I have been using go for ten years and still pick it as my language of choice for most projects however I stay away from channels and especially any complex use of them unless it’s 100% required to scale the application. Even then you can most of the time come up with a better solution by re architecting that part of the application. For pet projects go crazy with them though.

▲

latchkey 4 days ago | parent [-]

What are you disagreeing with exactly, are you trying to argue against testing? Are you trying to argue that using a library protects you from bugs somehow?

You stay away from something you don't understand after 10 years of working with it? What kind of logic is that? Channels aren't magic.

Subtle bugs in what? Have you considered that maybe you have bugs because you aren't writing tests?

If you aren't unit testing that stuff, then how are you able to fix/change things and know it is resolved?

My experience is that I built a binary that had to run perfectly on 30,000+ servers across 7 data centers. It was full of concurrency. Without a litany of automated tests, there is no way that I would have trusted this to work... and it worked perfectly. The entire deployment cycle was fully automated. If it passed CI, I knew that it would work.

It wasn't easy, it took a lot of effort to build that level of testing. But it was also totally bug free in production, even over years of use and development.

▲

edvinbesic 4 days ago | parent | next [-]

You asserted that bugs are hard if you write unit tests. The parent stated that some issues only occur under production load and a unit test will not catch it. Nowhere was it implied that unit tests are useless.

Perhaps a less defensive posture might invite more discussion.

▲

latchkey 4 days ago | parent [-]

> The parent stated that some issues only occur under production load and a unit test will not catch it.

I can't think of a single production problem that can't be replicated with a unit test. If you're seeing a problem in production, you need to fix it. How do you fix it? You write a test that replicates the problem and then fix the code, which fixes the test.

▲

zaptheimpaler 4 days ago | parent | next [-]

> If you write comprehensive unit tests, it is not easy to have bugs in golang.

First you claimed before that unit tests will catch your subtle concurrency bugs before they happen, and that's just not often the case. They are subtle, might involve many systems and weird edge cases and often don't get caught BEFORE they happen. Of course anyone can write a test to replicate the problem after seeing it in production and spending hours/days debugging it.

More importantly, "Write comprehensive tests" is technically a strategy to avoid any bug ever. You can tell C programmers not to segfault by writing comprehensive tests but that doesn't negate the point that the language makes it easy to write segfaults. "Write more tests" is not a rebuttal to saying C makes some classes of errors easy to write. Writing comprehensive tests often takes a lot of time, is often not prioritized by companies, and is especially hard with distributed systems, concurrency, mocks and complex applications. If we just said "git gud noob" in the face of error prone and difficult abstractions, we might as well all be using assembly.

▲

latchkey 4 days ago | parent [-]

Why are you comparing golang to C?

▲

ctvo 3 days ago | parent [-]

Your replies here have been less than useless. I clicked on your profile and saw you were "founder and CEO" of some company.

I guarantee you I won't be using your product. Just something to consider.

	▲	latchkey 3 days ago \| parent [-]
		Thank you for sharing your perspective. I genuinely appreciate honest feedback. My goal is always to add value to discussions, but it seems I’ve fallen short in this instance. If there’s a specific way I could clarify or improve my comments, I’d be grateful to hear it. Regarding my company, I respect your decision, but I hope that if our paths cross again, I might have the opportunity to change your mind through actions that demonstrate the value we provide to our customers.

▲

mplewis 3 days ago | parent | prev [-]

Then you have not worked on complicated systems.

▲

latchkey 3 days ago | parent [-]

Why would anyone even say this to someone? Totally rude.

▲

noop2714 3 days ago | parent [-]

Reading through the thread, I can tell you have depth of experience.

Perhaps bringing it down a notch could help you connect with others’ perspectives as well.

	▲	latchkey 3 days ago \| parent [-]
		If people were actually sharing perspectives (like the guy above), that would be fantastic.

▲

glzone1 4 days ago | parent | prev [-]

The original comment was about how concurrency expands / makes it easier for there to be errors in go (which avoids LOTs of other errors just with compile time / type safety stuff).

"very easy to have bugs when working with channels and the way it handles errors etc"

If you've done some programming you'll find this to be true. You have to think a LOT harder if doing concurrency, and you generally have to do a lot more tests.

Go - WITHOUT that much testing, is often surprisingly error free compared to more dynamic languages just out of the box both language side and how a lot of development happens. Python by contrast, you can have errors in dependencies, in deployment environment (even if code is fine), based on platform differences (tz data on windows), and plenty of runtime messes.

Channels are not as default safe / simple after compile as a lot of other go.

Try programming without channels in go and this may become clearer.