3 ms·

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 ma

by winrid 6y ago

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.

Cthulhu_ 6y ago
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 6y ago
  > 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 6y ago
  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 6y ago
  > 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.
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 ago
    does it?
    - vips7L 6y ago
      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?
- 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 ago
  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! :)

by winrid 6y ago

Cthulhu_ 6y ago

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 6y ago
> 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 6y ago
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 6y ago
> 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.

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 ago
  does it?
  - vips7L 6y ago
    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?
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 ago
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! :)