tinygo now has a "wasi" target that you can try.
On Fri, Dec 16, 2022 at 2:10 PM 'Kevin Chowski' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I recently learned that WASI ( > https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md) > supports filesystem abstractions directly for WASM code. > > Is there an plan to integrate this into Go? > > On Saturday, November 5, 2022 at 5:59:08 AM UTC-6 Konstantin Khomoutov > wrote: > >> On Fri, Nov 04, 2022 at 02:08:08PM -0700, 'Kevin Chowski' via golang-nuts >> wrote: >> >> [...] >> > I am on a project which primarily ships a Go command line interface >> (CLI), >> > but we have aspirations of using the wasm compilation mode to also >> > distribute a simple webapp version of it, while sharing most of the >> code. >> [...] >> > The next big hurdle is the fact that we cache things on disk >> > for later reuse, so things are failing out-of-the-box any time we >> attempt >> > to touch the filesystem. Luckily, in our case, the fact that we are >> > touching the filesystem is a bit incidental (its used as a cache for >> making >> > consecutive CLI invocations faster), and as long as the system was >> > consistent for the lifetime of the main Go process things will work >> just >> > fine. >> > >> > We /could/ pass a filesystem object across the codebase, and maybe we >> will >> > one day we will anyway for some other reasons, but I'd rather not have >> to >> > do that just to get further with this webapp prototype: it's a lot of >> > tedious plumbing, and there is a nontrivial amount of code to touch. >> > >> > So instead I decided to try some global-mutable-at-startup variables >> for >> > things like os.OpenFile, os.Remove, etc, that should be easy to cleanup >> if >> > we decide not to move forward with the prototype; but even then, there >> are >> > plenty of random things I have to do to get this to work. I've spent >> about >> > 2 hours on this direction so far and I keep hitting unexpected >> roadblocks - >> > thus this email seeking out a new strategy. >> > >> > Are there any plans to automatically support filesystems on >> wasm-compiled >> > Go applications? Even an ephemeral, in-memory filesystem would >> basically >> > solve all of my problems without having to change any code on my end, >> which >> > would be nice. >> >> I'm not a Go developer, but I'd say it is unlikely due to the combination >> of >> these two facts: >> >> - The os package was implemented as a sort-of grab bag of many features >> one expects on a typical OS (hence the name). The fact the filesystem >> operations were implemented in that package directly and not elsewhere >> is the direct manifestation of that approach. >> An environment in which WASM runs in a browser is too different from that >> provided by a typical OS, so I cannot see how one could sensibly >> implement >> in GOOS=js. >> >> - Even if some sort of FS emulation were to be implemented for GOOS=js, >> the question is: which one exactly? Keeping stuff in memory in just one >> way of doing things. While I'm not a web developer, I know of at least >> session storage and local storage which provide for two levels of >> persistence beyond keeping stuff in memory. Which one to pick for >> implementing stuff from the os package? >> >> > In lieu of that, does anyone have any tips about how I could go about >> doing >> > this in a better way? >> >> If you need a hard-and-fast solution, I'd propose you're trying to >> abstract >> your stuff away on a wrong level. I think it would be cleaner to factor >> out >> your persistence code into a set of functions "store this stuff" and >> "load >> that stuff"; the default implementations would call out to the os >> package, and >> the wasm implementation would use either approach you select: keeping >> things >> in memory, using local storage etc. >> >> I mean, trying to implement and pass around through the whole codebase >> something like a "filesystem accessor" switchable at runtime is only >> worth it >> if your code makes heavy use of the filesystem in nontrivial way. I'd say >> that >> it's better to abstract away high-level store/load operations. >> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/dd8306ab-75bf-4bb6-a9ac-3c9f778665a7n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/dd8306ab-75bf-4bb6-a9ac-3c9f778665a7n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANKfucZOghu5O%2BCdERtZ0QhZfnK2u4-OU-7pm%3DrHZdSYjSPy-Q%40mail.gmail.com.
