3 ms·

> No process nor code is trusted in my company. Then you cannot use any modern computer in your company. Much less hypercomplex systems like Node, v8 and JITs

> No process nor code is trusted in my company. Then you cannot use any modern computer in your company. Much less hypercomplex systems like Node, v8 and JITs in general. > compared to the multi-million risks What "risks"? What standards are you following? Insurance? > WASM execution can be optimized a lot as it goes past MVP. Citation needed. There is no magic. > I don't know how to import a ES6 module using C ABI. So that is why you want WASM?

TomMarius 6y ago
V8, JVM, CLR and others are well proven runtimes providing a well functioning sandbox, but of course we test a lot. I am sure you know what the risks are with native code - you're a native code proponent after all; any code running in a medium and bigger company that could misplace money is a huge liability. I don't know what magic you're talking about - we're simply waiting for WASM to standardize GC, SIMD, tail calls etc, you can read more here[0]; and to get the execution optimized like V8 did over the past 10 years[1] (WASM on V8 gets most of these gains by default as a bonus). I already said why I want WASM: because it provides a good sandbox and opens most ecosystems through safe and typed interop. I don't care about ES modules in particular - I care about ES modules, Ruby modules, Python modules, Prolog modules, Fortran modules, C modules, Rust modules, AssemblyScript modules, COBOL modules, Erlang modules, F# modules, Java modules, and so on - at once. Finally a future where I can use and trust any library and not get limited to the language I use (if I don't want to spend most of my time fighting and securing C ABI interop, if at all humanly possible) is there. [0] https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals [1] https://v8.dev/blog/10-years#performance-ups-and-downs https://v8.dev/blog/10-years#performance-ups-and-downs

TomMarius 6y ago

V8, JVM, CLR and others are well proven runtimes providing a well functioning sandbox, but of course we test a lot. I am sure you know what the risks are with native code - you're a native code proponent after all; any code running in a medium and bigger company that could misplace money is a huge liability. I don't know what magic you're talking about - we're simply waiting for WASM to standardize GC, SIMD, tail calls etc, you can read more here[0]; and to get the execution optimized like V8 did over the past 10 years[1] (WASM on V8 gets most of these gains by default as a bonus). I already said why I want WASM: because it provides a good sandbox and opens most ecosystems through safe and typed interop. I don't care about ES modules in particular - I care about ES modules, Ruby modules, Python modules, Prolog modules, Fortran modules, C modules, Rust modules, AssemblyScript modules, COBOL modules, Erlang modules, F# modules, Java modules, and so on - at once. Finally a future where I can use and trust any library and not get limited to the language I use (if I don't want to spend most of my time fighting and securing C ABI interop, if at all humanly possible) is there. [0] https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals [1] https://v8.dev/blog/10-years#performance-ups-and-downs https://v8.dev/blog/10-years#performance-ups-and-downs