C# ahora supera a Rust en tamaño en WASM

Artículo original ↗ Discusión en Hacker News ↗

Una nueva toolchain experimental afirma producir binarios WebAssembly de C# más pequeños que los de Rust para un programa minimalista estilo “hello world”, lo que suscita escrutinio sobre lo justa que es la comparación y cuánto posprocesamiento y recorte del runtime interviene. Los comentaristas señalan que Rust también puede optimizarse mucho para tamaño, y que C# actualmente no puede apoyarse en el GC emergente de WASM, de modo que cualquier ventaja de tamaño depende mucho de la carga de trabajo y de la toolchain, más que de una ventaja general. El hilo se amplía a si WASM merece la complejidad fuera de apps pesadas en el navegador, y a una valoración más amplia de las fortalezas de C#, sus lagunas de ecosistema y su relevancia a largo plazo frente a lenguajes como Rust, Zig y TypeScript.

Validez y equidad del benchmark

  • Varios comentaristas consideran engañosa o injusta la formulación de “C# supera a Rust”.
  • La salida WASM de C# está muy optimizada en tamaño y luego se posprocesa (por ejemplo, mediante Binaryen), mientras que la base de Rust solo está optimizada de forma moderada.
  • Se señala que Rust tiene técnicas de reducción adicionales bien conocidas (recompilar std para tamaño, eliminar datos de formato/ubicación, comportamiento abortivo más agresivo) que no se aplicaron.
  • Los benchmarks entre lenguajes se consideran ampliamente intrínsecamente complicados y a menudo clickbait si no se basan en código idiomático y real del mundo real.

C# en WASM frente a Rust/Zig/C

  • El resultado mostrado (~46–47 KiB para un pequeño programa en C#) se considera técnicamente impresionante.
  • C# actualmente no usa Wasm GC; trae su propio runtime y GC, con algunas funciones como reflexión ausentes.
  • Se discuten las características faltantes o problemáticas de WebAssembly GC (weak refs, finalizers, interior pointers) y cómo C# las sortea (por ejemplo, ref struct/Span<T>).
  • Los binarios WASM de Rust suelen considerarse “grandes”, pero un comentario afirma que un pequeño hello world en Rust (40 KiB) es similar a Zig (45 KiB), con C aún mucho más pequeño (~4 KiB).

Valor práctico de WASM

  • Algunos desarrolladores ven poco atractivo real en WASM fuera de aplicaciones pesadas de clase escritorio (por ejemplo, CAD, edición de video); prefieren renderizado del lado del servidor más JS.
  • Otros enfatizan las fortalezas de WASM: aislamiento en el navegador, portabilidad, mejor contenerización para cómputo embebible y casos “edge”, aunque todavía no se considera central para la mayoría de las aplicaciones.

Toolchain, licencias y Blazor

  • La nueva toolchain es independiente del stack oficial de .NET/Blazor y apunta a uso en producción con cargas útiles mucho más pequeñas que el Blazor WASM actual (a menudo >10 MB).
  • Algunos desconfían porque la toolchain no es de código abierto; les preocupan futuros costes de licencia y evitan adoptarla por ese motivo.

Visiones sobre C# (y F#) en general

  • Muchos elogian C# para trabajo de backend: tooling sólido, características modernas, buen rendimiento y buena ergonomía frente a Java.
  • Las críticas incluyen: gran superficie del lenguaje, diseño inconsistente o menos componible frente a Rust, ecosistema numérico más débil que Python y complejidad en torno a async/paralelismo.
  • Algunos sugieren que F# ofrece un lenguaje aún más agradable sobre el mismo runtime, aunque recibe comparativamente poca inversión.
  • Hay debate sobre la relevancia a largo plazo de C#, incluida la especulación de que las herramientas de IA podrían orientar a nuevos desarrolladores hacia otros stacks salvo que se les indique explícitamente lo contrario.