It seems you agree. Systems and scripts are not differentiated by the size of the codebase. The way you speak about errors, like "being tempted to swallow errors" and "returning Result from every single function", suggests that you are accustomed to writing scripts. Which isn't unexpected as a lot of computing workloads are script in nature. And, indeed, the 'try/catch' model is well suited to it.
But it not fun when writing systems. That is why we have different tools for different jobs.
That's fine. Obviously words can mean anything and naturally one would ensure that they are aware of what they are intended to mean in a given context before going any further if there is any lack of clarity. As there was no earlier questioning of what they might mean, there clearly was no issue with clarity. To backtrack now is strange and hilarious.
But I posit that the "definition" is consistent with the literature. Scripts carry out a defined set of tasks and if something goes wrong they can simply fail, wait for the problem to be resolved, and then try again. Systems don't have the same luxury. They have to find alternative solutions when fault occurs. "An error occurred. Try again later." is not acceptable for systems, but is acceptable and perfectly valid for a large class of computing problems.
Again, "try/catch" is great for scripts as most of the time you just want the error to "bubble up to the top" to notify the user, or whatever, anyway. Such a thing would be unthinkable in systems, though. When you actually have to deal with errors at every turn, "try/catch" is a slog, and I would argue a poor mental model to boot (what's special about errors that deserves something different?).
It turns out that software development is an engineering endeavour, not a religious one. Different tools for different jobs.
I suppose you live in a bubble where "script" is almost all code ever written.
Here's a definition of "script" that shows how out-of-touch your definition is: https://en.wikipedia.org/wiki/Scripting_language
"... a script is a relatively short and simple set of instructions that typically automate an otherwise manual process."
You keep talking about "system" as if there was also a clear definition for that in software, which makes me think you're not even a software engineer at all, are you?
> Obviously words can mean anything
No, that's your mistake. Words can't mean what you choose they to mean! Do you know the old meme "Stop trying to make fetch happen!"?? So, "system" wont' happen!
I guess that you're talking about embedded development??? Where Exceptions are not used because they're a bit too costly (and because they're written in C which has an incredibly primitive error handling, it doesn't use Result types anywhere), NOT because they make software unreliable. You may disagree with that, but for goodness sake stop with your condescending tone pretending that you know something you clearly don't and work on "systems" which we, mere mortals (despite you having zero idea what kind of "systems" I work on), have no idea about.
> I suppose you live in a bubble where "script" is almost all code ever written.
Most tasks humans perform are in following a "script" so stands to reason that software would carry that forward. Why wouldn't most code be of the script variety? It would be quite surprising if that wasn't the case.
> which makes me think you're not even a software engineer at all, are you?
Appeal to authority and ad hominem at the same time. Intriguing.
> I guess that you're talking about embedded development???
I am talking about scripts and systems. You had this figured out earlier when you linked to Wikipedia. It was right there in front of you. Why the confusion again all of a sudden?
It is probably true that embedded device work is generally system in nature. It is likely that their typical workload isn't amenable to scripts, although there are some obvious exceptions, so perhaps that is what you had in mind there? But systems certainly aren't limited to embedded work.
> Where Exceptions are not used because they're a bit too costly
While I respect your ability define words as you see fit, if you really want to be the word pedant, we're talking about errors, not exceptions. Specifically carrying errors via exception handlers. It is not unusual for embedded systems to store exceptions, even in C, but that is well beyond the topic at hand.
It is always funny when the pedants aren't even technically correct. Well, at least you tried. You will always have that.
But it not fun when writing systems. That is why we have different tools for different jobs.