Many years ago, there was a programming language experiment named Wyvern that promised the polyglot developer he could, in the same file, write each function in a different language, and it would all work. It was a crazy idea at the time, but now? Now we write this way all the time. The Web Assembly Component Model is only going to make that all the more true.
WASM has a virtue: at its core, the only thing it can do with the outside
world is access an array of memory made up of 32-bit integers. That's it. On
it's own it can't do anything else. You can write those functions in any
language you want, but WASM is a pure, functional interface: you put data in,
you get data out. Any language that supports functions of type
(data: i32) -> i32) can be compiled into WASM. The list of common languages that can compile
to WASM and are considered production-ready is already impressive: C, C#, C++,
COBOL, F#, Forth, Go, Lua, Rust, TypeScript, WebAssembly, Zig. And there are
many more in the works. The
"mature" languages all support interfaces that allow each functiIon to access
becoming less "necessarily so" with every day), and provide mappings so that
strings and dictionaries and such can be serialized back and forth via
All that copying and translating of
i32 can be expensive, though. WASM isn't
like game programming where 3D rendering a
frame has lots of internal mathematical needs.
The Wyvern Programming Language
Over a decade ago, the Wyvern programming language promised that if you had a strong type-definition for a language, you could add that language's syntax to Wyvern and it would Just Work. You could write one function in C and another in Python and a third in Scheme all in the same file and the Wyvern compiler would create the appropriate interfaces for each function to be able to call any other, as long as the types matched up.
Only young academics head-deep into Programming Language Theory would think "You know, this recursive function to traverse the character list is best implemented in Scheme, but the renderer is easier in C, and I'll just shove them all into the same file."
The Web Assembly Component Model: Wyvern 2.0?
The Component Models for WASM provides a promise similar to Wyvern. You can write many different functions in whatever language is most appropriate for each function's need, and the WASM-CM will figure out how to make the passing of data between one function and the next as efficient and copy-free as possible within the VM. It will no longer be necessary, as it is now, for the host environment to mediate the passing of data between different WASM code.
There are different ways of thinking about this:
First, this could be Wyvern 2.0. The functions wouldn't necessarily all be in the same file, but they would be in the same project, and would require developers be fluent in the different languages used to implement the various functions used by the project.
Second, this could be an evolution in the skillset developers need to master. Functional programmers who think Haskell and Rust are nifty are part of this evolution. The function signature contains the truth, and the description of the function is all we need. Developers wouldn't need to be fluent in the language at all; they just use the function that Does The Thing.
We've already been here for awhile
I've started to call this methodology "sorcerous programming;" we don't understand what's going on under the hood. We just try to use the library according to the description given in the documentation, invoking it through ritual and guesswork, testing our assumptions and empirically determining that the library's behavior is "good enough."
In many ways, the WASM-CM model is just going to make that sorcery more prominent. We have APIs we tickle for data, and it gives it, and we don't know where it came from. Large language models like Chat-GPT and Stable Diffusion produce text and images based on our prompts, but we have no idea why changing the position of two words in our prompt means the characters drawn will or won't have the right number of fingers. The React scheduler means that our web pages might behave correctly, but if the programmer doesn't have the right kind of experience it's entirely possible the page might misbehave if the computer is slower than the hot boxes developers typically have.
And The Train It Won't Stop Going, No Way To Slow Down
I'm hopeful. We're already in a place where Madness abounds; developers are burning out because they're expected to know how to do thirty different things while actually holding "the business value" or the "return on investment" in their heads. Programming has always been hard, but web development is notoriously so, spawning articles like How Web Development Got So Complicated andI Can't Keep Up. I don't know if WASM-CM will make it any better, or if it'll just be Another Thing we're all just gonna have to live with. But I have to be hopeful, because the alternative is just disappointingly more workload with less reward.