[gwbas1c]

Targeting the JVM (or the CLR) requires that your language work nicely in the Java (or C#) memory model.

This basically means your language needs to work nicely with stop the world garbage collection.

(And yes, I know that modern garbage collectors aren't really stop the world, but the tradeoffs are still there.)

[pjmlp]

CLR was designed for multi-language since the beginning.

Go dig one of those .NET 1.0 SDK release CDs from 2002, plenty of sample languages on it.

[gwbas1c]

I know that.

The problem is that the CLR comes with the the C# memory model and garbage collection.

If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection.

That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an airplane.

If you want to use the CLR for a real-time application, you basically have to replace most of the .Net API with a completely pointer-based version, and consider implementing your own real-time memory management model.

At that point, you might as well target your language to compile natively and use standard libraries in the operating system.

[pjmlp]

The CLR was designed to support C and C++ as well, apparently new generations don't have a proper clue what CLR is all about.

Also contrary to WASM, there are real hardware devices actually shipping stripped down versions of it.

And if real time is a concern, then not using a real time OS is already the big first mistake, there is nothing here for WASM to prove, only to catch up with existing battle tested solutions.