Feature request: Add support for 'wasi' target

[bikallem]

Support WASI target

One of the popular and emerging use cases for wasm apps is deploying/executing them in environments other than browsers, for example in the desktops, in the servers on the edge or on IOT devices. Example of these apps are backend web services, microservices in kubernetes clusters, desktop GUI, CLIs, etc.

At the moment, getting moonbit built app to deploy/run on the above environments requires using a few external tools, such as wit-bindgen, wasm-tools, wac, and possibly wasi-sdk (for c lib interop). The experience is fragmented, involves lots of trial and error and requires significant investment in terms of time and skill in understanding and using these external tools. Emphasising the last point, one basically needs to skill up on the rust language and its ecosystem to effectively use these external tools.

A moonbit application developer writing applications for the above mentioned deployment targets would be very productive if moonbit were to support wasi target in lieu of current 'wasm', 'wasmgc', and 'js'.

[bikallem]

A few a data points:

• rust supports - wasm32-wasip2 (Add a new wasm32-wasip2 target rust-lang/rust#119616)
• zig supports - wasm32-wasi

[peter-jerry-ye]

Emphasising the last point, one basically needs to skill up on the rust language and its ecosystem to effectively use these external tools.

Could you please elaborate?

[peter-jerry-ye]

Also, having a wasm32-wasip2 support only means compile the code to wasm32 + compile their stdlib to wasi preview 2. We do not have a stdlib that depends on wasi, and we compile already to wasm with --target wasm. I don't see the point of supporting wasm32-wasi as a build target.

This may occur after we have a stdlib that contains io/rand that would effectively rely on the backend.

[bikallem]

Emphasising the last point, one basically needs to skill up on the rust language and its ecosystem to effectively use these external tools.

Could you please elaborate?

Sure. Most of the external tools that I mentioned above are written in rust and a couple of them(wac, wasi-sdk) are not packaged at least for NixOS (which I use). This means I have to build them myself. I am relatively new to rust so it took some time and trial and error to figure out the rust ecosystem, build these required tools and then become productive with these tools. It wasn't too bad in the end. However, after having experienced that, I somehow feel that the user experience (of using moonbit) to target webassembly applications in the server could be improved. Especially if the facilities provided by those tools were streamlined and provided out of the box by moonbit. My suggestion for a new 'wasi' target was meant to convey this desire for an enhanced developer ux.

[peter-jerry-ye]

I see your point. It would indeed be better if we support to generate wasm that is compatible with component model. Supporting other tools such as wac might be out of scope and wasi-sdk has nothing to do with this project.

As of the distribution of tools, it is indeed inconvenient. I would suggest opening issues for those tools. I also suffer for having to install them using cargo.

[tonyfettes]

It would indeed be better if we support to generate wasm that is compatible with component model.

Do you mean that there is some WASM modules that are not compatible with component model? Is that even possible?