
В этой рубрике мы уже рассказывали про Кена Томпсона и Денниса Ритчи, соавторов Unix, UTF-8 и операционной системы Plan 9. Они практически всю жизнь работали вместе в Bell Labs (AT&T, потом Lucent) как коллеги и единомышленники. Так вот, третьим членом их коллектива был Роб Пайк.
Кроме соавторства Unix и нескольких учебников по программированию, он известен как создатель языка программирования Go. Этот язык родился из философии простоты в программировании, которую Пайк пропагандирует всю жизнь.
Биография
Роб Пайк родился 10 ноября в 1956 году в Канаде. С юности интересовался астрономией, откуда впоследствии возник интерес к вычислениям, математике и программированию.

В одном из интервью Роб рассказывает, что в юности они с друзьями проводили наблюдения за солнечными пятнами, и тогда он написал свою первую серьёзную программу на Fortran IV для статистического анализа данных. Эта программа стала практическим введением в программирование как средство автоматизации научных вычислений в конце 60-х — начале 70-х. Он также писал на Algol и LISP — и это до получения формального образования. Его первая научная статья 1974 года посвящена наблюдениям за солнечными вспышками.

В университете Роб продолжил изучать пересечение физики и информатики, участвуя в проектах по компьютерной графике и астрономическому моделированию. Например, в 1976 году совместно с Даффом разработал алгоритм преобразования растровых изображений с устранением скрытых поверхностей в 2,5-мерном пространстве.
Он также создал систему KEPLER, инструмент для компьютерной анимации астрономических явлений. Во время учёбы в университете Пайк опубликовал несколько научных работ по наблюдательной астрономии, включая простую компьютерную модель светового загрязнения в городских условиях.
После получения степени бакалавра в Торонто поступил в Калифорнийского технологический институт, где работал лаборантом и системным администратором, продолжая писать свои текстовые редакторы. Исследования в те годы были сосредоточены на физике конденсированного вещества (научная статья Пайка на эту тему), и он присоединился к группе по разработке ПО в этой области.
В начале 80-х Роб Пайк пришёл на работу в Bell Labs, где познакомился с вышеупомянутыми коллегами — и начал многолетнюю работу над Unix, Plan 9 и другими инновационными компьютерными системами.
Язык Go
После ухода из Bell Labs в 2002 году присоединился к Google на должности «выдающегося инженера» (Distinguished Engineer), занявшись распределёнными системами и высокопроизводительным ПО. В 2007 году совместно с Робертом Грисемером и Кеном Томпсоном создал язык программирования Go, чтобы решить проблемы параллелизма в инфраструктуре Google. Этот язык представил такие сущности, как горутины и каналы (вместо тяжёлых системных потоков), по образцу более ранних экспериментов Пайка в Newsqueak (1990 год) и Limbo (1997).
На протяжении всей карьеры Пайк подчёркивал простоту и практичность в разработке программного обеспечения. Его работа оказала влияние на несколько поколений системных программистов. Но наверное, больше всего — на современное поколение программистов в 2020-е годы, потому что мы не только впитали принципы простоты в программировании, но ещё и получили новый язык Go, который идеально воплощает эти принципы и лучше всего подходит для системного программирования высоконагруженных веб‑сервисов.
По Пайку, вот ключевые принципы дизайна ПО, реализованные в языке Go:
Простота. Пайк всегда выступал против избыточных фич, сложных иерархий наследования и ментальной перегрузки разработчика.
Читаемость важнее лаконичности: Код пишется один раз, а читается сотни раз. Явное всегда лучше скрытого (explicit is better than implicit).
Композиция вместо наследования: Вместо жёстких структур Go использует интерфейсы, что делает системы гибкими и простыми в поддержке.
Ортогональность: Возможности языка не должны дублировать или усложнять друг друга.
Другие проекты Пайка
Чуть выше мы упоминали о ранних экспериментах Пайка в области языков программирования Newsqueak (1990 год) и Limbo (1997). Как и многие другие разработки его и коллег в Bell Labs, все эти эксперименты были маленькими частями больших экспериментальных проектов — распределённых ОС Plan 9 и Inferno.

