[pjmlp]

Some corrections in regards to CLR.

The language that fully exposes its capabilities is C++/CLI and not C#.

In fact, most of the performance improvements since C# 7, have been how to surface those C++ capabilities into C#, while keeping the generated MSIL verifiable. C++/CLI is also able to generate unsafe MSIL sequences.

This is specially relevant since C++/CLI is Windows only, so one cannot just switch to it in cross platform .NET.

Secondly, .NET was also an excuse to reboot VB language, so some QuickBasic quirks were also thrown out, additionally, they have increasingly made VB less painful to migrate old VB 6 code.

Other than that, you are right, and this is also a reason why platform languages always have an edge over guest languages, even if they aren't as shiny in getting new language features out the door.

[chubot]

Hm very interesting! So what it sounds like is that CLR started out like a JVM-like VM, but now they're adding a WASM-like VM to it :)

That is, WASM is a much more natural target for C++/Rust than anything higher level. It can also express unsafe code when you consider the issues brought up in the paper, i.e. that it's unaware of heap integrity. Conversely, the JVM/CLR was traditionally better for Java/C# like languages and you couldn't run C/C++ naturally.

This makes sense as I've heard some of the more recent C# features are to recover performance, like value types, slicing, etc.

[pjmlp]

You got it wrong, CLR supports C++ since version 1.0, released in 2002, including the concept of safe and unsafe code.

It is WebAssembly that tends to be "sold" as if it was the first of its kind.

In fact even the CLR wasn't the first one, there were other bytecode formats for languages, like EM from Amsterdam Compiler Toolkit, IBM and Unisys mainframes/micros.

And around 2003, there was a Swedish startup trying to push a mobile OS that used a VM capable of J2ME, C and C++, the name I cannot longer remember, just some Sony-Ericson models used to have it.