News for hackers. Stuff that matters.
Re:Diving into Go by building a CLI application by winrid on Wednesday May 27, 2020 @02:09AM (#23319867)
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.

Re:Diving into Go by building a CLI application by mpfundstein on Wednesday May 27, 2020 @04:17AM (#23320676)
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.

Re:Diving into Go by building a CLI application by jerf on Wednesday May 27, 2020 @09:05AM (#23322530)
"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.

Re:Diving into Go by building a CLI application by vips7L on Wednesday May 27, 2020 @08:08AM (#23322007)
> start up a whole async event loop

Doesn't Go start NCPU event loops every time?

Re:Diving into Go by building a CLI application by mpfundstein on Wednesday May 27, 2020 @01:57PM (#23327160)
does it?
Re:Diving into Go by building a CLI application by vips7L on Wednesday May 27, 2020 @02:09PM (#23327358)
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?
Re:Diving into Go by building a CLI application by winrid on Friday May 29, 2020 @07:26PM (#23356804)
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! :)

Re:Diving into Go by building a CLI application by Cthulhu_ on Wednesday May 27, 2020 @03:50AM (#23320512)
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.

Re:Diving into Go by building a CLI application by pansa2 on Wednesday May 27, 2020 @03:55AM (#23320543)
> 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.

Re:Diving into Go by building a CLI application by eryb on Wednesday May 27, 2020 @05:24AM (#23321079)
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.

Re:Diving into Go by building a CLI application by sagichmal on Wednesday May 27, 2020 @07:10PM (#23331301)
> 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.