Это абсолютно новаторские для 90-х годов разработки, где распределённые ресурсы заложены в саму архитектуру ОС.

Только 30 лет спустя такие разработки оказались по‑настоящему востребованы индустрией (в первую очередь — в распределённых дата‑центрах Google).
Ещё во время учёбы Пайк внёс вклад в разработку версии текстового редактора QED для Университета Торонто — легковесного инструмента для редактирования текстовых файлов в Unix. Конкретно эта версия известна своей эффективностью, портативностью и считается лучшей версией QED.
По приходу в Bell Labs аспиранта определили в Центр исследований вычислительных наук (CSRC), где он первое время занимался UI и графикой. В 1981 году совместно с Бартом Локанти разработал терминал Blit — графическую рабочую станцию для мультиплексирования окон в Unix, с процессором 68 010 и HD‑дисплеем. Софт поддерживал управление несколькими асинхронными процессами, что стало шагом к современным графическим средам. Пайку принадлежит здесь ключевое изобретение — перекрывающиеся окна для растровых дисплеев без перерисовки всего экрана (его единоличный патент США 4,555,775). Это изобретение способствовало эволюции оконных систем, предшествуя широкому коммерческому принятию в X11 и др., повлияв на растровые GUI в распределённых средах.

Любопытно, что Bell Labs в 1982 году выпустила обучающую анимацию о Blit с пояснением, что такое манипулятор «мышь»:
В конце 80-х годов разработал Newsqueak — экспериментальный язык программирования, предназначенный для параллельного программирования, особенно в GUI. Здесь появились легковесные каналы как механизм общения между параллельными процессами. Newsqueak считается ключевым предшественником всех будущих языков, акцентирующих внимание на параллелизме, в том числе Go.
Чуть позже Пайк создал Limbo (1997) — язык программирования для распределённой операционной системы Inferno. Он поддерживает автоматическую сборку мусора, а также параллелизм через модули и каналы.
Из других разработок:
Текстовый редактор Sam (1987), сочетавший структурное редактирование на основе регулярных выражений и взаимодействие с мышью. В отличие от традиционных редакторов, Sam позволял применять команды ко всему файлу или только к буферу, что повышало эффективность при редактировании на крупномасштабных задачах.
-
Текстовый редактор Acme (1992), наследник Sam, с легковесной оконной системой и продвинутым программированием операций над текстом, с аккордами (сочетания нескольких клавиш), структурной навигацией и выполнением выделенного текста как команд оболочки.

Текстовый редактор Acme Для Plan 9 разработал сервер mux (1990) как часть оконной системы 8½, это легковесный мультиплексор, который рассматривает экран, мышь и клавиатуру как ресурсы
/dev/cons,/dev/mouse,/dev/bitbltдля совместного использования локальными и удалёнными клиентами. Таким образом, несколько программ получают доступ к одному дисплею в качестве виртуальных терминалов через соединения по протоколу 9P, при этом сервер занимал менее 90 КБ и был подчёркнуто простым.Для языка Go разработал параллельный сборщик мусора, который кратковременно приостанавливает выполнение для освобождения памяти, систему интерфейсов для полиморфного поведения без наследования, горутины (легковесные потоки, управляемые средой выполнения) и каналы для безопасного обмена данными между ними. Горутины и каналы взяты из ранних работ Пайка, а другие разработки сделаны вместе с Томпсоном и Грисемером.

В 1992 году вместе с Томпсоном спроектировал стандарт кодировки UTF-8 для поддержки международных символов в Plan 9. С тех пор этот формат Юникода стал общеупотребительным стандартом в IT.

