You can get much smaller native binaries with .NET's NativeAOT nowadays: https://github.com/MichalStrehovsky/sizegame
Funnily enough, I'm using C# to solve quite a similar type of tasks. It's a really pleasant experience.
Funnily enough, I'm using C# to solve quite a similar type of tasks. It's a really pleasant experience.
Not counting having to learn about IL trimming, and the whole AOT compatible libraries.
It's a very straightforward process - you pass a single flag, maybe specify optimization preference and instruction set target, and it gives you the binary upon 'dotnet publish'ing the project.
The process of static linking (if you care about this scenario), with other static dependencies written in C/C++/Rust is not too different from other toolchains - you specify `DirectPInvoke` and `NativeLibrary` properties in .csproj, and they are linked into the final product as a part of the build process. You may need to forward linker arguments[0] for the imports referenced by those however, but this is expected regardless of .NET.
I think it's fair to criticize the additional compatibility effort required for high-level user libraries that rely on un-analyzable reflection, reflection emit or assembly loading, but none of these features usually have any relevance in the domain of systems programming.
When you write a project from scratch, you never have to think about whether it's native compilation or "JIT+CIL assemblies sandwich" executable, or anything else. It just works.
For example https://github.com/codr7/sharpl - the author was pretty much learning C# on the go and it needed exactly 0 changes besides adding `PublishAot` property to make it output a native executable.
[0]: https://github.com/U8String/U8String/blob/main/Examples/Inte...
However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary".
Which is the experience I think the team should strive on as goal, especially for newcomers.
More so when comparing IDE experience of something like Delphi or Swift to keep it in context (press build), versus Visual Studio (besides csproj, create publish properties file, followed by a solution publish, which is hardly documented still).
But...it works in this exact way?
dotnet publish -o folder -p:PublishAot=true
On Visual Studio, I have started to recommend to newcomers to avoid its publishing UI which is convoluted and is easy to get side-tracked with. CLI offers much cleaner UX. Not that it matters outside of Windows. But you don't need to create publish file either, just tick the boxes you care about in the modal window.
Edit: you can't be serious, no one in their sane mind would consider a single extra keyword to get the final product once you're done writing code a learning curve too steep, unless you're in a bad mood and want to make a bad faith argument. Consider what you make the comparison against - C and C++ with their CMake, Ninja, or even raw MSBuild, Swift is barely better too. Rust with Cargo is about the same amount of effort as .NET CLI. Cmon, Pjmlp.
CLI only isn't the answer, if you want better adoption.
This is an older mechanism that works differently to NativeAOT, it's also used by host-installed runtime to improve startup latency, and you can do your own R2R, either full or granular, to further improve this: https://learn.microsoft.com/en-us/dotnet/core/deploying/read... It can slow down the build quite a bit from what I've seen.
NativeAOT is different - when you use it, ILLink (which previously was the Mono Linker and now has evolved) trims all unreachable and links together all of the remaining CIL bytecode and metadata from the CIL assemblies that the application/library consists of. After that, ILC (IL AOT Compiler) compiles everything (and performs AOT-specific optimizations) into a single static bundle emitted as COFF or PE (or Mach-O?) file containing machine code. Then the toolchain invokes a host-provided linker which produces the final native executable or library, much like it happens with C, C++ or Rust. It even has the OS-specific symbol format, so you can feed it to the same tools that work with native code.
Technically speaking, .NET's compiler still retains the name "RyuJIT", but in practice it's not JIT-specific and ILC drives the same back-end as JIT compilation at runtime, but with different optimizations and options.
This is a new feature that was introduced in .NET 7, and has substantially improved further in 8 and upcoming 9. Completely different output aside, NAOT builds take less time than the ones that have R2R from my experience.
Your mileage may vary depending on how big the application is, how complex linking it requires and how much the native code to compile there is.
The main difference with Rust is that compilation time whether it's good or bad has much less relevance because for development you can use JIT (both debug and release, i.e. plain 'dotnet run') or even hot-reload which can recompile actively running code without restarting the application with 'dotnet watch' which works surprisingly well.
We get to enjoy both worlds, and picking the best deployment options as per scenario.
Rust development experience would be much better if they adopted a similar approach, which by the way, is common on other ML inspired languages.