[jy3]

Describing its concurrency model as one of its weakness is a bold statement, because it's probably one of the biggest reason it became widely adopted.

Everyone is different, but Go 's concurrency model has been the easiest for me to reason about. And I've dealt with my fair share of "async/await".

[kasey_junk]

Maybe. But I’ve been developing golang full time in high scale concurrency environments for 4 years and working with a team of similar people. It’s an opinion that is near universally shared on that team.

At high concurrency levels almost everything abandons standard golang concurrency patterns and tools.

[tandr]

Would you be so kind and explain what term "high concurrency levels" implies?

thank you in advance.

[kasey_junk]

Consumer facing systems. System wide throughput between 6-12 million QPS (daily low/high) (query body average size is 1.5KB). Each server tops at ~130K QPS. On a system with 2 1 GB NICs we pop the NIC. On a 10G we pop the CPU.

Current bottleneck is the golang http/net libs. Would likely need to rewrite it from the NIC up to do better.

[wahern]

That's an issue with the http/net libraries, not the concurrency model.

At really high throughout you can run into into issues with the kernel's networking and driver stack. I've encountered situations with my own homegrown event libraries (mostly C or Lua+C; I've never used Go) that were bottlenecked in the kernel. I've also seen issues that were fundamentally related to the use of poor buffering and processing pipeline strategies that resulted in horrible performance. For example, I can get an order of magnitude greater streaming throughput using my own protocol and framing implementations than when using ffmpeg's, though I use ffmpeg's codecs and a non-blocking I/O model in both cases, all in C. And that's because of how I structured the flow of data through my processing pipeline.

There's is no general model of concurrency that can solve that, and I've never seen any model that was easier in the abstract to tweak than any others. Those are implementation issues.

[apta]

Do you think the JVM would have faired better at this? Otherwise, perhaps something like Rust would be a better fit.

[kasey_junk]

I don’t know if it would have been holistically better, golang has lots of advantages.

But the concurrency would have been more straight forward on the JVM because the language allows for more choices & their are lots of options that get you there.