Учебники Пайка и Кернигана «Unix. Программное окружение» (1984) и «Практика программирования» (1999) переведены на десятки языков мира, в том числе на русский. Вторая из них предлагает вечные, никогда не устаревающие рекомендации по стилю программирования, тестированию и отладке.
Всего библиография Роба Пайка включает 49 книг и научных статей. Примерно две трети из них Пайк написал самостоятельно, а остальные в соавторстве с Брайаном Керниганом, Рассом Коксом, Кеном Томпсоном и другими коллегами, чьи имена к настоящему времени стали легендарными.
Есть в списке и статьи на довольно неожиданные для Пайка темы, например, «Введение в квантовые вычисления и квантовые коммуникации» (2000).
Последняя статья в списке библиографии — «Язык программирования Go и программное окружение» — опубликована в журнале «Communications of the ACM» (том 65 5, стр. 70−78) в мае 2022 года.
В далёком 1989 году Роб Пайк сформулировал пять правил программирования. В последнее время эти правила часто вспоминают. Прошло почти 40 лет, но ни одно из них не устарело.
Изначально правила были опубликованы в пятистраничном сборнике коротких эссе «Заметки о программировании на С», под заголовком «Сложность».

Пять правил программирования Роба Пайка
Большинство программ слишком сложны — то есть, более сложны, чем им нужно для эффективного решения задач. Почему? В основном, из‑за плохого дизайна, но эту тему здесь пропустим, потому что она слишком большая. Но программы часто сложны на микроскопическом уровне, и вот это можем обсудить.
Правило 1. Невозможно предсказать, где программа будет тратить время. Узкие места возникают в неожиданных местах, поэтому не пытайтесь предугадать и вставлять ускоряющие изменения, пока не докажете, где именно узкое место.
Правило 2. Измеряйте. Не оптимизируйте для скорости, пока не измерите, и даже тогда не оптимизируйте, если только одна часть кода не подавляет остальные.
Правило 3. Сложные алгоритмы медленные при маленьком
n, а оно обычно маленькое. У сложных алгоритмов большие константы. Пока неизвестно, чтоnбудет большим, не усложняйте. (Даже еслиnстанет большим, сначала используйте правило 2).Правило 4. В сложных алгоритмах больше ошибок, чем в простых, и их гораздо труднее реализовать. Используйте простые алгоритмы и простые структуры данных.
Следующих структур достаточно почти для всех практических программ:
массив;
связный список;
хэш‑таблица;
бинарное дерево.
Конечно, их можно собирать в составные структуры. Например, таблицу символов реализовать в виде хэш‑таблицы со связными списками из массивов символов.
Правило 5. Данные важнее алгоритмов. Выбери правильную структуру — и алгоритм почти всегда станет очевидным. Структуры данных, а не алгоритмы, занимают главное место в программировании (см. Брукса, стр. 102).
Правило 6. Нет правила 6.
Примечания:
-
На первый взгляд, правила 1 и 2 дополняют известную цитату Дональда Кнута: «Предварительная оптимизация — корень всех зол» из статьи «Структурное программирование с операторами перехода» (1974). Правила Пайка более понятны, чем оригинальная цитата, которая требует погружения в контекст.
В упомянутой статье Кнут говорил об операторе безусловного перехода
goto, который предлагалось заменить структурирующими операторами более высокого уровняif,forиwhileс потерей в производительности. Кнут объяснял, что некоторые программисты много времени тратят на микрооптимизации в некритических областях программы, хотя есть вещи поважнее: дальнейшая поддержка и отладка кода. Ну то есть отgotoлучше отказаться.
Примеры из статьи «Структурное программирование с операторами перехода». Код с gotoдаёт выигрыш в производительности примерно 12%: «Нет сомнений в том, что грааль эффективности ведёт к злоупотреблениям», — пишет Кнут по этому поводу Правила 3 и 4 являются примерами философии дизайна KISS. Кен Томпсон перефразировал эти правила так: «Если сомневаешься — запускай брутфорс».
Ссылка на Брукса (стр. 102) в пятом правиле — это ссылка на книгу Фреда Брукса «Мифический человеко‑месяц». Это правило иногда переформулируют следующим образом: «Пишите глупый код, который использует умные объекты».
Пайк устал от нейрослопа
В декабре 2025 года Роб Пайк ещё раз напомнил о себе на весь мир, когда его пост против нейронок набрал тысячи лайков и репостов:

