An experimental project called NetWasm says its C# toolchain produced a smaller standalone WebAssembly component than Rust for a tightly defined test, highlighting how much runtime design and build configuration can influence binary size. The project reports a 47,895-byte output for NetWasm, compared with 53,635 bytes for Rust 1.95.0.
Both artifacts performed the same print-42 task and targeted WASI Preview 2 components. NetWasm’s output included its runtime and a precise garbage collector. The Rust build used documented size-focused settings, including size optimization, link-time optimization, a single code-generation unit, aborted panics and stripped symbols. On those terms, the NetWasm artifact was reported as 10.7% smaller before compression and 19.5% smaller with Brotli at level 11.
The repository explicitly limits the conclusion. This is a result for one workload and profile, not proof that C# generally creates smaller WebAssembly programs than Rust. More aggressive alternatives could shrink both sides while changing their capabilities: Rust can use no_std, while C# can be paired with a minimal library that omits much of the standard library and garbage collection. The comparison instead focuses on ordinary supported builds with their selected runtime boundaries.
NetWasm takes a different approach from carrying desktop .NET or Mono into a browser or WASI environment. Roslyn first produces Common Intermediate Language, after which NetWasm compiles reachable code to WebAssembly, specializes generics and links only required runtime support. Its normal output is a self-contained .NET program, although it still needs a compatible WebAssembly host such as Wasmtime to run.
The toolchain also integrates Binaryen’s wasm-opt into its standard compiler pipeline. The project notes that applying the same tool directly to Rust’s WASI Preview 2 component would require extracting its core module and then rebuilding the component, so that additional manual procedure was not included in the comparison. NetWasm’s figure came from its default release publication flow.
NetWasm remains pre-1.0 and supports a deliberately narrower profile than desktop .NET. Its repository lists important exclusions, including managed threading, runtime assembly loading, dynamic features and several general operating-system APIs. Existing NuGet packages work only when the code they actually reach fits that supported surface. Interfaces and compatibility may also change between minor releases.
The benchmark is therefore best read as a demonstration of a design choice rather than a verdict on two languages. It shows that C# can reach native-WebAssembly-sized output when a compiler uses a compact runtime, selective linking and an intentionally constrained platform. Whether that advantage persists depends on the application, required APIs, optimization rules and the compromises developers are prepared to accept.
