Hey folks,
I've been playing with rust, tokio, hyper, and wasi for a couple of months now. I'm able to run the hello_world example from tokio-wasi on wasmer and my next goal is to run the same example on NodeJS with --experimental-wasi-unstable-preview1 and wasmtime. Unfortunately, wasm32-wasi is relying on 6 APIs (sock_open, sock_bind, sock_connect, sock_getaddrinfo, sock_getpeeraddr, and sock_getlocaladdr) that are not part of wasi_snapshot_preview1 and therefore, they don't exist on the NodeJS wasi implementation. Those APIs are implemented in wasmer so I wonder if they will become part of the wasi standard; also, do you know why wasm32-wasi relies on those APIs even when they're not part of the wasi standard?
I'm trying to understand the compatibility between the different runtimes (wasmer, wasmtime, wasmr, nodejs, etc.).
Thanks!
Yes, the next major iteration of WASI will have sockets bind/connect/listen/etc. functionality. They won't be compatible with wasmer because wasmer is currently antagonistic towards the standards process, seeking to gain control over the ecosystem. But they will be standard and implemented in the wasm32-wasi target in Rust and implemented by Wasmtime and other WASI runtimes.
Thanks a lot!
wasmer is currently antagonistic towards the standards process, seeking to gain control over the ecosystem
do you have references? just curious.
A very public example is their attempt to trademark "WebAssembly". And when that became public, their response consisted of arguing that it could have worked, that it was all a big misunderstanding, and that it was the lawyers' fault.
interesting. thank you.
As tempting as it may be to stoop down to the level that others are at, let's try to keep things professional in this space. Thanks.
fitzgen (he/him) said:
As tempting as it may be to stoop down to the level that others are at, let's try to keep things professional in this space. Thanks.
Okay, I am very sorry about that.
Last updated: Dec 23 2024 at 12:05 UTC