Apple убивает Swift

Swift был отличным языком, но он далеко ушел от своего первоначального видения.

Довольно далеко.

Сегодня мы узнаем, как управляются современные языки программирования. Я объясню, чем уникально плоха диктаторская структура Swift, и продемонстрирую вам, насколько плохой стала ситуация.

Но сначала — краткий урок истории Swift.

Краткая история Swift

Swift был страстным проектом Криса Латтнера, создателя LLVM и старшего директора по разработке инструментов в Apple. По вечерам и выходным в начале 2010-х годов он писал основы языка, который мы знаем и любим сегодня.

Высшее руководство Apple было до отказа набито командой OG NeXT, все они были в первых рядах с Джобсом и построили свою карьеру на Objective-C. Потребовалось много внутренних политических усилий, чтобы дать Swift зеленый свет.

В условиях классической секретности Apple до анонса на WWDC 2014 только 250 сотрудников знали о проекте, который в конечном итоге сделает их кодовые базы устаревшими.

Видение Латтнера?

Простые вещи, которые создают композицию.
Прогрессивное раскрытие.
Один способ делать вещи.

В следующем, 2015 году Латтнер добился немыслимого: убедил вторую по секретности компанию в мире открыть исходный код Swift.

Язык Swift с открытым исходным кодом развивался в течение многих лет; им управляли три племени, которые держали друг друга в узде:

1. Сам Латтнер, который придерживался своего основного видения и держал в узде технологический долг.
2. Open-source сообщество, которое в основе своей хотело лучшего для языка, но в совокупности ведет себя как мусорный мешок, полный кошек.
3. Apple, гигант, который платит зарплату команде Swift, и который непоколебимо стремится к прибыли.

В 2017 году Крис отправился возиться с искусственным интеллектом. Приятели Тима Кука по MBA начали вплетать свои усики в Swift и направлять его к следующему этапу жизни.

Swift превратился в гигантский, сверхсложный пакет специальных случаев, специального синтаксиса, специальных вещей…,  - Крис Латтнер, 2024

В 2024 году мы застряли с вышеупомянутыми 217 ключевыми словами. Они не являются ни простыми, ни дополняющими друг друга.

Без твердой руки Латтнера Swift оказался в неудобном положении между двумя враждующими кланами: open-source сообществом и компанией Apple.

У обоих есть свои стимулы и свои недостатки, но вы можете догадаться, кто имеет большее влияние.

Apple Inc. является лидером проекта и выступает в роли арбитра. Руководитель проекта производит назначения на руководящие должности,  - Swift.org

Как управлять языком программирования

Каждый язык программирования разрабатывается и поддерживается кем-то. Это может быть отдельный человек, команда в компании или большое распределенное сообщество.

У всех языков есть свои правила, по которым выбираются, разрабатываются и внедряются изменения, функции и расширения. Это очень важно для обеспечения стабильности, непрерывности, улучшения и обратной совместимости. Для любого языка, которым пользуются миллионы разработчиков, необходима уверенность в том, что они смогут зарабатывать на жизнь.

Давайте рассмотрим модели управления, используемые в самых популярных и успешных языках.

Python: пожизненный благожелательный диктатор

Python был создан Гвидо ван Россумом в 1990 году (и назван в честь Монти Пайтона). Гвидо был BDFL (benevolent dictator for life), титул, который чертовски радикален (и по сути является эвфемизмом для «lead maintainer»). В конце концов, жаркие споры о назначениях привели к тому, что Гвидо покинул свой пост в 2018 году.

Сегодня Python управляется руководящим советом из 5 инженеров, которых ежегодно избирают около сотни мантейнеров. Изменения в Python предлагаются через PEP, которые обсуждаются open-source сообществом. Последнее слово остается за управляющим комитетом.

