duckscript VS rustc_codegen_clr

Currently i'm using it in cargo-make but will also use it later to parse args for duckscript commands.

At it's most basic you could make a really simple interpreter by just doing such a thing, and there is essentially already such a simple language like that built for/in rust called Duckscript (rust has a surprisingly large number of little embedded languages), and that would be completely and entirely sufficient for many purposes, though if you want speed then you'll need to JIT or AOT the code, which is why wasm is so handy as you can interpret or JIT (or even AOT it with wasmer) without the much larger overhead of a, for example, javascript or java embedded runtime.

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.