스위프트는 훌륭한 프로그래밍 언어였으나, 원래의 비전에서 많이 멀어졌습니다.
정말 많이 멀어졌습니다.
오늘은 현대 프로그래밍 언어가 어떻게 운영되는지에 대해 배우도록 하겠습니다. 스위프트의 독재적인 구조가 얼마나 특별히 나쁜지 설명하고, 상황이 얼마나 악화되었는지를 보여드리겠습니다.
하지만 먼저, 스위프트에 대한 간단한 역사 수업을 시작하겠습니다.
스위프트의 간략한 역사
Swift는 Chris Lattner의 열정 프로젝트로, Lattner는 LLVM의 창시자이자 Apple의 개발 도구 수석 이사입니다. 2010년대 초반의 저녁과 주말 동안, 그는 우리가 오늘날 알고 사랑하는 언어의 기초를 작성했습니다.
Apple의 고위 리더십 팀은 경력의 대부분을 Objective-C에 쌓은 OG NeXT 팀으로 가득 차 있었고, 그들은 모두 잡스와 친분이 있었습니다. Swift에 대한 승인을 얻기 위해서는 많은 내부 정치가 필요했습니다.
전형적인 Apple의 비밀주의 속에서, 2014년 WWDC 발표 이전에, 단 250명의 내부 직원만이 결국 그들의 코드베이스를 구식으로 만들게 될 프로젝트에 대해 알았습니다.
Lattner의 비전?
구성하는 간단한 것들.
점진적 공개.
일을 처리하는 하나의 방법.
2015년, Lattner는 상상할 수 없는 일을 해냈습니다: 세계에서 두 번째로 비밀스러운 회사를 설득하여 Swift를 오픈 소스로 전환하게 만들었습니다.
오픈 소스화된 Swift 언어는 시간이 지나면서 발전해왔습니다; 서로 견제를 하는 세 개의 집단에 의해 추진되었습니다:
- 기본 비전을 추진하고 기술 부채를 관리하는 Lattner 자신.
- 언어의 최선의 발전을 원하지만 집합적으로 행동할 때는 고양이 가득 담긴 쓰레기봉투처럼 행동하는 오픈 소스 커뮤니티.
- Swift 팀의 급여를 지급하는 거대 기업 Apple로, 이익에 대한 변함없는 약속을 가지고 있습니다.
2017년, Chris는 AI와 관련된 일로 떠났습니다. Tim Cook의 MBA 친구들은 Swift에 손을 대기 시작하며 다음 생명 단계로 이끌었습니다.
“Swift는 거대하고 복잡한 특별한 경우, 특별한 구문, 특별한 것들의 봉투로 변했습니다…”
2024년, 우리는 앞서 언급된 217개의 키워드에 갇혀 있습니다. 이들은 간단하지도 않고 구성되지도 않습니다.
라트너의 안정적인 손길이 없던 시절, Swift는 두 개의 대립하는 집단 사이에서 불편한 위치에 놓였습니다: 오픈 소스 커뮤니티와 Apple Inc.입니다.
두 집단 모두 자체적인 동기와 결점이 있지만, 누가 모든 영향력을 가지고 있는지는 쉽게 추측할 수 있을 것입니다.
“Apple Inc.는 프로젝트 리드이며 프로젝트의 중재자 역할을 합니다. 프로젝트 리드는 고위 직책에 임명합니다.”
프로그래밍 언어를 어떻게 관리할 것인가
모든 프로그래밍 언어는 누군가에 의해 개발되고 유지됩니다. 이는 개인일 수도 있고, 회사의 팀일 수도 있으며, 널리 분산된 커뮤니티일 수도 있습니다.
각 언어는 변경 사항, 기능 및 확장이 어떻게 선택되고 설계되며 구현되는지에 대한 고유한 규칙을 가지고 있습니다. 이는 안정성, 연속성, 개선 및 이전 버전과의 호환성에 대한 중요성을 가집니다. 수백만 명의 개발자가 사용하는 언어의 경우, 그들의 생계에 대한 자신감이 필요합니다.
가장 인기 있고 성공적인 언어들이 사용하는 거버넌스 모델을 살펴보겠습니다.
Python: 평생 자애로운 독재자
파이썬은 1990년에 귀도 반 로섬에 의해 만들어졌습니다 (몬티 파이썬에서 이름을 따왔습니다). 귀도는 BDFL(평화로운 평생 독재자)라는 직함을 가지고 있었으며, 이는 매우 멋진 직함으로 “주 유지 관리자”를 의미합니다. 궁극적으로, 할당 표현식에 대한 격렬한 논쟁은 2018년에 귀도가 사임하게 된 원인이 되었습니다.
오늘날, 파이썬은 연간 선출되는 5명의 엔지니어로 구성된 운영 위원회에 의해 관리되고 있으며, 이들은 약 100명의 오픈 소스 유지 관리자로부터 선출됩니다. 파이썬에 대한 변경 사항은 PEP를 통해 제안되며, 오픈 소스 커뮤니티가 이에 대해 논의합니다. 운영 위원회가 최종 결정을 내립니다.
“파이썬 개발은 일반적으로 진화적입니다. 파이썬은 새로운 기능과 버전으로 천천히 그리고 신중하게 나아갑니다. 현재의 운영 위원회는 모든 종류의 언어 개선 아이디어에 열려 있지만, 일반적으로는 하위 호환성 유지를 매우 강하게 중시합니다.”
— 귀도 반 로섬
러스트: 커뮤니티 주도의 오픈 소스
러스트는 안전하고 효율적인 시스템 프로그래밍 언어로, 커뮤니티의 힘을 바탕으로 발전해왔습니다. 이 언어는 메모리 안전성을 보장하면서도 높은 성능을 자랑합니다.
러스트의 특징
- 메모리 안전성: 러스트는 소유권 시스템을 통해 메모리 관리를 자동으로 처리합니다.
- 병행성: 러스트는 여러 스레드에서 안전하게 작업할 수 있도록 설계되었습니다.
- 높은 성능: C와 같은 저수준 언어에 필적하는 성능을 제공합니다.
커뮤니티의 중요성
러스트는 활발한 커뮤니티에 의해 지속적으로 개선되고 있습니다. 개발자들은 포럼, GitHub, 채팅 플랫폼을 통해 서로의 지식과 경험을 공유하며, 언어의 발전에 기여하고 있습니다.
러스트 시작하기
러스트를 배우고 싶으신가요? 공식 웹사이트에서 문서와 튜토리얼을 확인하실 수 있습니다.
러스트 로고
결론
러스트는 강력한 기능과 활발한 커뮤니티를 통해 많은 개발자들에게 사랑받고 있는 언어입니다. 앞으로도 지속적인 발전이 기대됩니다.
Rust는 처음에 그레이든 호어의 개인 프로젝트로 시작되었으며, 그의 고용주인 모질라에 의해 채택되었고, 결국 AWS, 화웨이, 구글, 마이크로소프트, 모질라가 참여하여 비영리 단체인 러스트 재단의 지원을 받게 되었습니다.
Rust 언어에 대한 변화는 오픈 소스 커뮤니티에서 환영받으며, RFC 프로세스를 통해 논의됩니다. 이 과정에서 언어, 컴파일러, 개발 도구와 같은 재단 팀의 지도가 이루어집니다.
이러한 점이 이상적으로 들릴 수 있지만, 러스트 커뮤니티는 모든 오픈 소스 커뮤니티와 마찬가지로 드라마가 없지 않습니다.
러스트의 주요 결정은 모두 요청 사항(RFC)으로 시작됩니다. 모든 사람은 제안에 대해 논의할 수 있으며, 상호 이해를 위한 협력에 초대됩니다. 때로는 힘들 수 있지만, 이 커뮤니티의 숙의 과정은 러스트의 품질을 위한 비결입니다.
— 러스트 거버넌스
Kotlin: 기업 지원 오픈 소스
Kotlin은 JetBrains에 의해 개발된 프로그래밍 언어로, 구글의 안드로이드 공식 언어로 채택되면서 많은 주목을 받고 있습니다. Kotlin은 현대적인 언어 특성을 갖추고 있으며, 자바와의 호환성이 뛰어나기 때문에 기존 자바 기반의 프로젝트에 쉽게 통합할 수 있습니다.
Kotlin의 특징
- 간결한 문법: Kotlin은 코드의 가독성을 높이고, 개발자가 더 적은 코드로 더 많은 일을 할 수 있도록 도와줍니다.
- 안전성: 널 포인터 예외를 방지하기 위한 기능이 내장되어 있어, 안전한 프로그래밍을 지원합니다.
- 확장 가능성: 기존 클래스에 새로운 기능을 추가할 수 있는 확장 함수를 제공하여 코드의 재사용성을 높입니다.
- 함수형 프로그래밍: Kotlin은 함수형 프로그래밍 패러다임을 지원하여 코드의 유연성을 높입니다.
기업 지원의 중요성
Kotlin이 기업의 지원을 받는 것은 매우 중요한 요소입니다. 기업이 자금을 지원하고, 커뮤니티와의 협업을 통해 언어의 발전에 기여함으로써, Kotlin은 안정성과 신뢰성을 확보하게 됩니다. 이러한 지원 덕분에 Kotlin은 지속적으로 업데이트되고, 새로운 기능이 추가되며, 개발자들이 필요로 하는 도구와 라이브러리가 확장되고 있습니다.
Kotlin 커뮤니티
Kotlin 커뮤니티는 매우 활발하고, 다양한 리소스와 자료를 제공하여 개발자들이 쉽게 접근할 수 있도록 하고 있습니다. 공식 문서, 튜토리얼, 포럼 등은 개발자들이 Kotlin을 배우고 활용하는 데 큰 도움이 됩니다.
결론
Kotlin은 기업의 지원과 활발한 커뮤니티 덕분에 더욱 발전하고 있는 언어입니다. 개발자는 Kotlin을 통해 생산성을 높이고, 안전하며 효율적인 코드를 작성할 수 있습니다. 앞으로도 Kotlin의 성장은 계속될 것으로 기대됩니다.
코틀린은 IDE 회사인 JetBrains에 의해 2011년에 만들어졌습니다. 그들은 인텔리제이의 판매를 늘리고 다른 개발 도구를 크로스셀링하기를 희망했습니다. 2017년 구글이 안드로이드에 대한 코틀린 지원을 발표하면서 큰 반향을 일으켰습니다.
코틀린은 코틀린 재단에 의해 관리되며, 이 재단은 구글과 JetBrains이 공동으로 설립했습니다. 재단의 이사회는 주요 언어 디자이너를 임명하며, 이 사람은 기본적으로 고위 JetBrains 엔지니어입니다. 커뮤니티 구성원은 커뮤니티에서 논의할 KEEP을 제출할 수 있으며, 개발자들은 최종화되기 전에 실험적 API를 테스트할 수 있습니다.
“언어 설계는 돌에 새겨져 있지만, 이 돌은 상당히 부드럽고, 약간의 노력으로 우리는 나중에 이를 재형성할 수 있습니다.”
이 모든 언어들은 변경 사항을 제안하고 논의하는 오픈 소스 커뮤니티를 가지고 있습니다. 그들은 또한 언어 자체를 유지 관리하고 확장하는 보다 중앙집중적인 집단이 있으며, 언어의 발전에 대한 최종 결정을 내립니다.
인센티브
인센티브는 사람들이 특정 행동을 하도록 유도하기 위해 제공되는 보상이나 동기부여 요소입니다. 이러한 인센티브는 개인이나 집단의 성과를 향상시키기 위해 다양한 형태로 제공될 수 있습니다.
인센티브의 종류
- 재정적 인센티브: 보너스, 급여 인상, 직무 성과에 따른 금전적 보상 등
- 비재정적 인센티브: 인정, 감사의 표시, 직무 만족도를 높이는 프로그램 등
- 사회적 인센티브: 팀워크와 협력을 장려하는 활동이나 이벤트 등
인센티브의 중요성
인센티브는 개인이나 팀이 목표를 달성하도록 돕는 중요한 역할을 합니다. 적절한 인센티브는 동기를 부여하고, 생산성을 높이며, 조직 내에서 긍정적인 분위기를 조성하는 데 기여합니다.
결론
인센티브는 사람들의 행동에 긍정적인 영향을 미칠 수 있는 강력한 도구입니다. 이를 통해 개인과 조직 모두가 성장할 수 있는 기회를 제공받을 수 있습니다.
근본적으로 프로그래밍 언어 거버넌스는 인센티브를 조정하는 것과 관련이 있습니다. 모든 프로그래밍 언어에는 3개의 주요 이해관계자가 있습니다:
- 일상적으로 언어를 사용하는 최종 사용자 개발자들입니다.
- 언어 제안을 제출하고 구현하는 커뮤니티입니다.
- 최종 결정을 내리는 운영 그룹입니다.
최종 사용자 개발자들은 멋진 언어로 작업하기를 원합니다. 언어는 그들의 인센티브이며, 그들은 키보드로 투표합니다. 이 집단은 수백만 명에 이르지만, 언어 전환 비용이 매우 높기 때문에 실제로는 가장 적은 영향력을 가지고 있습니다. 대부분은 자신의 수년간의 경험을 버리기를 원하지 않습니다.
커뮤니티는 가장 열정적인 최종 사용자 개발자들과 운영 그룹이 이끄는 전담 팀으로 구성됩니다. 이 파벌은 일반적으로 선호하는 언어를 개선하고자 하는 가장 순수한 인센티브를 가지고 있습니다. 그러나 그들은 몇 가지 다른 opposing forces에 직면해 있습니다:
- 이력서 중심의 개발은 엔지니어들이 개인의 고용 가능성을 높이기 위해 논의에 참여하도록 자극합니다. 게다가, 노력하는 것은 어렵습니다.
- 바이크쉐딩은 행동의 일반적인 동기입니다: 제안의 기술적 설계에 집중하는 대신, 저항이 가장 적은 길을 선택하고 구문 및 명명과 같은 사소한 문제에 에너지를 집중하는 것이 쉽습니다.
Swift의 발전 포럼은 구문적 바이크쉐딩으로 페이지가 가득 차 있는 것으로 유명합니다.
운영 그룹은 의사 결정 권한이 있는 가장 강력한 이해관계자이며, 거버넌스 구조에 따라 매우 다른 인센티브를 가질 수 있습니다.
Python이나 Rust와 같은 경우에는 운영 그룹이 가장 영향력 있는 커뮤니티 구성원으로 형성되어, 언어에 대해 “가장 좋은 것”을 지향하는 불완전한 인센티브 집합을 조정합니다.
반면, Kotlin의 경우 언어를 운영하는 기업은 이익 동기를 가지고 있습니다: IDE(예: JetBrains)를 판매하고 Android 개발자의 수와 생산성을 높이는 것입니다(예: Google).
다행히도 이러한 거버넌스 인센티브는 다른 이해관계자들의 인센티브와 잘 맞아 떨어집니다: 좋은 언어를 만드는 것이 이러한 목표를 달성하는 데 도움이 될 것입니다.
스위프트: 평생 기업 독재자
스위프트라는 말은 주로 프로그래밍 언어를 지칭하지만, 이 포스트에서는 그보다 더 깊은 의미를 탐구해 보려고 합니다. 스위프트는 단순한 기술이 아니라, 기업 세계에서 권력을 어떻게 행사할 수 있는지를 상징합니다.
스위프트의 배경
스위프트는 처음에는 애플에 의해 개발된 프로그래밍 언어로 시작했습니다. 하지만 시간이 지나면서, 이 언어는 여러 산업 분야에서 활용되며 그 자체로 하나의 독립적인 생태계를 이루게 되었습니다. 이는 기술의 발전이 기업의 운영 방식에도 큰 영향을 미친다는 것을 보여줍니다.
기업에서의 스위프트의 역할
스위프트는 기업 내에서 결정적인 역할을 할 수 있습니다. 그 사용은 개발자뿐만 아니라 경영진에게도 큰 영향을 미치며, 이는 기업의 전략적 결정에까지 이어집니다. 이를 통해 기업은 더 빠르고 효율적으로 운영될 수 있으며, 경쟁력을 유지할 수 있습니다.
스위프트와 독재적 경영
스위프트의 도입은 때때로 독재적 경영 스타일을 강화할 수 있습니다. 기술의 힘이 경영진에게 집중됨에 따라, 의사 결정 과정에서 더 많은 권한을 가진 이들이 등장할 수 있습니다. 이는 기업의 유연성을 저해하고, 직원들의 의견을 무시하는 결과를 초래할 수 있습니다.
결론
스위프트는 단순한 프로그래밍 언어를 넘어, 현대 기업에서의 권력 구조를 재편하는 중요한 요소로 자리잡고 있습니다. 이로 인해 기업의 운영 방식과 경영 스타일에도 큰 변화가 일어나고 있습니다. 따라서 스위프트를 이해하고 활용하는 것은 이제 선택이 아닌 필수가 되었습니다.
애플과 스위프트는 최악의 환경을 만들어냅니다.
애플은 스위프트의 독재자입니다. 그들은 대부분의 핵심 팀의 급여를 지급하며, 프로젝트 리더십 팀 구성원을 임의로 임명할 수 있는 권한을 가지고 있습니다.
애플이 가진 순수한 동기는 주주를 위한 이익 극대화입니다.
이 이익 추구는 수백만의 iOS 개발자들과 어느 정도 일치합니다. 더 나은 언어는 더 많은 iOS 엔지니어를 의미하고, 이는 더 많은 앱, 더 많은 스토어 수익 및 기기 판매로 이어집니다.
하지만 이러한 동기는 언어를 발전시키는 오픈 소스 커뮤니티와 위험하게 대립하게 됩니다. 덜 심각하게는 스위프트 핵심 팀과도 대립하게 됩니다.
스위프트 5.1은 애플이 커뮤니티에 대해 전혀 신경 쓰지 않는 전형적인 사례입니다. 이는 불투명한 결과 타입, some, 암시적 반환, 프로퍼티 래퍼를 도입했습니다. 심지어 함수 빌더를 진화 과정 없이 컴파일러에 구현하기도 했습니다!
이러한 기능들은 함께 스위프트 UI, 미래의 화려한 새로운 UI 프레임워크™의 구문적 뼈대를 형성합니다. 애플의 내부 일정은 이러한 기능들에 대한 일방적인 승인을 결정했으며, 커뮤니티에게 공정한 발언권을 주지 않았습니다.
결과적으로 스위프트 UI는 View를 명시적으로 return했을 때보다 조금 더 보기 좋습니다. 스위프트 UI는 부모 결과에 자식 뷰를 추가할 필요가 없어 더 깔끔합니다. 하지만 이러한 기능들은 전체 언어에 복잡성과 컴파일러 마법을 주입했습니다.
개인적으로, 스위프트 동시성 선언서는 2017년에 작성되었습니다. 하지만 2019년에 최신 UI 프레임워크를 완성하는 것이 스위프트 팀의 리소스를 배분하는 데 훨씬 더 높은 우선 순위였고, 이로 인해 스위프트 동시성은 수년을 지연된 후 2021년에야 실현되었습니다.
Lattner의 유산
…
크리스 래트너의 디자인 철학을 다시 살펴보고 현대의 스위프트와 비교해 보겠습니다:
- 구성하는 간단한 것들. (구성하지 않는 복잡한 기능들)
- 점진적 공개. (스위프트는 217개의 키워드를 가지고 있습니다)
- 일 처리하는 방법이 하나입니다. (결과 빌더 및 매크로?!)
2017년 애플을 떠났음에도 불구하고, 래트너는 2021년까지 스위프트 핵심 팀에 남아 있었습니다. 그의 퇴사 이유는 스위프트에 대한 비관적인 전망을 예고했습니다:
…여러 차례의 논의 후 보다 더 많은 열기를 생성하는 과정에서, 제가 제출한 공식 제안 검토 댓글과 우려가 일방적으로 무시되고, 핵심 팀과의 투명성 문제로 인해 시간을 낭비하고 있다고 느꼈습니다.
…몇몇 커뮤니티 구성원들은 제안의 진정한 동기를 이해하지 못하고 있으며, 그들의 의견이 반영되지 않고 있다고 느끼고 있습니다.
높은 목표, 고정된 일정, 해결해야 할 심각한 버그 대기열, 대중이 접근하기 전에 검토/디자인 하기를 원하는 내부 인물들, 팀 외부의 압력 등 여러 압력이 커뮤니티와의 이상한 상호작용을 유발합니다.
일들이 우리에게 전달될 때쯤이면, 계획은 이미 많이 진행된 상태이며, 때로는 개인들이 그들이 많은 에너지를 쏟은 디자인에 집착하게 됩니다. 이는 모든 관련자에게 도전적인 역학을 초래합니다.
이 첫 손 경험은 스위프트의 불균형한 거버넌스 구조에서 우리가 기대할 수 있는 것과 정확히 일치합니다.
애플은 그들의 오픈 소스 커뮤니티에 형식적으로 서비스하며, 제안에 대한 의견을 구하는 척하지만, 그들은 또한 습관적으로 자신의 제안을 밀어붙입니다 — 그들은 배포할 프레임워크가 있습니다.
그들의 성벽을 강화하는 독점적인 UI 프레임워크 및 크로스 플랫폼 기능과 같은 전략적 우선 사항은 항상 우선시될 것입니다. 몇몇 불평하는 개발자들을 귀찮게 하는 것이 무슨 상관입니까?
기술 부채와 컴파일러
크리스 래트너는 팟캐스트 출연에서 컴파일러의 기술 부채에 대한 지연 문제를 여러 차례 언급하였습니다. 이는 그의 작은 팀이 수백만 명의 개발자들을 행복하게 유지하면서 Objective-C에서 전체 개발 환경을 마이그레이션하고 Swift 2에서 3로 이동할 때 피할 수 없는 일이었습니다.
요즘, 그의 영향력에서 벗어난 컴파일러는 회복할 수 없을 만큼 매우 부조리한 기술 부채를 안고 있습니다.
현대의 Swift는 애플 MBA 집단의 위에서 아래로의 의도에 종속되어 있습니다. 이들은 비밀을 중시하며 커뮤니티의 의견을 경시합니다. 래트너의 영향력이나 잡스의 장인 정신에 대한 끊임없는 추진력에서 벗어나, 이제는 최신 독점 수익 창출 제품을 출시하는 것이 전부입니다.
애플은 그들의 인센티브 구조를 감안할 때 Swift에 대해 비합리적으로 행동하고 있지 않습니다. 현재 상황을 좀 더 명확히 설명해 보겠습니다:
SwiftUI가 상당히 뛰어나다고 주장하기는 어렵지 않습니다.
비즈니스 관점에서 볼 때, 2019년까지는 선언적 UI 프레임워크를 출시하는 것이 필수적이었습니다 이는 빠르게 성장하는 크로스 플랫폼 경쟁자인 React Native와 Flutter와 경쟁하기 위해서였습니다.
iOS, MacOS, watchOS, TVOS, 그리고 이제는 VisionOS까지 플랫폼을 통합하는 것도 주요 전략 지침이었으며, 이는 애플 하드웨어 전반에 걸쳐 생태계를 강화했습니다.
Craig Federighi는 바보가 아닙니다 — 언어를 더 복잡하게 만드는 것은 그들이 고려한 트레이드오프였습니다. 항상 그렇듯이, 비즈니스의 이익이 컴파일러의 타입 체크 예외에 대해 불만을 토로하는 기술 애호가들보다 우선합니다.
Swift에 대한 희망은 있을까요?
애플과 더 넓은 오픈 소스 커뮤니티는 크리스가 관계를 끊는 극적인 조치를 취했을 때 주목했습니다. 그것이 유일한 요인은 아니었지만, 독재적이지 않고 더 투명한 거버넌스 모델로의 전환을 촉진하는 데 도움이 되었습니다.
스위프트는 러스트 모델에서 아이디어를 차용하고 있습니다 — 애플 외부의 팀 구성원을 포함한 전문화된 운영 그룹 및 작업 그룹을 말이죠.
그들이 “기여자 경험”을 위해 전체 Steering 그룹이 필요하다는 것이 조금 웃깁니다. Lattner는 그들이 가장 약한 부분을 정확히 지적했습니다.
애플의 폐쇄적인 환경 외부에서 Swift를 사용하는 것에 대한 강조는 애플의 거버넌스가 독점 프레임워크의 숲 속에서 훌륭한 프로그래밍 언어의 숲을 볼 수 있는 희망의 빛을 제공합니다. 현재 Swift를 Windows와 Arduino에 도입하기 위한 플랫폼 Steering 그룹이 존재합니다.
애플은 자사의 일부 백엔드 시스템에서 Swift를 내부적으로 사용하며, 초당 수백만 건의 요청을 처리하고 있습니다. 이는 완전히 이타적인 것은 아니지만, 서버에서의 Swift 작업 그룹에 대한 투자는 꽤 훌륭합니다.
마지막으로 애플은 모든 플랫폼에 잘 포팅될 수 있는 오픈 소스 Swift 패키지로 Foundation을 재작성하는 작업을 진행하고 있습니다. AsyncAlgorithms와 같은 많은 새로운 라이브러리도 표준 라이브러리처럼 운영 체제에 묶이지 않고 패키지로 제공됩니다.
Swift는 원래의 구성할 수 있는 간단한 것들이라는 비전에서 멀어졌지만, 언어는 여전히 세계 최고의 범용 프로그래밍 언어를 만들기의 목표를 달성할 수 있을 것입니다.
정말 그렇게 되기를 바랍니다.
최근에는 주로 Substack에 글을 올리고 있습니다.