I would add that engineering is the art of tradeoffs. The language authors decided to route all network scheduling through netpoll, and launch a new goroutine for every incoming http request. These decisions carry a significant overhead. But they mean that users of the language can effortlessly write production ready web apps which magically scale to utilise all the cores at our disposal, handle concurrent and long-running requests with grace, handle orders of magnitudes more requests than python or ruby, and which do not require us to become experts in tuning Apache/Nginx configs.
So the authors have decided to favour making our lives easier over trying to get absolutely optimal performance in benchmarks. Personally I appreciate their choices and enjoy using Go. Those who have other priorities are more than welcome to write the web apps in Perl, Rust, C++, assembler etc... Go was never meant to be all things to all people. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0aad04a4-136e-4a9d-992e-c2fa89d1dedd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
