Swift website work group

Following the announcement about open sourcing Swift.org, the Swift core team is happy to welcome the inaugural members of Swift website work group:

With Tom Doron (@tomerd, Apple) representing the Swift core team.

The Swift website workgroup is a steering team that helps guide the evolution on the Swift.org website. The workgroup will:

  • Define a set of processes that govern the contributions to the Swift.org website.
  • Actively guide Swift.org website development and contributions.
  • Define and prioritize Swift.org website related efforts that address the needs of the Swift community.
  • Channel feedback to Swift core team about the needs of the Swift community.

See Swift.org workgroup for additional information about the workgroup.

45 Likes

Thrilled to be part of this as a workgroup member! I’m looking forward to working together with the other members, the core team, and the community on making Swift.org an even better resource for everyone. :slightly_smiling_face:

11 Likes

I'm really happy to see this! It's much needed.

There's one thing I'd like to mention; a thing that's been bothering me for a little while - it would be really great to build a version of the compiler for WebAssembly which you could run in your browser with no setup. It would be a fantastic resource to have - whenever anybody's discussing some Swift code and they're like "why doesn't this compile?" or "why do I get this strange result?", we could all reference the online result. It's an environment which is configured the same way for everybody. It's super easy for beginners to jump in to, can always be the latest version to demonstrate new language features, etc.

I don't think we really need much to do it, either. It's probably already 99% done.

It has long been possible to run Clang in the browser. That's the full Clang, compiling and executing C++ code in the browser. Clang itself is just a C++ application built using LLVM, of course, just like the Swift compiler is, so theoretically it can also be run in a browser on some source file to produce a binary. And since Clang supports WebAssembly output, you can also execute that binary in the browser, and IMO the result is pretty smooth. We also have a port that supports WebAssembly output. We could do that.

In contrast with swiftwasm.org, which to my understanding compiles code on the server and sends you back a Wasm file, this would make no extra demands of the server - it just serves static files. After that, it's a fully local compiler, you can build as many files as you like without getting the server involved again. It's like the download options we already offer, just downloading a toolchain that is immediately usable on the web.

So as part of the website rework, I think it would be cool to see if anything could be done there. It feels like a lot of the foundations have already been laid.

19 Likes

So I'll preface this by saying yes! I'd love to have something like that on the site. There's also things like Swift Fiddle (https://swiftfiddle.com) which is plain Swift rather than WASM.

Long term I think running local code through WASM would be great but it's probably outside of the remit of the work group. It's likely something for the language workgroup or the embedded group to actually solve. As workgroup we'd probably be very keen to take something like that once solved however

8 Likes

Yeah what I meant with that is I think it would be great if Swift's web presence included a simple sandbox. I believe the reason we don't already have that is because of server resources, and in that case Wasm seems ideal.

