That said, well done for making this.
Lilith: x86-64 OS written in Crystal (github.com/ffwff). [1]. And Crystal has GC.
If people keep doing that, the term will eventually loose meaning. Maybe in 20 years, it will have eroded enough that something like Python will be called a "systems programming language". I mean after all, a printf statement in C also parses the format string at runtime. Who is to say the fact that all of the code is interpreted should thusly exclude something like Python? I'm being sarcastic, if that wasn't obvious.
Nature claims 'concise'ness in it's README's opening paragraph. That is laudable. It's even more laudable if the conciseness would also be reflected in the use of natural language (no pun) that describes it.
Calling it a "systems programming language" while using GC is IMHO eroding the meaning of the term.
Something meaning X and someone including Y and then someone pointing out that X does not include Y has thusly nothing to do with stereotypes here.
I worked in a "systems" lab as an undergraduate (basically, doing memory allocator research as an independent study) and my main workhorse was python because I was working with largely static data and then generating C. Is python a systems language? The idea is ridiculous. But I was definitely doing systems work. I think we need more flexibility in terms of how we view these cultural ties as inherent to the language as opposed to how it's wielded in context. Most of the time we can use a more specific term (eg "manually memory-managed", "C ABI linkable", "native", "reentrant", "able to use inline assembly", etc) with zero loss of meaning and great benefit in reducing arguing over terms.
Hell, if scala native could take off, it could be a real competitor to C++ and Rust. Is oberon a systems language? How about lisp? People have definitely written entire operating systems in both. Things get really weird once you wander outside the mainstream. Is erlang in a switchboard a systems language? I would say it should be considered such despite looking wildly different than C in just about every manner.
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.
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.
Edit: you may find Game Oriented Assembly Lisp interesting: https://en.m.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
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.
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.
See also: "is C a high-level or low-level language?" Just shoot me instead, please.
"Nature is... A general-purpose open-source programming language and compiler designed to provide developers with an elegant and concise development experience, enabling them to build secure and reliable cross-platform software simply and efficiently."
I believe nature is equally suitable.
I wouldn't care if my network daemon was written in Python or not, but I would care if the networking stack itself was.
But suppose the very top of stack is high frequency trading system or traffic light controller. Car brakes...
Depending on your stack, determinism may or may not be a key part. And that is only possible if determinism is guaranteed all the way down.
"Determinism" feels like a very odd pitch for manual memory management when the latter in no way implies the former, and lack of manual memory management in no way implies non-determinism. Generally, any dynamic allocation is non-deterministic. Furthermore, in the HFT context the non-determinism of the network is going to absolutely dwarf any impacts GC has, especially if you have ever heard of arena allocation. Even your OS's scheduler will have larger impacts if you make any efforts to avoid memory churn.
Now, an interrupt handler should never allocate memory and should generally run with a constant number of cycles. But that's an extremely niche interest, and you'd probably want to hand-code those instructions regardless.
(FYI, I work in a support role to a HFT product, among many others, but it runs on the JVM)