Core team to form language workgroup

tkremenek · 2022-02-22T23:46:20.919Z

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

taylorswift · 2022-02-23T01:10:26.830Z

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.

tkremenek · 2022-02-24T06:49:27.840Z

taylorswift:

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.

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.

tkremenek · 2022-03-05T01:04:33.715Z

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

Jon_Shier · 2022-03-05T22:39:36.996Z

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.

masters3d · 2022-03-06T06:24:30.829Z

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.

Tino · 2022-03-06T11:31:22.943Z

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.

philipturner · 2022-03-08T04:18:41.986Z

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

mickeyl · 2022-03-08T06:54:28.809Z

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

ktoso · 2022-03-08T06:56:57.680Z

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?

taylorswift · 2022-03-09T01:22:43.273Z

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.

stevapple · 2022-03-09T02:30:30.525Z

taylorswift:

library installation and distro packaging

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.

taylorswift:

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.

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.

taylorswift · 2022-03-09T02:35:51.955Z

stevapple:

Distributing libraries and consuming them in applications form a rather complete ecosystem, which is different from what SSWG is currently focusing on.

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

stevapple · 2022-03-09T02:47:16.161Z

taylorswift:

actually, i would say that packaging and modularization is very important for server applications.

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.

mickeyl · 2022-03-09T20:57:44.460Z

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

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:

Actors vs. NSObject conformance brokenness on Linux ([SR-15282] Using an actor with NSObject conformance on Linux · Issue #3200 · apple/swift-corelibs-foundation · GitHub)
NSNotificationCenter regressions ([SR-14815] Regression (Linux): NotificationCenter silently failing since 5.4.1 · Issue #3218 · apple/swift-corelibs-foundation · GitHub)
Same delegates being optional on macOS and not on Linux.
IFF_UP is an Int32 on macOS, but an Int on Linux.
To use Posix without Foundation, you must jump through namespacing hoops which everyone is reinventing, see e.g. GitHub - NozeIO/xsys: Basic cross Linux/Darwin/Win(?) Posix aliases for Swift, Socket.swift/OS.swift at master · BiAtoms/Socket.swift · GitHub, GitHub - bscothern/SwiftyPOSIX: A Swift wrapper around the C POSIX Standard., and many more.
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!".

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.

taylorswift · 2022-03-09T22:01:20.931Z

mickeyl:

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

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.

tkremenek · 2022-03-11T16:35:07.159Z

taylorswift:

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.

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

Swift Documentation Tooling work group - call for interest (video call kickoff survey) Announcements

There has been some interest expression in forming a "documentation tooling work group" focused around tooling for documentation generation and symbol graph-related projects: To kick things off, I'm am looking to schedule a video call during the week of March 21-25 where those interested can gather together and explore opportunities for collaboration in such a work group. My impression is that there may be interest from individuals spanning a wide range of timezones, so I'd like to survey bot…

tomerd · 2022-03-15T18:28:43.732Z

Some additional information on topics raised on this thread:

mickeyl:

Packaging

If it wasn't for @futurejones activities, we would install our favorite language (runtime) like in the stonehenge days…with tarballs.

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.

mickeyl:

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 - Swift ) and then compare this miserable situation with other programming languages tools.

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.

stevapple:

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.

stevapple:

That’s true. Server applications also need the ability of consuming libraries, that’s why I believe binary dependency support falls to SSWG already.

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.

mickeyl:

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

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.

tkremenek · 2022-04-18T22:07:41.735Z

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.

tkremenek · 2022-04-22T22:03:01.378Z

tkremenek:

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.

I've sent out the call for interest here:

Call for interest (video call kickoff ) - using Swift for embedded / bare-metal / low resources programming Announcements

As I promised weeks ago, I'd like to set up a "call for interest" in discussing community investment using Swift for embedded / bare-metal / low resources programming. There was vocalized interest in creating a workgroup (or workgroups) that focused on these areas: I want to host a video conference call where we can bring folks interested in these areas together to explore exciting directions! The call covers a wide range of potential investments, and in the end, if there is enough interest …