Возмущение Пайка вызвало письмо, которое он получил от Claude Opus. Какой‑то почитатель таланта Роба захотел выразить ему своё почтение и использовал нейронку, чтобы составить текст. Это просто вывело из себя гения:
«Идите в ж%пу, народ! — написал Роб Пайк. — Изнасиловать планету, потратить триллионы на токсичное оборудование, которое не подлежит переработке, при этом подорвать общество, и ещё найти время, чтобы ваши мерзкие машины поблагодарили меня за стремление к более простому ПО.
Просто идите в ж%пу. Все вы.
Не могу вспомнить, когда последний раз я был так зол.»
Чуть ниже в комментариях Пайк добавил:
«И кстати, вы обучаете своего монстра на данных, которые созданы в том числе моими руками, без атрибуции и компенсации.
Для остальных: Прошу у всех прощения за свою непреднамеренную, наивную, хоть и незначительную роль в содействии этому нападению.»
Для понимания: письмо в адрес Роба Спайка составил один из ИИ‑агентов проекта AI Village, основанного активистами философии эффективного альтруизма (движение за максимизацию благ для человечества в будущем). На тот конкретный день агентам была поставлена задача «совершить акты спонтанной добродетели». Один из агентов поэтому составил благодарственное письмо в адрес отца‑основателя современного программирования, системы Unix и языка Go.
Личная жизнь
У Пайка в компании Google был адрес электронной почты r@google.com. Он ушёл на пенсию в начале 2020-х. Сейчас выступает на конференциях, ведёт личный блог. Там делится мыслями о программировании и подробностями о разработке Go.
Роб сохраняет канадское гражданство. Женат на известной американской художнице и иллюстраторе комиксов Рене Френч, они проводят время в США и Австралии. Кстати, именно Рене нарисовала прикольных маскотов Plan 9 и языка Go.

© 2026 ООО «МТ ФИНАНС»
Комментарии (21)

VADemon
03.08.2026 09:37Пайку принадлежит здесь ключевое изобретение — перекрывающиеся окна для растровых дисплеев без перерисовки всего экрана (его единоличный патент США 4,555,775).
М-да? А я по ссылке читаю, что
[...] a plurality of regions for separate displays. Each separate display is called a "window’ and the prior art has the ability to display multiple windows simultaneously, with several if not all windows overlapping, leaving one window fully visible and the others partially or wholly obscured. Windows are overlapping rectangles each of which can be considered an operating environment, much like sheets of paper on a desk. One limitation of the prior art is that only the window at the front, which is totally unobscured, is active or continuously operating. [...]
А его пупер-патент заключается в:
For each layer bitmap, there is a corresponding host program which allows each layer to be operating continuously.
Переводя на нормальный язык: ранние графические системы позволяли обновляться окну только активного приложения. Остальные окна замирали, пока пользователь не перейдет к ним. Патент: давайте разрешим всем окнам, будь они активные или нет, обновляться. Таким образом, пользователь всегда видит прогресс неактивных окон в фоне на рабочем столе.
Таким образом, если бы патент использовался по назначению (читай: в судах), то это был бы хрестоматийный пример патентного троллинга.
PS: Все же, это нововведение вполне в рамках его работы было:
Софт поддерживал управление несколькими асинхронными процессами
повлияв на растровые GUI в распределённых средах
Потому что это означает переход от однопроцессности к многозадачности пользовательского окружения.

apevzner
03.08.2026 09:37Суть патента - в изобретении backing store - невидимой памяти, куда приложения рисуют, не задумываясь о том, что их окошко может быть частично или полностью перекрыто другими, а потом графическая система собирает из этих отрисованных, но невидимых прямоугольников финальную картинку, с учётом перекрытий.
AT&T активно использована этот патент против разработчиков X Windows System, но прямо вот до суда не дошло.
Так что да, этот патент является хрестоматийным примером патентного троллинга.

