A systems language does not imply anything about scale and reliability. By your definition, Java would be a systems language, while C and assembly would not be.
A systems language is one that not only allows direct low-level access to hardware, but it's well suited for it. It not only works without a runtime (or at least a very minimal one), but it is its main mode of operation.
Many languages can do many things. Some are more suited for writing systems, and we call those systems languages. That rules out Go, Lisp, etc, despite people having written systems in them.
Well, that's fine, we're all entitled to our opinions.
Such a definition of systems language strikes me as borderline useless and vague, though, hence my request to chuck it out the window. (See also: high-level vs low-level is an even more poorly defined and useless term). I also don't see C (or rust, or C++) as having any unique affinity for accessing hardware—certainly, certainly not better access than lisp, which can often resemble an assembler with twenty megabytes of macros baked on top. Hell, I'd argue lisp is more systems-y and "low-level" than C is, which can't even be easily utilized to pump out a maintanable boot sector. It's just not built for that; it's built to generate object files, which then need to be lowered into binaries with a linker. Lisp is just flexible enough to rewrite itself into the target domain, which C cannot do.
Look, I'm not trying to argue about definitions; it's a waste of both our time. But genuinely, why are you so strident about using the term if you clearly have a more precise understanding of what you want to communicate? Why not just say "programming languages with access to an inline assembler and address lookups" (which, again, would include most common lisps)? Why not say "can link to the C ABI without relying on FFI at runtime" (which would exclude many lisps)? And granted, this only came up because it was used seriously in the original post, so the onus is really on everyone to care about how precisely they characterize language.
We should honestly just stop using "systems/high-level/low-level" entirely; they're too vague and get people too worked up. Which is just baffling to me; I have no emotional attachment to any programming language or similar tool.
> But genuinely, why are you so strident about using the term if you clearly have a more precise understanding of what you want to communicate?
Because, up until I've read your comment, I've seen the term used with my definition pretty much everywhere, so I believe it's a fairly well understood and agreed on term, with you being more of an exception.
We all have our opinions and perspectives. Typically, people who agree with eachother don't beat this conversation to death every time the term comes up. Frankly, nobody has ever made the case to me the term is worth using iin the first place outside of protecting some misplaced sense of pride. Until you, I wasn't aware anyone outside of enterprise c/c++ coders took the term seriously.
But, if you didn't read and acknowledge the submission that "systems" is more of a culture than some association with a language, I think this conversation is over. I'm super happy you know what a pointer is, bro. Good luck socializing.
A systems language is one that not only allows direct low-level access to hardware, but it's well suited for it. It not only works without a runtime (or at least a very minimal one), but it is its main mode of operation.
Many languages can do many things. Some are more suited for writing systems, and we call those systems languages. That rules out Go, Lisp, etc, despite people having written systems in them.