4 ms·

I started using WebAssembly in earnest a few months ago to make a backend auth library that works in several different languages[0]. It's built on Extism[1], wh

I started using WebAssembly in earnest a few months ago to make a backend auth library that works in several different languages[0]. It's built on Extism[1], which abstracts away some of the interfacing complexity. It's been an awesome experience. Frequently feels like magic. WASM is in an interesting place. The value has clearly been proved with a pretty minimal core spec. Now there's a big push to implement a much larger API surface for WASI and the Component Model. A lot of people in the community are concerned about this direction, or at least the way it's happening[2]. For my part, I hope WASM doesn't go the way of the rest of web browsers where it gets so complicated that only big tech is capable of making implementations and experimenting. [0]: https://github.com/lastlogin-net/decent-auth https://github.com/lastlogin-net/decent-auth [1]: https://extism.org/ https://extism.org/ [2]: https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html

pjmlp 2y ago
It will be re-inventing the whole application containers ecosystems we had back a few decades ago across JVM and CLR ecosystems.
- apitman 2y ago
  When you jump into every WASM thread with this take, what are you trying to accomplish?
  - pjmlp 2y ago
    Make everyone aware, born after 2000's what is being re-invented, while being sold as innovative. You are free to ignore my comments.
    - apitman 2y ago
      That's a fair reason. It's important to realize how often we re-invent the wheel in our field. As an example, you're an expert in distributed systems, which I've only recently started dabbling in. In the process I'm learning how so many of the fancy "new" distributed systems and we have today were essentially invented decades ago. But in the WASM case, to what end? There's a cost to your comments. I'm sharing an example of how WASM has helped me solve a real problem, and might solve real problems for other people. Your comments create noise to these types of discussions. Maybe it's worth the tradeoff in your mind, but I'm curious what your end goal is?
      - fc417fc802 2y ago
        I can't speak to his purpose but for myself I find it interesting to consider the differences that lead WASM to help you solve a real problem where the preexisting solutions presumably didn't.
    - pie_flavor 2y ago
      WASM is designed to be embedded and its model is that of native code rather than any particular high-level language's primitives. It is closer to LLVM than Java. Comparisons to Java are surface-level and boring, since all foundational reasons why Java failed are false of WASM.
      - pjmlp 2y ago
        Interestingly enough, people keep forgetting that since UNCOL in 1958 there were many polyglot bytecode based runtimes, because comparing to Java is always easier argument.
        pie_flavor 2y ago
        You're the one who brought it up. Make a good point or don't.
    - panick21_ 2y ago
      Believe it or not, just because on an abstract technically something similar has been done before, its possible for people to still care about something that is being built. Reinventing the wheel is perfectly fine and even good, special if it happens in a different context and with a different community and process. And the WebAssembly people are well aware that Java/CLI exist and are learning from it. Making the same comment on every single Webassembly thread for the last couple years as if the everybody working on WebAssembly or WASI is some bro-programer born in 2008 is just disrespectful to the engineers working on these projects. Sorry that we are not all as cool as you and use UNCOL everyday. I mean who would want to use a technical idea that isn't first of its kind.
- tadfisher 2y ago
  Seems to have a lot more momentum though? I can run Haskell on WASM, and all the backends for JVM and CLR are long dead. More to the point, I can target the browser without plugins, lock-in, or security problems.
  - pjmlp 2y ago
    And in a couple of years the same will most likely happen to the WASM backend. That was already possible with Haskell to JavaScript.
    - pie_flavor 2y ago
      For all browser targets to die, people must no longer be interested in writing Haskell while writing webapps, even though people will probably remain interested in writing Haskell, and probably remain writing webapps, which seems unlikely. For the WASM target to die and the JS target to remain, this would have to mean that there is some technical barrier that makes the maintenance burden not worth the staggering performance gain, and if there is some such burden I am not aware of it. 'Java died so WASM will die because both are VMs' is basically a content-free dismissal - what do you actually think will no longer be needed, or is currently not needed but overvalued, and why?
      - pjmlp 2y ago
        Yet we are talking about targeting the server in this thread, because so far the tooling for the browser sucks, and VCs are more willing to sponsor startups selling server products. Java not only is pretty much alive on the server, so is .NET, Erlang, and plenty of compiled languages that have always been a better alternative to JavaScript.
        pie_flavor 2y ago
        I am comparing your words about WASM to your words about JS. Misdirections about VCs are irrelevant. You can expect the WASM target to have as great or greater longevity than the JS target, and if your prediction about future failure isn't true of JS then it won't be true of WASM.
