Earlier quoted context omitted.
It's interesting that this seems on one hand "unpredictable" while also being logical. If a company has employees familiar with TypeScript (or even JS) and they have to make a choice between yet another flavor of that or a new language like C/Rust... well the choice is understandable. Once again the path of least resistance to a new web technology ended up being JavaScript - it just wasn't immediately obvious when WA…
A JavaScript SuperSet becoming the de facto standard of writing for WASM - I think one can file this under „worse is better“.
How Shopify Uses WebAssembly Outside of the Browser
131–135 of 135 posts
Re: How Shopify Uses WebAssembly Outside of the Browser
#132Earlier quoted context omitted.
> "Simplicity" - nothing is more 'simple' than JS, which is why it's used the world over. Not in terms of implementing the language.
Not in terms of using the language either. And the reason it is used the world over is because it was dictated to developers by browser makers. That's the single and only reason.
Re: How Shopify Uses WebAssembly Outside of the Browser
#133Earlier quoted context omitted.
"readily apparent" is not good evidence. Security isn't as simple as number of lines of code. You need actual in depth analysis to even know the attack surface. The reason why people view wasm as more secure is the runtimes used for it are VM's that control execution at an instruction level along with the wasm instruction set being far simpler than x86. Not saying wasm is magically secure because of this, there's not…
Wasm execution doesn’t exist in the abstract. Lucet, the vm in question, does no theoretical instruction-level mitigations of which you speak. It does, however, expose a larger attack surface than simply using seccomp (not seccomp-bpf).
Re: How Shopify Uses WebAssembly Outside of the Browser
#134Re: How Shopify Uses WebAssembly Outside of the Browser
#135Earlier quoted context omitted.
Are you serious? You want to ask partners to write embedded C programs using a pre allocated virtual memory range? It's obvious why they went for WASM instead.
My point was exactly that you don’t necessarily write your code for an embedded environment in the seccomp model. You provide code in a dynamic library format and the normal dynamic linker links the necessary calls (e.g. malloc) at runtime, exactly as a wasm would provide that environment (via WASI or whatever). Since those calls are all only implemented in terms of write,read,exit,and sigreturn you are guaranteed a…