It's quite difficult to clearly pinpoint my trade, because I do development (mostly system related and backend), system administration (mostly Linux), lightweight cloud operations (mainly VM's and other IaaS services), and some security (sandboxing, applied cryptography).
However, at least in the last few years, when selecting the tooling I need to rely upon, I have developed (many more) and observed quite a few biases, that I would like to reflect on.
Now, before dwelling into that, I would like to stress that I'm not averse to one programming language or another, as I've programmed in C and a bit C++ (in a former life), quite a bit in Java (though not much lately), recently Rust and Go, experimented in Erlang, even toyed around with Scheme / Lisp variants, and dabbled in Python (mainly 2 and now 3), and tied everything together with Bash. So I can't say I like any language over any other; in fact I think I would especially enjoy a Scheme-based Rust-inspired syntax, with a runtime model of Erlang, with the build tooling of Go, while preserving the performance of C/Rust. :)
But, as hinted initially, when choosing the tools I want to invest my time into, I mainly settle on those that have (or lack as is the case) the following traits:
if it's NodeJS, I'll skip it regardless of anything else; I don't have anything against NodeJS, in fact at one time I thought it's a nice idea, and I've even written myself a few things in NodeJS; however experience has shown me that the quality of the JavaScript ecosystem is nowhere near "production ready";
the same applies to anything written in any system shell; (although many tools written in
sh, i.e. POSIX shell, seem to be better written than perhaps many JavaScript tools, I findshto be the worst language to write anything in;) on the other hand, most of my own "wrapper" and "support" tools are exclusively written inbash, in the most strict style as possible, and thus I would say I'm well-informed on the reliability of shell tools;they are written in a natively compiled language such as Go and Rust; or C/C++ if nothing else works, but I do stay away from those tools written in languages that aren't "mainstream" yet (such as Haskell, OCaml, etc.); I've yet to form an opinion on newer entries on the scene like Zim, Nim, Hare, etc.; (whereby "mainstream" I mean those languages for which the major Linux distributions like Ubuntu or OpenSUSE package recent versions of the required build tools and libraries;)
(although not a strict requirement) installing should require downloading a single binary and placing it in my
$PATH; (in fact, almost a year ago I've written an article dedicated to this topic;)it must be a CLI tool; except for Firefox, Thunderbird, and the nowadays mandatory "chat app" so as not to be isolated from the "civilized" world, I use everything from my favourite X11 terminal emulator
rxvt-unicode;(although not a strict requirement) it should have a GitHub presence; I don't mind tools hosted on other "hubs" and "forges", but I do find the "standard GitHub experience" a bit nicer than the "alternative GitLab experience" that seems broken if one doesn't have JavaScript turned on... (or worse, if it's self-hosted, it's almost certain to disappear five years from now...)
looking at the repository it should have a bit of activity in the last few months, else it might mean the project is abandonware;
(as a bonus, but not a strict requirement) it should be present (even if an older version) in the major distributions repositories; (which implies a somewhat longer life and better support, somewhat independent of the original developer;)
(although not a deal-breaker) I try to stay well away of anything that is written any interpreted language (including "mainstream" ones like Python, Ruby, Perl, PHP, Erlang, etc.); (I've described my reasons in depth in the single binary executable article one year ago;) (plus, especially Python, many of these languages are moving target these days...)
if it requires running a daemon or agent (even without
root), I tend to stay away; I interact enough withsystemdas not to need yet-another-service to manage;at runtime it should not spawn dozens of sub-processes without a very good reason; especially not to double-fork zombie processes! (for example any Erlang-based application that wants to do DNS resolution, would spawn a sub-process just for this purpose, which I find at least strange...)
That's about it!
Instead of a conclusion, which I don't have, as said initially these are my personal biases which are not at all objective! To some, many of these might seem too restrictive, but then again these are my personal choices, based on my personal experience within the field.