I suspect we probably do have the expertise in the community to set this up (at least to get a single build as a demonstration of a modern release; whether we can maintain it is another question). Somebody gave a talk at CppCon 2019 about porting Clang to Wasm, and their repo is on GitHub (Note: that's actually a different person to the one I linked to before. Another person independently had the same idea, I think), and although the state of Wasm has no doubt changed since then, it seems as though broadly-speaking the biggest issues they had were build-system finagling and filesystem emulation. Which make sense - compilers don't have a huge amount in the way of OS dependencies other than ingesting and emitting files, and most things can be emulated. They don't do networking and so on.

I'm not going to say it's easy because it undoubtedly wouldn't be, but there's enough that it doesn't sound impossible, right?

Perhaps somebody wasn't motivated to try it before, or was unaware of the prior success with Clang, and now wants to give it a try with Swift :slight_smile:

1 Like

@Karl would something like Swift-Colab be what you want? I have always been trying to make this project into an easily accessible sandbox for using Swift.

What's unique about Swift-Colab compared to Repl.it (and maybe Swift Fiddle too) is its ability to JIT compile random Swift packages hosted in GitHub repositories. It doesn't yet have a solution for caching pre-built packages on some server, but you are JIT compiling on a 2.2 GHz Intel Xeon processor with native assembly.

Having a WASM in the browser may be difficult if the toolchain is too large, taking several minutes to download. You would also need frequently used packages to be pre-compiled and cached to be fetched on-demand from an external server, just for that web application. Colab already solves the first problem - Google's servers have super high network bandwidth and download a 500 MB toolchain in 24 seconds.

But Swift-Colab might not be what you're looking for. It runs the Linux toolchain instead of the WASM toolchain. But maybe there is potential. Someone could modify or fork it to JIT-compile using the WASM toolchain, reusing the work put into the interactive editor experience.

All of that said, I probably am probably biased in favor of Swift-Colab. What would you say are the downsides of this idea?

1 Like

I particularly love Swift Fiddle because I can easily test non official features by selecting the nightly main build. It would be much more friendly to test swift evolution features if there was an official playground like this. The proposals could even link a playground code with the necessary build and compiler flags

2 Likes

Compiler Explorer (godbolt.org) tends to work great for quickly testing things and to map the generated assembly to source line (and yes, you are able to execute the input as well).

5 Likes

According to the CppCon talk, Ben Smith (the presenter) was able to get Clang down to ~35MB, and LLD down to about ~28MB. Which is fine. That's well under the AppStore cellular limit, for instance. And they're just static files, so they can be really easily cached and used offline, etc.

If there's a reason why the C++ parts of the Swift compiler need a huge amount more than Clang/LLD, it would be interesting to understand and try to fix. But that's a relevant data point for what a realistic download size might look like.

But yeah, I mentioned this because I think it would be a great service for both new and experienced Swift developers, and give everybody a reason to visit swift.org. There are some similar services, such as rust-lang.org's playgrounds. I'm not sure how they use it in the Rust community, but their GitHub Gist integration is really interesting as a way to host and share code snippets.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9ac4dbeee14b0c58009cf60dcb4312ed

You could imagine how something like that would tie in to Swift.org; we could perhaps host some kind of executable single-file playgrounds or tutorials.

For example, I imagine there will be lots of interest in our new strongly-typed regex literals once they release, and it would be nice if people who have never used Swift could click a link and try it in an interactive playground. It could be a big part of the sales pitch in getting people to consider Swift for more of their projects. And you can't beat local processing for immediate feedback while editing.

5 Likes

The Swift toolchain is already compressed down as much as physically possible, and the true size is around 3 GB (compressed to 500 MB). Compare 3 GB to Clang being 35 MB and LLDB being 28 MB pre-compression. Other parts of the compiler, such as the Swift Stdlib, take up most of the size. But if the toolchain is cached server-side, size may not be an issue. Apple will have to actively maintain these caches, which costs money to do.

We have swiftwasm.org's playground, but it seems to be a pre-compiled demo that doesn't actually run the code. It executes in-browser upon pressing "Run", but after modifying one character of the code it starts compiling indefinitely. I don't know if Swift WASM is running slowly client-side, or there's some other bottleneck in their servers preventing the demo from working. Perhaps it's better to use a native Linux toolchain running server-side instead of client-side.

We also have to consider whether we want third-party packages to be accessible from the demo. Compiler Explorer has a feature for "libraries", but they have to be pre-approved by the people running the site. So far, there are none for Swift. SwiftFiddle also doesn't support JIT-compiling third-party packages. Swift-Colab might be the only browser-based IDE that has such a feature.

Perhaps we should list all the existing solutions for Swift in the browser and compare them. Maybe we would learn the best aspects of each approach, or find that an existing solution already fits this purpose.

There’s also pad.swiftwasm.org, which has been responsive that the SwiftWasm home website in my experience. It’s more specialized to running Tokamak apps, so it offers linking with the library when compiled, with compilation, of course, happening on the server.

EDIT: I also remembered ReplIt is good and kept fairly up-to-date, although their demo (before signing in) seems to run an outdated version of Swift.

1 Like

@tomerd Heads up: Tim's name is spelled wrong in this post and on the web link. It's Condon, not Codon.

@bdrelling Thank you for letting us know!

Happy to do so -- that dude is like fully responsible for all of my success using Vapor and all of my interest in Server-side Swift, so we better spell his name right! :grin:

2 Likes