Memory safety approaches multiply as WebAssembly stalls
Two threads ran in parallel today: one on Fil-C, a memory safety approach for C that aims to retrofit safety without rewriting, and one on GC and exception handling in Wasmtime, the WebAssembly runtime. The Fil-C thread included a running list of prior Fil-C HN posts in CPS style, signaling that this project has become a recurring topic. Critics in the thread argued the syscall safety guarantee has holes, and the author pushed back.
The Wasmtime thread surfaced a blunt take that WebAssembly has had ten years and still hasn't achieved the ecosystem influence of HTML, CSS, or JavaScript. The comment is harsh but the underlying observation is real: Wasm adoption outside of browser plugins and a few specific server-side niches has been slower than early boosters predicted.
The pattern connecting these threads: there is no consensus memory safety solution. Rust is winning in some domains, Wasm was supposed to win in others, Fil-C is trying to retrofit safety onto existing C, and none of these is the obvious default. Founders and platform teams are choosing between genuinely different tradeoffs, not picking from a settled menu.
So what?
If you're making a language or runtime choice for a new systems project, the lack of a clear winner means the decision is still a real one with meaningful long-term consequences. Wasm's slower-than-expected adoption is a signal that 'runs everywhere safely' is harder to ship than to spec. Rust remains the highest-confidence choice for new memory-safe systems code, but the ecosystem cost is real.