WebAssembly lacks many standard system interfaces, making it difficult to reuse existing applications.
… despite many years of standardization efforts, WASI remains an extremely simplified OS interface which lacks support for common OS features like memory-mapping, process fork/exec, asynchronous I/O, and signals. Many applications require these features and simply cannot run on WASI.
Wasm asserts a specific set of design goals, one of which is “platform independence”, and none of which are “allow the reuse of existing applications”. So I’m rather confused by this paper — it defines an interface that appears to violate the explicit goal of platform independence, in order to solve a “problem” that isn’t actually a goal of the project.
But I might be missing something! If so, I’m eager to be educated…
I’d posit that a project can find uses that either weren’t envisioned originally, or weren’t a key design goal. To me, this is a nice option to have in your toolkit.
I think there’s a difference between uses that weren’t envisioned and uses that run directly counter to the goals of the ecosystem. Microsoft J++ extended Java in ways that weren’t envisioned, by directly exposing Win32 APIs to Java so that Java apps could be tightly coupled with Windows. This was directly counter to the goal of Java to make applications portable across operating systems.
This has the same feel: WebAssembly exists to be OS and architecture agnostic. Adding CPU-specific or OS-specific things is both counter to the goals and also risks significantly undermines the value proposition.
Sure! But in that case, I would expect anything like this paper to make it clear that it’s operating outside of the defined goals of Wasm, which (AFAICT) it doesn’t do.
Don’t get me wrong, I’d love to see all the binary package repositories at some point to become deprecated and replaced with a single WASM package target but I’m not sure if this gets us closer or farther from that goal.
I wouldn’t, at least not with WASM in its current form. If we’re going to provide an IR that we distribute target-agnostic binaries in, please let’s not pick one that conflates pointers and integers. Current targets may not be able to enforce object-granularity memory safety without significant overhead, but let’s not bake in a design that precludes it in the future.
Now, if you’d said MS-WAsm, I might agree. Not sure what the current status is, but their abstractions were the right ones for enabling software or hardware memory safety on a per-program basis.
Wasm asserts a specific set of design goals, one of which is “platform independence”, and none of which are “allow the reuse of existing applications”. So I’m rather confused by this paper — it defines an interface that appears to violate the explicit goal of platform independence, in order to solve a “problem” that isn’t actually a goal of the project.
But I might be missing something! If so, I’m eager to be educated…
I’d posit that a project can find uses that either weren’t envisioned originally, or weren’t a key design goal. To me, this is a nice option to have in your toolkit.
I think there’s a difference between uses that weren’t envisioned and uses that run directly counter to the goals of the ecosystem. Microsoft J++ extended Java in ways that weren’t envisioned, by directly exposing Win32 APIs to Java so that Java apps could be tightly coupled with Windows. This was directly counter to the goal of Java to make applications portable across operating systems.
This has the same feel: WebAssembly exists to be OS and architecture agnostic. Adding CPU-specific or OS-specific things is both counter to the goals and also risks significantly undermines the value proposition.
Sure! But in that case, I would expect anything like this paper to make it clear that it’s operating outside of the defined goals of Wasm, which (AFAICT) it doesn’t do.
“The street finds its own use for things.” –William Gibson.
Yes, let’s just make it yet another POSIX, and destroy it.
Does WASM need to become Docker?
Don’t get me wrong, I’d love to see all the binary package repositories at some point to become deprecated and replaced with a single WASM package target but I’m not sure if this gets us closer or farther from that goal.
I wouldn’t, at least not with WASM in its current form. If we’re going to provide an IR that we distribute target-agnostic binaries in, please let’s not pick one that conflates pointers and integers. Current targets may not be able to enforce object-granularity memory safety without significant overhead, but let’s not bake in a design that precludes it in the future.
Now, if you’d said MS-WAsm, I might agree. Not sure what the current status is, but their abstractions were the right ones for enabling software or hardware memory safety on a per-program basis.
Need to or not, it’s already well on the way to becoming exactly that for the “edge compute” / “serverless” niche at the very least.