None of what 'jcmfernandes lists are part of WebAssembly. At best they can be considered related technologies, like the relationship between the JVM and JavaBeans.
And in terms of design, they're closer to COM or OLE. The modern replacement for CORBA/DCOM/etc is HTTP+JSON (or gRPC), which doesn't try to abstract away the network.
I've had the misfortune of working professionally with CORBA, and I've spent some time trying to keep up with WIT/WASI/that whole situation. Whatever WIT is going to be, I can assure you it's very different from CORBA.
The best way I think to describe WIT is that it seems to be an attempt to design a new ABI, similar to the System V ABI but capable of representing the full set of typesystems found in every modern language. Then they want to use that ABI to define a bunch of POSIX-ish syscalls, and then have WebAssembly as the instruction set for their architecture-independent executable format.
The good news is that WIT/WASI/etc is an independent project from WebAssembly, so whether it succeeds or fails doesn't have much impact on the use of WebAssembly as a plugin mechanism.
Correct, they are a part of WASI. Indeed, different things, but well, tightly related. Made sense to talk about them given the chat on bridging gaps in bazel using WASM.
Yes, the concept is old. I may be wrong, but to me, this really seems like it, the one that will succeed. With that said, I'm sure many said the same about the technologies you enumerated... so let's see!
