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.
If I worked in a Go shop I'd probably use Go, though.
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.
Doesn't Go start NCPU event loops every time?
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.
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! :)
But I guess the counter-downside to Go is that you need to compile different versions for different platforms; the 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.
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.
Why is this a downside? Native binaries are the Platonic ideal for distributing applications.