3 ms·

Web Assembly comes from JavaScript on the client, which means: -it's extremely secure, tested for many years, etc... -it's different than other VMs, almost no

by irq-1 5y ago

Web Assembly comes from JavaScript on the client, which means: -it's extremely secure, tested for many years, etc... -it's different than other VMs, almost no types or functions, the VM cannot access outside memory, only call functions supplied by the host (or write to stdout, again supplied by the host.) -It loads fast, runs fast. Browser JavaScript has been very optimized. -unrelated to the browser, but many languages can be compiled to WASM What you see in this project is the WASI interface that provides the normal libc functions like fopen(), allowing WASM to act like a normal binary. But you can run WASM with other sets of functions, or none and the host can do all the moving of bytes. Cloudflare, Netlify and others are trying to figure out how to host WASM for cloud functions because it's perfect for their systems: small, fast and safe.

nextaccountic 5y ago
I think there are some misconceptions here. Wasm on the server using WASI (which nowadays is probably either wasmtime or wasmer) doesn't have anything to do with Javascript. Actually, wasm on the browser doesn't have anything to do with javascript either! This is actually unfortunate, because wasm in the browser can't natively interface with JS's GC yet [0]. On the other hand, I think a great strength of wasm is that wasm isn't tied to a single memory management system: if it forced a GC on you, it would also need to dictate the memory layout, and would need to determine how this GC gets run, all this would add unnecessary overheard and inflexibility when compiling low-level languages. Or when compiling any language that don't quite conform to the memory management model, different languages want to manage memory differently. This is a pain in the JVM and wasm fixed that. Another strength is vendor neutrality. All major browsers embraced wasm, and it's got multiple implementations in the server as well. There isn't really a dominant implementation that others must conform, and wasm tools are interoperable between implementations. There are also embedded implementations (I know of wamr and wasm3). On a darker note, I'm sad to see see one WASI runtime bashing another [1]; I wish the competition was more cordial, or at least, more professional. [0] see the issues in this repo https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc [1] https://wasmer.io/wasmer-vs-wasmtime https://wasmer.io/wasmer-vs-wasmtime - makes outlandish claims and uses benchmarks without clearly specifying what is being benchmarked (ideally it would link to a Github repo)

by irq-1 5y ago

nextaccountic 5y ago

I think there are some misconceptions here. Wasm on the server using WASI (which nowadays is probably either wasmtime or wasmer) doesn't have anything to do with Javascript. Actually, wasm on the browser doesn't have anything to do with javascript either! This is actually unfortunate, because wasm in the browser can't natively interface with JS's GC yet [0]. On the other hand, I think a great strength of wasm is that wasm isn't tied to a single memory management system: if it forced a GC on you, it would also need to dictate the memory layout, and would need to determine how this GC gets run, all this would add unnecessary overheard and inflexibility when compiling low-level languages. Or when compiling any language that don't quite conform to the memory management model, different languages want to manage memory differently. This is a pain in the JVM and wasm fixed that. Another strength is vendor neutrality. All major browsers embraced wasm, and it's got multiple implementations in the server as well. There isn't really a dominant implementation that others must conform, and wasm tools are interoperable between implementations. There are also embedded implementations (I know of wamr and wasm3). On a darker note, I'm sad to see see one WASI runtime bashing another [1]; I wish the competition was more cordial, or at least, more professional. [0] see the issues in this repo https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc [1] https://wasmer.io/wasmer-vs-wasmtime https://wasmer.io/wasmer-vs-wasmtime - makes outlandish claims and uses benchmarks without clearly specifying what is being benchmarked (ideally it would link to a Github repo)