[paride5745]

Exactly this point.

Go and Rust produce native binaries, I wish C# had an official native compiler without the big runtime needs of .Net.

[cachius]

You might want to read https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

[skeeter2020]

There are quite a few gotchas for this, especially web apps. THis is understandable because it was added after the fact, vs. a first-party design requirement. It's cool and might work for you, but taking a non-trivial .net codebase to native AOT can be tough, and if you're starting greenfield, why go .net?

[parliament32]

And this sounds great until you get to the laundry list of restrictions. For us the showstopper was you can't use reflection.

[4rt]

They're self contained and native, but they're still massive.

There's been some work on CoreRT and a general thrust to remove all dependencies on any reflection (so that all metadata can be stripped) and to get tree-shaking working (e.g. in Blazor WASM).

It seems like in general they're going in this direction.

[midnitewarrior]

Not every library is capable of building to Native AOT, which means any app that depends on those libraries run into the same problem. If the library or app uses reflection, it likely isn't capable of Native AOT compilation.

[Salgat]

Just an FYI, Go still bundles a runtime in its native binaries. C#'s AOT has restrictions on what works (largely reflection), but these same restrictions apply to Go (although Go applies these restrictions into how it's designed for the entire thing).

[synergy20]

rust and go are only good at single binary. when you need a few their size adds up quickly, because they don't really do shared libs.