Разработка Python в целом носит эволюционный характер. Python медленно и осторожно продвигается к новым функциям и версиям. Нынешний руководящий совет, будучи открытым для всевозможных идей по улучшению языка, в целом уделяет большое внимание сохранению обратной совместимости, — Гвидо ван Россум

Rust: открытый исходный код, управляемый сообществом

Изначально Rust был личным проектом Грейдона Хоара, который был принят компанией Mozilla, его работодателем, и в итоге стал поддерживаться Rust Foundation — некоммерческой организацией, созданной AWS, Huawei, Google, Microsoft и Mozilla.

Изменения в языке Rust получаются от open-source сообщества и обсуждаются в рамках процесса RFC, при этом команды Foundation руководят такими направлениями, как язык, компилятор и инструменты разработки.

Хотя это может показаться утопией, сообщество Rust, как и все open-source сообщества, не лишено драматизма.

Каждое важное решение в Rust начинается как запрос на комментарии (RFC). Всех приглашают обсудить предложение, чтобы прийти к общему пониманию компромиссов. Хотя это обсуждение в сообществе иногда бывает трудным, оно является секретным соусом качества Rust, — Об управлении Rust

Kotlin: открытый код, поддерживаемый корпорацией

Kotlin был создан компанией JetBrains, специализирующейся на IDE, в 2011 году. Компания надеялась продать больше копий IntelliJ и наладить перекрестные продажи других инструментов для разработчиков. В 2017 году Google объявила о поддержке Kotlin для Android.

Kotlin управляется Kotlin Foundation, созданным совместно Google и JetBrains. Совет директоров фонда назначает ведущего дизайнера языка, который, по сути, является высокопоставленным инженером JetBrains. Члены сообщества могут представить KEEP для обсуждения сообществом, а разработчики могут протестировать экспериментальные API до их окончательной доработки.

Дизайн языка застыл в камне, но этот камень достаточно мягкий, и, приложив некоторые усилия, мы можем впоследствии изменить его форму,  - Команда дизайна Kotlin

Все эти языки имеют open-source сообщества, которые предлагают и обсуждают изменения. У них также есть более централизованная фракция, которая поддерживает и расширяет сам язык и имеет окончательное право голоса в вопросах эволюции.

Стимулы

По сути, управление языком программирования — это согласование стимулов. У каждого языка программирования есть три основных участника:

1. Разработчики для конечных пользователей, которые используют язык ежедневно.
2. Сообщество, представляющее (и реализующее) предложения по языку.
3. Руководящая группа, за которой остается последнее слово.

Разработчики приложений просто хотят работать с хорошим языком. Язык — это их стимул, и они голосуют своими клавиатурами. Эта когорта исчисляется миллионами, однако на самом деле они имеют наименьшее влияние из-за чрезвычайно высокой стоимости перехода на другой язык: большинство из них не захотят бросать свой многолетний опыт.

Сообщество формируется из наиболее увлеченных разработчиков, работающих с конечными пользователями, а также из штатных команд под руководством управляющей группы. У этой фракции, как правило, самые чистые побуждения: желание улучшить любимый язык. Однако они подвержены влиянию нескольких других противоборствующих сил:

• Résumé-driven разработка подталкивает инженеров к участию в дискуссиях просто для того, чтобы повысить свою личную конкурентоспособность. Кроме того, тяжелая работа — это тяжелая работа.
• Закон тривиальности — распространенная причина такого поведения: вместо того чтобы сосредоточиться на техническом дизайне предложения, легко пойти по пути наименьшего сопротивления и сосредоточить энергию на таких мелочах, как синтаксис и именование.

Форумы, посвященные эволюции Swift, печально известны своими страницами синтаксических тривиальностей.

Руководящая группа, имеющая право принимать решения, легко может быть самой влиятельной группой, и у нее могут быть совершенно разные стимулы в зависимости от структуры управления.

В некоторых случаях, например, в Python или Rust, руководящая группа формируется из наиболее влиятельных членов сообщества, что позволяет выровнять их несовершенный набор стимулов в направлении чего-то, напоминающего «то, что лучше для языка».

