Every time I mess around with sysadmin stuff, I'm always flummoxed by dumb things like "what is the difference between /usr/bin and /usr/local/bin, what the heck is an LD_LIBRARY_PATH, should I use sudo for this build tool or not," etc.). I guess this is how backend devs feel when they have to tweak a Webpack config.

Maybe this is why I'm a little skeptical of the whole "move everything to Rust/Zig/Go/etc" movement in the JS ecosystem. I like JavaScript, I understand JavaScript. If I have to debug some JS tool, I'm well-equipped. Whereas if I have to dip down into some weird error like "libfoo.so.42: cannot open shared object file" then I know I'm gonna get lost.

Plus I don't think we've come close to exhausting all the ways to optimize JS deps: https://marvinh.dev/blog/speeding-up-javascript-ecosystem/

Speeding up the JavaScript ecosystem - one library at a time

Most popular libraries can be sped up by avoiding unnecessary type conversions or by avoiding creating functions inside functions.

@nolan personally, I prefer my tools forcing me to learn a language. That's how I learned JS to begin with. Tho, for terminal stuff, there's more variety of languages than JS, which is rather inconvenient.

And even then, going back to your first post, we still deal with OS issues such as directory conventions, permissions, and environment variables. I understand why you don't want language specific issues on top of all that