The problem with super-minimal environments like Duktape, PicoC, Lua, mruby, TinyPy, etc is precisely what you describe: there's no batteries-included behavior.

I am seriously considering acquiescing to the performance impact of Go build times (yup, it's slow, who woulda thunk) because of the sane-batteries-included nature of the language.

How fast is a hello world in node.js to you?

I forgot to mention my formerly favorite language: Python. It's _much_ faster than Node.js in startup and relatively basic things. Node wins on almost everything I make, though.

    $ time python test.py  # second run
    hello world

    real    0m0.009s
    user    0m0.009s
    sys     0m0.000s

Best times from a few "do nothing" runs of Node:

  $ time node -e ''
  real    0m0.098s
  user    0m0.084s
  sys     0m0.010s

Of course on my desktop it's a

  $ time node -e ''
  real    0m0.002s
  user    0m0.000s
  sys     0m0.000s

tiny bit different.

Python on my laptop is just slow enough that I really notice it:

  $ time python -c ''
  real    0m0.032s
  user    0m0.022s
  sys     0m0.009s

Of course PHP is all 0.014, 0.010, 0.012, etc.

Incidentally, this T43 is a backup machine I'm using while my desktop is on indefinite loan to a family member after their laptop broke. This will be fixed eventually; I'm not sure how.

But I've discovered that this old machine is a remarkably good performance catalyst; something that runs blindingly fast on this machine will run really, really well on a faster box - and the thing is, if I write stupid or inefficient code on this older laptop, I'll notice I'm doing it wrong sooner, because it takes less to make this machine fall over from inefficiency.

If only I could tell the above to the Chromium team, though... sooo many Chrome issues... (and Firefox is unfortunately slower on old hardware than ever before! >.<)

It seems almost all the time node.js runs hello world is spent loading its own modules. You should try something like this:

    // watch.js
    var file = process.argv[2]
    console.log('press enter to run '+file)
    process.stdin.on('data', function(){
        var [s1,ns1] = process.hrtime()
        for(var k in require.cache) {
            delete require.cache[k]
        }
        require(file)
        var [s2,ns2] = process.hrtime()
        var s = (s2-s1)+(ns2-ns1)*1e-9
        console.log('time: ' + s.toFixed(9))
    })

Result: less than 1ms on first run

    $ node watch.js ./test.js
    press enter to run ./test.js

    hello world
    time: 0.000952656

    hello world
    time: 0.000284171

edit: script now deletes all cache, not only the passed script (result is the same if the script doesn't require others)

Hmm, very interesting. Something to definitely keep in mind, thanks.

Python is faster on my laptop.

    time php -r ''

    real	0m0.064s
    user	0m0.055s
    sys	0m0.007s

    time python -c ''
    real	0m0.021s
    user	0m0.011s
    sys	0m0.005s

These startup metrics are also super arbitrary anyway, as in web servers code loading is behind your app server anyway (uwsgi, php-fpm, whatever).

It's possible "php -nr ''" might be faster; -n stops loading php.ini, which is what points to all of the modules PHP ships with.

> These startup metrics are also super arbitrary anyway, as in web servers code loading is behind your app server anyway (uwsgi, php-fpm, whatever).

This is true; but only about 1-5% of everything _I_ do (as a hobbyist) faces a webserver, and then the things that do require a webserver are simplistic enough that I can write said webserver in bash and run it from socat.