Theme 1 – Ergonomic pain with Go channels
Developers frequently cite the awkward semantics of channels (closing rules, zero‑value reads, forced use with select) as a source of bugs and boilerplate.
“Managing channels and making sure they are closed just once is quite messy compared to other languages.” – unscaled
“Channels are the main pain point… you're essentially forced to use them because they're the only things that can work withselect.” – Groxx
“I still feel like I never quite 'got' channels. Every time I use them I need to go consult the manual…” – voidfunc
Theme 2 – Go’s simplicity and production viability
Many praise Go’s goroutine/channel model for feeling “magical,” easy to learn, and solid in real‑world systems.
“The concurrency and threading in Go just feels like magic compared to every other language. I'm a goroutine addict and I refuse to be rehabilitated.” – SamInTheShell
“In production, Go has proven solid for several years.” – Joel_Mckay
“Go achieves its 'magic' by feeling like the lingua francas of programming, C and C++. Go doesn't make the developer learn too many new concepts.” – CoolestBeans
Theme 3 – Preference for alternative concurrency models
Commenters often argue that languages such as Kotlin (coroutines + structured concurrency), Haskell (STM, high‑level primitives), Erlang/BEAM, or Java (virtual threads) provide safer, more ergonomic concurrency than Go’s low‑level channels.
“Kotlin gets this right… concurrency in Kotlin feels more ergonomic to me than Go.” – unscaled
“The concurrency in Go feels similar, but is a definite downgrade due to the lack of STM.” – kccqzy
“In Haskell you can just fork a thread and block till it's done…” – nh2
“Java's virtual threads + structured concurrency + immutable records and immutable value types.” – za3faran