4 ms·

No mention of working with the WASM component model.

• nilslice 2y ago
  of course not - Go has taste and appreciates quality and simplicity.
  • euroderf 2y ago
    The WASM IDL for components (WIT) seems sleek enough.
    • nilslice 2y ago
      its fine, I prefer ours more oriented around a familiar format like OpenAPI https://github.com/dylibso/xtp-bindgen https://github.com/dylibso/xtp-bindgen
• jallasprit 2y ago
  Feel free to elaborate, because I have never heard about it either.
  • boomskats 2y ago
    From the wasi.dev[0] front page: > WASI can be implemented by both core Wasm modules and applications built according to the Component Model, a specification for Wasm applications that are interoperable and composable. You can learn more about components in the Bytecode Alliance's WebAssembly Component Model documentation[1]. [0]: https://wasi.dev/ https://wasi.dev/ [1]: https://component-model.bytecodealliance.org/ https://component-model.bytecodealliance.org/
    • jcmfernandes 2y ago
      I thought that WASI and the component model were separate specs. Am I wrong?
      • 4ad 2y ago
        WASIp2 implies component model. WASIp2 is implemented using component model.
        • jcmfernandes 2y ago
          I see, thank you. I'm trying to get up to speed with the whole ecosystem as I have a use case for it. I would like to interact with WASM components from a go binary, but it seems like wazero doesn't and won't support the component model anytime soon. The rust tooling seems more mature ATM :(
          • 4ad 2y ago
            At some point Wazero will have to support component model, regardless of their opinion about it. Otherwise they will lose any relevance. But I agree with you, the tooling is very immature.
            • nilslice 2y ago
              no it will not. Wazero will likely never do that.
              • 4ad 2y ago
                Great, there are other Wasm runtimes to choose from.
            • ncruces 2y ago
              It's not just a matter of opinion, but resource allocation. WASI preview 1 was already a significant effort. It is the least polished bit of the wazero implementation, but even compared to: a spec compliant interpreter, two compilers and runtime, it weighs. It has some issues around filesystem sandboxing. And portability to “everywhere Go runs” is a pain. Preview 2 is a significant departure, with little promise that preview 3 isn't another, ad nauseam. For a small team, that's hard to track. Wasm 1.0 is a useful spec; Wasm 2.0 is still a draft. wazero supports everything final from 2.0 so far. WASIp1 was useful too, but wazero is useful without WASI. Until the dust settles, I'd rather wazero was reworked to make WASI even more pluggable from the outside (there are two impls already), than invest more resources in the WASI implementation itself. Still, if anyone wants to fund fulltime work on this, I guess that can be arranged.
• boomskats 2y ago
  Correct, this looks like wasip1 support only for now. Discussion thread here[0]. Might be for the best, with wasip3 just around the corner. [0]: https://github.com/golang/go/issues/66984#issuecomment-2076284666 https://github.com/golang/go/issues/66984#issuecomment-20762...
• phickey 2y ago
  This addition unlocks the ability to use Go with the component model. The component model layers on top of Wasm Modules - a module which imports and exports functions with the component model ABI can be turned into a component using e.g. `wasm-tools component new`, and that transformation can include adapting wasip1 interfaces to wasip2. Without support for declaring export functions besides `main`, Go could only target the wasip2 CLI command world, but this enables it to target any component model world.