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