What he's described is pretty trivially done in most modern languages/frameworks. I can write the same in C#, Scala or C++11--swapping greenlets for standard threads, which honestly is unlikely to be a perf concern--pretty trivially.
The hardest of the above would be C++, because boost::threadpool isn't officially part of Boost--though it works fine--and otherwise you'd have to get a little creative with boost::thread_group (but in doing so it'd probably be only slightly more complex than the Go version).
I mean, it's a nice feature, albeit bolted to a language with a lot of issues. But unless you have pressing reasons to look at Go, something like that sounding easy probably won't really trip your trigger. =)
You don’t need a thread pool or threads at all. Just schedule a timer for each server. You could do it in JavaScript.
I’d even guess that a JavaScript implementation would be more efficient than Go. A goroutine has an overhead measured in kilobytes; a JavaScript timer is presumably smaller.
Yeah, I realize you can accomplish the same result in almost any language, but not nearly as easily. It's the syntactic sugar that impressed me, and the fact that's it's such an integral part of the language.
The hardest of the above would be C++, because boost::threadpool isn't officially part of Boost--though it works fine--and otherwise you'd have to get a little creative with boost::thread_group (but in doing so it'd probably be only slightly more complex than the Go version).
I mean, it's a nice feature, albeit bolted to a language with a lot of issues. But unless you have pressing reasons to look at Go, something like that sounding easy probably won't really trip your trigger. =)