[mpfundstein]

i always find it 'perverse' to start up a whole async event loop for a tool that then transforms a csv or does some other single task :-)

also portability quite sucks. if you use features that my node version doesn't support, i screwed.

with go (or C, Rust...), I just compile and distribute the binaries. look for instance how easy it is to install nomad.

[jerf]

"Start up a whole async event loop" is really just "call one of the event loop APIs in the kernel". It's not like "starting an event loop" is intrinsically costing a millisecond and half a gig of RAM or something.

What a larger system builds around the event loop may be heavyweight, but I think that would generally be less about "using Node" or "using Go" and more about picking up some heavyweight framework within the event-looping language. The event loop itself is generally going to be too light-weight to worry about compared to the things it is waiting on to worry about, until you get to a scale that you're unlikely to reach on a CLI.

[vips7L]

> start up a whole async event loop

Doesn't Go start NCPU event loops every time?

[mpfundstein]

does it?

[vips7L]

I'm not a Go dev, but is that not what the go runtime is? An event loop for NCPUs or a work stealing queue that uses NCPUs?

[winrid]

Most of the tools we have use less than 100mb of ram - and a good number under 50mb. Point is, Node is pretty light for how fast you can build tools with it.

All my co-workers have the same version of Node, since we code in Node, so that argument is mute. My point was it depends on your environment! :)