9 ms·
Again, you keep bringing these up, by they are not the same thing as WASM. Graal does not have a standard binary interchange format for compiled C/Rust/etc.-st
by Rusky 7y ago
Again, you keep bringing these up, by they are not the same thing as WASM.
Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in terms of program source.
The CLR's C++ support is nothing like WebAssembly C++- you either FFI to native code, bypassing the VM, or you compile a limited subset of C++ to unverified bytecode- and the latter doesn't support newer language standards and is being phased out.
WebAssembly solves both of these problems- existing compilers for any unmodified language can target its standard binary interchange format the same way they would target a hardware architecture, and run within its sandbox. WebAssembly doesn't need to add support for them, or know anything about their source form.
- chrisseaton 7y ago> Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs It does - LLVM bitcode.
- Rusky 7y agoLLVM bitcode is far worse than WASM bytecode as a standard binary interchange format. It is intentionally non-portable and unstable by its designers. Google tried using it for this purpose with PNaCl and it wasn't great. Apple makes it work by strictly controlling the target hardware they use it for, and with massive investment in the toolchain.
- chrisseaton 7y agoI didn't claim it was a good binary format - I just claimed GraalVM supports it, which it does.
- afiori 7y agoBut it is not an application delivery format which is the whole point here.
- pjmlp 7y agoSure it is, that is what watchOS uses.
- chrisseaton 7y agoI ship LLVM to deliver applications just fine.
- repolfx 7y agoThat's more a criticism of C rather than LLVM. Bitcode isn't as portable or stable as JVM bytecode because real world C programs use processor specific intrinsics, make assumptions about endianness and word sizes, embed assembly etc etc. LLVM is designed to support all real C programs, which means it can't be entirely portable. Wasm today is a toy hardly anyone uses. It can't run many real world C programs which means they'll need to be "ported" to the subset of C wasm supports. Well, if you're willing to work with that constraint you can constrain bitcode in the same way. By the way Graals LLVM support can execute multiple bitcode versions, with seamless and fast language interop, and it virtualises execution so that e.g. a subset of x86 assembly can be cross compiled on the fly to other arch's. It's needed because so much real C doesn't target an abstract machine but real CPUs.
- pjmlp 7y agoActually LLVM Bitcode can be made portable, that is what Apple does in their store apps for watchOS.
- pjmlp 7y agoBesides chrisseaton's answer, not only is C++/CLI already compatible with C++17, it will be part of .NET Core Windows variant, because it was yet another reason why we wouldn't migrate away from .NET Framework. WASM in its current form is still quite limited forcing language runtimes to bring along features that other battlefield proven solutions support out of the box. Hardly a synonym for unmodified.
- Rusky 7y agoC++/CLI is already full of incompatibilities with C++17 (and C++14, and C++11), and there are plans to cut off C++/CLI support with newer standards. Existing support is mostly by accident. Meanwhile "must distribute a runtime with the app" does not affect the language at all, and indeed applies to these other solutions as well.