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.

https://github.com/FractalFir/rustc_codegen_clr - from a quick glance at it, with 1.8k stars and 17 contributors, it deserves a better treatment than a passive—aggressive dismissal like this as a top comment.

It is a very impressive piece of work.

> Cue rust devotees in 3, 2, ..

If you are a rust devotee, you can use https://github.com/FractalFir/rustc_codegen_clr to compile your rust code to the .NET runtime. The project is still in the works but support is said to be about 95% complete.

We now have https://github.com/FractalFir/rustc_codegen_clr . So we can keep all our Rust files out-of-tree and just submit C code like everyone else.

I'm impressed by this individual's effort to bring rust to the clr: https://github.com/FractalFir/rustc_codegen_clr

It is already way more complete given it's age than I would have expected.

I agree that the clr is a more natural target than, let's say, the JVM (at least until Project Valhalla comes out).

No, it is not.

The comparison we discussed was for unrepresentative code that used none of the features that make .NET fast (especially generics, SIMD and devirtualization). The closest case in there was JSON serialization. It is unfortunate that you feel a need to say this, knowing that it doesn't even show a tip of the iceberg.

Please do not mislead casual readers here with such comments.

They will have a bad time running basic programs - the original Mono is outdated and cannot execute assemblies that target non-legacy versions, and the Mono that lives in dotnet/runtime (which you have to go out of your way to use on CoreCLR platforms) tends to have all kinds of regressions on user-provided code that is not as robust on runtime checks to ensure that Mono does not accidentally go onto the path that that it has especially bad regression on. Even CoreLib code nowadays uses more and more struct generics assuming monomorhpization which performs poorly on Mono. There is very little work done to improve performance on Mono with effort invested mostly in WASM area and to ensure it does not regress further. Major platforms like Android and iOS are in the slow but steady progress to migrate to CoreCLR/NativeAOT (there are other reasons not in the least much smaller binary size). And for WASM there is NativeAOT-LLVM experiment that is likely to make Mono obsolete for that target too.

The workloads that matter and are representative are the ones produced by C#, F# and VB.NET compilers as well as projects that care about exercising the standard library and/or produce recommended CIL forms (like https://github.com/FractalFir/rustc_codegen_clr).

For clarity, that portion after the : is the blog post title, the prefix was added to the submission, so they're kind of disjoint

One will also want to temper their expectations per https://github.com/FractalFir/rustc_codegen_clr#current-stat... (MIT & Apache 2)

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.