> even Microsoft behaves as if it was C# Language Runtime, given some of the latest decisions on .NET features not exposed to VB, F# and C++/CLI. While the tra

> even Microsoft behaves as if it was C# Language Runtime, given some of the latest decisions on .NET features not exposed to VB, F# and C++/CLI. While the track record is not squeaky clean in this area, it is pretty much not true anymore and was already in a decent state for quite some time. Also, very late into .NET 8 development cycle there was a breaking change regarding ref readonly parameters, which was introduced without proper consideration of F# and caused a lot of trouble for F# team. I think after that the issue can be assumed to be fully addressed because there were changes made to ensure that F# and CIL level compatibility are considered much more comprehensively even in areas where it wasn't considered relevant in the past. It is less of a language problem and more of a popularity problem - Java just has so much more developers, so sibling languages even relatively niche ones will easily have the amount of developers and jobs necessary to clear the viability threshold. Personally, I do not think that all, especially low-level, aspects of the platform need to be uniformly available everywhere - something like ClojureCLR certainly doesn't need to concern itself with convenient syntax for byrefs. At the end of the day most features C# exposes that aren't syntactic sugar exist at CIL level meaning that anything can target them as they eventually become a part of ECMA spec. It would be great to see more guest languages as .NET is a target that can offer higher level LLVM bitcode like experience with way better performance assurances than OpenJDK or GraalVM Truffle, and because guest languages implemented today are way less likely to use un-analyzable reflection or reflection emit, it means zero effort is required to turn your CIL output into a native executable.