Your comparison is a bit disingenuous. I thought that the reasonable point of comparison was obvious, so let me state it in case it's not:
* For this C program: Let's say a default install of a Debian system, with GCC and Make installed. Nothing else. Just clone and run make && ./bin/nms.
* For an hypothetical JavaScript implementation: Same Debian system, with Node.js installed. Nothing else. Just clone and run node ./src/nms.js.
Now tell me that the second point would ever happen, of course without the obvious trick of vendoring tens or hundreds of dependencies in the repo itself. Given the current trends and ecosystem incentives in the JS development world, I highly doubt it.
These trends only favor mindless composition, of which the latter is good, but the former is bad. IMHO most devs would probably not even consider the idea of writing a compact, self-contained piece of code and have their own termio [1] or charset [2] implementations, to begin with.
So your assertion is that if those exact same devs would write C, they would somehow magically stop seeking out libraries to solve the problem for them? Because there are thousands and thousands of C libraries, just like there are libraries in every other language. That seems a bit of a stretch - my "disingenuous" assertion is that library use is orthogonal to language.
Also, there are plenty of non-C languages (js may be one of them, but it's been half a decade since I touched it and longer since I used it in any meaningful way) that you could transliterate this program into - its a handful of lookup tables, a couple loops, and a couple syscalls available in every stdlib I'm familiar with. It seems disingenuous to assume that there are only C and JS (or being generous that those extremes are the only options).
Not so much ignoring other languages, as just talking about the one which coincidentally (or maybe not) is the one that usually attracts most conversations about dependency ballooning, at least around here on HN.
> if those exact same devs would write C, they would somehow magically stop seeking out libraries to solve the problem for them?
I'd posit that an ecosystem which doesn't encourage to add a third party library for the tiniest of needs, yes, does indeed discourage from using libraries except for the most egregious needs.
E.g. you wouldn't implement a whole object-based oo-style programming paradigm in C, it would be wiser to just use GLib with its GObject implementation.
But it would be uncommon to use a stupid library like is-even. Something that is very common to do in JS.
And actually this leaves the space of being opinion based and is more supported by evidence. You'd hard pressed to find this kind of mindless lazy usage of libraries in well consolidated and popular C-based software. But I bet you wouldn't need even 30 seconds to find some popular JS package that in its transitive dependency tree ends up using a left-pad [1] level of library.
* For this C program: Let's say a default install of a Debian system, with GCC and Make installed. Nothing else. Just clone and run make && ./bin/nms.
* For an hypothetical JavaScript implementation: Same Debian system, with Node.js installed. Nothing else. Just clone and run node ./src/nms.js.
Now tell me that the second point would ever happen, of course without the obvious trick of vendoring tens or hundreds of dependencies in the repo itself. Given the current trends and ecosystem incentives in the JS development world, I highly doubt it.
These trends only favor mindless composition, of which the latter is good, but the former is bad. IMHO most devs would probably not even consider the idea of writing a compact, self-contained piece of code and have their own termio [1] or charset [2] implementations, to begin with.
[1]: https://github.com/bartobri/no-more-secrets/blob/master/src/...
[2]: https://github.com/bartobri/no-more-secrets/blob/master/src/...