В других случаях, как, например, в случае с Kotlin, бизнес, управляющий языком, руководствуется мотивом прибыли: продажа IDE (JetBrains) и увеличение числа и производительности Android-разработчиков (Google).

К счастью, эти стимулы управления хорошо сочетаются со стимулами других заинтересованных сторон: создание хорошего языка будет способствовать достижению этих целей.

Swift: корпоративный диктат на всю жизнь

Apple и Swift создают худший из миров.

Apple однозначно является диктатором для Swift. Они платят зарплату большинству членов основной команды и имеют право произвольно назначать членов руководства проекта.

У Apple есть самый чистый из всех стимулов: максимизация прибыли для акционеров.

В какой-то степени этот мотив прибыли объединяет их с более слабой когортой миллионов iOS-разработчиков. Лучший язык означает больше iOS-инженеров, а значит, больше приложений, а значит, больше доходов магазина приложений и продаж устройств.

Но этот стимул ставит их в опасное противоречие с open-source сообществом, которое двигает язык вперед. В меньшей степени это ставит их в противоречие с основной командой Swift.

Swift 5.1 — это канонический пример того, как Apple плевать на сообщество. В нем появились непрозрачные типы результатов с some, неявные возвраты и обертки свойств. В этой версии в компилятор даже внедрили билдеры функций без какого-либо процесса эволюции!

Все эти функции вместе составляют синтаксический костяк SwiftUI, нового блестящего фреймворка пользовательского интерфейса будущего™. Внутренние сроки Apple диктовали одностороннее одобрение (или отсутствие такового) этих функций, вместо того чтобы дать сообществу возможность высказаться.

В результате SwiftUI выглядит немного красивее, чем если бы мы работали с View в явном виде. SwiftUI стал чище без необходимости добавлять дочерние представления к родительскому результату. Но эти функции также привнесли сложность и магию компилятора в весь язык.

С моей личной точки зрения, манифест Swift Concurrency Manifesto был написан в 2017 году. Однако, при распределении ресурсов команды Swift* гораздо более приоритетной задачей стало создание в 2019 году нового UI-фреймворка, что отложило Swift Concurrency на годы, до 2021 года.

* Что ж, по крайней мере, я получил Combine.

Наследие Латтнера

Давайте еще раз рассмотрим философию дизайна Криса Латтнера и сравним ее с современным Swift:

• Простые вещи, которые компонуются. (Сложные функции, которые не компонуются).
• Прогрессивное раскрытие. (В Swift 217 ключевых слов)
• Один способ делать вещи. (Билдерырезультатов и макросы?!).

Несмотря на уход из Apple в 2017 году, Латтнер оставался в основной команде разработчиков Swift до 2021 года. В объяснении причин его ухода говорилось о пессимистичных перспективах Swift:

…после нескольких дискуссий, в которых было больше жары, чем света, когда мои официальные замечания и опасения по поводу рассмотрения предложений были проигнорированы в одностороннем порядке, а также из-за общих проблем с прозрачностью в работе с основной командой, я решил, что просто зря трачу время.

…несколько членов сообщества считают, что не понимают реальной мотивации предложения, что к ним не прислушиваются.

Многие факторы (включая высокие цели, фиксированные графики, большие очереди на устранение ошибок, люди внутри, которые хотят просмотреть/разработать вещи до того, как к ним получит доступ общественность, и начнется давление вне команды) вызывают странное взаимодействие с сообществом.

К тому моменту, когда вещи попадают к нам, планы уже очень далеко продвинулись, и иногда люди привязываются к дизайну, в который они вложили много энергии. Это приводит к сложной динамике для всех участников процесса.

Этот мрачный рассказ из первых рук полностью совпадает с тем, что мы должны ожидать от однобокой структуры управления Swift.