nilslice 2y ago
One of the maintainers of Extism here! Thank you for the kind words. As you know, we're all about delivering value with the actual standards today. This means using truly portable, w3c Wasm core modules. Not some "maybe in the future" standard a la Components. If you realistically want to use Wasm everywhere, in practically every language, Extism is the way to go and we're in it for the long haul. For those who appreciate the WIT IDL being worked on (now for way too long), we support a far simpler, more familiar OpenAPI based version to eliminate the boilerplate of type conversion & serialization across the guest-host boundary, worth checking out: https://github.com/dylibso/xtp-bindgen https://github.com/dylibso/xtp-bindgen
- apitman 2y ago
  Thank you for Exstism. My main request is that you keep the core interface as simple and forkable as is feasible. You're certainly incentivized to make it as complicated as possible so only your team can maintain it, but I hope you're able to find a sustainable business model that doesn't go down that path.
  - nilslice 2y ago
    I wouldn’t say incentivized, but temptation would lead to that. We are not tempted though. We build new things on the same open, simple interfaces we want to support long term. For example, https://mcp.run https://mcp.run is one such business we are very excited about — and it is Extism at the core. No modifications to the runtime, just the same Extism we all know and love. And we want way more than our own team to help maintain the open source project, no doubt about that! So simplicity and transparency are the name of the game.
yoshuaw 2y ago
I agree about what your concerns about complexity, but the way I see what we're encapsulating is almost entirely essential. To draw analogies with native binaries: - Wasm is a (virtual) instruction format for programs to be compiled into (think: x86). - Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF). - WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files). To reach our goal of having shared, portable binaries that aren't locked into any one vendor we need all three. A standard instruction set, standard calling convention, and standard syscalls. Wasm Components and WASI might not be necessarily be perfect, but at a minimum they're targeting the right scope. And that carries essential complexity.
- MisterTea 2y ago
  > A standard instruction set, standard calling convention, and standard syscalls. This sounds like an OS like user space to run atop WASM similar to POSIX. Standards are good but my hope is the design is well thought out.
