Core team to form language workgroup

Announcements
18

Also, if others want to engage on talking about such a workgroup, please let me know.

7 Likes
19

if i may add a suggestion, there are quite a few of us heavily involved in documentation generation and symbol graph-related projects. i’d certainly be interested in forming a Documentation Working Group, if that makes sense.

11 Likes
21

I think this is a great idea.

This thread mentions a couple of good suggestions for workgroups. I think what I will do in the coming days is, for each of those ideas, send out a general call for engagement and arrange a kickoff video call for those that are interested.

21 Likes
22

I’ll be sending out separate call-for-participation/interest for some of these workgroup suggestions next week.

15 Likes
23

If you're taking suggestions, I'd like to suggest a Core Networking or HTTP group which would be responsible for common networking or HTTP infrastructure to share between both client and server libraries. It would be really nice if Alamofire, Vapor, and SwiftNIO could all share common HTTP representations and other types. Official overlays on Foundation would be nice too.

10 Likes
24

I love the idea of networking focused groups. I would love lower level networking like control plane network tools like GitHub - osrg/gobgp: BGP implemented in the Go Programming Language or network device automation that is predominantly Python based now a days.

2 Likes
25

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.

2 Likes
26

This was mentioned once on another thread, but there are a few people interested in an ML working group.

2 Likes
27

Even though there is a server workgroup, I can imagine a bunch of folks (including me) being interested in a Linux-interoperability group.

28

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 :slight_smile: 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?

1 Like
29

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.

3 Likes
30

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.

5 Likes
31

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).

32

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.

4 Likes
33

Oh, where should I begin… there's more, but let me just mention two things:

  1. Foundation

For the time being, almost everyone who is writing cross-platform Swift programs will have to use Foundation on Linux.

The Swift Standard Library is lacking way too many things to make up for that. Besides the many missing APIs

(FileDescriptors, [SR-15545] Linux: DispatchTime's advanced() is not implemented · Issue #601 · apple/swift-corelibs-libdispatch · GitHub, ), it's the

differences in semantics which are making a cross-platform developer's life really hard. Random tidbits from a crowd:

  1. Packaging

If it wasn't for @futurejones activities, we would install our favorite language (runtime) like in the stonehenge days…with tarballs. Combine this with the lack of static linking and proper cross-compiling for other platforms ([SR-15701] Linux: Compile error when cross-compiling with --static-swift-stdlib · Issue #57980 · apple/swift · GitHub) and then compare this miserable situation with other programming languages tools.

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.

11 Likes
34

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.

3 Likes
35

I sent out a “call for interest” in this working group:

1 Like
36

Some additional information on topics raised on this thread:

There is an active project to create Swift.org issued and signed native Linux packages: see RPM and Debs for Swift: Call for the Community - #40 by mishal_shah. The project has been going on for a while and additional community participation is welcome.

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.

Given the proximity of Swift on Server on Swift on Linux, the Swift Server Workgroup has also been busy developing tools and documenting best practices for Swift on Linux: See GitHub - swift-server/guides: Guides for building, debugging and deploying Swift Server applications. Additional community participation is welcome.

9 Likes
37

Quick update - April 18

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.

39 Likes
38

I've sent out the call for interest here:

4 Likes