[bogota]

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]

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]

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.

[glzone1]

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.