There is a real time specification of Java called RTSJ. It's also available from several vendors including IBM and Aicas (JamaicaVM)

https://en.wikipedia.org/wiki/Real_time_Java

https://www.aicas.com/cms/sites/default/files/rtsj-next-gen-...

http://www.ibm.com/developerworks/java/library/j-devrtj1/ind...

And Aonix (or Atego). Theirs had quite a few innovations. Plus, had a series of them ranging from full Java down to DO-178B, hard-real-time VM.

Especially since in C# as soon as you are doing this it involves a lot of inconvenience, odd syntax, and is going to not be popular internally.

In this JavaScript world nothing is too mad.

> 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++.

You realize that Go also is GCed right?

Yes, and I never said that Go is a systems language. I said Go has found a niche of networking services. This doesn't make it a systems language.

It makes it, because it has all the same language features as Oberon has.

https://en.wikipedia.org/wiki/Oberon_(operating_system)

http://wiki.osdev.org/Go_Bare_Bones

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.

LuaJIT is GCed and being used in many system software projects from SnabbSwitch to NetBSD kernel[1]

[1] https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2...