Wasmtime GitHub notifications bot (Jan 17 2023 at 16:38): Wasmtime GitHub notifications bot (Jan 17 2023 at 16:38):tessi commented on issue #5582:
Wasmex author here :wave: I'm happy for wasmex to be included in the list. Thanks @etehtsea for this PR :tada:
Wasmtime GitHub notifications bot (Jan 17 2023 at 19:28):alexcrichton commented on issue #5582:
Thanks for the PR here, and thanks for you work on this @tessi!
Before merging this though I'd be curious to ask a few questions about the API of the wasmex package. To be clear though I have no experience with Elixir myself so these are moreso higher level questions. The existing language embeddings of Wasmtime all currently follow roughly the same shape which is more-or-less to take the C API and expose something idiomatic within the language itself. For example most languages have a
Config,Engine,Linker, etc. While not necessarily strictly required I do at least personally feel that this is beneficial for maintaining a consistent level of support and expectations of what embeddings do across languages.Looking at wasmex I see though that it has a much longer history than many of the other extensions and additionally has the history of switching wasm engines internally. This has resulted in a pretty different API of the wasmex package than, say, the Python package. For example in the wasmex documentation there's a
Wasmex.start_linkfunction as opposed to theLinkertype. Additionally there's a "get the memory for this instance" function as opposed to "get the memory named"foo""-style function. When it comes to API design I don't mean to say that there's a right or wrong choice of course, but I wanted to point out how the style of the wasmex package is different than our preexisting packages.@tessi I'm curious if this is something you would like to, or have already planned to, handle in the future? Again it's not necessarily required to be added to this list (it's not so formal of a list anyway) but I do at least personally think it would be best for "official" bindings of Wasmtime to have roughly the same look-and-feel.
Wasmtime GitHub notifications bot (Jan 17 2023 at 22:53):fitzgen commented on issue #5582:
+1 for matching the style of the existing Wasmtime packages, especially if we are going to feature it in our README.
It probably makes sense to split out a
wasmtime-elixirpackage that matches the API style of Wasmtime and its other language packages, and then use this package fromwasmex. Especially ifwasmexwants the possibility of switching between Wasm engines in the future like it apparently has in the past.
Wasmtime GitHub notifications bot (Jan 18 2023 at 09:17):tessi commented on issue #5582:
Hey :)
yes, we recently switched from Wasmer and this is a reason why we're not fully copying wasmtimes API. However, I don't plan to actively copy other packages APIs (or the C API) for the sake of being similar. But I want to expose wasmtimes Rust API and make it Elixir-friendly (which is similar, but not the same I guess). We follow the Rust API, because wasmex is not a C-extension but a Rust-extension to the Erlang/Elixir VM. I see value in being very similar to what wasmtime does - it's just easier to maintain and more straight to understand as a user :) Since I assume the other wasmtime packages are doing similar, I'd say we converge in our APIs over time.
The existing language embeddings of Wasmtime all currently follow roughly the same shape which is more-or-less to take the C API and expose something idiomatic within the language itself. For example most languages have a Config, Engine, Linker, etc. While not necessarily strictly required I do at least personally feel that this is beneficial for maintaining a consistent level of support and expectations of what embeddings do across languages.
We're not there yet :) But we already have concepts for Engine, Config, Instance and more (no Linker yet and I bet more is missing). We're not 100% where I want to be with memories (it currently assumes one exported memory per instance, which is not always a working assumption). Similar with imports (we can have imported functions, no memories, tables nor globals yet). So there is much left to do, but also many things done already.
With that being said, let me go into more detailed answers:
there's a Wasmex.start_link function as opposed to the Linker type
start_linkis a function implemented for Elixir Genservers. It has nothing to do with Linker :) (we don't have the linker concept in wasmex yet, but will add it eventually).Additionally there's a "get the memory for this instance" function as opposed to "get the memory named "foo""-style function
Yes, this is a relict from where I started the project with limited understanding of memories. Eventually, we will switch to the later style.
When it comes to API design I don't mean to say that there's a right or wrong choice of course
Thanks for being so polite and kind :purple_heart: But no worries, feel free to expose any shortcomings/differences. I take no offense
It probably makes sense to split out a wasmtime-elixir package that matches the API style of Wasmtime and its other language packages, and then use this package from wasmex. Especially if wasmex wants the possibility of switching between Wasm engines in the future like it apparently has in the past.
I don't intend to switch WASM engines again. There was a discussion to support multiple engines, but with me as the only main contributor it's not realistic to maintain multiple engines unless someone pays me to make this my day job :losing_money: If we ever switch (again, very unlikely), we'd have separate packages for each engine.
Next steps for wasmex is to switch to the async wasmtime API with the goal to support ~10k parallel calls into WASM using cooperative time slicing through epoch based interruption. There will be work to wrap WASI std IO into into en Elixir-style messaging. These initiatives are an opinionated way to use wasmtime and are prioritized higher than converging wasmex and wasmtime APIs. However, with every change I intend to bring the APIs closer together if the chance comes.
I hope this gives you a good understanding of where we are and where we want to go with wasmex. Feel free to throw more questions at me :)
Wasmtime GitHub notifications bot (Jan 19 2023 at 18:58):alexcrichton commented on issue #5582:
Ok that all sounds reasonable enough to me. I think though given the differences from this embedding from other embeddings it migth be good to signal that perhaps. @etehtsea and @tessi would y'all be ok with an
Elixir (unofficial)name for this to be linked as? Basically just making it clear that it's not necessarily as "official" as the other bindings since it's of a different shape, but still mentioned to help others discover it
Wasmtime GitHub notifications bot (Jan 19 2023 at 19:28):tessi commented on issue #5582:
Ha, as long as it's not "Elixir (horrible)" I'm good ;)
It's nice to be mentioned however you feel comfortable doing it.We can have another look in a year or so and see if wasmex is more "official" then :)
Wasmtime GitHub notifications bot (Jan 19 2023 at 21:43):alexcrichton commented on issue #5582:
Ok, does that sound alright to you @fitzgen and @etehtsea?
Wasmtime GitHub notifications bot (Jan 19 2023 at 22:26):fitzgen commented on issue #5582:
SGTM. Maybe break the section up in the README into something like
Languages supported by the Bytecode Alliance: * Rust * etc... Languages supported by the community: * Elixir
Wasmtime GitHub notifications bot (Jan 20 2023 at 10:23):etehtsea commented on issue #5582:
Sure, I've updated the PR.
Last updated: Dec 23 2024 at 12:05 UTC