Wasmtime 1.0 Released - Bytecode Alliance Declares It Production Ready

[bug77]

not quite. there's still no way to load and run WASM in a browser without some JS code.

Oh, come on. That's a shim that is like 3 lines long.

[jKicker]

Well, interesting but not quite sure what benefit it has above wasmer.

These are some interesting reads.

https://wasmer.io/wasmer-vs-wasmtime

https://github.com/wasmerio/wasmer/issues/142

[ssokolow]

Well, interesting but not quite sure what benefit it has above wasmer.

These are some interesting reads.

https://wasmer.io/wasmer-vs-wasmtime

https://github.com/wasmerio/wasmer/issues/142

It's the official reference implementation, as I remember. Also, that first link may be PR-convenient out of date information. Back in 2021 Q1, this benchmark showed Wasmtime's LLVM backend being more competitive than Wasmer's diagram would indicate.

[bug77]

Well, interesting but not quite sure what benefit it has above wasmer.

These are some interesting reads.

https://wasmer.io/wasmer-vs-wasmtime

https://github.com/wasmerio/wasmer/issues/142

As a reference implementation, wasmtime's job is to make sure things included in the spec can actually be implemented. Oftentimes, when implementing things, you sometimes find edge cases that you didn't consider before or perhaps patterns that lead to improvements in the spec.
Having a RI is the bare minimum to prove your spec is not just full of hot air. It doesn't prevent anyone from building a better implementation or from building stuff on top of the RI.

[Michael_S]

The Enarx project runs WebAssembly (WASI) workloads in a trusted execution environment (TEE: such as Intel SGX, AMD SEV). WebAssembly gets us a few things:

• Security first: Wasi applications can only make networking connections with prior authorization. Apps also can only read/write files with authorization. So greater control with regard to what an application can do. It's like having an application-level firewall built in.
• Prevent vendor lock-in: Wasm applications don't know about the architecture being used (Intel vs. AMD). Normally, an application would have to be aware of the technology being used, but Wasm helps us abstract that away.
• Any language: Wasm/Wasi is it's a byte code format which is separate from a language, so developers can use any language which supports Wasi and run their code in a TEE (what we call a Keep). Rust, C, C++, Go, .net are the best supported today.
• Cross-platform: When ARMv9 and ARM's Confidential Compute Architecture (CCA) comes out, Enarx will allow running the exact same workload on different CPU architectures.

A nice thing about Wasm/Wasi is it's a byte code format which is separate from a language. So any application, any OS, any programming language can use it. For example, you could have a native application which has plugins which work on any OS/arch. Maybe Wasm beats Java at it's own game: "write once run anywhere".

Disclaimer: I'm one of the Enarx devs, so maybe biased about Wasm.

(emphasis mine)

As far as I understand it, one of the other selling points of WASM is that cross-language interoperability is simpler to implement and safer to guard against bugs and buffer overruns than using old-fashioned foreign function interfaces into C. So, at least in principle, your WASM app might have C++ compiled to WASM using a .NET library compiled to WASM.

And while Rust, C, C++, Go, and .NET are most mature at targeting WASM, I think just about every major language has compile-to-WASM as a point of focus. PHP-to-WASM, here we go!