Every single language I've seen that has been 'loved on HN as "taking over the world"' has had C FFI interop, whether it is Node, Rust, Python, Ruby, C#, Java, Haskell, Zig, Crystal, Julia, LUA, etc.

Web assembly is the browser C FFI, not some high level platform like Java or .Net. Your examples aren't comparable.

Failure to understand what bytecode based execution runtimes is all about it seems.

Also failure to understand that C ABI does not exist, rather it is the OS ABI from OS written in C, and that other OS, not written in C, don't have such thing as C ABI across all languages.

Examples of such OSes, IBM i, z/OS, Unisys ClearPath, UCSD, Unisys ClearPath, Classic Mac OS, UCSD, Native Oberon, Mesa/Cedar, Windows (plenty of stuff is .NET/COM/UWP nowadays), Android, ChromeOS, Garmin OS, and the Web.

So no, it isn't the browser C FFI, all major ones aren't even written in C for the past 20 years.

You have repeatedly missed the point of the discussion because you are hyper-focused on the implementation details that are irrelevant to the end user. I honestly don't know how you jumped from the JVM and CLR to Unisys Clearpath (twice) and Mesa/Cedar except as a red herring. The topic of discussion is Web Assembly which implies a modern browser.

The majority of browsers now support Web Assembly and about half the global population has a web browser and access to the internet - and now, access to an actual universal bytecode based execution runtime by nature of being part of the web browser standards instead of an OS feature or framework installation or (god forbid) Oracle TOS.

The C FFI part was an analogy. The whole point of Web Assembly is that it can't call out to just any library on the OS.

Except it can, because WebAssembly has long stop being a browser only story.

By the way, JVM on the browser, Flash CrossBridge and PNaCL were there first in what concerns "universal bytecode based execution runtime by nature of being part of the web browser".

I know I haven't worked with Java for the past 6 years (time flies!), but back then none of the 2 companies I worked for used anything else than Java on the JVM. In fact, until Kotlin came I only met one guy working with Scala, and nobody for the other languages. It was in France though,not in the US.

But I think your argument holds for CLR, were I've seen the 4 languages you mention being used altogether in the same code base.

I know you know this, but I’ll write it for other readers: there is even more languages on CLR if we count the one not supported by MS. Also, C native libraries and thus any language that can target it, can by used as well on Windows, Mac OS and Linux with PInvoke.

Hence why I posted a link to the language list on my first comment. :)