I'm unclear on the relevance of a comparison between Go and Ruby here. Ruby is radically slower than Go. It's down there with Python, if not a touch behind [1]. From the outside, I'd expect that it's possible that slight improvements in the context switching time will be dwarfed by the generally slow execution of Ruby itself; that is, if Ruby is going to take 100 microseconds to do something, whether it context switches in 1 microsecond (best-case OS thread cost) or .2 microseconds (best-case goroutine switch) is of somewhat less consequence then it is for a compiled langauge that can complete that task in 2 microseconds. That ratio of 50x is not just something I made up, it's about what you can expect in general. I'd need to see the actual Ruby benchmarks to come to any conclusions as to whether or not I'm right.

The other problem with this sort of benchmark, which is a mistake I also commonly see made by Node developers, is that the Ruby HTTP stack has significant native code in it, like: https://github.com/puma/puma/tree/main/ext/puma_http11 This is a good and proper thing that brings benefits to all involved; it's not like it's "cheating" or anything, it's a real performance benefit. But it does mean when you're benchmarking a simple HTTP server, you're benchmarking Ruby qua Ruby a lot less than you think you are, and so the relevance of such benchmarks to codebases that have actual Ruby in them will be less.

[1]: https://programming-language-benchmarks.vercel.app/python-vs...