4 ms·
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 featu
by 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 agoI 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 agoAdditionally, 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/...