One reason it's so popular: even though it skips the actual curly brackets (thus making itself more accessible), it doesn't stray too far from the general syntactic paradigm of "curly-bracket languages'" - even though I've also seen people being alienated by the idea of "significant whitespace", again for no other reason but that it "seems wrong" to them.
> The problem was your suggestion that node was uniquely well suited
No, just much better suited than people give it credit for. And this ecosystem brings new things to the table, too.
> when actually the CLI is a solved problem in most languages.
Being able to build a CLI at all? I guess, sure. Being able to quickly build an accessible CLI? Hardly so. Everything in the area of HCI is in flux, and gatekeeping the CLI domain for does more harm than good. Btw do you know anyone doing this sort of interface before Yeoman? https://github.com/synox/youtube-dl-interactive/raw/master/d.... before JS.
> There's a whole plethora of options out there.
Which is why you've got to take into account opportunity cost, choice paralysis, etc. All of the options out there are positively fascinating, but if I have the options to solve problems in multiple contexts with the same familiar tool, I tend to usually go for it.
> Quite a few do: ksh93, yash, zsh and murex (disclaimer: I wrote that shell) are all interactive shells which support floating point arithmetic.
None of which are POSIX, or common defaults?
> In terms of shell scripting languages, you can add the following to the above group: awk, bc, dc
None of which are shells - they're DSLs you can call into from the shell.
> perl
Again, not really a shell. Though I wouldn't be surprised if anyone's using it as one.
> bc <<< "scale=10; 365/7" > 365/7
Even though these tools have a good reason to be like this, having to _research_ how to _call out to an external executable_ to do something as trivial as floating point division (in the sense of "cmon man I can do this in my head, why does is it have to be so hard to tell a computer to do it") is hardly on anyone's list of priorities.
At this point, nearly anyone would rather reach for the scripting language they're already familiar with, rather than learn an unfamiliar one just because it has historically dominated the problem domain.
> one liners being more readable than multi-lined code
Admittedly, that was a pretty bullshit argument. Not any less nuanced than "[l]ine counts mean jack shit", either - I take it as a general rule that one would prefer to write less code.
And I'm not weighing any of the examples against "[c]ode golfing, minifified code, shell 1 liners, Perl, etc. I didn't really take into account the extra functionality of the Go version - it was just as unreliable as the Bash one so I quickly discarded it when I found something that worked.
There's a story behind this comparison. It was likely user error, in the sense I failed to prepare my initramfs correctly using mkinitcpio or dracut (incidentally, both of those being shell scripts - insufficiently documented and not very readable to my untrained eye, either) But the JavaScript version worked for me because it didn't even try to chroot into the initramfs - it just moves a tiny handful of required binaries into a ramdisk, and works from that.
Since that solution _works_, I am hard pressed not to commend its minimalism. Is it inconceivable that that the author was not more clever, but the tools that they used enabled them to come up with a simpler solution in the time that would've otherwise been spent googling `bc` or poring over the sources of initramfs builders?