News for hackers. Stuff that matters.
Re:Long live the callbacks by pcwalton on Thursday August 22, 2013 @01:10PM (#6258413)
> 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.

Re:Long live the callbacks by jerf on Thursday August 22, 2013 @03:16PM (#6259404)
"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.