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:
our first major step for WebAssembly is a concrete and focused objective. We want to design a means for garbage-collected languages to communicate their memory layouts and low-level feature implementations within an extended WebAssembly. This will enable browsers to independently verify that every access is safe, removing the need for a sandbox, and it will enable browsers to manage the memory of these programs themselves using the same garbage collector as for JavaScript and the DOM, enabling memory to mix freely across these systems to provide smooth interop.
We already have a WebAssembly port, and efforts are being made to upstream that. @Max_Desiatov knows more about it. I believe we also have some early libraries and tools for JS and DOM interop.
Swift is a safe language which is not garbage-collected (people sometimes confuse ARC with garbage collection, but they are not at all equivalent). Enabling memory to mix freely between Javascript and a Swift WASM library is an interesting topic: theoretically, it could be possible if we can guarantee safety. I also understand that the WebAssembly project is exploring reference types and interface types (e.g. for strings) to facilitate cross-language interop. How does this initiative differ from those efforts, or is it part of them?
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 (System collation and system timezone data · Issue #25 · WebAssembly/WASI · GitHub). It would be nice to see some movement on it.
1 Like
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.
If you're porting an app or a library that depends on libc/POSIX, then surely WASI seems like a good option (one of the few). Binary size is one of the reasons not to use it then. Even the WASI JavaScript polyfill itself is pretty heavy, not to mention the actual WASI code compiled to WebAssembly. Apps and libraries that I'd like to develop only need a small fraction of that, and until there's a way to strip unneeded cruft with LTO or through some other means, there's still a use case for avoiding WASI as a dependency.
1 Like
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)
Of course, and the WASI polyfill is written in JavaScript, so in fact you need to run dead call elimination across three languages at the same time. I'm not sure when/if that becomes realistic, that's why building a WASI-less stdlib seems like a more interesting goal, and it also gives much tighter control over binary size. AssemblyScript runtime takes only 2KB (!), it's going to be very hard to compete with this if we don't start chipping away at the actual dependencies. Obviously, in addition to our reliance on automated optimizations such as LTO/DCE.
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: Wasm By Example
That link shows example code for using specically WASI APIs. It's not needed though, nothing prevents you from importing console.log into your WebAssembly (ergo AssemblyScript) module directly and using that without any WASI code whatsoever, as shown here: Wasm By Example
1 Like