Re: Systems Programming Language vs. Application Programming Language
Because they intuitively recognize that, in addition to being capable of low-level programming, Rust also has a lot of high-level constructs and, more importantly, it cares a lot about being an imperative systems programming language in the original definition of the term, where languages with comparable guarantees tend to be functional languages like Haskell.
To reference a quote used to good effect in https://willcrichton.net/notes/systems-programming/ :
> In Systems Programming Languages (Bergeron et al. 1972), the authors say:
>> A system program is an integrated set of subprograms, together forming a whole greater than the sum of its parts, and exceeding some threshold of size and/or complexity. Typical examples are systems for multiprogramming, translating, simulating, managing information, and time sharing. […] The following is a partial set of properties, some of which are found in non-systems, not all of which need be present in a given system.
>> The problem to be solved is of a broad nature consisting of many, and usually quite varied, sub-problems.
>> The system program is likely to be used to support other software and applications programs, but may also be a complete applications package itself.
>> It is designed for continued “production” use rather than a one-shot solution to a single applications problem.
>> It is likely to be continuously evolving in the number and types of features it supports.
>> A system program requires a certain discipline or structure, both within and between modules (i.e. , “communication”) , and is usually designed and implemented by more than one person.
In other words, by the original definition that Rust pays a lot of attention to, Java and Go are also systems programming languages, because systems programming is about producing complex infrastructural components with a long service life that need to be maintained by shifting teams... like the networks of microservices Go excels at.