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.
I'd love to hear about how GCs can be useful for hard real-time systems! I was always under the impression that you needed to avoid that kind of stuff, so any links / information you have would be really interesting.
It comes down to the fact that in hard real-time you care about doing things in bounded amounts of time, and in soft real-time you typically want to do things "as fast as possible" and fixed-cost incremental GCs tend to be comparably high fraction of CPU usage versus a good generational stop-the-world collector.
Many hard real-time systems already operate with an excess of CPU power in order to simplify analysis of scheduling. Furthermore you are already bounding things like allocations, and a simple incremental GC that runs on a timer tick can guarantee to run in fixed time if you have bounded allocations per timer-tick.
All of this is somewhat moot though as many hard real-time systems completely eschew dynamic allocations.
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.