I came across the SOIL-initiative which aims to create a Single Open Intermediate Language. I believe perhaps if there is a collaboration with this initiative it might be of mutual benefit for this project also. This can help further research in IR, optimisation of IR, better targeting of web and other platforms, inter-language operability, etc.
I'm not sure what this exactly is or what it entails, but looking at the page you linked to:
Quick Load Times
Programs need to be small, quick to audit, and easy to compile so that they can be booted as they are downloaded.
Code size is certainly one of the biggest issues Swift WASM libraries face. There are some things we can do (e.g. @kateinoigakukun's LTO project to eliminate more dead code), but there are also things that WASI (the "WASM OS") could do -- like giving us a way to access the browser's copy of unicode and time-zone data, so we don't need to include our own copies in every Swift library that uses a String or DateFormatter.
The WASI developers are aware of the issue (https://github.com/WebAssembly/WASI/issues/25). It would be nice to see some movement on it.
Just to clarify my personal opinion, I hope at some point in the future we could provide builds that don't depend on WASI, similarly to what other projects such as rustwasm and AssemblyScript do. We don't depend on WASI because we want to, but because it was the quickest way to make things work. Swift stdlib despite being somewhat minimalistic (as in, shifting more responsibilities to the Swift Foundation library), still assumes the presence of ICU and libc. While the swift-embedded project shows that you could avoid bundling ICU, for a libc-less build we need to write our own custom memory allocators and stuff like that, which is not currently feasible with only a couple of contributors that SwiftWasm has. Everyone is very welcome to join and kickstart work in that direction though.
As as a side-note, the name of our project is SwiftWasm, or "Swift for WebAssembly" if you prefer a less concise version. While "WASI" is an acronym, "wasm" is not, and it looks like rustwasm people follow that convention too
Is that still correct? My understanding is that they predate WASI, and the first entry of the latest blog post on the rust website actually is about adding wasi support. What’s the value in using anything other than WASI’s standardised set of syscalls and libc implementation?
And yes, the standard library currently needs ICU. If WASI (or some other interface, which I assume will need support from the host) provided a means to access the data, the ICU algorithms could be adapted to use them, so the standard library’s copy would shrink dramatically.
I guess this would require cross-language LTO, as WASI’s libc is written in... well, C of course.
(Or maybe not, for just dead-code elimination? I think the linker should manage that anyway)
I guess an even better solution would be to dynamically link WASI’s libc, and rely on the browser having a cached, precompiled version available (similarly to how we dynamically link the system libc on other platforms). But wasm doesn’t have dynamic linking yet So - another thing for the initiative
For similar reasons, I guess it would be better to leave the JS polyfill alone - so it can be cached more easily.
Yes, that's totally valid reasoning, but from that perspective the binary size of your app doesn't matter much because it can be cached and loaded from disk too. The problem is that we're optimizing here for the cold load time, and in that case any kind of payload is something something we'd like to avoid, regardless of whether it can be cached or not.
Additionally, not only we'd need dynamic linking to work, but also some kind of ABI stability. Again, things like AssemblyScript don't need to care about this at all because they don't bother with WASI in the first place and that's an enviable position to be in, at least from my point of view.
From what I can tell, even in AssemblyScript, you still need WASI for simple things like writing to the console: https://wasmbyexample.dev/examples/wasi-hello-world/wasi-hello-world.assemblyscript.en-us.html
That link shows example code for using specically WASI APIs. It's not needed though, nothing prevents you from importing