2 ms·

Sandboxing alone is a very important reason. Sandboxing 3rd party code inside existing applications for example. Like plugins for Photoshop-like applications o

Sandboxing alone is a very important reason. Sandboxing 3rd party code inside existing applications for example. Like plugins for Photoshop-like applications or game mods. Portability is also a big plus for this kind of thing too.

__MatrixMan__ 1y ago
Agreed. Wasm let's you just revoke network access from things that don't need it. I know you can also do that with docker but its an awful big hammer for the job.
- DanielHB 1y ago
  Yeah exactly, it is kinda insane how deep open source tech stacks have gone. We need a world where we can seamlessly synchronously (no IPC, no network) call a function from a 3rd party and be sure it doesn't make any network requests, read the disk (or any other type of I/O) or read non-assigned RAM. If we could do that the amount of scrutiny you need for your 3rd party code goes down massively. WASM is a step to get there.
  - kerkeslager 1y ago
    I think ultimately this isn't the solution. The solution to insanely deep open source tech stacks is to use simpler stacks. This is really my whole problem with the way JS is ubiquitously developed: you simply do not need 99% of the tools the JS devs are using these days. I use very simple full-stacks: so simple that I don't need a JS package manager (I do use pip/pypy, but I'm extremely guarded about what code I'll import--usually <10 packages). I do write some code that could be imported in a library sometimes, but I also barely ever do any rewriting to deal with deprecations, and my builds never break due to a package change. My builds are often reproduceable by accident. In the short run, I'm not less productive than people who use all of npm. In the long run, I'm far more productive. And even if that weren't the case, developer productivity at the expense of user security was a pretty bad tradeoff anyway. I really wish fewer people were doing that.
  - __MatrixMan__ 1y ago
    I think what you're saying is that we need a world where more things are built out of pure functions with explicit inputs. And I agree. Wasm lets you take something that is coincidentally pure and run it in a way that ensures that it'll stay that way even for novel inputs, but you're still treating it like a black box... Just a particularly well behaved one. Sometimes you need that because you're dealing with somebody else's code and they weren't especially interested in providing the kinds of assurances that you'd like to have. So I agree, it is a step in the right direction. But if you want to author code that gives users such assurances, building to wasm is a rather small step. There only so much that can be done at the bytecode level. Much more can be done at a language level (Unison comes to mind, which goes so far as to eliminate the function's name as a source of works-differently-on-my-machine, though Haskell is probably a more common choice).

__MatrixMan__ 1y ago

Agreed. Wasm let's you just revoke network access from things that don't need it. I know you can also do that with docker but its an awful big hammer for the job.

DanielHB 1y ago
Yeah exactly, it is kinda insane how deep open source tech stacks have gone. We need a world where we can seamlessly synchronously (no IPC, no network) call a function from a 3rd party and be sure it doesn't make any network requests, read the disk (or any other type of I/O) or read non-assigned RAM. If we could do that the amount of scrutiny you need for your 3rd party code goes down massively. WASM is a step to get there.
- kerkeslager 1y ago
  I think ultimately this isn't the solution. The solution to insanely deep open source tech stacks is to use simpler stacks. This is really my whole problem with the way JS is ubiquitously developed: you simply do not need 99% of the tools the JS devs are using these days. I use very simple full-stacks: so simple that I don't need a JS package manager (I do use pip/pypy, but I'm extremely guarded about what code I'll import--usually <10 packages). I do write some code that could be imported in a library sometimes, but I also barely ever do any rewriting to deal with deprecations, and my builds never break due to a package change. My builds are often reproduceable by accident. In the short run, I'm not less productive than people who use all of npm. In the long run, I'm far more productive. And even if that weren't the case, developer productivity at the expense of user security was a pretty bad tradeoff anyway. I really wish fewer people were doing that.
- __MatrixMan__ 1y ago
  I think what you're saying is that we need a world where more things are built out of pure functions with explicit inputs. And I agree. Wasm lets you take something that is coincidentally pure and run it in a way that ensures that it'll stay that way even for novel inputs, but you're still treating it like a black box... Just a particularly well behaved one. Sometimes you need that because you're dealing with somebody else's code and they weren't especially interested in providing the kinds of assurances that you'd like to have. So I agree, it is a step in the right direction. But if you want to author code that gives users such assurances, building to wasm is a rather small step. There only so much that can be done at the bytecode level. Much more can be done at a language level (Unison comes to mind, which goes so far as to eliminate the function's name as a source of works-differently-on-my-machine, though Haskell is probably a more common choice).