C# now beats Rust on WASM size

Original Article ↗ Hacker News Discussion ↗

A new experimental toolchain claims to produce C# WebAssembly binaries smaller than Rust’s for a minimal “hello world”-style program, prompting scrutiny of how fair the comparison is and how much post-processing and runtime stripping is involved. Commenters note that Rust can also be heavily optimized for size, and that C# currently cannot rely on the emerging WASM garbage collector, so any size win is highly workload- and tooling-dependent rather than a blanket advantage. The thread broadens into whether WASM is worth the complexity outside heavyweight in-browser apps, and into a wider appraisal of C#’s strengths, ecosystem gaps, and long‑term relevance compared with languages like Rust, Zig, and TypeScript.

Benchmark validity and fairness

  • Several commenters call the “C# beats Rust” framing misleading or unfair.
  • The C# WASM output is highly size-optimized and then post-processed (e.g., via Binaryen), while the Rust baseline is only modestly optimized.
  • People note that Rust has well-known additional shrinking techniques (rebuilding std for size, stripping formatting/location data, more aggressive abort behavior) that weren’t applied.
  • Cross-language benchmarks are widely viewed as inherently tricky and often clickbait if not based on idiomatic, real-world code.

C# on WASM vs Rust/Zig/C

  • The showcased result (~46–47 KiB for a tiny C# program) is seen as technically impressive.
  • C# currently doesn’t use Wasm GC; it brings its own runtime and GC, with some features like reflection missing.
  • Discussion of missing/messy WebAssembly GC features (weak refs, finalizers, interior pointers) and how C# works around them (e.g., ref struct/Span<T>).
  • Rust WASM binaries are often considered “large,” but one comment claims a small Rust hello world (40 KiB) similar to Zig (45 KiB), with C still much smaller (~4 KiB).

WASM’s practical value

  • Some developers see little real-world appeal for WASM outside heavy, desktop-class apps (e.g., CAD, video editing); they prefer server-side rendering plus JS.
  • Others emphasize WASM’s strengths: in-browser isolation, portability, better containerization for embeddable compute and “edge” cases, though it’s still not seen as core for most apps.

Toolchain, licensing, and Blazor

  • The new toolchain is separate from the official .NET/Blazor stack and targets production use with much smaller payloads than current Blazor WASM (often >10 MB).
  • Some are wary because the toolchain is not open source; they worry about future licensing costs and avoid adopting it on that basis.

Views on C# (and F#) more broadly

  • Many praise C# for backend work: strong tooling, modern features, good performance, and good ergonomics compared to Java.
  • Critiques include: large language surface, inconsistent/less composable design vs Rust, weaker numerical ecosystem vs Python, and complexity around async/parallelism.
  • Some suggest F# offers an even nicer language on the same runtime, though it receives comparatively little investment.
  • There is debate about C#’s long-term relevance, including speculation that AI tools may default new developers to other stacks unless explicitly directed.