Stream: wasmtime

Topic: ✔ Why Wasmtime C API?

Jan Provazník (Jul 30 2024 at 08:26):

I am wondering why host APIs (wasmtime-dotnet, wasmtime-py, wasmtime-go) use the C API. It's not keeping up with the new (WASI) features.
Likely I am naive, but isn't it possible to expose and use the Rust API the same way to be consumed by other languages and there would be less maintenance effort?
Specific pain points:
In C API: https://docs.wasmtime.dev/c-api/wasi_8h.html only the following are supported - env, directory, stdio, args. But nowadays WASI defines also: random, http, clocks... . It would be useful to give fine-grained access to these to have the "capability-based security model".
Also component model is not supported in C API which limits the usability of the dependent host APIs in the future: Add component model support to the c-api · Issue #6987 · bytecodealliance/wasmtime (github.com)

Alex Crichton (Jul 30 2024 at 14:15):

Using the C API provides a number of benefits in my personal opinion:

• Uniform surface area across bindings
• No need to manage building binaries, precompiled ones can be used
• Most languages can only interface with C so a C API needs to be invented typically anyway

It's obviously no magic bullet, but I also don't think that "just use the rust api for bindings" is a magic bullet either. Someone's still got to do the work to integrate with each language. At this time it doesn't seem like it's all that much more work to implement something in the C API first and then bind it in languages.

Notification Bot (Jul 30 2024 at 16:58):

This topic was moved here from #general > Why Wasmtime C API? by fitzgen (he/him).

Notification Bot (Sep 09 2024 at 12:21):

Till Schneidereit has marked this topic as resolved.

Last updated: Dec 23 2024 at 14:03 UTC