[feniv]

WebAssembly on desktop and servers is maturing pretty rapidly! There are several backend interpreters already in Rust and Go (life). The native, compiled options are even faster, Fastly's Lucet compiler and runtime was one of the first to implement WASI (https://wasi.dev/): https://www.fastly.com/blog/announcing-lucet-fastly-native-w...

The differentiator for InNative seems to be the ability to bypass the sandbox altogether as well as additional native interop with the OS. Looks promising!

[forty]

I'm wondering what's the point of compiling server side stuff in wasm? Unless I forgot something, all main server languages are rather portable already, either because they are interpreted (python, node, jvm...) or can be compiled to many targets (rust, go...).

[zaarn]

You're not confined by the instruction set below. It no longer matters if your language supports PowerPC, Power8, x86, x86_64, ARMv5 through v8 or even more exotics. Similar to the Java VM, which definitely showed the advantage of being more easily portable, it decouples the binary you deploy from the actual hardware.

Rust and Go have support for many targets but not as many as other compilers (GCC), a coverage problem that can be fixed by using WASM as intermediate and porting a WASM Runtime to that architecture.

Something like Innative would also enable desktop applications to be independent of the OS and architecture. The same binary would run on x86_64 Windows, PowerPC Mac and ARMv8 Linux.

It's basically Java but you don't have to use Java to get all the good parts.

(Disclaimer: I know the main dev of innative and do some WASM work myself)

[AnIdiotOnTheNet]

> It no longer matters if your language supports PowerPC, Power8, x86, x86_64, ARMv5 through v8 or even more exotics

Yeah, instead it matters which WASM runtimes it supports and which archs those runtimes support.

But that's ok, we just need one more layer of abstraction to fix the whole mess.

[zaarn]

For innative it matters what LLVM supports and LLVM supports already dictates the support of many programming languages atleast as a superset (Rust and Go support a subset of what LLVM supports), I don't see how this is "one more layer of abstraction will fix the whole mess" when it reuses existing abstractions.

[her_tummy_hurts]

WASM is based off of a specification, so compilers target the spec instead of an individual runtime.

[fanf2]

It’s yet another UNCOL (1958) or ANDF (1987) :-)

https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...

[zaarn]

Doubtful considering how much work is being done around WASM.

[pjmlp]

Usually being hyped by people that apparently don't know the history of bytecode formats since the early 60's.

[zaarn]

I'm well aware of the history of bytecode formats, Java was pretty successful for a while, even managed to get in the Browser and only failed there due to a lack of a DOM Interaction story and similar integration problems.

There is already plenty of companies that deployed WASM on their stack (like Ebay, they use Wasm for their barcode scanner), it's not going away any time soon.

[vijaybritto]

You don't have to recompile for different architectures. Just compile once to wasm and it will run in all platforms it supports at the same speed. Note: the author mentions this too.

"WebAssembly’s 32-bit integer indexes break LLVM’s vectorization due to pointer aliasing. Once fixed-width SIMD instructions are added, native WebAssembly will close the gap entirely, because this vectorization analysis will have happened before the WebAssembly compilation step."

[pjmlp]

UNCOL, ANDF, P-Code, M-Code, JVM, PNaCL, MSIL, TIMI, ...

[aclatuts]

It is nice in development to have bcrypt, openssl, etc for other languages without a build step and build tools