> I have no idea how that would refute my statement
Ada is used for building systems running on bare metal.
> Native support for calling OS services, for example through system calls (specifically, reservation of memory space). 2) Pointers, pointer arithmetic, and reading/writing memory through pointers.
Oberon variants and Modula-3 support GC pointers and have been used to write full OSs.
Pointer arithmetic is possible in code regions marked as unsafe.
The Oberon based ones were used for several years at Swiss Federal Institute of Technology.
Spin (Modula-3) didn't had such luck, as DEC and Olivetti got closed down.
Just read the code provided in the link for Oberon's example.
The problem is that many think GC == Java, while during the years Java was getting loose into the world, there where languages like Cedar, Oberon and Modula-3 that while having a GC do offer the fine grain control one needs for system programming.
> Note that native support for heap-allocation means that GC is optional anyway
Not really. In safe systems programming language the GC is always there and you need to mark the code as unsafe when allocating from foreign heap. Meaning you are responsible for not tainting the whole code base.
For example, in the Oberon OS only the Kernel and driver modules do manual allocation.
Actually, Java 9 is getting the missing features from safe systems programming languages (some of them will only come in Java 10).
Ada is used for building systems running on bare metal.
> Native support for calling OS services, for example through system calls (specifically, reservation of memory space). 2) Pointers, pointer arithmetic, and reading/writing memory through pointers.
Oberon variants and Modula-3 support GC pointers and have been used to write full OSs.
Pointer arithmetic is possible in code regions marked as unsafe.
The Oberon based ones were used for several years at Swiss Federal Institute of Technology.
Spin (Modula-3) didn't had such luck, as DEC and Olivetti got closed down.
Just read the code provided in the link for Oberon's example.
The problem is that many think GC == Java, while during the years Java was getting loose into the world, there where languages like Cedar, Oberon and Modula-3 that while having a GC do offer the fine grain control one needs for system programming.
> Note that native support for heap-allocation means that GC is optional anyway
Not really. In safe systems programming language the GC is always there and you need to mark the code as unsafe when allocating from foreign heap. Meaning you are responsible for not tainting the whole code base.
For example, in the Oberon OS only the Kernel and driver modules do manual allocation.
Actually, Java 9 is getting the missing features from safe systems programming languages (some of them will only come in Java 10).