openEcommerce VS rustc_codegen_clr

I don't have something that could be of Crafting Interpreters level on hand, but the general suggestion given to this question on DotNetEvolution discord by Roslyn team members was to start with the spec itself: https://ecma-international.org/publications-and-standards/st...

This might be a bit of a learning curve if you don't have experience with writing compilers like that though.

There are other materials that might prove useful should you go down this path:

- A series of blog posts of a student who is writing a Rust to .NET compiler which you could follow along: https://fractalfir.github.io/generated_html/home.html The project itself: https://github.com/FractalFir/rustc_codegen_clr

- A video series on writing a compiler for .NET from scratch: https://www.youtube.com/watch?v=wgHIkdUQbp0&list=PLRAdsfhKI4... Notes: https://github.com/terrajobst/minsk/tree/master/docs

As for CLR via C#, while it has certain facts that remained the same, the ecosystem has changed a lot since then, you really want to target the latest LTS to get best experience and performance.

p.s.: if it's any consolation, the promise in CLR via C# of JIT having the advantage of dynamically profiling code execution and compiling to profile-guided version, tuned to the exact hardware and environment is finally fulfilled, many years later :)

The author answers the "why" in the FAQ https://github.com/FractalFir/rustc_codegen_clr?tab=readme-o.... I didn't find it very convincing but I'm sure the author will learn a lot of neat things along the way.

After adding support for statics and many bug fixes related to pointers/slices, my compiler backend targeting .NET can finally build a barely working version of the standard library. It can be loaded into the .NET runtime, allocate memory (e.g. for a Box, Vec or String), push elements to Vec's and String's (currently without relocations). There are also some other parts of the standard library that already work, but I want to stress that the project is still fairly early into development (I started working on it late August), and you should expect most things in std to not work at all. Things working is the exception, not the rule. This newest set of commits allows you to use a small subset of the standard library, within code running inside the .NET runtime. | Here is some Rust code that I wrote to demo the ability to use the Rust std within the .NET runtime:

This is a small update about my rustc backend, which is supposed to allow compilation of Rust code into .NET assemblies. This would allow you to use Rust crates in C#, and C# libraries in Rust.

I am currently working on a rust codegen targeting .NET. One of the features I currently work on is a .NET interop layer, mycorrhiza, and I am having some trouble modeling certain type constraints. There are 2 ways to store a reference to a GC type in Rust: 1. By a handle - this type has some cost associated with it, but can be stored anywhere (heap, stack). 2. By a raw reference - raw references may only live on the stack. They can be copied, and behave almost exactly like a normal rust type (with exceptions related to transmutes and enums), as long as they are stored on the stack.