Not only that, but Node actually got faster as simultaneous connections increased while keeping a completely stable memory footprint. The benchmark showed the opposite of what the author claimed -- Node scaled effortlessly. Its performance was completely stable and predictable under load, whereas Go's wasn't.

Not to knock Go -- it's a beautiful language, and absolutely faster than Javascript for most purposes (and will no doubt increase in stability and speed as time goes on). But this post had some pretty flawed analysis of the benchmark presented.

FYI, the original article has been updated with graphs showing reqs/sec, virtual, and real memory for both using 100, 500, and 1000 simultaneous requests. Aside from virtual memory (do we care about that?) it seems to show Go as continuing to perform better.

Ah, great. That's a good update. Go does end up responding well at 1000 concurrent requests for real memory. But a spike in virtual memory means it's paging all that extra data, right? Doesn't that normally slow things down? what's interesting is Go still maintains a similar requests per second.

of course, for a front end guy, Node is still the most exciting thing on the block simply because it is server-side javascript. The fact that it's not much worse than the latest greatest compiled language is pretty exciting to me.

I don't think the spike in VM means it's paging all that. That just means it has that address space reserved, not that it's using it. I'm not aware of any real cost to having a huge pile of address space reserved, aside from that some monitoring utilities will penalize you for it (unreasonably). So, no, I don't think it'll slow anything down by thrashing, unless the locality of the memory it is accessing is really bad, but I'm no expert on Linux virtual memory or how Go uses it.