C# 现在在 WASM 体积上胜过 Rust
一个新的实验性工具链声称,针对最小化的“hello world”式程序,它生成的 C# WebAssembly 二进制比 Rust 更小,这引发了人们对比较是否公平以及其中有多少后处理和运行时裁剪的审视。评论者指出,Rust 也可以针对体积进行高度优化,而 C# 目前又不能依赖正在出现的 WASM 垃圾回收器,因此任何体积优势都高度依赖具体工作负载和工具链,而非普遍优势。讨论随后扩展到:在重型浏览器应用之外,WASM 是否值得其复杂度,以及对 C# 的优势、生态缺口和长期相关性,与 Rust、Zig 和 TypeScript 等语言相比应如何看待。
基准测试的有效性与公平性
- 几位评论者认为“C# 胜过 Rust”这种表述具有误导性或不公平。
- C# 的 WASM 输出经过了高度体积优化,随后又会经过后处理(例如通过 Binaryen),而 Rust 的基线只做了相对温和的优化。
- 有人指出,Rust 还有一些众所周知的额外瘦身技巧(为体积重建 std、去掉格式化/位置数据、更激进的 abort 行为),但这些并未应用。
- 跨语言基准测试普遍被认为天生就很棘手,如果不是基于惯用的、真实世界的代码,往往会沦为标题党。
WASM 上的 C# vs Rust/Zig/C
- 展示出的结果(一个很小的 C# 程序约 46–47 KiB)被认为在技术上很令人印象深刻。
- 目前 C# 并不使用 Wasm GC;它带着自己的运行时和 GC,一些功能如反射并不可用。
- 讨论还提到了缺失或不完善的 WebAssembly GC 特性(弱引用、终结器、内部指针),以及 C# 如何绕过它们(例如
ref struct/Span<T>)。 - Rust 的 WASM 二进制通常被认为“很大”,但有评论称一个小的 Rust hello world 大约是 40 KiB,与 Zig(约 45 KiB)相近,而 C 仍然要小得多(约 4 KiB)。
WASM 的实际价值
- 一些开发者认为,除了重型、桌面级应用(例如 CAD、视频编辑)之外,WASM 在现实世界中的吸引力有限;他们更偏好服务端渲染加 JS。
- 另一些人强调 WASM 的优势:浏览器内隔离、可移植性、对可嵌入计算和“边缘”场景更好的容器化,不过它仍不被视为大多数应用的核心技术。
工具链、许可与 Blazor
- 这个新工具链独立于官方 .NET/Blazor 技术栈,面向生产用途,且载荷体积远小于当前的 Blazor WASM(通常超过 10 MB)。
- 有些人因为该工具链不是开源而持谨慎态度;他们担心未来的许可成本,并因此避免采用它。
对 C#(以及 F#)的更广泛看法
- 许多人称赞 C# 非常适合后端开发:工具链强大、特性现代、性能良好,与 Java 相比人体工学更佳。
- 批评包括:语言表面积大、与 Rust 相比设计上不够一致/可组合、与 Python 相比数值生态较弱,以及在 async/并行方面的复杂性。
- 有人认为同一运行时上的 F# 是一门更优雅的语言,但获得的投入相对较少。
- 讨论中还涉及 C# 的长期相关性,包括一种猜测:如果不明确指引,AI 工具可能会把新开发者默认带向其他技术栈。