There's a lot of very lovely very interesting very enjoyable Function-as-a-Service things & platforms, and server-side wasm is one very promising generic way to

There's a lot of very lovely very interesting very enjoyable Function-as-a-Service things & platforms, and server-side wasm is one very promising generic way to be able to potentially simmer down & make generic & very fast these networks of functions. Today FaaS (ex: aws lambda) are most frequently run by having a process for each function, but with wasm the nice sandbox system/object-capabulities style, everyone can share a runtime & have less barrier crossing & much less overhead. There's a ton of near magic properties here that could help radically change how we write & maintain systems, shifting us from big blocky monoliths to something more like an Erlang universe, where there's lots of small interoperating pieces, sharing a common fabric that stitches them together. I think the CloudFlare Workers world probably comes the closest to showing off these promises, and it's a pretty slick elegant low fluff take, that also comes with very big advantages about being architected from the start to have many many deployment points, with the ability for individual workers to come & go on demand at very high speed at any given deployment site. We can also easily spot incipient demand for wasm by just looking at all the places folks embed scripting languages. Every time you see a Lua scripting engine (neovim, nginx, a million other places), you could potentially have any langauge you please. And given the lightweight sandbox, how quick it is to spawn instances, we can make our software pipelines much more user configurable & dynamic. A good parallel is the kernel, which has become much more capable of programmed behavior via the addition of ebpf to instrument not just networking but all kinds of subsystems. This has lead to huge wins, huge gains in all kinds of very fast very secure networking interlinks, with record low overhead. It's being used to help remap weird input devices behaviors, and dozens of other interesting little things you only get by having some flexibility built in. Rather than hard-coded subsystems everywhere. Wasm is lined up to be the ebpf of user land systems, it is the thing that allows apps to bake in flexibility & programmability, in a fast, safe, interoperable way. The discussion here is about how the library of wasm modules can arise & reinforce each other. The cynicism against interoperability, suggesting source translation, is blind to the use cases above. It doesn't see the Erlang view of the world, it's rooted in the boring legacy view that computing is and always will be giant monolithic apps doing three million different things within the confines of the colossus-sized process. Having other alternatives to computing where we can have a sea of smaller units that message each other doesn't have a clear & obvious triumph, it's not inherently obviously better than the megaprocess view of the universe, but it should be possible & we should find out what we can do. And even if the femto-service / Nano-function model ends up being bad, we'll still have apps that have a well established means & well supported common tool chains for adding programmability in. That requires a mature interoperable modular system to get anywhere, and thankfully folks aren't scared off from trying, not dissuaded because someone mentions the CORBA boogeyman under the bed & tries to gloom us away. This is incredibly promising technology & I recommend everyone come evaluate it with a positive hopeful light. I hope I've helped share good outlooks that can help get folk excited (as they should be!)