It's frustrating to see that people advocate to use programming languages in the areas where they don't belong just because those languages are convenient, have nice syntax, popular, etc. Go for example started that way but ultimately went to the niche of writing networking services where it shines. It's weird that languages with unpredictable runtime characteristics such as Java and C# are being advertised as systems programming languages.
> It's weird that languages with unpredictable runtime characteristics such as Java and C# are being advertised as systems programming languages.
Languages don't have unpredictable runtime characteristics, only specific language runtimes have unpredictable language characteristics. One could replace the standard .NET runtime GC with a hard realtime GC, and .NET would then have more predictable runtime characteristics than C and C++.
If I am able to write an OS using just the language, with the help of some Assembly, or bootstrap the language and runtime, it is a systems language.
Many of the criteria people use to judge systems languages like inline assembly, would disqualify C when applied to a pure ANSI C compliant compiler without language extensions.
The primary criteria where a system language should be judged is the control over the underlying machine code execution. With GC languages you don't have any - the GC will kick in unpredictably. It may not be an issue for UI (although everyone hates when UI stumbles), but for system code like OS, DBMS, etc. it's simply not acceptable. Languages like C and Rust offer this level of control - you simply know exactly what your code is doing at any given time. With JVM, .NET, Go - you don't.
And yet Xerox PARC, UK Royal Navy, DEC all managed to write operating systems in GC enabled systems programming languages, some of them quite productive Workstation OSes.
You don't want the GC to mess with your lovely data structure?
Allocate on the stack, as a global static or let the GC know not to touch it.
Check Algol-68RS, Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Oberon-07.
You can control the GC by not allocating, or by allocating off-heap, when you need to. It is totally possible to write kernels, DBMSes, network stacks, etc. in GC languages.
Whether a particular language makes that nice enough to be more worth using than a non-GC language is another question.
> With GC languages you don't have any - the GC will kick in unpredictably.
This is only true of specific GC implementations. Incremental GCs never pause the program. On-the-fly and realtime GCs pause the program for a few microseconds.
