FYI this hasn’t been the case with C# for a very long time now.

.NET has been able to build a self contained single file executable for both the JIT and AOT target for a quite some time. Java also does not require the user to install a runtime. JLink and JPackage have both been around for a long time.

Maybe some other runtimes do this or it has been changed, but in the past self-contained singe-file .NET deployment just meant that it rolled all the files up during publishing and when you run it, it extracted them to a folder. Not really like a single statically linked executable.

It hasn't done that in years.

You can indeed produce a compiled native executable with minimal bloat: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

C# AOT filesizes are huge compared to Go.

Do you have data backing that up? Per https://github.com/MichalStrehovsky/sizegame:

C#: 945 kB Go: 2174 kB

Both are EXEs you just copy to the machine, no separate runtime needed, talks directly to the OS.

Sadly yes, we have data. We are migrating our C# SDK to Rust in part because customers want a much smaller dependency. And the AoT compiler didn't trimmed as much as we wanted.

(regarding size - there are tools like sizoscope to understand what is taking space, sometimes it’s something silly like rooting a lot of metadata with reflection referencing many assemblies or because of abusing generic virtual members with struct parameters in serialization, obviously if you can use Rust without productivity loss it’s fine, but usually problems like that take an hour or two to solve, or less)

But in either case binary sizes are smaller and more scalable than what Go produces. The assumption that Go is good at compact binaries just does not replicate in reality. Obviously it’s nice to be able not touch it at all and opting into Rust for distributing native SDKs. Go is completely unfit for this as it has even more invasive VM interaction when you use it as dynamically linked library. NativeAOT is “just ok” at this and Go is “way more underwhelming than you think”.

I think we would have preferred continuing with .NET, as no one is Rust expert on the team. But binary size and lack of some SIMD instructions moved the balance to Rust. And then, the PoC had big memory usage improvements, so...

What kind of SIMD instructions were not available? I assume something like AVX512GFNI or SHA x86 intrinsics?

I think if you're in domain of using SIMD, besides base RAM usage of 2-5MB you should not see drastic difference unless you have a lot of allocation traffic. But I guess Rust solved most of this, just wanted to note that specific memory and deployment requirements are usually solvable by changing build and GC settings.

Yes, but they may not always work. While generally true there are still some edge cases.

SQL Server connections are one example where I do get .exe with the .pdb in the publish directory but the .exe won't run correctly without the "Microsoft.Data.SqlClient.SNI.dll" file.

Another example are any libraries that have "RequiresDynamicCodeAttribute" requirements.