Как и просили, вот мои предложения по развитию Rust в 2019 году и далее.
Должен отметить, что говорю только за себя, а я даже не очень активный участник проекта. Более того, эти предложения в значительной степени относятся ко многим проектам. Rust — частный случай, но именно он сейчас наводит на некоторые размышления.
Ещё должен отметить, что я в целом доволен развитием Rust, и это предложение делается только ради сохранения дальнейшего благополучия, чтобы избежать некоторых проблем, которые я сейчас наблюдаю со стороны.
TL;DR: Важно осознать проблему и запланировать явные механизмы по ограничению роста двух вещей:
В частности, хочу обратить внимание на невозможность и нежелательность неограниченного роста по обоим направлениям. Существуют естественные пределы. Как и во всех природных системах, которые достигли пределов роста, лучше подготовиться к этому событию и провести его контролируемым, запланированным образом.
Обратите внимание, что я не пишу о пределах роста многих других направлений. Например, индекс пакета, объём сайта или даже сообщество пользователей. Неясно, какую угрозу это несёт Rust, поэтому сейчас мы говорим только о двух конкретных проблемах выше.
У каждой природной системы есть пределы роста. Вот почему Вселенная не является (например) одной амёбой, которая расширяется со скоростью света. Система растёт (и часто скорость расширения тоже растёт!) до тех пор, пока не сталкивается с ограничивающими факторами, а затем постепенно рост замедляется, пока общий размер системы не выйдет на плато. Типичные закономерности роста при этом выглядят примерно как сигмоид или «S-образная кривая», постепенно приближаясь к некоторой асимптоте. По крайней мере, если ограничивающие факторы наступают постепенно и контролируемым образом.
Когда система сталкивается с пределом неконтролируемым образом или внезапно, может произойти явление, больше похожее на перелёт цели или даже возврат: предел всё ещё существует, но его эффект ощущается скорее в виде коллапса или кризиса. S-образная кривая поднимается до пика, за которым следует обвал. Такого хотелось бы избежать.
В проекте Rust действует несколько форм управления процессами, которые по сути ограничивают темпы изменений и/или роста. Я считаю эти меры очень разумными: частично благодаря им проект до сих пор успешен. По аналогии с ними хочу сформулировать следующие рекомендации. Нынешние формы управления:
Кроме того, в рамках проекта созданы важные социальные структуры для ограничения количества участников проекта.
Всё это, по сути, признание того, что в отсутствие контроля могут произойти неприятности и кризисы: по крайней мере, хаос и дисфункции в определённой степени. По возможности контроль автоматический и полностью беспристрастный (чтобы свести к минимуму недоброжелательность и субъективную оценку, соблазн срезать углы и т. д.) Если субъективности не избежать, по крайней мере, нормы и процессы чётко сформулированы в письменной форме, в хорошо документированных, известных местах.
Вернёмся к двум проблемным областям, где сейчас у проекта нет адекватных механизмов или политики для контроля Rust, что несёт риски возможной дисфункции или даже кризиса. В обоих случаях не совсем понятно, насколько далёк сейчас проект от такого кризиса. Но в любом случае лучше действовать на упреждение, чем опоздать.
Это трудная часть, где я постараюсь избегать чётких формулировок. В конце концов, важно принять контроль по собственной воле, а не навязанный извне. Думаю, что участники проекта должны сделать паузу, поразмыслить, коллективно рассмотреть и установить некоторые элементы управления. Поэтому я только предложу несколько возможных вариантов, не очень структурированных, но в праздничном рождественском духе: как кучу потенциально интересных подарков, чтобы их развернуть, посмотреть и решить, оставить или обменять на что-то более интересное.
Это лишь некоторые идеи в общем направлении ограничений на рост. Уверен, что вы можете придумать и более реалистичные способы, как взять под контроль ограничения на размер языка и личные нагрузки. На протяжении многих лет сообщество Rust показало себя восхитительно творческим, мыслящим и самокритичным. За это вас следует похвалить. Надеюсь, эта статья будет воспринята в том же духе конструктивной критики.
С Новым годом и удачи!
Должен отметить, что говорю только за себя, а я даже не очень активный участник проекта. Более того, эти предложения в значительной степени относятся ко многим проектам. Rust — частный случай, но именно он сейчас наводит на некоторые размышления.
Ещё должен отметить, что я в целом доволен развитием Rust, и это предложение делается только ради сохранения дальнейшего благополучия, чтобы избежать некоторых проблем, которые я сейчас наблюдаю со стороны.
TL;DR: Важно осознать проблему и запланировать явные механизмы по ограничению роста двух вещей:
- Обязательные общие технические артефакты, особенно само определение языка.
- Нагрузка на людей, участвующих в обсуждении этих артефактов.
В частности, хочу обратить внимание на невозможность и нежелательность неограниченного роста по обоим направлениям. Существуют естественные пределы. Как и во всех природных системах, которые достигли пределов роста, лучше подготовиться к этому событию и провести его контролируемым, запланированным образом.
Обратите внимание, что я не пишу о пределах роста многих других направлений. Например, индекс пакета, объём сайта или даже сообщество пользователей. Неясно, какую угрозу это несёт Rust, поэтому сейчас мы говорим только о двух конкретных проблемах выше.
Ограничивающие факторы и перелёт
У каждой природной системы есть пределы роста. Вот почему Вселенная не является (например) одной амёбой, которая расширяется со скоростью света. Система растёт (и часто скорость расширения тоже растёт!) до тех пор, пока не сталкивается с ограничивающими факторами, а затем постепенно рост замедляется, пока общий размер системы не выйдет на плато. Типичные закономерности роста при этом выглядят примерно как сигмоид или «S-образная кривая», постепенно приближаясь к некоторой асимптоте. По крайней мере, если ограничивающие факторы наступают постепенно и контролируемым образом.
Когда система сталкивается с пределом неконтролируемым образом или внезапно, может произойти явление, больше похожее на перелёт цели или даже возврат: предел всё ещё существует, но его эффект ощущается скорее в виде коллапса или кризиса. S-образная кривая поднимается до пика, за которым следует обвал. Такого хотелось бы избежать.
Примеры хорошего контроля
В проекте Rust действует несколько форм управления процессами, которые по сути ограничивают темпы изменений и/или роста. Я считаю эти меры очень разумными: частично благодаря им проект до сих пор успешен. По аналогии с ними хочу сформулировать следующие рекомендации. Нынешние формы управления:
- Очередь Bors пропускает изменения по корректности для программы.
- Crater пропускает релизы по корректности для экосистемы.
- Запланированные релизы предпочитают выпустить в срок, даже если запланированная функция не готова. Решение принимается по времени, а всё неготовое отрезается.
Кроме того, в рамках проекта созданы важные социальные структуры для ограничения количества участников проекта.
- Кодекс поведения. Не все помнят, но он не просто постулирует социальную справедливость и так далее. Он также устанавливает лимиты на соотношение сигнал/шум в разговорах, эксплуатацию чужого внимания и времени и подталкивает к компромиссам (ведь не каждое решение даёт нулевую сумму).
- Процесс RFC. Правила о форме, содержании, сроках, наборе участников, разрешённых и ожидаемых формах дискурса при обсуждении существенных изменений.
- Модель управления. Разграничение сфер ответственности, иерархическое делегирование, где это необходимо, роли и ожидания участников и так далее.
Всё это, по сути, признание того, что в отсутствие контроля могут произойти неприятности и кризисы: по крайней мере, хаос и дисфункции в определённой степени. По возможности контроль автоматический и полностью беспристрастный (чтобы свести к минимуму недоброжелательность и субъективную оценку, соблазн срезать углы и т. д.) Если субъективности не избежать, по крайней мере, нормы и процессы чётко сформулированы в письменной форме, в хорошо документированных, известных местах.
Проблемные области
Вернёмся к двум проблемным областям, где сейчас у проекта нет адекватных механизмов или политики для контроля Rust, что несёт риски возможной дисфункции или даже кризиса. В обоих случаях не совсем понятно, насколько далёк сейчас проект от такого кризиса. Но в любом случае лучше действовать на упреждение, чем опоздать.
- Сам язык. Его определение. Это (в отличие от многих частей проекта) обязательный общий технический артефакт. В нём заинтересованы все, а каждое изменение потенциально влияет на всех. Более того, все должны изучить и понять его существенную часть: невозможно игнорировать неинтересные части. Даже то, что хочется игнорировать, существует в общим контексте: документация и учебные материалы, примеры тестов и проверочный материал, внутренние компоненты компилятора, формальные модели, базы кода, общая нагрузка на обслуживание и т. д.
Здесь рост языка как артефакта ограничивают как минимум следующие факторы:
- Возможность новичку выучить язык.
- Способность среднего пользователя уверенно себя чувствовать, адаптироваться к чужим кодовым базам.
- Способность эксперта или мейнтейнера знать все (или большинство) изменений.
- Соотношение затрат и выгод от каждого нового изменения с точки зрения новой и текущей работы. Количество людей или примеров использования, которые от него выигрывают. Затраты комбинаторны во многих измерениях проекта и размера языка. Они почти всегда увеличиваются.
Если не соблюдать эти лимиты, можно столкнуться с очень серьёзными рисками:
- Необоснованные изменения языка, вплоть до невозможности поддерживать гарантии критической безопасности.
- Репутация излишней сложности, потеря пользователей. Риск стать следующим C++ или Haskell.
- Некачественные функции с неполным определением, тестами, документацией.
- Малоиспользуемые функции, на которые потрачены усилия, необходимые в другом месте.
- Дробление на диалекты, изолированные программы, снижение ценности.
- Нагрузка на людей, работающих над языком. Некоторые части проекта можно делегировать, распределить среди всех доступных разработчиков. Это не общие технические артефакты. В какой-то степени многим людям (а их всё больше) приходится участвовать почти во всех изменениях. Это означает большое давление на всех в этой группе: они должны следить за всеми обсуждениями, а ведь растёт и количество изменений, и число участников дискуссий.
Некоторые ограничения на рост этой нагрузки для участников проекта:
- Количество часов в сутки.
- Количество оплачиваемых часов в сутки.
- Ответственность и интересы вне проекта.
- Резерв ментальной энергии, чтобы понять происходящее.
- Доверие мнению всех, кто участвует в разговоре.
- Резерв психологической и эмоциональной энергии для чтения и обсуждения.
- Презумпция добросовестности каждого участвующего в разговоре.
Риски превышения этих лимитов тоже потенциально весьма серьезны:
- Плохие решения, принятые из-за истощения или выгорания.
- Рост неравенства: только наиболее привилегированные, доступные, энергичные, хорошо оплачиваемые или иным образом хорошо устроенные участники могут за всем следить.
- Сужение дискурса: от тщательного рассмотрения — к «выигрышу спора».
- Люди валяют дурака, выгорают, плохо себя ведут, уходят из проекта.
- Разочарование, обвинение в недобросовестности, обиды, конспиративное мышление, форки.
Хочу подчеркнуть, что описанные ограничения и риски совершенно не специфичны для конкретных людей или даже проекта Rust в целом. В разной степени они встречаются где угодно. Простая замена текущих мейнтейнеров (например) на тех, кто вам нравится, на самом деле не решит проблему: ограничения сохранятся. Единственное решение — продуманное управление в условиях столкновения с лимитом. Взять всё под контроль.
Возможные варианты управления
Это трудная часть, где я постараюсь избегать чётких формулировок. В конце концов, важно принять контроль по собственной воле, а не навязанный извне. Думаю, что участники проекта должны сделать паузу, поразмыслить, коллективно рассмотреть и установить некоторые элементы управления. Поэтому я только предложу несколько возможных вариантов, не очень структурированных, но в праздничном рождественском духе: как кучу потенциально интересных подарков, чтобы их развернуть, посмотреть и решить, оставить или обменять на что-то более интересное.
- Отрицательно определённое пространство. Вынесите процесс обсуждения функций и понятий из планов будущего развития языка. Разрешите (или поощряйте) RFC, которые говорят «Rust никогда не будет иметь X» для некоторого значения X. Так мы получаем единовременный раунд для справедливого обсуждения и рассмотрения возражений к долгосрочному изменению («никогда» — это довольно долго!). Затем этому обсуждению навсегда будет положен конец. Оно не станет вечным источником затяжного конфликта. Несколько примеров, где можно сформулировать отрицательно определённые пространства:
- навсегда убрать определённые категории экспрессивности из системы типов (например. зависимые типы, HKT и др.);
- из синтаксиса (например. ключи параметров, позиционные или именованные аргументы);
- из набора видов элемента (например, анонимные типы записей);
- из набора обязательств по выводу в middle-end (например, синтез констант, неявные аргументы).
Установите некоторые жёсткие ограничения: чтобы избежать этих объектов, а также людей, которые поставили целью «сделать всё как надо». - Затраты на разработку нужно явно сформулировать. Взяв страницу из списка изменений WebAssembly, дайте понять, что уже на раннем этапе такой RFC потребует соответствующих инвестиций в реализацию, формализацию, пересмотр документации, пересмотр учебных материалов, написание тестов, техническое обслуживание и т. д. Если невозможно покрыть расходы, на этом этапе отложите изменения «пока не найден спонсор».
- Установите цели по скорости обучения и объёму материала. Попытайтесь работать в обратном направлении: исходить из количества времени и количества страниц, необходимых для изучения языка или чтобы стать экспертом в нём — а затем удалите всё, что выходит за эти рамки. Если «выучить Rust за 21 день» не подходит, найдите подходящий интервал. Три месяца? Шесть? Год? Подумайте о языках, изучение которых «определённо требует слишком много времени», и выберите меньшее число. Нормально ли руководство на 1000 страниц? 500? 300?
- Установите другие автоматические лимиты: количество строк кода в компиляторе, общее время загрузки, доллары в день на инстансы AWS, количество правил в грамматике, в системе типов, процент покрытия тестами, процент документов, которые можно пометить как «неполные» и т. д. Проявите творческий подход, выясните значимые вещи, которые поддаются измерению, а затем внедрите механизмы для их ограничения.
- Лимит на личное время: сколько примерно часов (или оплаченного времени) человек реально может уделять проекту без истощения или выгорания, включая участников с минимальными правами. Установите аналогичные ограничения на группы, отдельные релизы и на соответствующие планы работ. Затем снимите или отложите всё, что не вписывается в лимит.
- Разрешите модераторам устанавливать лимиты на частоту сообщений или устанавливать периоды тишины в конкретных обсуждениях. Иногда со стороны кажется, что дискуссия слишком жаркая. Для деэскалации конфликта проще установить общий лимит, чем применять санкции к отдельным участникам.
- Как и с модераторами: создайте дополнительную межпроектную команду, которая занимается составлением бюджета и аудитом уровней нагрузки в других командах. Это может быть эффективно: команда аудита поможет людям сказать «нет», когда это необходимо, а не терпеть, как поступает большинство участников команды, соглашаясь на слишком многое.
Это лишь некоторые идеи в общем направлении ограничений на рост. Уверен, что вы можете придумать и более реалистичные способы, как взять под контроль ограничения на размер языка и личные нагрузки. На протяжении многих лет сообщество Rust показало себя восхитительно творческим, мыслящим и самокритичным. За это вас следует похвалить. Надеюсь, эта статья будет воспринята в том же духе конструктивной критики.
С Новым годом и удачи!
