I love WASM. It is actually how I will be running my apps by having it run F# in dotnet in the WASM. So using parts of Blazor but running F#. Bolero pioneered this setup. But I have the same issues as you do not have access to sockets or the filesystem.
My thoughts recently has been to create an installable module that would run as a service/deamon that would allow multi-threading, file system and sockets, etc and then have the app use that if available on a system. Again, currently, my thoughts are to have that service do the safe network interaction.
I am also wondering if doing a straight up F# dotnet implementation of the rust crates (again stumbling here as I am not really a programmer) might be something worth doing because dotnet does run on windows, mac and linux.
I am not a lover of Microsoft but dotnet is open now and does handle a big bunch of things for me personally.
3 Likes
I suspect now quic is near standard that we could abstract away quic (that’s quinn for us) and say, here is a WASM module (not wasi) that is a safe node, you do now need to add your own network stack, so include this and all our logic is there.
Then do the same with filesystem calls, which gets client up and running.
i.e. until wasi is more complete we WASM right up to the fs/i/o boundary and give clear instruction on the i/o parts API we require. That “should” be an interim route, but I have not even attempted it, yet!
I suspect this trumps any FFI attempts (which are just a nightmare)
5 Likes