The runtime alone is a bit over 200mb, and that doesn't include additional packages you'll most likely need.

That being said, I'd much prefer to deploy a C# application over Node or Java, no argument there. But saying "I wish more startups were using C#" makes me wince. C# seems well-suited for the monolith-architected VM-image-deployed strategy of the early 2000s, but it's pretty close to being the exact opposite of modern best practices. And unfortunately it's kinda unfixable in a language that depends on a VM execution environment.

I'm sure all this is short-lived however -- I'm relatively confident we'll see deployment best practices converge down to "use whatever language you want but you must compile to WASM" in the next decade, so the warts of devs' chosen language aren't an ops problem anymore.

C#/dotNet has Ahead of Time compilation that works very well with containerization. Obviously there are still overheads for the AoT runtime, but it is pruned.

AOT would solve a lot of these problems if it didn't have show-stopping restrictions like "you can't use reflection" and "you can't use native sessions".

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/n...

Reflection doesn't work with AOT because there is nothing left to reflect on... it's compiled away. You can't use reflection with C, C++ or Rust either, doesn't mean you can't use them for useful things.

But the runtime is in the base image, so that is shared across all deployed services on the a single host system(s). So it's much less of an issue, also, the entire runtime isn't loaded into RAM for every application. From Task manager in windows, I'm running a local app in debug/dev mode and it's taking 226mb ram, which is a lot compared to IIRC well under 20mb for the last rust-axum project I wrote.

That said, you get a lot of functionality in the box and nearby out of that extra resource usage and it doesn't really grow by much under load.

Beyond that, there's nothing particularly wrong about having a mostly monolithic backend for a lot of things, I would say most applications are better served starting with a more monolithic backend in a mono-repo with the FE.