Good news — I hope that the workgroup concept will help to get more people on board without adding more friction due to longer discussions, and achieve progress in several directions at the same time without splitting forces too much.
In my opinion, some official frameworks for common fields of application could really push the ecosystem. Laying a simple but solid groundwork which enables people to create interoperable libraries could be more effective than trying to "solve" a topic completely with a huge and complicated package (which would also take a long time to develop).
Obvious candidates would be all kinds of media: Definitely (pixel) images, audio and video, maybe also two and three dimensional vector graphics and animation.
What do you have in mind for "linux-interoperability"? Generally that is an area the SSWG tries to cover, so if there's things of interest not covered a good first step might be to surface those Totally happy to see more people help out to push the needle here, but not sure what "interoperability" means here?
Is it things like apple/swift-system that provides API to underlying OS APIs, or packaging, or what else do you have in mind?
without speaking for @mickeyl , i think “linux interoperability” might cover a lot of those areas that we neglect on the server side but are mightily important for other linux use cases, including:
library installation and distro packaging
GUI applications
basic cross-platform infrastructure, like file format codecs — a lot of people rely on Apple-only frameworks to handle things like this, and on the server side we don’t always deal with PNG, JPEG, PDF, etc. directly, oftentimes it’s opaque data so we’re less likely to encounter this problem.
With pkgconfig support in SwiftPM, it’s already quite easy to find a library on Linux. What we should do next is to push the work of binary dependencies on non-Darwin platforms, so that anyone can package a prebuilt library into a format that’s recognizable for SwiftPM. This is among the work range of SSWG, IMO.
Fairly speaking, not only Linux developers are longing for such support. Windows developers also need GUI and other utility frameworks. While we already have quite a lot C libraries to use, they may be less performant, or unsafe/weird to use without wrapping.
Packaging is also related. Distributing libraries and consuming them in applications form a rather complete ecosystem, which is different from what SSWG is currently focusing on. The way to package and install a library or an application is quite similar, both on Linux and Windows.
To conclude, instead of “Linux interoperability” (which is, like @ktoso said, more of SSWG’s capability), I think the one we need is a workgroup for library and application development on non-Darwin platforms.
actually, i would say that packaging and modularization is very important for server applications. i have ten modules in my current stack; not everyone is just using Vapor for everything.
however, i think the types of libraries server applications tend to consume are a very limited subset of the libraries needed to support a full ecosystem. this is why “server-side” development is a category in the first place, because most server applications depend on a similar set of libraries (though usually different implementations).
That’s true. Server applications also need the ability of consuming libraries, that’s why I believe binary dependency support falls to SSWG already.
However, the libraries you mentioned is not so frequently distributed into a system library to be used by clients of even other languages. Server developers usually don’t make their modules available through zip archives, GUI installers or system package managers, that’s what I mean for “packaging” here.
The only higher level cross-platform stream-based communication infrastructure (Stream) being deprecated on Apple platforms with every one always asking "Why don't you use Network?" to which my answer is "Because I care about more than just Apple!".
Swift on Linux may be quite fine, but Swift for APPLE and !APPLE is pretty painful.
That's what I mean with Linux (or better !APPLE) interoperability being a diverse field of challenges and opportunities where a dedicated working group could make a significant difference.
i feel like so many of swift’s usability issues on linux just boil down to poor library support. including the friction with binary and system dependencies — we would probably see more progress on that front if there existed more cross-platform swift libraries available in the first place.
Static linking of the Swift runtime libraries is a supported feature. You may also find SE-0342 interesting, we would love to hear more opinions on this.
SE-0305 introduces some capabilities towards this goal. The next logical step is to add library support which starts pulling on topic like system dependencies. Suggestion and follow up proposal on this topic are welcome.
Hi everyone, I just wanted to update where we are with workgroups as there has been some time since the original post:
The core team has discussed how different workgroups will function and that there will be different "archetypes" for how workgroups will operate. For example, the C++ interoperability workgroup and the Swift on Server workgroup have other models in terms of membership, how and in what form they meet, the "product" of the workgroup, etc.
The core team is looking to have each workgroup have a semi-formal charter that outlines how the workgroup operates, its goals, and how it will interact with the rest of the Swift community.
Further, the core team wants each workgroup to directly tie in with the principles and goals of our Diversity in Swift workgroup. Related, the core team is looking at how to evolve the Diversity in Swift's workgroup's role with the rest of the project.
We're also looking at how the core team's role will change with the presence of a language design group and what other workgroups are natural to split off that currently are overseen most directly by the core team. The goal is to make the core team more of a general oversight group for the entire project.
We've had one video call for interest in a documentation tooling workgroup, and we'll be following up soon on the next steps for those who expressed interest in getting involved in such a workgroup. Further, there was a call for interest in participating in a Swift website workgroup. We are very encouraged by the enthusiastic outreach we received to that call for interest and plan to finalize the formation of that workgroup very soon.
I've been tardy in organizing a similar video conference call for those interested in bare-metal/embedded use cases of Swift. I apologize for that and plan to send out a call for interest in participating this week.
To summarize, to support the creation of the language workgroup, we're looking at the needed restructuring of the overall project to facilitate both that workgroup and the other ones people have expressed interest in creating. We're getting close to ironing those out, and you should expect more activity on these fronts to roll out in pieces over the coming weeks.
Totally happy to see more people help out to push the needle here, but not sure what "interoperability" means here?