Core team to form language workgroup

The core team is currently looking at restructuring the project's leadership to provide more pathways for community members to become actively involved in the project's stewardship. Swift has gradually introduced more workgroups to focus on technical and non-technical investments (an idea that has been successful in other language and OSS projects). We are looking to push that idea further. In the coming weeks, we hope to introduce a new language workgroup that will focus on the core of the language evolution itself, splitting off this responsibility from the core steering of the project. The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions. More details will be coming soon.

Related, some of you have probably heard of @Chris_Lattner3's departure from the core team. Chris took a hiatus last year and has decided to leave the core team to focus his time on other projects. It has been one of the greatest privileges of my life to work with Chris on Swift. I cannot express my gratitude enough for his leadership in starting the project from the very first line of code to pushing it through critical formative years to make it a language to be reckoned with on the world stage.


I think this is an amazing development, and will do a lot to get more “ecosystem feedback” into the design of language, particularly from library maintainers and other people involved in the sort of middle-ring infrastructure of the language.

best of luck to @Chris_Lattner3 in all his future endeavors!


Moderator note: this post was originally in the light-weight same-type requirement syntax thread, but only because this thread was locked. We have re-opened this thread and moved this post to separate it from the technical discussion in that thread.

Someone asked for more information:

... but their post got deleted by a moderator; they asked me to follow up anyway. After consideration, I decided to respond, but the obvious thread is locked, so I'll respond here. If a moderator thinks this is off topic for this thread, please move it to that one or some other thread, or (if this is somehow considered off-topic for the Swift forums entirely) I can repost somewhere else on the internet.

In any case, Ted's simple answer in this thread is right, but there is of course more behind my decision to leave the Swift core team and the Swift Evolution community.

For context, I left Apple over five years ago and the only constant in my life is that I'm always "very busy" :smile:. That said, Swift is important to me, so I've been happy to spend a significant amount of time to help improve and steer it. This included the ~weekly core team meetings (initially in person, then over WebEx), but also many hours reading and responding to Swift Evolution, and personally driving/writing/iterating many Evolution Proposals. As such, my decision to leave the core team last summer wasn't easy.

To answer your question, the root cause of my decision to leave the core team is a toxic environment in the meetings themselves. The catalyst was a specific meeting last summer: after being insulted and yelled at over WebEx (not for the first time, and not just one core team member), I decided to take a break. I was able to get leadership to eventually discuss the situation with me last Fall, but after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it. As such, I decided not to return. They reassure me they "want to make sure things are better for others in the future based on what we talked about" though.

On Swift Evolution, my original intention was to continue participating in the forums, but after several discussions generating more heat than light, when my formal proposal review comments and concerns were ignored by the unilateral accepts, and the general challenges with transparency working with core team, I decided that my effort was triggering the same friction with the same people, and thus I was just wasting my time. I don't think my feeling is unique here, e.g. this thread includes several community members who apparently feel they don't understand the real motivation for the proposal, aren't being listened to, and reached out to me because they thought I could help.

It is obvious that Swift has outgrown my influence, and some of the design premises I care about (e.g. "simple things that compose") don't seem in vogue any more. Equally obvious, I have many other interests than Swift, and no shortage of things to spend my time on. I am the sort of person who is always looking ahead, so while this situation is sad, I moved on and am definitely a lot happier not having to deal with it!

Swift has a ton of well meaning and super talented people involved in and driving it. They are trying to be doing the best they can with a complicated situation and many pressures (including lofty goals, fixed schedules, deep bug queues to clear, internal folks that want to review/design things before the public has access to them, and pressures outside their team) that induce odd interactions with the community. By the time things get out to us, the plans are already very far along and sometimes the individuals are attached to the designs they've put a lot of energy into. This leads to a challenging dynamic for everyone involved.

I think that Swift is a phenomenal language and has a long and successful future ahead, but it certainly isn't a community designed language, and this isn't ambiguous. The new ideas on how to improve things sounds promising - I hope they address the fundamental incentive system challenges that the engineers/leaders face that cause the symptoms we see. I think that a healthy and inclusive community will continue to benefit the design and evolution of Swift.



Hi @Chris_Lattner3, I wanted to thank you for everything you did for Swift and its community. Your contributions are outstanding and invaluable.


This is great! It's an important step in the evolution of Swift as a language as it matures. It would be great to see influential library maintainers play a bigger role in language evolution as they are confronted with the day-to-day hurdles of API design outside Swift's core libraries. I hope this stronger position of influence will give even more incentive to create high-quality maintained libraries as the ecosystem expands.


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.


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.


Thanks for rocking our world, sir!

Best of luck on your AI endeavors!


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!


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.


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.


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.


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


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.


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


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.


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.