8 ms·

For me, the most interesting potential of WASM is it provides a platform-independent sandboxed way to run untrusted code written in multiple programming languag

For me, the most interesting potential of WASM is it provides a platform-independent sandboxed way to run untrusted code written in multiple programming languages. This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser. And while I'm sure there's "serious" business uses for that capability :) I'm most interested in what it enables in terms of user customisation/modding of games. Which was my main motivation for creating a Wasmtime WASM runtime add-on for the Godot game engine: https://gitlab.com/RancidBacon/godot-wasm-engine https://gitlab.com/RancidBacon/godot-wasm-engine And also designing the "WebAssembly Calling Card" specification as a way of demonstrating how the same code could produce graphical output that is then used in 2D or 3D environments: https://wacc.rancidbacon.com https://wacc.rancidbacon.com

jsd1982 5y ago
This is exactly what I'm doing right now with SNES emulators, bsnes-plus specifically. The idea is to be able to extend certain games and give wasm module the ability to read/write the emulated memory and send/receive messages over a network connection to another process, among other things.
- follower 5y ago
  Sounds cool! Do you have anywhere that interested people can read more about the project/progress?
  - jsd1982 5y ago
    Hm not really but I do update my repo on github.com. It's all work in progress stuff being designed as I go. https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm
still_grokking 5y ago
> This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser. Maybe want to talk to the Java guys, and ask them why this doesn't work out in practice? ;-) Just having a common byte-code interpreter isn't enough for portability of applications.
- follower 5y ago
  Admittedly, "How is this different to Java [planned]?" isn't an entirely unreasonable question to ask in this context. :) What's your theory on why it doesn't/didn't work out in practice in Java's case? There is one key difference in our respective wording which might point to a difference of perspective: I referred to "the same code" and you referred to "portability of applications". I don't really foresee "portability of applications" so much as "portability of modules/functions" (or "portability of libraries/plugins", I guess). In which case, you're still correct when you say a common byte-code interpreter isn't enough--there also needs to be common specification/API for specific domains. (Which is where WASI is aiming for in terms of general system-level APIs; interface types are aiming for lower levels; and, other higher level domain/application-specific solutions may be developed for other situations.)
pjmlp 5y ago
> And while I'm sure there's "serious" business uses for that capability :) There surely is, Java, .NET were there first. If we leave the browser out, then there are plenty of examples since the early days of 1960's.

jsd1982 5y ago

This is exactly what I'm doing right now with SNES emulators, bsnes-plus specifically. The idea is to be able to extend certain games and give wasm module the ability to read/write the emulated memory and send/receive messages over a network connection to another process, among other things.

follower 5y ago
Sounds cool! Do you have anywhere that interested people can read more about the project/progress?
- jsd1982 5y ago
  Hm not really but I do update my repo on github.com. It's all work in progress stuff being designed as I go. https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm

still_grokking 5y ago

> This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser. Maybe want to talk to the Java guys, and ask them why this doesn't work out in practice? ;-) Just having a common byte-code interpreter isn't enough for portability of applications.

follower 5y ago
Admittedly, "How is this different to Java [planned]?" isn't an entirely unreasonable question to ask in this context. :) What's your theory on why it doesn't/didn't work out in practice in Java's case? There is one key difference in our respective wording which might point to a difference of perspective: I referred to "the same code" and you referred to "portability of applications". I don't really foresee "portability of applications" so much as "portability of modules/functions" (or "portability of libraries/plugins", I guess). In which case, you're still correct when you say a common byte-code interpreter isn't enough--there also needs to be common specification/API for specific domains. (Which is where WASI is aiming for in terms of general system-level APIs; interface types are aiming for lower levels; and, other higher level domain/application-specific solutions may be developed for other situations.)

pjmlp 5y ago

> And while I'm sure there's "serious" business uses for that capability :) There surely is, Java, .NET were there first. If we leave the browser out, then there are plenty of examples since the early days of 1960's.