Will continuous feature-enabling truly remain a continuous issue?

[workingjubilee]

I am not sure what the goal is here for wasm32 targets as to what they should be expected to support. The decision in #158 proposes this is a continuous issue, but people often use Web technologies because they are... relatively stable. In practice, code that is recompiled to a new featureset will tend to break tools that interoperate with it unless those tools are expecting the new output. New flags that enable compatibility with these new features are somewhat useless to the actual compiler user if those flags are passed inside a wrapper tool and the wrapper tool stops passing new flags (due to e.g. not being updated as-recently). One can argue those wrapper tools are poorly designed, but people often use them because they are not compiler engineers who have all the extension features for (sometimes several) instruction set architectures floating around in their head, so they enjoy using something that "just works" because it precalculates the needed features or whatnot.

And sometimes I have to furrow my brow and squint a bit to remember what features are what, too.

I do think things like lime1 will relieve the pressure quite a bit, but is there an intended "endgame" here? It may help in making it clear, if that "endgame" is obviously years off, that people who buy the ticket are in for quite a ride. I don't really mind communicating to people that they need to prepare for excitement if they build on certain wasm32 targets, especially if they choose to not build on things like e.g. wasm32lime1, but it does feel slightly wrong to just say "well, wasm32 is just going to change forever". That can't be the case, can it?

This goal can be quite vaguely stated, I think, as I'm definitely not looking for a hard, promised direction or timeframe. I'm guessing it's something like "wasm32 as a target platform will continue to evolve until it can support a full ecosystem that is functionally a peer to JS (on the Web) and C (on the server) alike, which means it must develop, at minimum, things like GC integration and multithreading powers, but may extend to varied and diverse capabilities that are seen as needed, as they arise, and these can be expected to be implicitly enabled in targets"?

[tlively]

WebAssembly's backward compatibility guarantees generally mean that old modules run on new engines. You can read about the specifics here: WebAssembly/spec#1900. They do not guarantee that new modules can run on old engines (or be processed by old tools) because that would imply that we would not be adding new features to the language.

So will we ever stop adding new features to the language? Probably, but it's hard to predict what time scale that might be on. There's certainly no grand plan with a defined end point. The nature of how WebAssembly is developed, with anyone able to propose new features and drive consensus to include them in the spec, means that new features will continue to be proposed as long as there is some economic incentive to propose them. Whether such an incentive exists also changes over time as WebAssembly's users and their needs change. So there's really no way to say with any confidence that "once condition X is met, WebAssembly will stop getting new features."

Whether e.g. the Wasm targets in LLVM/clang/Rust will ever be feature-complete is a similar but slightly different question because not all new WebAssembly features make sense to support in LLVM. It's possible that the subset of WebAssembly targeted by LLVM will stop getting new features long before WebAssembly as a whole stops getting new features. Personally, I doubt this will be the case because it seems that there is a long tail of potential WebAssembly features along the lines of SIMD or wide-arithmetic that bring low-level compute performance closer to native architectures, and these features are certainly in-scope to be targeted by LLVM. Certainly the rate of new additions will be lower for linear memory WebAssembly than for WebAssembly as a whole, though.

Ultimately the end state for WebAssembly targeted by LLVM is unknowable for the same reasons an end state for WebAssembly as a whole is unknowable.

[rossberg]

Also, C and let alone JS aren't particularly relevant for parity. You rather want to look at CPU architectures. They keep adding new features and instructions even after 50 years, so there is no reason to expect otherwise for Wasm.

And of course, despite the name, Wasm no longer just is a web technology. :)