4 ms·

If the VM is in Rust could it be compiled to WASM?

• rkangel 7y ago
  You wouldn't want to, for various reasons. See this blog post about Lumen and the decision decisions: https://tylerscript.dev/bringing-the-beam-to-webassembly-with-lumen https://tylerscript.dev/bringing-the-beam-to-webassembly-wit...
  • hobofan 7y ago
    You wouldn't want to _right now_. However for almost all points there is a solution underway/in planning. In a year or two it might be feasible. There would however be other limitations, like filesystem APIs etc. not being available in the browser that a lot of frameworks in BEAM languages expect, that would severely limit the usefulness, though I guess that applies to either implementation strategy.
    • dnautics 7y ago
      I think the point though is that architecturally there are performance hits if you don't respect the fact that WASM has a different architecture than what the BEAM expects (harvard vs von neumann IIRC), so you may NEVER want to if you get it right in the first place.
      • wahern 7y ago
        The Harvard-Von Neumann dichotomy is wrong. C also works perfectly fine on Harvard architectures--it's why function pointers in C are special, aren't guaranteed to be convertible to a void pointer, and why uintptr_t is optional. POSIX adds these additional guarantees to support dlsym, which returns function addresses as void pointers. The problems with compiling other languages to Web Assembly are primarily 1) lack of goto and 2) inability to instantiate and jump between different stacks. These limitations are especially problematic for languages like Erlang/BEAM and Go because Web Assembly-based VM implementations require an extra level of indirection in order to implement some of their core language semantics, resulting in quite slow performance compared to even a pure, strictly compliant C implementation (and presuming the WASM VM itself adds no overheard, which is not actually the case). WASM excluded goto support because it was argued that the relooper algorithm required to translate goto constructs to structured WASM statements was sufficiently capable to cover the vast majority of existing code. And they provided evidence to back up that claim. The flaw in that reasoning is that language implementations and similar niche cases have special needs that application code rarely requires, and in that space constructs like goto are crucial to both simplicity of implementation and performance; the inadequacies of relooper become the norm rather than the exception.
        • dnautics 7y ago
          thanks for the clarification!
    • rkangel 6y ago
      I can't imagine a situation in which it would be acceptable to download an entire (WASM compiled) copy of the BEAM from every new website I visit. Full AOT compilation with dead code elimination seems like a much better fit for minimising that bundle size.
      • derefr 6y ago
        WASM isn't just for the web, though. It's beginning to look a lot like the next "portable ISA" (successor to Pascal's pcode, applet-era JVM bytecode, Google's PNaCl, etc.) Add a progressive web-app to your mobile's home screen—get a cached WASM bundle, for near-native performance of the resulting "app." Download an Electron app—get a WASM bundle wrapped in a projector. Even then, there are still browser use-cases where "full fat" apps are no problem. The "apps" in the Chrome Web Store—Adobe has a version of Photoshop in there, I think—make a lot of sense to be WASM. You'll launch them once and keep them open for hours.