> In the general case, callbacks are slower due to the need to keep creating stack frames over and over, instead of leaping into already-existing ones in progress, and things like Go will always have an advantage there.
Theoretically it's the same asymptotic cost. If you have state that has to be saved from I/O operation to I/O operation then you have to store that somewhere. In Go you would store it in the goroutine stack; note that allocating a goroutine stack requires an allocation. In Node you would store it in the callback environment, also requiring an allocation. In theory an optimizing JavaScript engine could reuse the same captured variable environment across multiple closures if it's the same, resulting in the same asymptotic performance as Go.
"In theory an optimizing JavaScript engine could reuse the same captured variable environment across multiple closures if it's the same, resulting in the same asymptotic performance as Go."
I said stack frame, not capture environment. You don't "store it" in the goroutine stack, it is the goroutine stack. Something like Node is going to be constructing and destructing frames much more often.
Further, the performance argument is trivially discarded by observing that in real languages like Go or Erlang, the speed of real code is just as fast if not faster than Node. You only get slowdown in Node because you have to pay to implement abstractions at the wrong layer. In the general case, callbacks are slower due to the need to keep creating stack frames over and over, instead of leaping into already-existing ones in progress, and things like Go will always have an advantage there.