Hacker News Reader

Comment by thrance | Hacker News Reader

I am kind of worried that the eagerness for more WASM features may irremediably harm the young ecosystem. Most of what Go added to WASM could be done natively if the component model proposal [1] was merged already.

The standard evolves slowly and as adoption rises we risk having to support more and more non-standard features forever, like WASI and now this.

[1] https://github.com/WebAssembly/component-model

View on HN

The component model is... part of WASI, so that criticism doesn't make any sense.

When Go adds support for WASI Preview 2 (or 3), it will have no choice but to support component model. The way WASI Preview 2 works is by making use of the component model.

if Go supports it. I do not believe it is likely. There will still be no native Go runtime to execute components. No one is using WASI p2.

Predicting things is hard, especially about the future, that being said, the people doing the Wasm work for Go want to move to the component model.

ok. it’s on the brink of collapse. Bytecode Alliance is basically comprised of near-dead startups and one or two large corporates who do not care about it.

Considering the near complete overlap of people comprising the Bytecode Alliance with the people who created WebAssembly and people who maintain WebAssembly (especially the formal specification), I very much doubt that the Bytecode Alliance is in any sort of immediate danger. That said, you are right that corporations don't care about it, with some corporations even working against it.

the active overlap is basically 1 person.

do you need a disclaimer to your comments that you work on a product (XTP Bindgen) that is basically competing with the WASI component model? I don't care for either but thought the transparency was necessary.

Reply on news.ycombinator.com