Yeah, channels are the main pain point. In addition to the axioms being simply weird (because it's an easy set to implement), another major problem is that you're essentially forced to use them because they're the only things that can work with `select`, and that's the only reasonable option for many operations. Especially if you touch other code, like the stdlib.
That and the lack of tooling around mutex usage / concurrency correctness. The race detector is legitimately excellent and every language needs it, but it can only catch races that you trigger in tests/builds with it enabled, and few projects write anywhere near sufficient concurrent tests to catch issues in practice. There isn't even a "this var claims to be protected by lock X, but it is not held [here]" lint, or "this var is atomic but used non-atomically [here]" (though this one is significantly less of an issue with generics, as safe zero-cost abstractions now exist).
Go doesn't monomorphize, so benchmark your generics- they might not be zero cost
Go monomorphizes quite a lot, so that's mostly incorrect - it'd be relatively true for Java, for comparison, ignoring Graal. https://github.com/golang/proposal/blob/master/design/generi... there are only exceptions when you instantiate multiple different types that share an underlying type/layout, all other cases (including different types) are monomorphized. E.g. `type x struct{a int, b float32}` and `type y struct{b int, a float32}` share codegen, but if you even just swap the type order (float32 then int) they wouldn't.
The primitive generic atomics in the stdlib don't run into those details, so you really do get pretty much exactly the compiled code as what you'd write inline by hand:
>In particular, fundamentally different built-in types such as int and float64 are never in the same gcshape. Even int16 and int32 have distinct operations (notably left and right shift), so we don’t put them in the same gcshape.