Перевод статьи «For Better or For Worse» разработчика из компании DataDog Inc. Статья посвящена вопросу дизайна языков программирования и связи дизайна с попытками оценок качества языков. Частично является ответом на недавно переведенную тут эту статью.
В программистской тусовке возникает мем об “объективном качестве” дизайна Go. Буквально на днях я встретил его в статье про выбор языков от Honza, где он был очень хорошо виден:
Я думаю, что это крайне интересный набор противоречий, и автор с этим согласен.
Сложно было бы так безаппеляционно и уверенно утверждать, что Go плохо спроектирован, если бы это мнение не было столь расхожим. В прошлом году целый ряд статей и постов в блогах заложили основу этому мнению. Среди них были статьи людей, не любящих Go, потому что тот не позволяет им чувствовать себя умными или потому что в нём нет ничего принципиально нового. Они уверены, что Go, сознательно игнорируя определённые продвижения в дизайне языков программирования, остался в прошлом, из которого лучшие языки ушли далеко вперед. И они это утверждают весьма настойчиво.
Когда люди с таким видением пытаются объяснить популярность Go, они неизбежно приходят к парадоксу. Если Go настолько плох, почему он так популярен?
Причём в данном случае с когнитивным диссонансом весьма тяжело бороться. В отличие от других высмеянных, но популярных языков, Go не был навязан. Он не набирал критическую массу вопреки недостаткам, на новой платформе, оккупированной преимущественно аматорами и неопытными разработчиками. Он был разработан в крупнейшей интернет-компании в мире, одними из самых опытных программистов в истории, и получил свой первый виток принятия в распределённых инфраструктурных проектах.
Чтобы обойти этот парадокс, люди обычно либо делают вывод, что все дураки (что, к сожалению, в программистских сообществах, похоже, не редкость), либо, что были другие факторы, способствующие адаптации Go. Но вариант, что он может быть на самом деле хорош, если посмотреть на это определение под другим углом, обычно даже не рассматривается.
Это современная манифестация того, что Ричард П. Гэбриел описал в своём классическом эссе “Чем хуже, тем лучше”. В нём, Гэбриел озвучивает 4 главных ценности дизайна системы, которые могут быть в противоречии: простота, правильность, логичность и полнота. Далее он описывает две конкурирующие философии: подход MIT, ставящий выше правильность и логичность, и подход Нью-Джерси, ставящий выше простоту реализации.
Даже если можно поспорить, является ли подход Нью-Джерси постфактум описанием Unix-философии, то совершенно точно можно быть уверенными, что создатели Go явно продвигали простоту, как ведущий элемент их философии. Простота реализации это чётко сформулированная позиция как в самом языке, так и в библиотеках, и этот явный приоритет простоты над логичностью вшит в язык.
Простота стала вероятно ещё более признанным приоритетом с момента написания эссе в 1990, по мере того, как мир компьютеров разительно изменился.
Чтобы справиться с растущими объемами данных, вычисления и хранилища начали масштабироваться горизонтально, и логичным результатом, позволяющим справляться с этим, стал тренд к более простым вещам. Системы, восхваляемые в старой литературе, вроде CORBA или иронически названной SOAP, в итоге были похоронены в разы более простыми системами, чьи режимы отказа были гораздо менее элегантными, но реализация была на порядки проще.
Способ, которым разрабатывается софт, тоже претерпел изменения. Огромное количество компаний построены по большей части на open source продуктах, и они, в ответ, вносят в них свой вклад. Поскольку простой код проще писать, читать, дебажить и поддерживать, простые языки получают преимущество, будучи более простыми для изучения, что приводит к большему использованию, большему количеству библиотек и контрибьюторов, увеличивая жизнестойкость в краткосрочной перспективе и качество в долгосрочной.
Всё это отнюдь не говорит о том, что простота обязательно подразумевает уход от академической сферы в примитивизм. Просто сложные вещи вроде Paxos в конечном счёте уступают более простым вещам вроде Raft.
Несмотря на тренд в сторону простоты, обсуждения языков программирования, как правило, проходит во фрейме MIT-подхода. Это было так успешно и популярно, что это уже незаметно и даже неочевидно.
Сложные системы типов, в которых формально доказано отсутствие возможности определённых классов ошибок, восхваляются, несмотря на результирующую сложность реализации или когнитивную нагрузку на программиста. Сознательно упрощать эти системы всегда рассматривается как недоделка, а не как сознательный компромисс.
Проблема в том, что у этой темы оценки качества языков программирования нет явных связей с их эффективностью в написании реального кода.
Подход Go был в том, чтобы начать с C, затем выкинуть вещи, которые было сложно использовать правильно, и заполнить промежутки, пока не останется ничего достаточно простого или достаточно ортогонального, чтобы добавить. Взять известный набор компромиссов, известную точку на континууме между простым и усложнённым, и сделать небольшие изменения, основанные на дюжинах аккумулированных лет практического опыта разработки в реальном мире. Это непростительно прямолинейный инженерный подход к построению систем.
Безусловно, вы не можете положить всё на алтарь простоты. Многие низкоуровневые байткод- и ассемблерные языки легко написать и портировать, но их интерфейсы слишком сложны для использования программистами. Необходимо достичь баланса между количеством фич и простотой языка.
И мы видели, и не раз, что системы, которые не пытались сделать это правильно, обладают интерфейсами слишком сложными для их использования, а системы, которые пожертвовали простотой ради полноты реализованы слишком сложно, чтобы быть правильно использованными. Системы на сложной стороне спектра часто достигают “правильного” через нежелательные подходы из практических соображений, или лишь притворяются, что делают “правильно”. Достаточно полезные абстракции утекут, так что лучше, чтобы их поведение было достаточно простым, чтобы их последствия можно было понять заранее. Ошибки имеют сложность соразмерную сложности реализации их систем.
Чтобы узнать, что же решат присяжные насчёт Go, могут понадобиться годы. Нет простых и ясных способов измерить насколько “хорош” язык, так что это, в итоге, определяется по тому, насколько популярные системы процветают, а не популярные вянут и умирают. Вопреки своим очернителям, популярность Go продолжает расти благодаря своим сильным сторонам, а это значит, что он заслужил больше времени для оценивания. Если же его кажущиеся слабости реальны, мы непременно увидим их в реальном мире, по мере того, как созданные на нём системы достигнут зрелости, но пока что перспективы очень хорошие.
Зато что мы видим, так это то, что Go выбирают проекты, которые ещё лет 5 назад даже не представлялись возможными из-за ужасной ситуации с инструментарием в их нише. Даже если Go в конечном счёте провалится, чем дольше он будет расти, тем более вероятно, что следующие поколения языков будут начинать с Go, точно так же, как Go начал с C, и, учитывая родословную последнего и остающуюся силу, я бы сказал, что это будет огромный успех.
В программистской тусовке возникает мем об “объективном качестве” дизайна Go. Буквально на днях я встретил его в статье про выбор языков от Honza, где он был очень хорошо виден:
Учтите, язык объективно очень плохо спроектирован. [...] И, при этом, Go гораздо более популярен, чем Haskell, если верить GitHub. При этом, уже столько отличных проектов, написанных на Go, вроде Docker, InfluxDB, etcd, Consul, Prometheus, packer и других.
Я думаю, что это крайне интересный набор противоречий, и автор с этим согласен.
Сложно было бы так безаппеляционно и уверенно утверждать, что Go плохо спроектирован, если бы это мнение не было столь расхожим. В прошлом году целый ряд статей и постов в блогах заложили основу этому мнению. Среди них были статьи людей, не любящих Go, потому что тот не позволяет им чувствовать себя умными или потому что в нём нет ничего принципиально нового. Они уверены, что Go, сознательно игнорируя определённые продвижения в дизайне языков программирования, остался в прошлом, из которого лучшие языки ушли далеко вперед. И они это утверждают весьма настойчиво.
Когда люди с таким видением пытаются объяснить популярность Go, они неизбежно приходят к парадоксу. Если Go настолько плох, почему он так популярен?
Причём в данном случае с когнитивным диссонансом весьма тяжело бороться. В отличие от других высмеянных, но популярных языков, Go не был навязан. Он не набирал критическую массу вопреки недостаткам, на новой платформе, оккупированной преимущественно аматорами и неопытными разработчиками. Он был разработан в крупнейшей интернет-компании в мире, одними из самых опытных программистов в истории, и получил свой первый виток принятия в распределённых инфраструктурных проектах.
Чтобы обойти этот парадокс, люди обычно либо делают вывод, что все дураки (что, к сожалению, в программистских сообществах, похоже, не редкость), либо, что были другие факторы, способствующие адаптации Go. Но вариант, что он может быть на самом деле хорош, если посмотреть на это определение под другим углом, обычно даже не рассматривается.
Чем хуже, тем лучше
Это современная манифестация того, что Ричард П. Гэбриел описал в своём классическом эссе “Чем хуже, тем лучше”. В нём, Гэбриел озвучивает 4 главных ценности дизайна системы, которые могут быть в противоречии: простота, правильность, логичность и полнота. Далее он описывает две конкурирующие философии: подход MIT, ставящий выше правильность и логичность, и подход Нью-Джерси, ставящий выше простоту реализации.
Даже если можно поспорить, является ли подход Нью-Джерси постфактум описанием Unix-философии, то совершенно точно можно быть уверенными, что создатели Go явно продвигали простоту, как ведущий элемент их философии. Простота реализации это чётко сформулированная позиция как в самом языке, так и в библиотеках, и этот явный приоритет простоты над логичностью вшит в язык.
Простота стала вероятно ещё более признанным приоритетом с момента написания эссе в 1990, по мере того, как мир компьютеров разительно изменился.
Чтобы справиться с растущими объемами данных, вычисления и хранилища начали масштабироваться горизонтально, и логичным результатом, позволяющим справляться с этим, стал тренд к более простым вещам. Системы, восхваляемые в старой литературе, вроде CORBA или иронически названной SOAP, в итоге были похоронены в разы более простыми системами, чьи режимы отказа были гораздо менее элегантными, но реализация была на порядки проще.
Способ, которым разрабатывается софт, тоже претерпел изменения. Огромное количество компаний построены по большей части на open source продуктах, и они, в ответ, вносят в них свой вклад. Поскольку простой код проще писать, читать, дебажить и поддерживать, простые языки получают преимущество, будучи более простыми для изучения, что приводит к большему использованию, большему количеству библиотек и контрибьюторов, увеличивая жизнестойкость в краткосрочной перспективе и качество в долгосрочной.
Всё это отнюдь не говорит о том, что простота обязательно подразумевает уход от академической сферы в примитивизм. Просто сложные вещи вроде Paxos в конечном счёте уступают более простым вещам вроде Raft.
Природа качества
Несмотря на тренд в сторону простоты, обсуждения языков программирования, как правило, проходит во фрейме MIT-подхода. Это было так успешно и популярно, что это уже незаметно и даже неочевидно.
Сложные системы типов, в которых формально доказано отсутствие возможности определённых классов ошибок, восхваляются, несмотря на результирующую сложность реализации или когнитивную нагрузку на программиста. Сознательно упрощать эти системы всегда рассматривается как недоделка, а не как сознательный компромисс.
Проблема в том, что у этой темы оценки качества языков программирования нет явных связей с их эффективностью в написании реального кода.
Подход Go был в том, чтобы начать с C, затем выкинуть вещи, которые было сложно использовать правильно, и заполнить промежутки, пока не останется ничего достаточно простого или достаточно ортогонального, чтобы добавить. Взять известный набор компромиссов, известную точку на континууме между простым и усложнённым, и сделать небольшие изменения, основанные на дюжинах аккумулированных лет практического опыта разработки в реальном мире. Это непростительно прямолинейный инженерный подход к построению систем.
Безусловно, вы не можете положить всё на алтарь простоты. Многие низкоуровневые байткод- и ассемблерные языки легко написать и портировать, но их интерфейсы слишком сложны для использования программистами. Необходимо достичь баланса между количеством фич и простотой языка.
И мы видели, и не раз, что системы, которые не пытались сделать это правильно, обладают интерфейсами слишком сложными для их использования, а системы, которые пожертвовали простотой ради полноты реализованы слишком сложно, чтобы быть правильно использованными. Системы на сложной стороне спектра часто достигают “правильного” через нежелательные подходы из практических соображений, или лишь притворяются, что делают “правильно”. Достаточно полезные абстракции утекут, так что лучше, чтобы их поведение было достаточно простым, чтобы их последствия можно было понять заранее. Ошибки имеют сложность соразмерную сложности реализации их систем.
Чтобы узнать, что же решат присяжные насчёт Go, могут понадобиться годы. Нет простых и ясных способов измерить насколько “хорош” язык, так что это, в итоге, определяется по тому, насколько популярные системы процветают, а не популярные вянут и умирают. Вопреки своим очернителям, популярность Go продолжает расти благодаря своим сильным сторонам, а это значит, что он заслужил больше времени для оценивания. Если же его кажущиеся слабости реальны, мы непременно увидим их в реальном мире, по мере того, как созданные на нём системы достигнут зрелости, но пока что перспективы очень хорошие.
Зато что мы видим, так это то, что Go выбирают проекты, которые ещё лет 5 назад даже не представлялись возможными из-за ужасной ситуации с инструментарием в их нише. Даже если Go в конечном счёте провалится, чем дольше он будет расти, тем более вероятно, что следующие поколения языков будут начинать с Go, точно так же, как Go начал с C, и, учитывая родословную последнего и остающуюся силу, я бы сказал, что это будет огромный успех.
