That's... not really a correct description of "hard real time". All system architectures have performance edge cases. The idea of a "hard" real time system is

That's... not really a correct description of "hard real time". All system architectures have performance edge cases. The idea of a "hard" real time system is that those be known and fully characterized, and that they can be mapped to equally-fully-characterized application requirements. That way you know all the failure modes ahead of time. Not all aspects of a real time system need latency control like you're imagining. It's entirely possible to imagine, say, an aircraft autopilot or self-driving system (something that needs ~100ms round-trip latencies to approximate a human pilot) being implemented using a garbage collected runtime, as long as you can guarantee those GC pauses are acceptably small (lots of such systems exist). The same would be a very hard ask of a piston engine controller, where the timing needs are closer to 100us. Nonetheless the (again to pick an arbitrary example) logging/telemetry subsystem of that engine controller doesn't need that. So as long as you have an OS that can partition the engine tasks from the low priority stuff in a reliable way, you can still imagine a Lisp/Java/.NET/Go/whatever runtime being used there. Real time is a design philosophy, not a tech stack.