[winrid]

I personally love building CLI tools in Node, since I and my co-workers all have it installed. Nice synchronous STD lib for file manipulation and async/await makes for compact async code.

If I worked in a Go shop I'd probably use Go, though.

[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! :)

[Cthulhu_]

Node is nice, but maybe a bit verbose and the CLI utilities are a bit low-level. The main downside to Node is that you need an external runtime to run your applications.

But I guess the counter-downside to Go is that you need to compile different versions for different platforms; the binaries are not portable.

[pansa2]

> Go [...] binaries are not portable.

Maybe not, but Go has excellent support for cross-compilation. You can still support users on multiple platforms while only developing and building on one.

[eryb]

Binaries are obviously not portable, you can't run ARM binary on x86 and vice versa without emulation.

Unlike any other language Go lets you create binaries for almost all architectures and OS with a single command, you won't find this in any language.

[sagichmal]

> But I guess the counter-downside to Go is that you need to compile different versions for different platforms; the binaries are not portable.

Why is this a downside? Native binaries are the Platonic ideal for distributing applications.