Apple на словах поддерживает сообщество разработчиков с открытым исходным кодом, якобы обращаясь к ним с предложениями, но в то же время они постоянно продвигают свои собственные предложения — им нужно выпускать фреймворки.

Стратегические приоритеты, такие как собственные UI-фреймворки и кросс-платформенная функциональность, которая укрепляет их «огород», всегда будут иметь приоритет. Кого волнует, что они раздражают некоторых ноющих зануд?

Технологические долги и компиляторы

Крис Латтнер в своих подкастах неоднократно говорил о том, что компиляторы накопили большой технический долг. Это было неизбежно в самом начале, пока его крошечная команда успешно обеспечивала счастье миллионов разработчиков, переводя всю среду разработки с Objective-C и со Swift 2 на 3.

Сейчас, вдали от  его влияния, компилятор имеет крайне глупый технический долг, от которого он может никогда не оправиться.

Swift type check rules are for you. We just hardcode exceptions in the compiler when we need it.

go figure and make sense of Swift https://t.co/w6Ec6Elq43

— Marcin Krzyzanowski (@krzyzanowskim) August 1, 2024

Современный Swift — раб, подчиняющийся проходящим сверху вниз прихотям клики Apple MBA, которая ценит секретность и насмехается над вкладом сообщества. Независимо от влияния Латтнера или даже от неустанного стремления к мастерству, навязываемого Джобсом, все дело в том, чтобы предложить новейший запатентованный механизм получения прибыли.

Apple ублюдки?

Apple не ведет себя неразумно по отношению к Swift, учитывая их стимулы. Мы можем оценить текущую ситуацию.

Трудно поспорить с тем, что SwiftUI чертовски хорош.

С точки зрения бизнеса, к 2019 году было необходимо выпустить декларативный фреймворк пользовательского интерфейса, чтобы конкурировать с быстро растущими кроссплатформенными конкурентами React Native и Flutter.

Объединение платформ (iOS, macOS, watchOS, TVOS, а теперь и VisionOS) также было важной стратегической задачей, которая укрепила экосистему на всех устройствах Apple.

Крейг Федериги не идиот — усложнение языка было компромиссом, который они рассматривали. Как всегда, выгода для бизнеса превалирует над гиками-луддитами, жалующимися на исключения в компиляторе при проверке типов.

Есть ли надежда для Swift?

Apple и широкое сообщество open-source разработчиков заметили, когда Крис сделал резкий шаг — разорвал все связи. Хотя это был не единственный фактор, он помог катализировать сдвиг в сторону менее диктаторской и более прозрачной модели управления.

Swift заимствует идеи из модели Rust — специализированные руководящие группы и рабочие группы, включающие членов команды не из Apple.

Немного забавно, что им нужна целая руководящая группа для «Опыта контрибьюторов». Латтнер действительно показал, что это их самое слабое место.

Акцент на использовании Swift за пределами «огороженного сада» Apple дает проблеск надежды на то, что руководство Apple начнет видеть лес отличного языка программирования сквозь деревья проприетарных фреймворков. Сейчас существует руководящая группа по платформам, чтобы вывести Swift на Windows и Arduino.

Внутри компании Apple Swift используется на некоторых собственных внутренних системах, обрабатывая миллионы запросов в секунду. Хотя это не совсем альтруистично, инвестиции в рабочую группу Swift On The Server — это очень здорово.

Наконец, Apple работает над переписыванием Foundation в виде пакета Swift с открытым исходным кодом, который одинаково хорошо переносится на все платформы. Многие новые библиотеки, такие как Async Algorithms, также поставляются в виде пакетов, а не привязаны к ОС, как стандартные библиотеки.

Swift далеко отошел от первоначального видения простых вещей, которые компонуются друг с другом; но язык еще может достичь своей цели — стать лучшим в мире языком программирования общего назначения.

Я очень надеюсь, что так и будет.

Источник