- apitman 2y ago
  I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it? Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers. I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.
  - yoshuaw 2y ago
    > Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable. Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs. [1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/WASI/blob/main/Proposals.md
w10-1 2y ago
I'd love to hear why WASM now has more promise than Java 1.x. Java's subsequent development was driven by enterprise/containers (mainly Oracle), and the VM has stayed relevant for 30 years by incorporating dozens of advances in machine and programming models. Both successful and lamentable. If WASM (i.e., the loose collection of organizations driving it) could do it better than Java, wouldn't Java (with all its resources and organization) have already done it? The answer has to lie in unsustainable or limiting technical decisions. What exactly are the design decisions WASM made to make it seem like it would escape becoming Java-like?
- pie_flavor 2y ago
  Roughly the same reason as every time someone asks the same question in any post that mentions WASM: Java is a particular model with a particular view of the world, tied to a GC and a particular standard library and various hard limitations such as no user-defined value types that make it impossible to compile C code to properly and run it with reasonably C-like speed. Just because Java has incorporated dozens of 'advances' doesn't mean any of them address its longstanding problems, and you're mixing implementation tech with spec design in your reasoning. You, in your daily life, likely use zero software incorporating Java and multiple pieces of software incorporating WASM. You cannot imagine using Java for shaping functions embedded in font files, or sandboxed 'native' modules in a JS-based text editor, or blockchain smart contracts. In fact Java basically cannot be reliably sandboxed at all.
- apitman 2y ago
  Because WASM is currently solving a real problem for me that Java can't solve, ie easily embedding code I wrote in one language into many other languages. You can do something similar with shared libraries, but you have to compile them for every architecture and OS and solve the associated distribution problems. Ask Python and JS how that works out in practice. A WASM artifact runs everywhere, and has addition security benefits.

pjmlp 2y ago

It will be re-inventing the whole application containers ecosystems we had back a few decades ago across JVM and CLR ecosystems.

apitman 2y ago
When you jump into every WASM thread with this take, what are you trying to accomplish?
- pjmlp 2y ago
  Make everyone aware, born after 2000's what is being re-invented, while being sold as innovative. You are free to ignore my comments.
  - apitman 2y ago
    That's a fair reason. It's important to realize how often we re-invent the wheel in our field. As an example, you're an expert in distributed systems, which I've only recently started dabbling in. In the process I'm learning how so many of the fancy "new" distributed systems and we have today were essentially invented decades ago. But in the WASM case, to what end? There's a cost to your comments. I'm sharing an example of how WASM has helped me solve a real problem, and might solve real problems for other people. Your comments create noise to these types of discussions. Maybe it's worth the tradeoff in your mind, but I'm curious what your end goal is?
    - fc417fc802 2y ago
      I can't speak to his purpose but for myself I find it interesting to consider the differences that lead WASM to help you solve a real problem where the preexisting solutions presumably didn't.
  - pie_flavor 2y ago
    WASM is designed to be embedded and its model is that of native code rather than any particular high-level language's primitives. It is closer to LLVM than Java. Comparisons to Java are surface-level and boring, since all foundational reasons why Java failed are false of WASM.
    - pjmlp 2y ago
      Interestingly enough, people keep forgetting that since UNCOL in 1958 there were many polyglot bytecode based runtimes, because comparing to Java is always easier argument.
      - pie_flavor 2y ago
        You're the one who brought it up. Make a good point or don't.
  - panick21_ 2y ago
    Believe it or not, just because on an abstract technically something similar has been done before, its possible for people to still care about something that is being built. Reinventing the wheel is perfectly fine and even good, special if it happens in a different context and with a different community and process. And the WebAssembly people are well aware that Java/CLI exist and are learning from it. Making the same comment on every single Webassembly thread for the last couple years as if the everybody working on WebAssembly or WASI is some bro-programer born in 2008 is just disrespectful to the engineers working on these projects. Sorry that we are not all as cool as you and use UNCOL everyday. I mean who would want to use a technical idea that isn't first of its kind.
tadfisher 2y ago
Seems to have a lot more momentum though? I can run Haskell on WASM, and all the backends for JVM and CLR are long dead. More to the point, I can target the browser without plugins, lock-in, or security problems.
- pjmlp 2y ago
  And in a couple of years the same will most likely happen to the WASM backend. That was already possible with Haskell to JavaScript.
  - pie_flavor 2y ago
    For all browser targets to die, people must no longer be interested in writing Haskell while writing webapps, even though people will probably remain interested in writing Haskell, and probably remain writing webapps, which seems unlikely. For the WASM target to die and the JS target to remain, this would have to mean that there is some technical barrier that makes the maintenance burden not worth the staggering performance gain, and if there is some such burden I am not aware of it. 'Java died so WASM will die because both are VMs' is basically a content-free dismissal - what do you actually think will no longer be needed, or is currently not needed but overvalued, and why?
    - pjmlp 2y ago
      Yet we are talking about targeting the server in this thread, because so far the tooling for the browser sucks, and VCs are more willing to sponsor startups selling server products. Java not only is pretty much alive on the server, so is .NET, Erlang, and plenty of compiled languages that have always been a better alternative to JavaScript.
      - pie_flavor 2y ago
        I am comparing your words about WASM to your words about JS. Misdirections about VCs are irrelevant. You can expect the WASM target to have as great or greater longevity than the JS target, and if your prediction about future failure isn't true of JS then it won't be true of WASM.

nilslice 2y ago

One of the maintainers of Extism here! Thank you for the kind words. As you know, we're all about delivering value with the actual standards today. This means using truly portable, w3c Wasm core modules. Not some "maybe in the future" standard a la Components. If you realistically want to use Wasm everywhere, in practically every language, Extism is the way to go and we're in it for the long haul. For those who appreciate the WIT IDL being worked on (now for way too long), we support a far simpler, more familiar OpenAPI based version to eliminate the boilerplate of type conversion & serialization across the guest-host boundary, worth checking out: https://github.com/dylibso/xtp-bindgen https://github.com/dylibso/xtp-bindgen

apitman 2y ago
Thank you for Exstism. My main request is that you keep the core interface as simple and forkable as is feasible. You're certainly incentivized to make it as complicated as possible so only your team can maintain it, but I hope you're able to find a sustainable business model that doesn't go down that path.
- nilslice 2y ago
  I wouldn’t say incentivized, but temptation would lead to that. We are not tempted though. We build new things on the same open, simple interfaces we want to support long term. For example, https://mcp.run https://mcp.run is one such business we are very excited about — and it is Extism at the core. No modifications to the runtime, just the same Extism we all know and love. And we want way more than our own team to help maintain the open source project, no doubt about that! So simplicity and transparency are the name of the game.

yoshuaw 2y ago

I agree about what your concerns about complexity, but the way I see what we're encapsulating is almost entirely essential. To draw analogies with native binaries: - Wasm is a (virtual) instruction format for programs to be compiled into (think: x86). - Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF). - WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files). To reach our goal of having shared, portable binaries that aren't locked into any one vendor we need all three. A standard instruction set, standard calling convention, and standard syscalls. Wasm Components and WASI might not be necessarily be perfect, but at a minimum they're targeting the right scope. And that carries essential complexity.

MisterTea 2y ago
> A standard instruction set, standard calling convention, and standard syscalls. This sounds like an OS like user space to run atop WASM similar to POSIX. Standards are good but my hope is the design is well thought out.
apitman 2y ago
I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it? Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers. I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.
- yoshuaw 2y ago
  > Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable. Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs. [1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md https://github.com/WebAssembly/WASI/blob/main/Proposals.md

w10-1 2y ago

I'd love to hear why WASM now has more promise than Java 1.x. Java's subsequent development was driven by enterprise/containers (mainly Oracle), and the VM has stayed relevant for 30 years by incorporating dozens of advances in machine and programming models. Both successful and lamentable. If WASM (i.e., the loose collection of organizations driving it) could do it better than Java, wouldn't Java (with all its resources and organization) have already done it? The answer has to lie in unsustainable or limiting technical decisions. What exactly are the design decisions WASM made to make it seem like it would escape becoming Java-like?

pie_flavor 2y ago
Roughly the same reason as every time someone asks the same question in any post that mentions WASM: Java is a particular model with a particular view of the world, tied to a GC and a particular standard library and various hard limitations such as no user-defined value types that make it impossible to compile C code to properly and run it with reasonably C-like speed. Just because Java has incorporated dozens of 'advances' doesn't mean any of them address its longstanding problems, and you're mixing implementation tech with spec design in your reasoning. You, in your daily life, likely use zero software incorporating Java and multiple pieces of software incorporating WASM. You cannot imagine using Java for shaping functions embedded in font files, or sandboxed 'native' modules in a JS-based text editor, or blockchain smart contracts. In fact Java basically cannot be reliably sandboxed at all.
apitman 2y ago
Because WASM is currently solving a real problem for me that Java can't solve, ie easily embedding code I wrote in one language into many other languages. You can do something similar with shared libraries, but you have to compile them for every architecture and OS and solve the associated distribution problems. Ask Python and JS how that works out in practice. A WASM artifact runs everywhere, and has addition security benefits.