5 ms·

Show HN: A WebAssembly System Interface Implementation for Deno

90 points by caspervonb 6y ago

gitgud 6y ago
So this can compile other languages to run on deno using Web assembly? Seems like a lot of indirection to emulate the native assembly code. I guess it's cross-platform though right?
- tylerchilds 6y ago
  I imagine this type of approach will replace TypeScript in the long run. Instead of some wonky half-assed typed language that's chosen for running on a server and client, you can compile Java to wasm that can run on the server and client.
  - steve76 6y ago
    And then you can compile Scala to Java to webasm to run on Deno to run on Rust to run on LXC to run on Hypervisor. No need to worry about transpilers.
  - bastawhiz 6y ago
    That's a bit of a stretch. What makes you think WASM is going to give developers an appetite for statically typed languages? If anything, WASM opens the door to Python, Lua, and plenty of other languages that are not statically typed to run (performantly!) in places where only JavaScript has historically been practical.
    - brabel 6y ago
      At the moment, WASM is far from ideal to run anything that requires a GC as there's no GC in WASM yet and it seems it will take a long time for it to finally get one. So even running Java or Go in WASM is not easy at all (though there are compilers already - but they won't just run any program, they are extremely limited)... now, to run dynamic languages on top of a typed bytecode without GC... that has to be a huge challenge! Why do you think Python/Lua can run perfomantly on WASM?
    - wtetzner 6y ago
      > What makes you think WASM is going to give developers an appetite for statically typed languages? Well, they did say it will give TypeScript developers better alternatives. Presumably, if you're using TypeScript, you already had an appetite for statically typed languages.
      - bastawhiz 6y ago
        I suppose it depends on what problem you use TypeScript to solve. If you're writing a complicated and self-contained system, sure, I can see the appeal of "upgrading" to Java. If you're trying to enforce contracts between different codebases/libraries/etc., WASM hardly provides a better alternative: integrating with other libraries—especially JS ones—or even the DOM is non-trivial. Which is to say, using TypeScript as a quality of life improvement to provide autocomplete and checking for easily-detectable bugs is not going to lend itself well to being replaced with WASM. If the goal is to write a 100% typed codebase (e.g., having a complex, entirely self-contained tool that runs in multiple environments), you will have better luck. But I suspect the number of folks that could benefit from that are fairly low, because it assumes that JavaScript is the bottleneck for correctness and performance. But if the real reason why you're using TypeScript is that JavaScript was your only choice and you like the increase in safety, having a more appropriate language could be an even more attractive option.
  - vijaybritto 6y ago
    But the most likely scenario imo is that Typescript would eventually start compiling to wasm directly!
- qppo 6y ago
  One of the advantages of wasm in place of native is cross-platform sandboxing, including dependencies. That's kind of tricky to do in native code without a container.
