&quot;I&#x27;ve no experience with hard realtime systems, so I won&#x27;t debate about that (I&#x27;ll just say I doubt Scala is suitable for that either),&quot;<p>Hard and soft realtime both require deadlines to be met, the difference being that in soft realtime a missed deadline is not considered a fatal error, just highly undesirable.<p>Examples:
Soft realtime: A game where 60 FPS is desired for smooth animation. Lower frame rates degrade the experience but are tolerated.<p>Hard realtime: Flight surface control software in a fly-by-wire aircraft. Missed deadlines potentially result in a crashed plane - a true &quot;fatal error&quot;.<p>Any ahead of time compiled language with deterministic memory performance may be used for hard realtime. Absolute performance isn&#x27;t required, although it is desirable. As long as memory primitives are available for native Scala that permit pre-allocation, and the GC can be turned off (trivial), it should work fine even for hard realtime.<p>As an aside, I expect for many things native Scala will equal C++ in performance. On the JVM is extremely close to Java in performance.<p>&quot;but Haskell can be used to write simulators and games.&quot;<p>Realtime simulations and games? It seems hard to reconcile immutable state with time-based simulation in any efficient way. Then there are garbage collection cycles and laziness to deal with.<p>&quot;Haskell is currently a practical general purpose language. I don&#x27;t see any evidence Scala is any better at this. Are you speaking from experience?&quot;<p>GC based languages in general aren&#x27;t good choices for the types of systems discussed above. GC is also a problem on smaller hardware (embedded systems for instance) since there should be a much larger memory pool than actually used for good performance.<p>Haskell also throws in laziness, which leads to non-determinism.<p>Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system.