WebAssembly Interface Types: Interoperate with All the Things

On topic though, I'll be curious to see how bad it really is. The demo video showed code that ended up looking and behaving like normal Rust code. Maybe you'll end up with some oddities like Rust enums not being supported, but w/e.

At the end of the day, I don't need to make weird and often gross C bindings in my Rust or Go code. Is that not a huge win?

But you're right, maybe this will go the way of the JVM and no one will care. Or maybe not. Does it matter?

edit: And I should add, maybe I keep forgetting where my well supported JVM Python <-> Rust or Go <-> Rust bridge is. Maybe someone can remind me, because I've not seen it.

I agree with the latter two due to runtime uniqueness, but not so sure it holds for Rust. Since C FFI has become the defacto WASM standard (with higher level interop coming as the article suggests), some low-overhead langs like Rust can be reasonably used elsewhere via WASM (though in most cases, you'd use them as native libs if you had the option).

Essentially it comes down to two things: How much of the WASM conformance is language-specific at compile time (e.g. for Go, stack resumption is manually built causing bloated WASM), and how much overhead does WASM interop cause at runtime (e.g. can it use the string interface type instead of converting to what it considers a string in local memory and what are the tradeoffs of each approach). If your language has a low WASM impedance mismatch at compile time and runtime, like Rust, it is a decent candidate for a WASM target. If your runtime has a low WASM impedance mismatch (e.g. the browser, native, and to some extent the JVM), it is a decent candidate to run that other decent-candidate WASM code without a huge overhead.

I've run Rust on the JVM [0], C in the browser, etc with decent performance because of those characteristics.

0 - https://github.com/cretz/asmble/tree/master/examples/rust-re...

The CLR already supports a larger variety of programming languages from dynamically typed languages like Ruby and Python, to C#, to F# for functional style programming.

It already exists with a rich ecosystem of libraries. The tools to generate CIL opcodes are pretty good and the developer tools with Intellisense are pretty good as well.

It has good packaging support with assemblies. And you can already compile .NET code to WASM using Blazor.

And with .NET already running on Linux, Win, Mac, iOS, Android, and IOT devices, I don't really see targeting WASM adding anything that doesn't already exist.

Java tied a whole ecosystem and was a pain to connect to anything outside, Parrot is a perennially incomplete half-arsed experiment, and C# has been historically tied to the MS ecosystem (and is also a pain to link to from outside).

The promise here is that the new system would have cross platform, cross vendor support (e.g. MS, Apple, Google, Mozilla), and that it wont be a pain to link to from, say, C or Rust or Python.

>WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did.

Doesn't need to. It's enough that it solves the same issue linking to a C library with bindings does, but without re-compilation, with a sandbox, and an easier interface.

I'd like to use e.g. something like Pillow or a numeric lib, etc, in WASM from languages outside Python...

I endorse this point of view, from hard-won experience.

(Also: memory model. Always memory model.)

In Rust, calling foreign functions is considered unsafe, precisely for that reason: once you leave the boundaries of a single language, the compiler can no longer enforce these invariants for you.

i.e. Figma said it reduced page load times by a factor of 3, though they were using WASM to replace existing asm.js code.

https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

Amendment: Perhaps it's debatable what "substantive benefit" would be, but writing the whole app in it is a huge benefit if you really want to do that. That is to say, for years people wanted to write Web UI stuff in various languages, this also allows for that.

So while the concrete performance boost may not be meaningful in writing an entire web app in C, Rust, Go, Python or w/e - to the developer happiness the boost may be huge for those devs that want it.

Most (all?) WASM runtimes currently enforce this isolation, though, for security reasons. If any do allow memories to be shared between modules, I'd imagine it'd be very explicit and opt-in.

So any vulnerability in any piece of wasm in your webpage effectively compromises everything. One compromised module can also likely reach out into the page and then use other modules' public interfaces to compromise them too. There is not sandboxing in place to prevent this sort of attack, the sandbox merely protects the browser from attack by content.

I'll explain you why in the most neutral tone I can.

Do you understand that biggest peddlers of inscrutinable executable format on the web are people who are not fine with the open nature of the Internet, and who can not make their business when all code available through the browser is available to at least minimal form of inspection?

In other words, the people who are mad because they can't run business in the web because their business model depends on their code being closed, they WANT THIS big time. Their business thrives off non-interoperability and brokennes of software at large. Their success comes at the detriment of the Internet ecosystem at large. The more they brake the Internet for the rest of its users, the more money they can make, and this is why there can not be reconciliation with them and, us, the wider and more sane part of software developer community.

And we, the engineering cadres, the most influential class of people in the new tech driven world, have all the influence needed to deny WASM adoption.