Fortunately I've used Go, Kotlin and C# in production building systems dealing millions of rpm. I can correlate my experience with different parts author has de

Fortunately I've used Go, Kotlin and C# in production building systems dealing millions of rpm. I can correlate my experience with different parts author has described. But I would disagree with few parts, specially simplicity part. You see the so called "simplicity" comes at a cost of extra verbosity and pain e.g. no generics; I have to add 3 extra lines of code, and repeatedly do casting and `ok` checks to just get value out of an in-memory LRU cache. Now some of folks might argue well this is the right way to do it. IMHO generics is one example of compiler slacking on me, and putting the burden on developer to maintain those extra lines of code. I do agree with C#'s breakable TPL model where you can choke threads; and I think that problem exists due to Tasks being slapped on to legacy down the road. If they were to reinvent another language I bet no-body with sane ideas will ignore the async programming model. Kotlin is one such example. I can keep going on and on, but to cut it short; yes I would write a high performance router, reverse proxy, or a very simple micro-service in Go. But I would never recommend anyone to write a high business complexity service in Go. It's a matter of time before somebody writes a transpiler that would take these short comings of Go, and fixes them (Like Kotlin, Nim etc.).