I use go (long term) in places where I need as part of my DR plan the ability to fix stuff without expert access. The toolchain is simple enough that I can maintain it in this scenario alone, and meanwhile the stdlib is complete enough as to be useful for solving a multitude of problems, while offering the ability to produce programs that run on many systems and integrate with them with sufficient efficiency. It's a really usable systems glue language, and it powers chunks of my telco infrastructure. This pro is mostly about the implementation/engineering design.

My biggest gripe with the language is that it doesn't scale that well for teams. It requires a certain culture & approach to produce maintainable programs that goes against the grain for many developers, and while I enjoy the simplicity it offers, that simplicity leads to cost of ownership problems in many team scenarios. This con is mostly about the language.

As a specific tactical item, the runtime multiplexer could do with a refactor. The merging of the pollers essentially could continue until it is much cleaner, there are more layers there than necessary to solve the problem. You can follow the FD close path to understand the strains of the current factoring. Such a cleanup could probably remove some overhead for io heavy workloads too, maybe even drop some lock contention. Oh, and the spins should all be removed from the runtime before we really start using it on very high core count systems. This opportunity is mostly a side effect of a long history of incremental improvement.