Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
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.
Related posts
- Let's Write a Malloc
- Do you think typescript will ever have native support on brosers? Or we will have only the JS type annotations?
- Ezno's checker (a Javascript type checker and compiler written in Rust) is now open source
- Is there a TypeScript to native compiler available?
- AssemblyScript – TypeScript-like language for WebAssembly