2 ms·
> WebAssembly sits at the crux of directly opposing forces [...] No amount of hard work is going to magically fix these because they are directly opposed. I'm
by kodablah 8y ago
> WebAssembly sits at the crux of directly opposing forces [...] No amount of hard work is going to magically fix these because they are directly opposed.
I'm not sure they are directly opposed. I think that they can coexist reasonably. Specifically, keep the instruction set reasonably minimal, ask compilers to do the optimization while trying to avoid impedance mismatch between the insn set and CPU archs, add the rare high-level feature that is hard to implement without exposing lots of context (e.g. GC), don't act like features not used 100% of the time are "deadweight", and leave complications like strings to libraries/ecosystem. I.e. WASM abstracts the host and CPU, libraries abstract the logic on top.
I think, looking at the proposals, they are doing a good job with the tradeoffs. For all of your bullet points, I think they are reasonably addressed now or in the future. I am glad they are not tackling things that can be done just as well in libs (e.g. strings) while properly tackling things that cannot (e.g. GC, threads, etc).
What I really hope is that Rossberg et al remain true to their convictions, relish their BDFL-ish role, and don't get too beat down by people saying the higher level things they have on the road map are too high and/or the lack of other ones make the level too low.