I'm very happy to see the WebIDL proposal replaced with something generalized.

The article brings up an interesting point:

Webassembly really could enable seamless cross-language integration in the future.

Writing a project in Rust, but really want to use that popular face detector written in Python?

And maybe the niche language tokenizer written in PHP?

And sprinkle ffmpeg on top, without the hassle of target-compatible compilation and worrying about use after free vulnerabilities?

No problem use one of the many WASM runtimes popping up (like [1], [2]) and combine all those libraries by using their pre-compiled WASM packages distributed on a package repo like WAPM [2], with auto-generated bindings that provide a decent API from your host language.

Sounds too good to be true? Probably, and there are plenty of issues to solve.

But it sounds like a future where we could prevent a lot of the re-writes and duplication across the open source world by just tapping into the ecosystems of other languages.

[1] https://wapm.io/ [2] https://github.com/CraneStation/wasmtime [2] https://wapm.io/

JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language".

Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they didn't, and WASM won't.) At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc. And all of those will feel like a cousin to JavaScript, just as anything on the JVM feels similar to Java, on Parrot feels similar to Perl 6, and on the CLR feels similar to C#. WASM's choice of data structures, control flow, and data representations will be strongly influenced by the requirements of the major JavaScript engines (in Firefox, Chrome, and maybe WebKit). This is already the case when it comes to control flow semantics.

Could it be that JVM and CLR were technically correct, but policy wrong?

It is more politics than anything else, with WASM being the new cool kid on the block.

You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.

Would you please share the "very specific technical differences"?

As a long-time JVM user, I am curious about WASM and how it compares to the JVM and CLR.

As far as I know, WASM was thought of as a compilation target for languages like C and Rust, which are quite different from Java and C#.

That alone should make WASM quite different from the JVM, no?

The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis.

As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System.

Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,....

IBM and UNISYS mainframes language environments support a mix of COBOL, C, C++, Fortran, RPG, NEWP, also with a common type system for interoperability.

While UNISYS documents are a bit hard to come by, IBM ones are available as RedBooks.