[vitriol83]

The article is comparing Rust principally to Python (a new dynamically typed language) and C++ (an old statically typed language). It's certainly plausible that it can bring benefits over these.

More interesting to me would be comparing it to a new-ish multi-paradigm language, of which there are many right now (e.g Swift, OCaml, Haskell, F#, Scala). It seems like in practical applications these newer FP languages will be much more productive than Rust, as memory management is much simpler. Rust's principle of zero-cost abstractions is great in theory, but can't think of many applications where it's the limiting factor except perhaps embedded devices and kernel development.

[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.

[ionforce]

Python isn't "new".

[scott_s]

And neither are Haskell and OCaml. It's interesting how people's perceptions of programming language age work. For the record: OCaml is 20 years old, Python is 25 years old and Haskell is 26 years old.

[wtetzner]

Not particularly relevant to the discussion, but because I was curious, I looked up the age of ML: 43 years old. [1]

[1] https://en.wikipedia.org/wiki/ML_%28programming_language%29