&quot;The marketing on Go is that it has great concurrency built in&quot;<p>I say this every so often, but it&#x27;s worth repeating: This is why I tend to consider Go a scripting language rather than a &quot;systems&quot; language. If you&#x27;re used to Python or Ruby or PHP or something, holy cow does Go ever offer great concurrency support with blistering performance.<p>If, on the other hand, you&#x27;ve got a task where you&#x27;re literally counting cycles in the CPU and intensely worried about L1 cache and you&#x27;re using lock-free structures not because you read a blog post about lock-free last night but because you&#x27;ve tried everything else and it&#x27;s the only way to hit your performance targets, Go is not great choice. It&#x27;s probably still miles better than Python&#x2F;PHP&#x2F;Ruby&#x2F;etc. even so, but that&#x27;s damning with faint praise.<p>I think Go occupies a rather nice spot on the cost&#x2F;benefit chart, but it certainly does not occupy the highest performance slot. But to get to that point, expect to pay some more on the cost side, and for a lot of people, it is more than fast enough, with at most just a bit of performance analysis.<p>Also, I&#x27;d suggest that the defining characteristic of channels is &quot;select&quot;. If you&#x27;ve got a channel that will never ever be used in a select statement, you&#x27;re definitely paying a lot for that capability. On the other hand, if you really need it, I suspect it can&#x27;t get much cheaper. Again, it occupies a rather nice place on the cost&#x2F;benefit chart, but it is definitely not in the highest performance slot, and, again, for a lot of people it is more than fast enough and a major upgrade over what they are currently using.