Would it be worthwhile for the pitch to also describe how the new workgroup will enable all these goals? Most platforms require custom work, so my experience with Android will not usually be useful for your work with Windows. Sometimes we can generalize, as in changing the layout of the runtime libraries to support multiple architectures in one resource directory, but often we cannot.
One immediate benefit I can think of is to create a high-bandwidth hub where those adding new platforms can speak to and receive advice from those who already did similar work about the common issues faced, maybe on a Matrix group or something. Another possibility would be to create an Opencollective or some other funding mechanism, where the community could fund something like a FreeBSD port and the workgroup would manage that effort.
Swift is already a very cross-platform language, this workgroup would be a good way to make it one of the best.
From my perspective, we ought to try our best to ensure the end using experience is mostly identical. The implementation could be very different on different platforms, and we already met problems with swift-system where we found it hard even to keep the API surface aligned across platforms. Documentations and PR threads make sense for tracking those differences and their reasons. Code reviews from other members and steady CI support are also important to make sure a platform-specific patch doesn’t accidentally affect other platforms.
It’s worth noting that all Swift workgroups have regular meetings. For every big change or divergence we decide to make, it’s worth first pre-pitched and discussed during the meeting. I would expect feedbacks or suggestions, and sometimes a change will benefit or fit into other platforms as well. The meeting note is also a great resource for later contributors to see what difficulties we’ve met and their final solutions, in case they need them in their work.
I would like Swift Platform Work Group to maintain Swift ports in an SSWG way, where platform support are incubated and, as they grow mature and get upstreamed, we can mark them as graduated and officially supported. Community feedback is important here because the more users we have, the more likely we can know where to improve.
SSWG has a “Swift Open Source” Slack workspace which is very responsive to server-related questions, especially those regarding SSWG projects. It’s a place where users and maintainers can raise questions and discuss with each other, and all threads are public and searchable. That’s something we can take away.
As for funding, I don’t know if a Swift official (if) workgroup should receive funding by itself, but I guess we won’t block involved communities and individual maintainers from doing so. CI is where the workgroup itself will need financial support and I wish we can have a healthy model to make it run.
Even though you said SPWG wouldn't invest in low-resource and bare-metal platforms, I can see that a stable Swift tooling experience and better cross-platform support can be of great help for those areas.
Thanks for this difficult and important work. I’m really happy to see the community stepping up. While I would hope that Apple can put some of its own resources behind some of these efforts, many of which do ultimately benefit Apple, I’m also heartened to see a broader community stepping up beyond the walls of Apple. Swift deserves to be more than just the “Apple language.”
Putting my educator hat on, I want to especially cheer for the items under Improving Swift toolchain experience on existing platforms and Empowering the Swift compiler for existing platforms. I’ve wanted to use Swift more in my teaching, but pain points around its Windows and Linux support have been a major roadblock in the past. Just one year ago, I finally had a nontrivial number of students successfully running Swift code on their Windows machines. Hooray! Progress!
To use Swift in an intro class, however, with new beginners for whom even the tiniest install glitch or usability flaw can be crushing, the experience would have to be quite a bit smoother than it is. Even Java + VS Code — a combination with a huge user base and years of work — just barely cuts the mustard on this front! “Suitable for an intro class” is one of the highest bars to which a toolchain can aspire.
I’m running one Swift-based assignment again later this fall, which means a class full of students installing Swift, ~half of them on Windows. I’m wondering: Is there a SPWG forum where I can forward reports of paint points, both large and small? Even if they’re not strictly the fault of the Swift toolchain, but rather some interaction of, say, Swift + Windows defaults, or Swift + VS Code? Even if they’re not strictly bugs, but just points of confusion such as UX slip-ups or bad defaults? I would love to help advance the state of the art on this front, but don’t want to create noise where it’s not helpful.
Both SPWG and the already proposed Swift Tooling Workgroup will be dedicated to improving user experience of Swift on supported platforms. While the areas may unavoidably overlap, I see SPWG more of handling platform-related features and bugs, and STWG focusing on general usability improvements. It seems your requests are mostly related to the tooling side.
I would like to see these two new workgroups come into reality and work together. For user feedback, we may introduce a single Slack workspace for the two workgroups, since the two need cooperation frequently by themselves. There could be platform- or tool-specific as well as general channels for user feedback, and so both workgroups can be involved. WDYT? @0xTim
It was the runtime library discussion that caught my eye and brought me here. In addition to resolving that issue on Linux, it would be very helpful to start the work of sending patches upstream to LLVM (and any other tools forked and modified) to enable Swift support natively and not have to compile and include duplicates of system tools.
I am working to get Swift into Debian main. It is a long process, but progress is being made. I can try to represent the perspective of the Debian Policy that dictates what our packages must and must not do.
@Ron_Olson might be someone to include as he is the Fedora package maintainer.
I expect that they’ll sometimes awkwardly straddle the two sides in ways that require some coordination across groups. And I’m sure that it won’t always be clear to me which group applies to a particular problem, sitting as I do outside of both groups.
Having a Slack workspace or some such entry point for reporting pain points encountered off Apple platforms would certainly be nice!
Awesome! Thank you. I have been calling for something like that for quitesome time now. I sincerely hope that one of the effects of this group is to decrease the gaping gap in Foundation‘s feature parity.
In contrast to what many „Server-side-Swift“ people seem to think, Foundation is going to be relevant for cross-platform apps quite substantially and the semantics and feature gap is hurting a lot. Even more so when community contributions are actively discouraged by pretty much ignoring them. (That may be unfair and a bit harsh, but it‘s my perception when looking at the pull requests)
Nice explanation! I mentioned Swift System here because I regard it as a typical case where we should carefully design the differences in API design and implementation across platforms. These differences should be well documented and explained, so users and contributors can know how we get there.
BTW, as a multi-platform package, Swift System 1.0 is not doing very well regarding to Windows support, and it reflects the miss of cross-platform guidelines and best practices. That’s something I would like to address by the “working towards a better cross-platform Swift ecosystem” goal.
Yes. It is very clear (?) that there should be a „core“ Swift equal on all platforms, including important „core“(*) libraries. (And I think that nobody wants „language features“ to be different on any platforms.) E.g. having to import FoundationNetworking on non-Apple platform to use URLRequest and URLSession seems strange (apart from all historical reasons), and where such cross-platform libraries exist, I would hope that Apple would also use them on its platforms (if this is possible), e.g. having to use autoreleasepool just on Apple platforms for some methods in Foundation would not be necessary if the same implementations(**) would be used.
Clearly stating where something is not cross-platform is then quite important. Maybe the developer should even be warned when using features not available on all platforms when not stating according platforms in Package.swift? (I know the current „platforms“ entry works differently. And yes, there is the „available“ notation, but this is for source code, not for compiled libraries?)
(*): Yes, this is could be read as a reference to .NET Core from Microsoft, but I do not think that it will or should go as far. For an extreme case, having the same GUI experience on all platforms is certainly not a sensible goal.
(**): At the end of this interview Ben Cohen mentioned something about using the same implementations if I understand it correctly.
As a contributor, I observed noticeably slow responses to patches around platforms apart from Darwin and Linux, even for trivial ones. This could be a result of multiple factors:
new platform maintainers often don’t have commit access;
there’s no platform manager so non-trivial changes are not easily evaluated;
there’s no CI or testing infrastructure so others don’t know if it actually works;
This, however, becomes a blocker for new official platform support, even if the port is pretty mature. It will take time for us to smooth out these issues by letting a specific group of people to handle it officially. (And yes, CI costs, and we’re clearly in short of it. I’m not sure if funding can help, but that’s important for new ports…)
And like how SSWG tracks its own project and evaluates others regularly, SPWG will track the state of each unofficial port, including maturity, popularity and upstreaming process, so interested users can see the progress in a more direct way.
I apologize i’m advance for my naïve perspective; but the questions that come to mind are:
How do multi-platform improvements work with integration into Swift proper? Ie, is Apple fine to i have them included? Or are we dealing with a fork all the time?
Same question for libraries/frameworks etc.
Ideally, one would want anything cross-platform to
be implemented as consistently as possible, which won’t happen without a clear plan, guidelines, rules etc.. It would be great if Apple would endorse/approve such a thing.
Swift is an open-source effort, which should be open to any reasonable improvements, instead of having explicitly what Apple needs. New platform support, of course, can be upstreamed. Windows support is exactly the case, and SwiftWasm upstreaming is in progress. Eventually we should merge mature ports into mainline and announce them as officially supported.
IMO SPWG can take care of it, while Apple’s not so involved — we’re having plenty of people outside of Apple in various existing workgroups and they’re taking charge of a few important aspects of the Swift project. It’s a goal to improve cross-platform usability of standard/core/official libraries and as I mentioned in the initiative, there shall also be guidelines for other library maintainers to follow.
I'd just like to add that I've worked two weeks in May to provide support for Swift on Exherbo. I had to pause it but I'll mainly be back on it from March 6th to September 15th 2023, to hopefully finish the packaging. I may work on it before March 2023, but I can't confirm this yet. @compnerd has been of immense help for this challenging task.