- gavinray 6y ago
  Happen to know this particular fellow who authored the lib from the Deno discord (really brilliant, nice guy) and he took the time to explain the same question to me earlier in writing this. This is the gist of it: - WASM is sandboxed. The shortest way to explain it is that anything that uses a syscall won't work. These syscalls include things like networking and filesystem access. - WASI is a standard interface/specification for WASM. What it does is provide a spec of function signatures for syscalls, and provide the compile-time swap of stdlib functions that use these. For example, Rust’s "open" (and I believe C's "fopen") is implemented by calling "(__wasi_)path_open" when it’s compiled to WebAssembly via WASI. And "path_open" is meant to act like the "openat" syscall. You can already run other languages compiled to WASM on Deno, by just loading the .wasm file bytes and instantiating. You can also run native code in Deno through Rust "native Ops"/plugins. This can be pure Rust, or Rust calling C/C++ externs, etc. So what is the point then, why bother? WASI allows you to compile and run programs which have behavior that requires syscalls, and hopefully get the functionality fully emulated. So with an implemented WASI interface in a language, then you can take some compiled WASM lib using WASI and (mostly) assume it'll run in that environment too. --- Edit: Also a note, I have fairly little understanding of low-level programming so I may have butchered this. I make no claims to accuracy, this is my rough understanding. Edit2: What really helped my understanding was looking at the Typescript implementation of these syscalls, so here you can see the implementation of "path_open" in TS that provides WASI the functionality it needs for using that method: https://deno.land/x/wasi/mod.ts#L881 https://deno.land/x/wasi/mod.ts#L881
  - the_duke 6y ago
    To expand, this functionality is of course not unique. There are numerous WASM runtimes out there, like wasmtime [1] or wasmer [2]. The interesting aspects of using Deno for this are: a) v8 is bound to have a high quality wasm JIT and already has a sophisticated sandbox (although JS and the browser context probably bring in a lot of complexity that a pure WASM sandbox doesn't have to deal with) b) easy interop with Javascript/Typescript code c) Deno is experimenting with finer grained permission based sandboxing, so this fits well within the domain [1] https://github.com/bytecodealliance/wasmtime https://github.com/bytecodealliance/wasmtime [2] https://wasmer.io/ https://wasmer.io/
gutino 6y ago
This is amazing and very useful, now you will be able to compile any c++, c, rust app to wasm and run inside Deno, so you can easily distribute to any platform. No need to re-write your current native apps, just compile them to wasm and they can run everywhere!

90 points by caspervonb 6y ago

So this can compile other languages to run on deno using Web assembly? Seems like a lot of indirection to emulate the native assembly code. I guess it's cross-platform though right?

tylerchilds 6y ago
I imagine this type of approach will replace TypeScript in the long run. Instead of some wonky half-assed typed language that's chosen for running on a server and client, you can compile Java to wasm that can run on the server and client.
- steve76 6y ago
  And then you can compile Scala to Java to webasm to run on Deno to run on Rust to run on LXC to run on Hypervisor. No need to worry about transpilers.
- bastawhiz 6y ago
  That's a bit of a stretch. What makes you think WASM is going to give developers an appetite for statically typed languages? If anything, WASM opens the door to Python, Lua, and plenty of other languages that are not statically typed to run (performantly!) in places where only JavaScript has historically been practical.
  - brabel 6y ago
    At the moment, WASM is far from ideal to run anything that requires a GC as there's no GC in WASM yet and it seems it will take a long time for it to finally get one. So even running Java or Go in WASM is not easy at all (though there are compilers already - but they won't just run any program, they are extremely limited)... now, to run dynamic languages on top of a typed bytecode without GC... that has to be a huge challenge! Why do you think Python/Lua can run perfomantly on WASM?
  - wtetzner 6y ago
    > What makes you think WASM is going to give developers an appetite for statically typed languages? Well, they did say it will give TypeScript developers better alternatives. Presumably, if you're using TypeScript, you already had an appetite for statically typed languages.
    - bastawhiz 6y ago
      I suppose it depends on what problem you use TypeScript to solve. If you're writing a complicated and self-contained system, sure, I can see the appeal of "upgrading" to Java. If you're trying to enforce contracts between different codebases/libraries/etc., WASM hardly provides a better alternative: integrating with other libraries—especially JS ones—or even the DOM is non-trivial. Which is to say, using TypeScript as a quality of life improvement to provide autocomplete and checking for easily-detectable bugs is not going to lend itself well to being replaced with WASM. If the goal is to write a 100% typed codebase (e.g., having a complex, entirely self-contained tool that runs in multiple environments), you will have better luck. But I suspect the number of folks that could benefit from that are fairly low, because it assumes that JavaScript is the bottleneck for correctness and performance. But if the real reason why you're using TypeScript is that JavaScript was your only choice and you like the increase in safety, having a more appropriate language could be an even more attractive option.
- vijaybritto 6y ago
  But the most likely scenario imo is that Typescript would eventually start compiling to wasm directly!
qppo 6y ago
One of the advantages of wasm in place of native is cross-platform sandboxing, including dependencies. That's kind of tricky to do in native code without a container.
gavinray 6y ago
Happen to know this particular fellow who authored the lib from the Deno discord (really brilliant, nice guy) and he took the time to explain the same question to me earlier in writing this. This is the gist of it: - WASM is sandboxed. The shortest way to explain it is that anything that uses a syscall won't work. These syscalls include things like networking and filesystem access. - WASI is a standard interface/specification for WASM. What it does is provide a spec of function signatures for syscalls, and provide the compile-time swap of stdlib functions that use these. For example, Rust’s "open" (and I believe C's "fopen") is implemented by calling "(__wasi_)path_open" when it’s compiled to WebAssembly via WASI. And "path_open" is meant to act like the "openat" syscall. You can already run other languages compiled to WASM on Deno, by just loading the .wasm file bytes and instantiating. You can also run native code in Deno through Rust "native Ops"/plugins. This can be pure Rust, or Rust calling C/C++ externs, etc. So what is the point then, why bother? WASI allows you to compile and run programs which have behavior that requires syscalls, and hopefully get the functionality fully emulated. So with an implemented WASI interface in a language, then you can take some compiled WASM lib using WASI and (mostly) assume it'll run in that environment too. --- Edit: Also a note, I have fairly little understanding of low-level programming so I may have butchered this. I make no claims to accuracy, this is my rough understanding. Edit2: What really helped my understanding was looking at the Typescript implementation of these syscalls, so here you can see the implementation of "path_open" in TS that provides WASI the functionality it needs for using that method: https://deno.land/x/wasi/mod.ts#L881 https://deno.land/x/wasi/mod.ts#L881
- the_duke 6y ago
  To expand, this functionality is of course not unique. There are numerous WASM runtimes out there, like wasmtime [1] or wasmer [2]. The interesting aspects of using Deno for this are: a) v8 is bound to have a high quality wasm JIT and already has a sophisticated sandbox (although JS and the browser context probably bring in a lot of complexity that a pure WASM sandbox doesn't have to deal with) b) easy interop with Javascript/Typescript code c) Deno is experimenting with finer grained permission based sandboxing, so this fits well within the domain [1] https://github.com/bytecodealliance/wasmtime https://github.com/bytecodealliance/wasmtime [2] https://wasmer.io/ https://wasmer.io/

gutino 6y ago

This is amazing and very useful, now you will be able to compile any c++, c, rust app to wasm and run inside Deno, so you can easily distribute to any platform. No need to re-write your current native apps, just compile them to wasm and they can run everywhere!