Core team to form language workgroup

This is very good news. In particular, I hope this leads to reducing the pace of introducing new features to make room for more stabilizing the compiler and its infrastructure.

3 Likes

I hope this is one of the triggers to refocus the core team as you were saying @tkremenek and creating a language working group with a good mix of app developers too. Still but troubling to read that despite internal CoC’s.

I do remember this and the composability discussions, it is sad to lose knowledgeable voices to balance the scales though but someone cannot be forced to do something they do not enjoy anymore.

Anyways, sorry for the detour, will not continue this any further in this thread.

5 Likes

Thanks for rocking our world, sir!

Best of luck on your AI endeavors!

3 Likes

Thanks for sharing. I know how difficult it is and how much courage it takes. You are certainly greater than all that has happened to you. I'd like to thank you for giving us so much pleasure in programming for so long, but you are greater than the Swift language. Changes are always for the better and in the end what matters is the person, the individual and the human being. You are a great human being. Thank you, sir!

12 Likes

I can't forget the day I had the immense pleasure to exchange a few words with you during the week of WWDC 2015; the year Swift was open sourced.

Your work and approach is a big reason I am doing what I am doing today and the Swift ecosystem won't be the same without you.

16 Likes

I'll put one flag-post right here @tkremenek . Me and the Swift for Arduino guys are interested in helping to form a working group on things to do with bare metal Swift coding / realtime / extremely low resource environments. Is there some way to make this happen? In particular something that can work synergistically with the other working groups and important governance structures at the heart of the language.

32 Likes

Absolutely, let's explore this idea. It might be easier to have a breakout conversation to sketch out what that would look like. I'll reach out to you to set that up.

5 Likes

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

7 Likes

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

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

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

15 Likes

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

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

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

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

2 Likes

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

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

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

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

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