The language influences whether I can easily hack the utility or not.
The language influences how easy the utility is to port.
The language influences how easy the utility is to use as a lib, integrate with some other project.
The language influences how many memory bugs the utility might have (e.g. C vs Rust).
The language influences how fast a utility is to build (e.g. Go build times).
The language influences how easy a utility is to deploy, or to have many different versions of (e.g. static builds vs a mess of classpaths and virtualenvs and the like).
The language influences how easy is to install (e.g. go get/install, or cargo equivalent vs messing with languages with no package managers like C, where new or obscure projects are almost never in the official distro repos).
The language influences how easy is to build (e.g. go build
vs the C/C++ autoconf/automake clusterfuck and dependencies libraries hunt).
The language also influences how performant a utility will be (e.g. csv query/processing tools written in Python vs xsv -- or the canonical example, Electron monstrocities vs native tools).
Not all of these traits are guaranteed given a language (to preempt the first knee-jerk objection), e.g. a Python tool could be faster than a Go tool if written well enough.
But historically and statistically speaking, and in a regression to the mean sort of way for each language platform, I've found those things to work better in some language X over another Y.
Do you "hack" every utility you use? Is that a predicate on you using that utility? Would you not investigate a utility you like to see whether you can easily "hack" on it or not?
(I dislike the term “hack” as it denotes to me irresponsible way to throw code, rather than properly design features and implement them in a considerable manner.)
I agree with most of the things you say above, they are very important. I just don't think it should be part of the name and identity of a utility. A tool should not have to scream to the world "I am a fast tool because I was written in C++ and not JS"—that should be a given for every utility.
>Do you "hack" every utility you use? Is that a predicate on you using that utility?
No, but not all the utilities I use are open source either. When they are, and for some domains (e.g cli text manipulation tools and development utilities) I like to be able to hack them, even if I don't, so for that (and for the other reasons) the language they are written in is important to me.
I never said it's the sole criterion.
>I dislike the term “hack” as it denotes to me irresponsible way to throw code, rather than properly design features and implement them in a considerable manner
For deployment code, yes. For utilities, usually that's exactly what I want though: to irresponsibly throw code for my own purposes, when I find it convenient to fix an annoyance or bug in utility I use or add some small feature I want to it.
The language influences whether I can easily hack the utility or not.
The language influences how easy the utility is to port.
The language influences how easy the utility is to use as a lib, integrate with some other project.
The language influences how many memory bugs the utility might have (e.g. C vs Rust).
The language influences how fast a utility is to build (e.g. Go build times).
The language influences how easy a utility is to deploy, or to have many different versions of (e.g. static builds vs a mess of classpaths and virtualenvs and the like).
The language influences how easy is to install (e.g. go get/install, or cargo equivalent vs messing with languages with no package managers like C, where new or obscure projects are almost never in the official distro repos).
The language influences how easy is to build (e.g. go build vs the C/C++ autoconf/automake clusterfuck and dependencies libraries hunt).
The language also influences how performant a utility will be (e.g. csv query/processing tools written in Python vs xsv -- or the canonical example, Electron monstrocities vs native tools).
Not all of these traits are guaranteed given a language (to preempt the first knee-jerk objection), e.g. a Python tool could be faster than a Go tool if written well enough.
But historically and statistically speaking, and in a regression to the mean sort of way for each language platform, I've found those things to work better in some language X over another Y.
Hence, for me, the language matters.