This is really neat, I always wanted to see other languages target .NET much like the JVM was a popular platform to target. Considering .NET is fully MIT licensed I am surprised we dont see more languages that target .NET
That is why CLR used to mean Common Language Runtime, and there were so many languages on the launch event and .NET SDK bundled on computer magazines back in 2001.
Then the Windows only focus (for a while there was Rotor), and Microsoft being Microsoft, all that interest faded away and people focused on the JVM, even though MSIL was designed for all kind of languages (well dynamic came later with Iron languages and DLR), including C and C++.
Nowadays CLR almost feels to have changed into C# Language Runtime, given the C# centric decision on modern .NET design.
While "C# Language Runtime" as a joke term certainly exists, most runtime improvements benefit all languages that target it, individual changes would have different impact on different languages but that's expected. It is likely further devirt and escape analysis work will have greater impact on F# for example.
Before Rich made Clojure for the JVM, he wrote dotLisp[1] for the CLR. Not long after Clojure was JVM hosted, it was also CLR hosted[2]. One of my first experiences with ML was F#[3], a ML variant that targets the CLR. These all predate the MIT licensed .net, but prior to that there was mono, which was also MIT licensed.
1: https://dotlisp.sourceforge.net/dotlisp.htm
Microsoft didn’t manage to have Visual Basic target .NET without turning its semantics into C# with different syntax, so this will be interesting to see.
Historical precedent and anti-.NET bias - CLI/CIL is a much more powerful and flexible bytecode target than JVM, but it is also not as well-documented with fewer guest languages and, as a result, community know-how. With that said, it really is a breath of fresh air to see projects like this one, alongside ongoing work on F#, the main "other" language of .NET, and a couple small toy-like languages like Draco. There are also IKVM and ClojureCLR/ClojureCLR.Next.
In the past I have worked on Solidity -> Rust compiler, to enable Solidity on WASM VMs. My pain point was emulation of C3 inheritence in Rust, which I actually was able to implement with a few macros. In Rust -> .NET I'm interested in how he does the `DerefMut` trait.
From the repo[0]:
> The project aims to provide a way to easily use Rust libraries in .NET. It comes with a Rust/.NET interop layer, which allows you to easily interact with .NET code from Rust
.net considers the rust code "unsafe" so you can do unmanaged, non-GC stuff in the Rust portion of the code.
In theory, the compiler could do the same as C++/CLI, and output safe Assemblies when specific code patterns aren't used.
AFAIK, the IJW bits of the CLR are exclusive to Windows.
And strongly in a "do not use unless you must" category too.
You can already do that from .NET itself.
My question here is more along the lines of: "what Rust libs are out there that I might be interested in from .NET?"
What I think you missed in that statement is that the code is technically still Rust safe, so in theory it wouldn't just be unsafe .NET Code, it would be Rust safe code that happens to run on .NET with a speed up since its less managed. It's kind of genius, if I'm not misunderstanding.
The concept of "verifiable code" is effectively dead - even C#'s own syntax is sometimes desugared into what one could consider "unsafe" code in terms of feature use. Unsafe code is safe when used correctly, it does not imply the reliance on undefined or implementation-defined behavior :)
For all intents and purposes, the non-unsafe subset of Rust is a safe language, and the distinction pretty much does not exist at the IL level.
Another LLVM-to-.NET project: https://ericsink.com/tocs/rust.html
> I also plan to explain the difficulties with Rust code catching arbitrary .NET exceptions
Really looking forward to this one.