5 ms·

This is a timely article for me since I've been trying to learn more about webassembly lately, thank you for it. I think the system interface is probably extre

This is a timely article for me since I've been trying to learn more about webassembly lately, thank you for it. I think the system interface is probably extremely important and significant part of webassembly and history. It's history making. It's the definition of a foundational interface that all users of webassembly shall inherit and need to target if it takes off. Which I hope it does. A standardised bytecode format is awesome! Why do I say this? The binary interface for C programming such as the amd64 SysV calling convention is established and is important for C FFI interoperability. Likewise, the syscall interface for Linux is established and so is Win32 API or POSIX. If people are trying to compile existing code so it doesn't need to be changed to support webassembly, then that's one constraint. Another constraint is performant Javascript interop. Another constraint which I personally find most interesting is the capability of defining a new API that is fit for purpose for application development. So that incorporates threading, garbage collection and sockets.

eyberg 4y ago
The problem is that the wasm-on-the-server-side people don't seem to understand that the browser vendors will never ever let them have the laundry list of features that are necessary to fulfill Solomon's quoted tweet. The sooner the server-side people decide on their own standard (that won't be compatible 1:1 within the browser) for the server workloads the faster they can work on their end goals. WASI has been around for a while and is still missing quite a lot. raw sockets, dynamic linking, 32bit vs 64, linear memory (gc), memory protection, real threads, TLS - the list is seemingly endless. If I were building something in the wasm community (I'm not) I'd be less focused in on building one off bindings for fuctions-as-a-service, which seems to be the gtm right now and more focused on building the underlying foundations that are necessary.
- paulgb 4y ago
  I agree with your overall point, but interestingly it does look like Chrome is interested in shipping WASM GC in the browser. Here's their tracker for it: https://chromestatus.com/feature/6062715726462976 https://chromestatus.com/feature/6062715726462976
  - phickey 4y ago
    Additionally, googlers are championing memory control https://github.com/WebAssembly/memory-control/blob/main/proposals/memory-control/Overview.md https://github.com/WebAssembly/memory-control/blob/main/prop..., which provides memory protection, as well as memory 64, which is already done in chrome and firefox https://github.com/WebAssembly/memory64/blob/main/proposals/memory64/Overview.md https://github.com/WebAssembly/memory64/blob/main/proposals/...
makoz 4y ago
OOC how are you going about learning more about webassembly?
- samsquire 4y ago
  I've been reading the following repositories. https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/wasi-threads https://github.com/WebAssembly/wasi-threads

eyberg 4y ago

The problem is that the wasm-on-the-server-side people don't seem to understand that the browser vendors will never ever let them have the laundry list of features that are necessary to fulfill Solomon's quoted tweet. The sooner the server-side people decide on their own standard (that won't be compatible 1:1 within the browser) for the server workloads the faster they can work on their end goals. WASI has been around for a while and is still missing quite a lot. raw sockets, dynamic linking, 32bit vs 64, linear memory (gc), memory protection, real threads, TLS - the list is seemingly endless. If I were building something in the wasm community (I'm not) I'd be less focused in on building one off bindings for fuctions-as-a-service, which seems to be the gtm right now and more focused on building the underlying foundations that are necessary.

paulgb 4y ago
I agree with your overall point, but interestingly it does look like Chrome is interested in shipping WASM GC in the browser. Here's their tracker for it: https://chromestatus.com/feature/6062715726462976 https://chromestatus.com/feature/6062715726462976
- phickey 4y ago
  Additionally, googlers are championing memory control https://github.com/WebAssembly/memory-control/blob/main/proposals/memory-control/Overview.md https://github.com/WebAssembly/memory-control/blob/main/prop..., which provides memory protection, as well as memory 64, which is already done in chrome and firefox https://github.com/WebAssembly/memory64/blob/main/proposals/memory64/Overview.md https://github.com/WebAssembly/memory64/blob/main/proposals/...

makoz 4y ago

OOC how are you going about learning more about webassembly?

samsquire 4y ago
I've been reading the following repositories. https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/wasi-threads https://github.com/WebAssembly/wasi-threads