10 ms·
WASM is also useful for distributing a single binary blob that runs on different Operating Systems and CPU architectures, instead of 'stamping out' NxM native e
by flohofwoe 4y ago
WASM is also useful for distributing a single binary blob that runs on different Operating Systems and CPU architectures, instead of 'stamping out' NxM native executables. This area overlaps more with Java and .NET (but with more/different language options) than 'an alternative to JS in the browser'.
For instance I have a C++ shader compiler which includes some massive 3rd party libraries (glslangValidator, SPIRVTools and SPIRVCross) which takes forever to compile, so distributing in source code form is not really an option, and the only alternative is to ship precompiled binaries for each supported OS/CPU combination. Currently I do this via GH Actions, which kinda works, but just building a single WASM blob and shipping that to users (who then would need to install one of the WASM runtimes though) sounds kinda interesting.
PS: WASM may also be useful as universal plugin format. For instance the new Microsoft flight sim uses WASM instead of scripting or native DLLs for modding:
https://docs.flightsimulator.com/html/Programming_Tools/WASM/WebAssembly.htm https://docs.flightsimulator.com/html/Programming_Tools/WASM...
- kaba0 4y agoJava’s GraalVM can do plenty of languages, on top of running managed ones much faster. I don’t see novelty here.
- flohofwoe 4y agoIf I compile a C or Rust program to run in GraalVM, will the LLVM bitcode be converted to some sort of universal bytecode, or does Graal attempt to run the bitcode directly via a plugin? (e.g. do I distribute GraalVM bytecode or LLVM bitcode to the user?). The documentation is a bit unclear about this, but there's this weird blurb at the end: > Note: LLVM bitcode is platform-dependent. The program must be compiled to bitcode for an appropriate platform. ...why would this detail even matter if LLVM bitcode is converted to 'GraalVM bytecode'? In any case, it doesn't sound much like "write once run everywhere" ;) See: https://www.graalvm.org/22.2/reference-manual/llvm/ https://www.graalvm.org/22.2/reference-manual/llvm/
- kaba0 4y agoGraal’s truffle runtime works basically as an AST interpreter, so you have to ship the LLVM bitcode. I have yet to get my feet wet with sulong, but my guess would be that LLVM will produce different bitcode on different platforms, and thus the execution can potentially be different - also note that llvm bitcode is not a stable format. But I don’t think that interpreting it on a different platform than it was compiled on would have a fundamental reason not to work (after all, it is just java code) - perhaps it uses the platform llvm libs for some parsing, which is not platform-agnostic?
- coldtea 4y agoWell, the point is not in some novelty, but that it does a similar thing as an open standard, with more than one vendor and community behind it for runtimes, tooling, etc., that it doesn't come from Oracle (which is an extra bonus), and with compatibility with the web and bigger boost behind it than Graal ever achieved thus far to boot.
- kaba0 4y agoJava bytecode is an open standard with more completely independent implementations than wasm, but it is slightly higher level. Graal (truffle) uses ASTs mapping to Java language primitives as a basis (in a way sorta similar to wasm, as that is not really a byte code).
- deleted 4y ago[deleted]
- elcritch 4y agoWASM also takes a whitelisting approach to security rather than a blacklisting like the JVM. Java applets had lots of security issues over the years, whereas WASM provides much better isolation. Overall JVM or CLR always seemed too heavyweight for many use cases.
- kaba0 4y agoI do somewhat agree with the security aspects, though it seems to be in-process security measures are not the panacea. > Overall JVM or CLR always seemed too heavyweight for many use cases. The most common implementation may be; there are plenty of tiny jvms, some target embedded devices even.
- oblio 4y agoYeah, but then you run into the problem of, "are those tiny JVMs": 1. Well supported by a company and a community 2. Are they free? Especially 2, it sounds ridiculous but frankly even huge corps just use free stuff whenever they can.
- rtpg 4y agoI suppose the "novelty" is the existence of compilation to WASM target in more and more compiler toolchains, so you can use things. Though to your point GraalVM work is also progressing a lot! Nice to have a lot of energy in this space in general
- still_grokking 4y ago> I suppose the "novelty" is the existence of compilation to WASM target in more and more compiler toolchains Which ones? AFAIK WSAM runs only "C-like" language properly. Everything else is a major hack and slow as hell. When it even exists of course. Because to my knowledge there aren't much languages that compile to WASM besides C/C++/Rust. Because WASM lacks features for VM languages (and that is the big majority of languages). Did something in this regard change lately?
- rtpg 4y agoI wasn't being careful with my language. But we're basically looking at a continuation of the Emscriptem "hack" with WASM, meaning that you can run CPython in the browser and have a lot of third party pacakges work (much better than GraalVM's "PoC" Python interpreter). And yeah, I guess we're able to run things in the browser with WASM. One could say "well why use it on a machine outside the browser", to which I reply the obvious thing: hell of a lot easier to just use one VM rather than two. I think there are also social dynamics at play when it comes to _anything_ related to Oracle, which does poison the well. It's unfair to the GraalVM people's serious work, but it is what it is.
- flohofwoe 4y agoThere are plenty languages with WASM support that aren't "C-like" in this list (and you don't need special "GC support" in WASM to implement a GC in WebAssembly, at the cost of bundling the GC implementation in your WASM blob) https://github.com/appcypher/awesome-wasm-langs https://github.com/appcypher/awesome-wasm-langs
- still_grokking 4y ago
- sitkack 4y agoHilarious that you mention it, because Graal has a Wasm front end. https://www.graalvm.org/22.1/reference-manual/wasm/ https://www.graalvm.org/22.1/reference-manual/wasm/
- pjmlp 4y agoBasically what IBM and Unisys mainframes have been doing the last 60 years.
- flohofwoe 4y agoUnfortunately none of my users run IBM or Unisys mainframes (as far as I'm aware at least).
- pjmlp 4y agoWhat about Windows/Linux/macOS with CLR, or Android with ART?
- flohofwoe 4y agoThe task would involve compiling three big and complex C++ libraries (that have no equivalent in other languages) to the respective bytecode formats, and my past experiments (from the time before Emscripten was a thing) were not very successful. Maybe that has improved in the meantime, maybe not. Nothing beats clang's wasm output in that regard (e.g. both Emscripten's 'emcc' and Zig's 'zig cc' are drop-in replacements for a GCC-like toolchain which can produce WASM).
- still_grokking 4y agoBut you could run the JVM. Which does the same thing also since decades. The difference is: The JVM is already proven in production since a very long time.
- stefs 4y agoi'd really wish game mods would be run with WASM. the current solution of downloading native code from third party websites always makes me highly uncomfortable.