Live data from Hacker News

How Shopify Uses WebAssembly Outside of the Browser

shopify.engineering

131–135 of 135 posts

Re: How Shopify Uses WebAssembly Outside of the Browser

#131

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“.

JavaScript SubSuperSet

Re: How Shopify Uses WebAssembly Outside of the Browser

#132

Earlier 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.

I agree, but I'd still rank JavaScript as one of the more approachable major languages.

Re: How Shopify Uses WebAssembly Outside of the Browser

#133

Earlier 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).

By definition a WASM runtime running within seccomp does not increase the attack surface. That's in fact the whole point of layering such systems. I'm not exactly sure what your point is or why you're talking about seccomp-bpf here.

Re: How Shopify Uses WebAssembly Outside of the Browser

#135
post #126

Earlier 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…

The big difference is the tooling gives you that for free with WASM. You can even run Go programs in WASM. You don't get that with seccomp.
Post reply on HN