Tangentially related, I've written a barebones assembler for Android .apk files once (strictly speaking, the assembler is for .dex files, but it also comes with a set of tools to package and sign .apk files). It showed up to be surprisingly easy. I expected to stumble upon some blocker issue any time that would make it impossible for me to continue — but one just never materialized! It's written mainly in Nim and provides enough primitives to allow creating Java "stubs" for native .so libraries, so that .apk-s can be built in Nim WITHOUT JDK AT ALL. The Android NDK is still kinda needed/useful, though IIRC mainly for access to <i>adb</i>, and especially <i>adb logcat</i> (which you'll need A LOT for debugging if you try to use this contraption).<p>I'd love to One Day™ <i>Rewrite It In Rust</i>, so that we could write .apk-s purely using the Rust toolchain, just using a JNI library as appropriate, sprinkling the code with some proc-macro annotations where needed by the assembler (for stubs), and possibly adding some lines in a <i>build.rs</i> (for .apk packaging).<p>The .dex assembler itself is at: <a href="https://github.com/akavel/dali">https://github.com/akavel/dali</a> — you may like to check out the tests at: <a href="https://github.com/akavel/dali/tree/master/tests">https://github.com/akavel/dali/tree/master/tests</a> to see how using it looks like.<p>An example project with a simple .apk written purely in Nim (NO JDK) is at: <a href="https://github.com/akavel/hellomello/tree/flappy">https://github.com/akavel/hellomello/tree/flappy</a> (unfortunately, given Nim's poor packaging story, it's most probably already bitrotten to the extent that it can't be quickly and easily built & used out of the box). I recorded a presentation about this for an online Nim conference — see: <a href="https://www.youtube.com/watch?v=wr9X5NCwPlI&list=PLxLdEZg8DRwTIEzUpfaIcBqhsj09mLWHx&index=11&t=0s">https://www.youtube.com/watch?v=wr9X5NCwPlI&list=PLxLdEZg8DR...</a>
Article is a little wrong about the current state-of-the-art in writing Rust bindings for .NET.<p>One can use Uniffi with the C# generator to get fairly automatic bindings. You still need to package it up, which is a bit of a pain.<p>Uniffi really is an awesome idea. I expect more and more Rust code for foundational shared libraries as a result.
Looks like the OP is still in high school.
Kudos to them for pushing through, and having fun with compiler internals.<p>I wish I had this level of dedication at that age...
If one was to do this as something other than a "fun project", wouldn't it make more sense to do a CIL backend for LLVM? That way any language utilizing LLVM would get be able to target .NET, or am I completely misunderstanding how rustc and LLVM works?
I wonder if it could run on this Rust implementation of the CLR I wrote a few years ago: <a href="https://github.com/Leowbattle/clr_lite">https://github.com/Leowbattle/clr_lite</a>
Cool project. I remember someone else taking a crack at this a few years ago.<p><a href="https://ericsink.com/entries/dotnet_rust.html" rel="nofollow noreferrer">https://ericsink.com/entries/dotnet_rust.html</a><p><a href="https://ericsink.com/entries/sg_rust_dotnet_preview.html" rel="nofollow noreferrer">https://ericsink.com/entries/sg_rust_dotnet_preview.html</a><p><a href="https://ericsink.com/entries/lousygrep.html" rel="nofollow noreferrer">https://ericsink.com/entries/lousygrep.html</a>
If it’s any consolation, Microsoft itself has shipped production assemblies generated with bad IL (for the auto-generated bindings/interop between the Windows 10 SDKs and C#)! Code appeared fine and would run OK until you tried to either R2R or AOT a project depending on that DLL (and it was just a single entry point that was mangled, iirc).
Beware, the rustification has broken thru .net defenses :)
Not sure if I ever find use for Rust in .net runtime (C# has more or less same capabilities), but congrats anyway. However I'd gladly welcome some lightweight compiled language with easy and powerful meta-programming and AST transformation capabilities.
I thougth to myself that surely there would be a CIL backend for LLVM, and why didn't the author just use it? But amazingly there doesn't seem to be.
From the linked GitHub repo:<p>> As for the heap allocated objects, they will be allocated from unmanged(non-GC) memory, and will be allocated/freed exactly like in Rust.<p>I understand this decision, but it would also be interesting to see a version of this that hijacks the global allocator and the alloc types to use the GC instead (while still allowing you to opt-out and use unmanaged memory).<p>Good work nonetheless!