[Pitch] A Vision for WebAssembly Support in Swift

[migueldeicaza]

This pitch has lifted my spirits.

This is what dreams are made of.

It opens so many opportunities for tooling, for distribution, for safety and paved the way to a whole new world of possibilities that were before just practically impossible.

I want to thank you and every member of the swift warm community for your work. I have watched in silence from a distance the project and I wish I had the time to praise the team’s work on a more regular basis.

I see the best of .NET coming to swift users, and I am excited for the world ahead for all of us.

[kateinoigakukun (Yuta Saito)]

@Finagolfin

Are there also plans to set up separate official CI for this WASM port? Currently, it is built as part as part of the official linux CI and appears to take up 11% of the build/test time on every full CI run (scroll down to see the build timings near the end).

Sorry for your inconvenience. Yes, I'm aware of the CI time.
Unfortunately, having a separate CI setup might require redundant resource consumption to build compiler and tools since we don't have a flexible job control like GitHub Actions. But I have a plan to mitigate the situation by improving WasmKit's performance, which is the current major bottleneck of the test time.

[Geordie_J (ephemer)]

FWIW I wrote a basic (and unfortunately largely undocumented) library for using wasm modules asynchronously in background web worker threads via distributed actors. See GitHub - swiftwasm/WebWorkerKit: A way of running Swift Distributed Actors in their own worker "thread".

While we’re happy with the result (we‘ve been using it production for years), that library / approach is more of a backwards compatibility workaround for browsers that don’t support Wasm threading. If everyone supported threads we’d probably just use them directly. Not sure if we‘d still model our domain as distributed actors if we did. Maybe!

Normally you should be able to just call synchronously into Wasm modules, be it between JS and Wasm in the browser, or between „natively“ compiled Swift and Wasm modules running in an embedded runtime.

[Ade (Ade Adegoke)]

@dimi I would like to learn too, lets learn together.

[austintatious (Austin)]

@Geordie_J

FWIW I wrote a basic (and unfortunately largely undocumented) library for using wasm modules asynchronously in background web worker threads via distributed actors. See GitHub - swiftwasm/WebWorkerKit: A way of running Swift Distributed Actors in their own worker "thread".

I tried to figure out how jt worked and gave up (likely too soon).

@Geordie_J

If everyone supported threads we’d probably just use them directly

What browsers don’t support Wasm threading? I was under the impression that all major browsers (as early as three years ago) supported threading.

Even though I use web assembly daily, I’m still very unaware of API coverage.

I really would love to see threading on Swift wasm.

[Geordie_J (ephemer)]

„As early as three years ago“ is your answer. We need to support devices up to about 6 years ago.

Threading in Swift Wasm already exists. I’ve never used it though so you’d be better off looking at the documentation on the Swift Wasm website.

[austintatious (Austin)]

I should have said Swift Wasm in the browser and more specifically using the regular concurrency / threads system in Swift.