3 ms·
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 quit
by mpfundstein 6y ago
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.
- vips7L 6y ago> start up a whole async event loop Doesn't Go start NCPU event loops every time?
- mpfundstein 6y agodoes it?
- vips7L 6y agoI'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?
- jerf 6y ago"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.
- winrid 6y agoMost 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! :)