Assemblyscript Removes WASI Support(twitter.com)
twitter.com
Assemblyscript Removes WASI Support
https://twitter.com/AssemblyScript/status/1561699214069047299
8 comments
Is there some explanation for why this person does not like WASI?
old topic:
https://github.com/WebAssembly/WASI/issues/401#issue-8177488...
The problem with WASI is that it is a some kind of truncated copy of CloudABI and POSIX. With all the goodies like abbreviated error codes like "fbig", "idrm", "srch" and etc. See: https://github.com/WebAssembly/WASI/blob/0ba0c5e2e37625ca5a6...
The main problem of WASI in my opinion is that it's based on a standard which is 30 years old. And yes, the idea was cool, to let you run even C without having to rewrite libc. But the reality is that we can't do this now and it's still a big question whether we can in the near future. Besides, C is probably the only one that needs such a low level api, but everyone has to suffer because of it, essentially reinventing libc based on WASI with their own language runtime on top of it. This is simply a waste of binary space.
Also it lead to fragmentation into the WebAseembly ecosystem. A compiled program in wasm32-wasi cannot run in a browser, only in wasmtime, wasmer or node.js. WASI-polyfill.js is very limited, adds a bunch of kilobytes of glue code and is still not even officially introduced.
The problem with WASI is that it is a some kind of truncated copy of CloudABI and POSIX. With all the goodies like abbreviated error codes like "fbig", "idrm", "srch" and etc. See: https://github.com/WebAssembly/WASI/blob/0ba0c5e2e37625ca5a6...
The main problem of WASI in my opinion is that it's based on a standard which is 30 years old. And yes, the idea was cool, to let you run even C without having to rewrite libc. But the reality is that we can't do this now and it's still a big question whether we can in the near future. Besides, C is probably the only one that needs such a low level api, but everyone has to suffer because of it, essentially reinventing libc based on WASI with their own language runtime on top of it. This is simply a waste of binary space.
Also it lead to fragmentation into the WebAseembly ecosystem. A compiled program in wasm32-wasi cannot run in a browser, only in wasmtime, wasmer or node.js. WASI-polyfill.js is very limited, adds a bunch of kilobytes of glue code and is still not even officially introduced.
As a relative newcomer to WebAssembly, the first thing I noticed was a disconnect between WebAssembly, which is loosely governed by W3C process, whereas WASI, a subgroup, never released a draft, closest thing being the module id people tend to use, wasi_snapshot_preview1. The next surprise is finding most implementations usable by end users (ex language compilers, not necessarily wasi-libc), employ a small subset of the apis on a whack-a-mole basis. Then, you find that most attempts to have a test kit failed, and unlike the core spec which has a way to say if you passed or not, there's neither decent documentation, nor a test kit for wasi. Then, when issues are raised, some comments you mention about copy/paste CloudABI problems are conceded even by the project team. However, there's no usable infrastructure to bridge to what the next one is (I think based on component model, but supposedly usable without it).
My feeling is that the amount of surprised I had was brought about by the overwhelming marketing that WASI was basically this thing that gives you a capabilities based model for system calls, and in practice it was a semi-implemented, glorified markdown file that was not a part of any standardization process, at least not W3C draft..REC.
Now, I look at some of the tensions and they seem to imply this solved backend, but not frontend :) Well, I would say that it got backends turning, basically pushing the abstraction cliff a bit farther out than ad-hoc host ABIs times X targets. This surely was helpful as it allows people to get much farther along especially when everything uses llvm and libc. However, I hope what's next can do a bit more rigor as the first was an example of how to thrash a lot of people. spectest shouldn't be an optional thing in something called a standard, detailed mapping documents can happen to help people implement the paper and pass those tests. I think whatever happens next can fix things, and it will be both a matter of avoiding copy/pasta spec, but also adding far more rigor.
Regardless, I personally am happy to continue supporting who has used WASI and its alternatives including the next WASIs. Progress is important and I think WASI, albeit stumbling, progressed the backend a lot.
my 2p and thanks for the post!
My feeling is that the amount of surprised I had was brought about by the overwhelming marketing that WASI was basically this thing that gives you a capabilities based model for system calls, and in practice it was a semi-implemented, glorified markdown file that was not a part of any standardization process, at least not W3C draft..REC.
Now, I look at some of the tensions and they seem to imply this solved backend, but not frontend :) Well, I would say that it got backends turning, basically pushing the abstraction cliff a bit farther out than ad-hoc host ABIs times X targets. This surely was helpful as it allows people to get much farther along especially when everything uses llvm and libc. However, I hope what's next can do a bit more rigor as the first was an example of how to thrash a lot of people. spectest shouldn't be an optional thing in something called a standard, detailed mapping documents can happen to help people implement the paper and pass those tests. I think whatever happens next can fix things, and it will be both a matter of avoiding copy/pasta spec, but also adding far more rigor.
Regardless, I personally am happy to continue supporting who has used WASI and its alternatives including the next WASIs. Progress is important and I think WASI, albeit stumbling, progressed the backend a lot.
my 2p and thanks for the post!
https://github.com/AssemblyScript/assemblyscript/pull/2439
Best I could find
Best I could find
From the FAQ
> Why the strange name?
> Assemblyscript is to assembly as Javascript is to Java. Not quite
Well yes :)
> Why the strange name?
> Assemblyscript is to assembly as Javascript is to Java. Not quite
Well yes :)
Why?
This looks to be to just be drama. It looks like it came down to string interop, the AS guy not feeling listened to, then stuff getting blown out of proportion
It is almost funny, almost sad, that we were in this for nearly five years, every single day, and despite that a cartel created for the occasion completely evaporated us politically for pointing out "technically not wrong" technicalities that nobody ever had the intention to address, this is how we are perceived still by the same people we once thought we were giving a voice to :) Yet, somehow, Wasm has turned out to be almost indistinguishable of what was once presented or what is still marketed by its outdated supplementary material. Openness? Portability? Security? Web interop? Multi-language? Professional conduct? Giggles through rose-colored glasses. https://github.com/WebAssembly/WASI/issues/401 —the AS guy