VADemon
03.08.2026 09:37Спасибо за дополнение. Я на разный лад пытался найти обычным поисковиком что-то в интернете - ноль результатов. Ни упоминаний, ни тем более судебных дел. Поисковые движки не туда свернули.

OlegZH
03.08.2026 09:37связный список
Я правильно помню, что связным списком называется структура, каждый узел которой содержит два указателя (ссылки) на соседние узлы (предыдущий/последующий)?

TIEugene
03.08.2026 09:37Двунаправленный - да

Sly_tom_cat
03.08.2026 09:37Не обязательноб одно-связный список - тоже связный.

OlegZH
03.08.2026 09:37Знать бы ещё, за что минус и от кого. Как может простой вопрос вызвать отрицательную реакцию?

TIEugene
03.08.2026 09:37Это аноним почесал своё ЧСВ. Не обращайте внимания, так тут принято.
- Вася, что ты делаешь у первоклашек? Твой 5-й В в другой аудитории!
- Зато я здесь самый умный! (c) "Ералаш".

VADemon
03.08.2026 09:37Культура расстрела за вопросы к хорошему не приведет. Ситуацию исправил, дружба победила.

Siemargl
03.08.2026 09:37Знать бы ещё, за что минус и от кого. Как может простой вопрос вызвать отрицательную реакцию?
ну если вопрос тупой, то вполне
хотя я обычно игнорирую такое, слишком много

apevzner
03.08.2026 09:37Тут не лишне бы упомянуть, что Plan 9 растащили по цитатам по другим ОС
Linux namespaces, bind mount, unionfs, все эти /proc и /sys - это всё оттуда.

thisnicknameisoccupied
03.08.2026 09:37После получения степени бакалавра в Торонто поступил в аспирантуру Калифорнийского технологического института, где в 1980 году получил степень по физике. Исследования в те годы были сосредоточены на физике высоких энергий, и он присоединился к группе по разработке ПО в этой области. К сожалению, детали его диссертации отсутствуют в открытом доступе.
Это вы где такое нашли? Про степень, диссертацию, физику высоких энергий? Поделитесь ссылками.
Я смог найти только, что у него, вероятно, степень магистра физики (но в русском языке под "степенью" обычно понимается "ученая степень", т.е. кандидат наук или PhD). Этого нет в Википедии или на сайте Калтеха, но упоминается на сайте golang.design. После двух лет в Калтехе (1978-80) он ушел в Bell Labs, так что навряд ли он получил что-то выше магистра. Научная статья из этого периода у него находится не по физике высоких энергий, а по физике конденсированного вещества (https://iopscience.iop.org/article/10.1088/0305-4470/14/5/013).

alizar Автор
03.08.2026 09:37Действительно, я немного напутал: В Калифорнийском технологическом Роб Пайк работал лаборантом и системным администратором, а диплом по физике у него из Торонто. Спасибо вам большое, что указали, плюс вам в карму!!!

Fisher324
03.08.2026 09:37Правило 4. В сложных алгоритмах больше ошибок, чем в простых, и их гораздо труднее РЕАЛИЗОВАТЬ.
Явно ошибка перевода. В оригинале наверно стоит "realize" - в данном контексте в значении "понять, осознать"

nickolaym
03.08.2026 09:37Интерфейсы в языке го - это прямо офигеть какая простота! Это гораздо, гораздо лучше воровства. Какое-то инженерное безумие.

OlegZH
03.08.2026 09:37Правило 1. Невозможно предсказать, где программа будет тратить время. Узкие места возникают в неожиданных местах, поэтому не пытайтесь предугадать и вставлять ускоряющие изменения, пока не докажете, где именно узкое место.
Это означает, что, если в коде встречается (например!) сортировка массива, то не надо спешить с выбором алгоритма сортировки. Можно получить параметризованный набор подпрограмм и иметь подключаемый (и пополняемый) набор реализаций алгоритма сортировки.
unreal_undead2
Недавно перечитывал "Практику программирования" - стоящая книга для любого программиста.