NetWasm's C# Hello World Is 47,895 Bytes, 10.7% Under Rust's Size-Tuned Build, by Its Author's Own Count

NetWasm, a pre-1.0 compiler that turns C# into WebAssembly components, says a program that prints 42 comes out at 47,895 bytes, against 53,635 bytes for Rust 1.95.0 with size flags set. The repository's README calls that "10.7% smaller raw" and 19.5% smaller after Brotli-11 compression. Every number comes from the project's own repository and was measured by its author.

The repo sits under the zion-sati GitHub account and shows 212 stars, 6 forks, 6 open issues and 257 commits. It drew 141 points on Hacker News on Oct. 21 under the headline "C# now beats Rust on WASM size." The README does not make that claim in those words.

What was measured

The workload is one line: Console.WriteLine(42) in C#, println!("{}", 42) in Rust. Both were built as WASI Preview 2 components and run under Wasmtime on macOS arm64, using NetWasm 0.10.0 from NuGet and Wasmtime 49.0.3 for the C# side. Wasmtime shipped v50.0.0 on Oct. 20, so the tested host is one major release behind.

The methodology page lists each build. The 47,895-byte figure is the template app's default Release publish with the compact garbage collector bundled in.

1. NetWasm 0.10.0, Compact GC48K bytes
2. Rust 1.95.0, size profile54K bytes
3. Kotlin 2.4.0 wasmWasi (Preview 1)79K bytes
4. Rust 1.95.0, ordinary release82K bytes
5. TinyGo 0.39.0 (Preview 1)93K bytes

Source: NetWasm repository size-and-methodology.md, author's own measurements, accessed 2026-10-21

Kotlin and TinyGo are included only for context, and both output Preview 1 core modules rather than Preview 2 components. They are not like-for-like with the top two rows.

The Rust side is tuned, the C# side is not

The Rust figure of 53,635 bytes uses opt-level = "z", link-time optimisation, one codegen unit, panic = "abort" and stripped symbols. An ordinary cargo build --release produces 81,997 bytes with the same compiler.

NetWasm runs Binaryen's wasm-opt as a standard step. For Rust components the README says wasm-opt would have to be applied by hand, which the published Rust figure does not include.

There is a second mismatch the author spells out. NetWasm's 47,895 bytes include a bundled tracing garbage collector. This Rust workload has none. The page says the result is "a measured workload/profile result, not a language-wide size ranking."

What the C# build leaves out

The size is possible because the output drops most of what .NET normally carries. The README says it does not bring the desktop CLR, Mono, dotnet.js or application DLLs into production. Reflection-heavy features are out of scope: runtime type names, dynamic, runtime assembly loading and managed threading.

General System.IO.File, Directory and FileStream, raw sockets and subprocess APIs are not implemented yet. Existing NuGet packages work only where the code they reach fits the supported profile.

For scale, the same page measures a Blazor WebAssembly AOT app that prints 42 on .NET 10.0.401 at 12,276,684 bytes of loaded Wasm across 32 files. That is about 256 times the NetWasm component, and the page states it covers Mono AOT, not CoreCLR Native AOT.

Licence terms

The split matters to anyone planning to ship it. CoreLib, runtime libraries and templates are MIT, and the garbage collectors are Apache-2.0. The compiler and tooling use the NetWasm Community License 1.0.

Use	Terms
Individuals, education, open-source work, evaluation	Free
Organisations under 250 employees and USD 10,000,000 annual revenue	Free
OEM and commercial offerings	Separate agreement

The README gives zion.sati@netwasm.com as the commercial contact and does not otherwise describe the author or any company behind it.

What was not measured

The page says these are footprint tests, not allocation stress tests or benchmarks. Startup time, memory use and speed were not measured, so nothing here says the C# component runs faster or leaner than the Rust one.

Renaming the assembly can change the output bytes, which is why the page pins the name NetWasmApp for exact reproduction. Wasm64 components are blocked by upstream tooling.

The page does check one outside figure: it reproduces a Rust 1.90.0 Hello World from a RIoT Secure article of October 2025 at 86,269 bytes against the 86,254 that article reported. It says that confirms scale, not the exact count. On the Rust side, Cloudflare's tsrs coverage and the Rust compiler roadmap show how much of the language's tooling is still moving.