[scott_s]

Rust is designed as a systems programming language, so it was explicitly made for situations where zero-cost abstractions and explicit memory management matter. Embedded devices and kernel development are two places that matters, but there are more: web browsers, web servers, databases and runtime systems all come to mind.

[vitriol83]

I don't think that one can necessarily equate systems programming with manual memory management (see e.g. Go). It's true that manual memory management will (probably) be more efficient and more predictable, but ultimately depends on how important that is in your application.

[scott_s]

I agree that systems programming does not necessarily imply manual memory management. But I think a modern language with manual memory management is necessarily a systems programming language - and if it's not, it made a mistake. Regardless, Rust was designed for systems programming where manual memory management matters.

[Narishma]

Go is not a systems programming language (as the term is usually understood), and Google labelling it that way when they first introduced it is unfortunate.

[hellofunk]

Indeed, and the author of Go himself has said that he is glad Google no longer uses that term when referring to Go, as he also doesn't believe it is one.

[vitriol83]

Citation needed. Plenty of people regard high-level languages as nonetheless suitable 'systems programming'. This is the first FAQ on golang.org! See also

https://ocaml.github.io/ocamlunix/

[tarblog]

I would define the term "high-level language" to mean that it's possible to write programs in the language without needing to worry about the specific hardware that the program is running on.

I would consider systems programming to be things like writing operating systems, drivers, high-performance native applications (for many difference definitions of high-performance), and databases.

I consider rust to be a high-level language and I further consider it to be suitable for systems programming using my definitions.

However, I don't consider go to be suitable for a lot of systems programming tasks because it has a significant runtime system that includes a garbage collector. Just because they describe themselves as a "systems programming language" doesn't mean that I believe them (at least as far as I understand that term). That said, there are certain applications that work fine with GC, and in those cases it can be a very nice way to achieve memory safety without programmer burden.