I apologize for not answering your question in this reply, but people still debate which language features are appropriate for which tasks...

My understanding is that Erlang is still primarily used in the telco industry, as it's name implies. In general Erlang shines in doing most software that would run on a server for long periods of time when interruption is expensive (it includes the ability to hot-patch running processes, for example).

Use of a GC is problematic for soft real-time systems (interestingly enough, it can become useful again in hard-real-time systems but that's too long of a tangent here). In rust you can completely ignore the GC just by choosing to not use it. The ease of getting raw-pointer access in rust also indicates places it could be used (I feel like I could write a bare-metal application in a subset of rust with a lot less work than doing so en Erlang).

It used to be that resources were so constrained that the entire OS would be written in a combination of assembler, and something slightly higher level (most commonly C, other times a reduced set of sine other high-level language). This meant that those languages were system languages. Nowadays, writing all but the kernel and drivers in something much higher level has become feasible, so the term "systems language" has blurred in meaning.

Erlang would not really fit the systems level programming model. Erlang runs on a VM the BEAM (Bogdan/Björn's Erlang Abstract Machine). Erlang is primarily design for back-end services to other systems. If you want a multi-node redundant system and need to do message passing to handle state and concurrency then Erlang fits that bill.

A significant one is that Rust has no GC, while Erlang does. This can matter if you're trying to build software that's very sensitive to random pauses, or embedded development.

Another significant one is that Erlang has been used to make some of the most reliable software ever for the past few decades, and Rust is still pre-1.0.