Your argument that a systems language must be memory unsafe relates only to current practices but not to science. science would rather prefer memory safety in systems.
Go is a systems language. The term isn't confined to device drivers. It includes platform/backend software such as web servers and things like message queues or the Docker ecosystem.
Real time programming requires you to be able to make hard guarantees about how long a certain piece of code can run and what resources it uses.
This is literally impossible with a GC because you can only bound one resource (time or memory) at a time.
The best RTS languages are a pain in the ass to use because the compiler will complain about everysinglething - cases that could go wrong with your code
They are used in mission critical (in all sense of the word) systems like spaceships - where a tiny bit of lag will send it thousands of miles in the wrong direction.
Those links you provided, one is a draft for a spec, it's not even implemented yet - and the other has nothing to do with real time languages.
- Algol 68
- Mesa/Cedar
- Sing#
- System C#
- Modula-2+
- Modula-3
- Oberon
- Oberon-2
- Active Oberon
- Oberon-07
- Component Pascal
- Lisp (regarding Lisp Machines and its derivatives)
- Java (when deployed bare metal on embedded devices, e.g. Aicas, PTC)
- Swift
- D
- C# (when used alongside .NET Native, IL2CPP, CoreRT, Netduino, meadow)