"Java or C will be much faster at any computational work"

That is far from clear. I've been using nodejs for some computational work using https://github.com/substack/gamma.js and https://github.com/niggler/bessel and found that the JS version is faster than the straightforward Java implementation.

The OP made too general of a statement because there are certain cases where V8 can preform better than the JVM; however, generally Java does seem to perform better (ignoring startup time).

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

In the linked benchmarks, V8 only has a decided advantage executing regexes.

Heh. Last time I checked v8 regexes were really fast, except their string builder was a disaster... it wrapped every piece of string as a js object (gc and everything).

Sounds familiar to Java's own string concatenation. In Java you use StringBuilder / Buffer to create larger strings from smaller ones; in Node you'd use Buffers, although I never dived too deep into those.

Well, C will be faster anyways... and the JVM is probably faster than v8 more times than not.

im not an expert but arent UDP Socket connections more like an fire and forget scenario which doesnt create alot of waiting ? Id think that game servers have to compute heavier stuff per tick and have to process all the incoming packets anyway so that waiting for IO isnt really an issue ? It might make sense to have the game world updating and sending/recieving packets in different threads though, so is that were nodejs makes sense?

The network stuff is, yeah. But presumably you want your minecraft world to be durable, which means hitting disk. And you don't want your network stuff blocked behind that.

ok makes sense but i wouldnt write every change to the disk anyway. The server state can well be kept inside memory and only be saved once in a while, but nevertheless doing that in a different thread would make sense.