Mojo: Как Крис Латтнер ускоряет Python в 35 000 раз и объединяет ИИ

Мы привыкли к архитектурному хаосу и бесконечной переписке кода с Python на C++ настолько, что перестали замечать эту сложность, словно рыбы, не видящие воду. Крис Латтнер намерен разрушить этот барьер с помощью Mojo — языка программирования с официальной поддержкой расширения .🔥, который обеспечивает 35 000-кратное ускорение и возвращает разработчикам прямой контроль над мощностью современного железа.

🔥 Новая эра программирования: Миссия Mojo и философия Modular 2:33

Миссия Mojo и Modular в мире ИИ 2:33

Крис Латтнер, стоявший за созданием таких фундаментальных технологий, как LLVM, Clang и язык Swift, видит современное состояние индустрии ИИ как «гигантский хаос» (gigantic mess) . В беседе с Лексом Фридманом он объясняет, что за последние десять лет мир вычислительной техники радикально изменился: если раньше мы полагались на центральные процессоры (CPU), то сегодня доминируют специализированные ускорители — GPU, TPU, NPU и другие «PU» . Каждое новое устройство требует своего набора инструментов, что создает фрагментацию и усложняет жизнь разработчикам.

Миссия компании Modular и созданного ею языка Mojo заключается в том, чтобы упростить этот стек технологий. По словам Латтнера, Mojo задумывался не просто как очередной язык, а как универсальная платформа, способная объединить удобство Python с производительностью системных языков вроде C или C++ . Ранее в разговоре они кратко упоминали о феноменальном ускорении кода в 35 тысяч раз, но Крис подчеркивает: главная цель — сделать программирование для ИИ доступным не только узким специалистам по «железу», но и обычным исследователям и разработчикам .

Mojo позиционируется как язык, ориентированный прежде всего на ИИ (AI-first). Это означает, что он изначально проектировался с учетом требований современных нейросетей и систем машинного обучения . Однако Латтнер уточняет, что проблемы, которые решает Mojo — например, эффективное управление памятью и работа с параллельными вычислениями — актуальны для всей индустрии ПО. Поэтому, будучи «заточенным» под ИИ, Mojo по своей сути является мощным языком общего назначения .

Эмодзи как расширение файлов в Mojo 4:10

Одним из самых необычных и обсуждаемых решений команды Mojo стало использование эмодзи огня (🔥) в качестве официального расширения имен файлов. Латтнер признается, что это решение было принято отчасти в шутку, но оно несет в себе глубокий смысл . В мире, где тысячи языков программирования используют расширения вроде .py, .c или .swift, расширение .🔥 позволяет проекту мгновенно выделиться.

Крис отмечает несколько причин для такого шага:

Визуальная идентичность: Эмодзи красочны и красивы, они делают код визуально узнаваемым в файловой системе .
Современный подход к метаданным: Использование Unicode-символов подчеркивает, что Mojo — это язык новой эпохи, не ограниченный стандартами полувековой давности.

Лекс Фридман в ходе дискуссии подмечает техническую сложность: например, система контроля версий Git может некорректно отображать такие символы в терминале . Однако Латтнер настроен оптимистично, полагая, что инструменты разработки адаптируются под новые реалии, как это уже было в Swift, где эмодзи разрешены даже в качестве имен переменных . Крис с юмором вспоминает, что после внедрения этой функции в Swift интернет заполнился кодом, где в качестве имен использовался символ «кучи какашек» (pile of poop), но уверен, что для расширения файлов сообщество выберет более эстетичные варианты .

Метапрограммирование и авто-тюнинг в компиляторе 17:24

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

Традиционные языки, такие как C++, используют шаблоны (templates) для метапрограммирования, но многие разработчики считают их синтаксис громоздким и сложным для понимания . Mojo идет другим путем: он позволяет использовать привычный синтаксис для написания логики, которая будет выполняться компилятором. Латтнер сравнивает этот подход с тем, что реализовано в языке Zig, где возможности рантайма переносятся на этап компиляции .

Одной из самых перспективных функций, вытекающих из такой архитектуры, является авто-тюнинг (auto-tuning) . Латтнер указывает на фундаментальную проблему: алгоритмы машинного обучения на разных GPU работают по-разному из-за различий в кэше, количестве ядер и пропускной способности памяти. Обычно эксперты вручную подбирают «магические числа» (параметры оптимизации) для каждого конкретного чипа .

Mojo автоматизирует этот процесс:

Компилятор может запустить множество вариаций одного и того же алгоритма с разными параметрами прямо в процессе сборки .
Система измеряет производительность каждой версии на целевом «железе».
В итоговый бинарный файл записывается самый быстрый вариант.

Это позволяет достигать максимальной производительности без необходимости для программиста быть глубоким экспертом в архитектуре видеокарт. «Большинство нормальных программистов на самом деле не хотят знать тонкости устройства железа», — резюмирует Крис, подчеркивая, что Mojo берет эту сложность на себя .

Анатомия скорости: почему Mojo быстрее Python в тысячи раз 27:56

Когда Крис Латтнер (Chris Lattner) и его команда представили Mojo, индустрию поразила цифра: новый язык способен работать в 35 000 раз быстрее стандартного Python. В разговоре с Лексом Фридманом (Lex Fridman) Крис подчеркивает, что такая производительность — это не просто теоретический максимум, а следствие радикального пересмотра архитектуры того, как код взаимодействует с «железом». Для современных ИИ-продуктов это означает не только экономию на серверах, но и возможность запускать более тяжелые и умные модели в рамках того же бюджета времени .

Технологический фундамент 35-тысячного ускорения 27:56

Главная причина медлительности стандартного Python заключается в том, что python3 — это интерпретатор байт-кода, который делает программу «непрозрачной» для оптимизаций процессора . Mojo же изначально строится как компилируемый язык, использующий современные методы генерации машинного кода. Однако разрыв в производительности объясняется не только наличием компилятора, но и решением трех фундаментальных проблем Python:

Избавление от «объектной инфляции»: В Python всё является объектом. Даже самое простое число имеет «заголовок» (header), хранящий информацию о типе и другие метаданные . Это приводит к тому, что при передаче данных программа постоянно оперирует указателями и косвенной адресацией (indirection). Mojo позволяет работать с данными напрямую, без лишних оберток .
Эффективное управление памятью: Python полагается на подсчет ссылок (reference counting), что создает огромные накладные расходы при выполнении каждой операции . Ранее в интервью Крис упоминал Глобальную блокировку интерпретатора (GIL), и именно способ работы с памятью в Mojo позволяет эффективно обходить подобные ограничения, обеспечивая масштабируемость.
Векторизация и параллелизм: Современные процессоры способны выполнять 4, 8 или даже 16 операций одновременно (SIMD/векторные вычисления). Mojo дает разработчику инструменты для прямого использования этих мощностей, позволяя выполнять задачи параллельно на уровне ядер и аппаратных блоков .

Как отмечает Крис, Mojo — это попытка дать Python-разработчикам «суперсилу» C++, сохраняя при этом привычный синтаксис .

Прогрессивная типизация: выбор между гибкостью и строгим контролем 31:06

Один из самых дискуссионных вопросов в программировании — это типизация. Лекс Фридман в шутку замечает, что «взрослые используют строгую типизацию», хотя сам предпочитает динамику Python для прототипирования . Mojo предлагает уникальный подход, называемый прогрессивной типизацией.

В отличие от стандартного Python, где аннотации типов (type hints) являются лишь подсказками для внешних инструментов вроде MyPy и игнорируются самим интерпретатором при выполнении , в Mojo типы имеют реальное значение для компилятора.

Основные преимущества системы типов Mojo:

Добровольность (Optionality): Вы не обязаны использовать типы везде. Если вы пишете быстрый набросок или скрипт, вы можете оставить код динамическим .
Производительность по требованию: Когда вы понимаете, что конкретный участок кода является «бутылочным горлышком», вы внедряете типы. Это позволяет компилятору оптимизировать представление данных в памяти .
Structs против Classes: Mojo вводит понятие struct. Если классы в Python всегда динамичны и гибки, то структуры в Mojo статичны, что обеспечивает производительность уровня C++, оставаясь в рамках Python-подобного синтаксиса .

Крис подчеркивает: разработчик не должен чувствовать давления со стороны языка. Использование типов в Mojo — это инструмент для достижения предсказуемости и скорости, а не бюрократическая обуза .

Наследие Python и вызовы сообщества 43:44

Разработка нового языка — это не только техническая, но и социальная задача. Крис вспоминает болезненный переход от Python 2 к Python 3, который занял у мирового сообщества многие годы и стоил огромных усилий . Mojo стремится избежать подобного раскола, предлагая путь плавной миграции, где старый код может постепенно обрастать новыми возможностями Mojo.

Обсуждая роль сообщества, Крис упоминает Гвидо ван Россума (Guido van Rossum), который в свое время покинул пост «великодушного пожизненного диктатора» Python из-за давления и сложности управления дизайном языка . Крис признает, что работа над Mojo в открытом режиме (начиная с версии 0.1) — это вызов, требующий баланса между архитектурной чистотой и потребностями пользователей .

Особое внимание в Mojo уделяется числовым типам данных. Поскольку язык ориентирован на ИИ, работа с целыми числами и числами с плавающей точкой вынесена на уровень стандартной библиотеки, а не зашита жестко в ядро, что дает разработчикам невероятную гибкость в оптимизации вычислений . Хотя Mojo еще находится на ранней стадии развития (версия 0.1 на момент записи), он уже позволяет низкоуровневым программистам творить вещи, недоступные в обычном Python .

В завершение этого сегмента Крис подводит к теме семантики значений и того, как Mojo обрабатывает копирование данных — критически важный аспект, который будет подробно разобран в следующей части разговора .

💎 Семантика значений и борьба с хаосом в инфраструктуре ИИ 50:12

Магия владения: как избежать «багов по неосторожности» 50:12

Одной из фундаментальных проблем при разработке сложных систем является управление общими данными. Крис Латтнер объясняет, что в традиционных языках программирования разработчик часто сталкивается с дилеммой: копировать ли данные при каждой передаче или использовать указатели (ссылки) . Если вы выбираете ссылки, возникает риск «призрачных изменений»: один программист меняет запись в базе данных, не подозревая, что этот же объект используется в другой части системы, что приводит к трудноуловимым ошибкам .

Mojo предлагает решение через продвинутую модель семантики значений (value semantics). В отличие от Python, где всё по умолчанию является ссылкой, или C++, где управление памятью ложится на плечи программиста, Mojo заимствует идеи из Rust, но стремится сделать их более доступными . Ключевые аспекты этой модели включают:

Исключение лишнего копирования: Система автоматически отслеживает, когда данные можно передать «по праву владения», не создавая дубликатов в памяти .
Уникальное владение: Для таких объектов, как дескрипторы баз данных или атомарные числа, Mojo позволяет гарантировать, что у объекта есть только один владелец в конкретный момент времени .
Безопасная мутация: Если вам нужно изменить объект, Mojo управляет правами доступа так, чтобы это не затронуло другие части программы непредсказуемым образом .

Латтнер подчеркивает, что цель Mojo — дать разработчику мощь системного программирования (как в Rust), но избавить его от необходимости постоянно «бороться с проверщиком заимствований» (borrow checker) . Это особенно важно для многопоточных вычислений, где правильная передача владения позволяет избежать блокировок (locks) и состояния гонки при обращении к тензорам . Ранее в разговоре они кратко упоминали причины высокой производительности Mojo, и именно такая работа с памятью является одним из кирпичиков этого фундамента.

Инфраструктурный тупик: почему ИИ застрял в «точках решения» 1:00:31

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

Основной конфликт разворачивается между миром исследований и миром продакшена. Исследователи работают в Python и Jupyter-ноутбуках — это удобно и гибко . Однако, когда модель нужно развернуть в облаке или на устройстве, она сталкивается с «деплоймент-стеной» . Python не предназначен для эффективного развертывания, поэтому код часто приходится полностью переписывать на C++ . Это не только замедляет процесс, но и разделяет команду на «учёных» и «инженеров», которые говорят на разных языках.

Крис выделяет несколько причин этой сложности:

Устаревшее наследие: Системы вроде TensorFlow создавались в эпоху, когда мир ИИ был другим, и попытки адаптировать их под новые задачи ведут к нагромождению костылей .
Point Solutions (Точечные решения): Вместо создания универсальных инструментов компании создают узкоспециализированные стеки под конкретное железо или задачу .
Взрыв аппаратного обеспечения: Сейчас существует более сотни стартапов, разрабатывающих новые чипы для ИИ . Каждый такой чип требует своего программного стека, что только усиливает хаос.

Миссия Modular: унификация против фрагментации 1:06:54

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

Проблема не в том, что Python плох, а в том, что он ограничен . Крис утверждает, что если бы Python был достаточно хорош для всех задач, Modular бы не существовало. Но разрыв между «удобным Python» и «быстрым C++» заставляет инженеров тратить годы на поддержку хрупких систем .

Решение Modular заключается в создании платформы, которая позволит:

Писать код один раз и разворачивать его на любом железе без переписывания .
Устранить необходимость в сложной «нарезке» (partitioning) моделей вручную для работы на нескольких машинах .
Дать разработчикам оборудования стандарт, под который они могут проектировать свои чипы, вместо того чтобы изобретать велосипед для каждого нового ускорителя .

Латтнер выражает симпатию к инженерам, которые вынуждены строить долгосрочные решения на этом зыбучем песке . Проект Modular и язык Mojo — это попытка создать твердую почву, где инновации в ИИ не будут тормозиться несовершенством инструментов .

🧩 Гетерогенные вычисления и физика программного обеспечения 1:15:26

Одной из фундаментальных проблем современной разработки Крис Латтнер считает разрыв между специалистами, знающими внутреннее устройство «железа», и авторами компиляторов. Программирование для специализированных чипов сегодня напоминает «черную магию»: эксперты по аналоговым компьютерам или архитектуре GPU могут написать невероятно эффективный код, но они не являются системными программистами . Роль Mojo заключается в том, чтобы сделать программируемость доступной для этих экспертов без необходимости погружаться в дебри разработки компиляторов. Ранее в разговоре Крис и Лекс упоминали сложность инфраструктуры ИИ, и именно здесь Mojo предлагает решение, основанное на управлении аппаратной неоднородностью.

Гетерогенные среды и координация ускорителей 1:18:47

Современные вычислительные системы давно перестали быть гомогенными. Как объясняет Крис Латтнер, термин «гетерогенность» в данном контексте означает сосуществование множества различных типов процессоров в рамках одной системы . Если десять лет назад стандартная схема ограничивалась связкой «CPU плюс GPU», где данные просто пересылались по сети или шине, то сегодня мы имеем дело с целым созвездием специализированных блоков .

Внутри одного современного чипа могут находиться:

Универсальные ядра (CPU) для общих задач;
Графические ускорители (GPU) для параллельных вычислений;
Специализированные нейросетевые ускорители (NPU), оптимизированные под матричные операции;
Блоки цифровой обработки сигналов (DSP) или блоки для работы с разреженными матрицами.

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

Программист должен иметь возможность четко определять, какая часть вычислений уходит на тот или иной участок чипа . Это классическая задача «размещения» (placement) и «партиционирования» (partitioning), которая в Mojo превращается из ручного труда в задачу авто-тюнинга. Вместо того чтобы вручную подбирать параметры для каждой архитектуры, система может использовать поиск по многомерному пространству решений, фактически превращая оптимизацию компиляции в задачу машинного обучения .

Сращивание ядер и физика памяти 1:18:49

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

Одним из ключевых методов борьбы с этой задержкой является сращивание ядер (kernel fusion) . Эта техника позволяет объединять несколько математических операций в один проход внутри ускорителя. Вместо того чтобы вычислить одну функцию, сохранить результат в основную память, а затем снова загрузить его для следующей функции, Mojo позволяет выполнять всю цепочку действий непосредственно в регистрах или локальной памяти чипа.

Крис выделяет иерархическую структуру оптимизаций, которую Mojo внедряет на уровне библиотек:

Векторизация: выполнение одной команды над множеством элементов данных одновременно .
Параллелизация: распределение задач между множеством ядер .
Тайлинг (Tiling): важнейшая оптимизация памяти, при которой данные разбиваются на небольшие блоки («плитки»), соразмерные с кэш-памятью процессора .

Если размер блока выбран правильно, данные остаются в кэше L1 или регистрах (которые Крис называет «кэшем нулевого уровня»), что позволяет избежать обращений к медленной глобальной памяти . Такой подход позволяет добиваться кратных ускорений (например, в 12 раз на простых задачах) даже без учета глобальных архитектурных изменений .

Преодоление фрагментации ML-инструментария 1:30:19

Состояние современных инструментов машинного обучения Латтнер описывает как «хрупкое» . В отличие от мира Си, где компиляторы развивались десятилетиями, стек ИИ построен разными командами, разными поставщиками оборудования и на разных системах. В результате, если вы пытаетесь развернуть новую модель на новом железе, конвертеры часто просто «падают» .

Mojo и инфраструктура MLIR (Multi-Level Intermediate Representation) созданы для того, чтобы стать «точкой фиксации сложности» . Это система, которая способна обобщать алгоритмы и делать их переносимыми. Вместо того чтобы переписывать код под каждый новый чип, разработчик описывает алгоритм в высокоуровневом виде, а компилятор берет на себя адаптацию под конкретную физику железа.

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

🐍 Совместимость как стратегия: почему Mojo не повторяет ошибки Swift и Julia 1:40:18

Разработка нового языка программирования — это всегда баланс между теоретическим совершенством и суровой практикой. Крис Латтнер (Chris Lattner) подчеркивает, что успех любого инструмента зависит не только от его производительности, но и от того, насколько легко сообщество может его принять. В контексте ИИ это означает неизбежное столкновение с доминированием Python.

Прагматизм против идеализма: урок Clang и GCC 1:46:48

Крис Латтнер часто возвращается к своему опыту разработки Clang и LLVM, чтобы проиллюстрировать важность обратной совместимости. Когда проект Clang только начинался в середине 2000-х, перед командой стояла дилемма: создать идеально чистый парсер C++ или сделать его совместимым с «грязными» и нестандартными расширениями GCC .

В то время GCC был де-факто стандартом, и хотя как инженер Латтнер понимал, что проще написать систему с нуля, прагматизм взял верх. Если бы Clang не мог скомпилировать существующие заголовочные файлы C, никто бы не стал его использовать . Этот «военный опыт» лег в основу философии Mojo: вместо того чтобы заставлять мир переписывать код, нужно строить мосты к уже существующим экосистемам.

Ранее в интервью Лекс Фридман (Lex Fridman) и Крис обсуждали невероятное ускорение Mojo по сравнению с Python, но именно совместимость Латтнер называет критическим фактором для того, чтобы эти цифры имели значение в реальном мире.

Ловушка «строгого надмножества» 1:43:37

Одним из самых тонких моментов в дизайне Mojo является отказ от статуса «строгого надмножества» (strict superset) Python. На первый взгляд это кажется контринтуитивным, но Крис объясняет, что попытка быть 100% совместимым на уровне синтаксиса «загоняет разработчика в угол» .

Проблема строгих надмножеств (как в случае с C и C++) заключается в том, что новый язык наследует все ошибки проектирования и ограничения своего предшественника . Python, при всей его элегантности, имеет фундаментальные проблемы с производительностью, связанные с глобальной блокировкой интерпретатора (GIL) и упаковкой объектов в памяти.

Mojo выбирает путь «совместимого, но независимого» развития:

Mojo позволяет бесшовно импортировать библиотеки Python, используя существующую экосистему .
При этом он не обязан следовать тем решениям Python, которые мешают работе с регистрами процессора или GPU .
Цель состоит в том, чтобы разработчик мог постепенно «модернизировать» свой код, внедряя типизацию и другие возможности Mojo там, где это необходимо .

Разговор с Гвидо ван Россумом и единство сообщества 1:50:08

Крис Латтнер отмечает, что для него было крайне важно обсудить проект с Гвидо ван Россумом (Guido van Rossum), создателем Python. Главный риск при создании Mojo заключался в потенциальной фрагментации сообщества, подобной болезненному переходу с Python 2 на Python 3 .

Гвидо, по словам Криса, проявил большой интерес к проекту. Основная идея сосуществования заключается в том, что пользователи Python и «моджичианцы» (Mojicians) — как Крис в шутку называет сообщество Mojo — могут делить один и тот же код . Mojo не пытается заменить Python для всех задач; он предлагает решение там, где Python достигает своего предела — в высокопроизводительных вычислениях и инфраструктуре ИИ.

Почему Swift для TensorFlow и Julia не стали мейнстримом 2:02:43

Анализируя прошлые попытки внедрить новые языки в сферу ИИ, Латтнер выделяет две основные причины их ограниченного успеха. Первая и самая очевидная: «Swift — это не Python» . Несмотря на то что Swift — быстрый и эффективный язык, барьер для входа оказался слишком высоким для исследователей, чей рабочий процесс полностью завязан на библиотеках Python.

Вторая причина касается архитектуры вычислений. В проекте Swift для TensorFlow (S4TF) Крис и его команда пытались внедрить дифференцируемое программирование непосредственно в компилятор. Это было технологическим прорывом, но рынок в тот момент двигался в сторону «eager mode» (немедленного выполнения), который популяризировал PyTorch .

Уроки Julia также были учтены:

Проблема «двух языков»: необходимость писать прототип на Python, а критические части на C++ или Julia, создает когнитивную нагрузку .
Экосистема: Julia создала великолепную среду, но она остается изолированной от огромного количества наработок на Python.

Mojo стремится решить «проблему N миров» (N-world problem) . Вместо того чтобы создавать еще один изолированный остров, Крис строит систему, которая объединяет простоту Python с мощностью C++, позволяя разработчикам LLM и других современных моделей не тратить время на переписывание кода ради производительности .

🛠 Стратегия «0.1»: уроки Swift и влияние Джереми Ховарда 2:20:49

Оглядываясь на десятилетия разработки языков программирования и компиляторов, Крис Латтнер подчеркивает, что успех новой технологии зависит не только от её архитектуры, но и от стратегии её выхода в мир. Опыт создания Swift и LLVM научил его, что избыточная секретность может стать ловушкой, а прагматизм практиков-исследователей — лучшим компасом для проектирования сложных систем.

Отказ от «секретных лабораторий»: уроки Swift и запуск Mojo 0.1 2:20:49

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

Проблема «закрытой» разработки заключается в накоплении технического долга. Когда вы строите систему в вакууме, вы часто принимаете решения, которые кажутся верными, но не проходят проверку реальностью на ранних этапах. В случае со Swift это привело к болезненным изменениям в версиях 2.0 и 3.0, когда код пользователей постоянно «ломался» .

С Mojo Крис Латтнер и команда Modular выбрали диаметрально противоположный путь — стратегию открытой и ранней итерации:

Публичность на этапе 0.1: Mojo был представлен сообществу в зачаточном состоянии, чтобы разработчики могли влиять на его дизайн с самого начала .
Итерация через Playground: Сначала доступ к языку был открыт через браузерную среду, что позволило собрать фидбек до того, как локальные версии распространились повсеместно .
Совместное строительство: Вместо того чтобы выкатывать «идеальный» (по мнению авторов) продукт через пять лет, Modular строит язык вместе с сообществом, избегая «шрамов войны» и внезапных поломок архитектуры в будущем .

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

Прагматизм Джереми Ховарда: ИИ как прикладная дисциплина 2:28:06

Огромное влияние на идеологию Mojo оказал Джереми Ховард, основатель fast.ai. Латтнер полушутя отмечает, что Mojo — это результат того, что он «наконец-то прислушался к Джереми» . Влияние Ховарда заключается в глубоко прагматичном подходе к машинному обучению, который контрастирует с чисто теоретическими изысканиями.

Джереми Ховард известен своим grassroots-подходом (идущим «от земли»): он обучает миллионы людей строить работающие модели, не дожидаясь идеальных инструментов. Еще во время работы Криса в Google над проектами для TensorFlow, Ховард указывал на то, что существующие фреймворки слишком громоздки и далеки от реальных нужд инженеров . Его критика всегда строилась вокруг эффективности: как сделать обучение моделей быстрее, а код — понятнее.

Влияние Fast.ai на Mojo проявляется в нескольких аспектах:

Доступность: Язык должен быть понятен не только PhD в области компьютерных наук, но и прикладному исследователю, которому нужно «просто запустить модель» .
Производительность «из коробки»: Джереми всегда настаивал на том, что Python-инфраструктура тратит слишком много времени на лишние вычисления (эпохи обучения, неэффективные циклы). Mojo стремится дать ту самую «скорость vroom», о которой говорил Ховард .
Уход от сложности: Ховард пропагандирует упрощение стека технологий. Вместо нагромождения библиотек на C++, CUDA и Python, Mojo предлагает единое пространство для экспрессивного и быстрого кода .

Прогноз на десятилетие: почему физика не станет проще 2:15:51

Обсуждая будущее, Латтнер подчеркивает, что сложность оборудования — это не временная трудность, а константа, продиктованная физикой. За последние 10 лет мы перешли от простых CPU к зоопарку из GPU, TPU и специализированных AI-акселераторов . Прогнозы на следующие 10 лет указывают на то, что аппаратная среда станет еще более «странной» и гетерогенной, возможно, включая аналоговые компьютеры .

Это оправдывает создание Mojo как инструмента, который не просто дает «дофаминовый удар» от 10-кратного ускорения кода , но и создает надежный мост между высокоуровневым программированием и физическими ограничениями железа будущего. Латтнер верит, что успех придет к тем системам, которые смогут предложить «средний путь»: прогрессивное обучение новым возможностям без принуждения к сложности .

Укрощение хаоса: упаковка пакетов и философия двух ключевых слов 2:32:09

Боль Python-зависимостей и системный подход Mojo

Одной из самых болезненных тем для любого, кто профессионально работает с Python, является управление зависимостями и дистрибуция пакетов. Лекс Фридман отмечает, что у многих разработчиков остались настоящие «шрамы» от попыток настроить окружение . Проблема Python не только в обилии инструментов управления пакетами, но и в том, что современная экосистема ИИ фактически расколота надвое: логика пишется на Python, а производительные библиотеки — на C или C++.

Крис Латтнер подчеркивает, что Mojo стремится решить эту многолетнюю проблему на фундаментальном уровне. Вместо того чтобы накладывать очередную заплатку на систему сборки, Mojo объединяет управление кодом на Python и низкоуровневым кодом в единую бесшовную систему. Когда язык изначально понимает и динамические, и системные аспекты программирования, необходимость в сложной «склейке» разных языков отпадает сама собой.

В ходе обсуждения Латтнер и Фридман касаются текущего состояния экосистемы:

Экосистема PIP: Это невероятный по масштабам ресурс, но он не стал проще в плане обнаружения (discovery) нужных инструментов за последние годы .
Роль GitHub: Сервис централизовал хранение кода, но Крис считает, что всё ещё есть место для инноваций в том, как разработчики находят и потребляют пакеты .
Сложность C+ Python: Гибридная модель делает всё сложнее, увеличивая когнитивную нагрузку на инженера .

Mojo предлагает пересмотреть саму концепцию упаковки. Поскольку компилятор Mojo (ранее в разговоре Крис упоминал его способность к глубокому анализу кода) видит всю структуру программы целиком, он может более эффективно управлять зависимостями, не разделяя их на «родные» и «внешние».

Выбор между гибкостью и строгостью: 'def' против 'fn' 2:40:00

Ключевое архитектурное решение Mojo — сосуществование двух разных режимов объявления функций: def и fn. Это позволяет Mojo быть одновременно и «лучшим Python», и мощным системным языком.

Режим def оставлен для максимальной совместимости с Python. Это динамический режим, где типы могут быть не указаны, а поведение программы остается гибким и привычным для тех, кто привык к быстрой итеративной разработке и написанию скриптов «на коленке» . Как отмечает Крис, Python прекрасен для одноразовых задач, где строгость только мешает .

Режим fn, напротив, предназначен для системного программирования. Он вводит строгие правила:

Явное объявление переменных: Вы не можете просто создать переменную присваиванием, не объявив её (например, через var) .
Строгая типизация: Требуется четкое определение типов аргументов и возвращаемых значений.
Контроль владения: Это дает компилятору возможность проводить оптимизации, недоступные в динамической среде.

Крис Латтнер сравнивает это с уроками, извлеченными из разработки Swift . Философия Mojo не в том, чтобы заставлять программиста быть строгим, а в том, чтобы дать ему выбор. Лекс Фридман признается, что предпочитает строгость (fn), так как она дает чувство контроля и силы . В режиме fn компилятор ловит опечатки и логические ошибки на этапе сборки, что критически важно для крупных инфраструктурных проектов.

Обработка ошибок и путь к завершению языка 2:44:19

Разница между def и fn проявляется и в том, как Mojo обрабатывает ошибки. В традиционном C++ существует концепция «zero-cost exceptions», которая, по словам Латтнера, на самом деле обходится очень дорого, когда ошибка действительно происходит . В Mojo используется иной подход: обработка ошибок реализована через механизм вариантов (variants), что делает её предсказуемой и очень быстрой.

Это позволяет Mojo масштабироваться до самых низов — вплоть до микроконтроллеров, где традиционные механизмы исключений Python или C++ слишком тяжеловесны . Вместо того чтобы «раздувать» бинарный файл сложными таблицами поиска для исключений, Mojo проверяет результат функции локально, что по производительности сопоставимо с возвратом кода ошибки, но сохраняет удобство синтаксиса try-except.

Несмотря на мощный фундамент, Крис честно признает, что Mojo — очень молодой язык (на момент записи подкаста ему было всего несколько месяцев). В списке задач на реализацию всё ещё значатся важные элементы:

Поддержка полноценных классов и наследования .
Синтаксис лямбда-функций и вложенных функций .
Полная поддержка кортежей (Tuples) и глобальных переменных .

На текущем этапе «Полярной звездой» для команды Modular является построение стека для ИИ . Все функции языка внедряются исходя из этой приоритетной задачи, но конечная цель — создать универсальный инструмент, который уберет барьер между исследователем данных и системным инженером.

🧠 Память без пауз и искусство найма в Modular 2:55:54

Жадная деструкция: как Mojo управляет жизненным циклом объектов 2:55:54

Одной из самых амбициозных технических инноваций в Mojo Крис Латтнер считает систему автоматического управления временем жизни объектов. В отличие от C++, где деструкторы срабатывают строго в конце области видимости (scope), или Python с его подсчетом ссылок и сборщиком мусора, Mojo использует принцип «жадной деструкции» (Eager Destruction). Объект уничтожается сразу после его последнего использования в коде .

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

Оптимизация кэша: Когда объект удаляется немедленно, занимаемая им память (часто еще «горячая» в кэше процессора) освобождается для немедленного повторного использования. Это критически важно для производительности нейросетей, где данные постоянно перетекают из одной операции в другую .
Хвостовая рекурсия (Tail Calls): В традиционных языках деструкторы в конце функции мешают компилятору оптимизировать рекурсию, так как стек нельзя очистить, пока не выполнены все деструкторы. Mojo, уничтожая объекты раньше, позволяет реализовать полноценную хвостовую рекурсию, что традиционно было прерогативой функциональных языков .
Трекинг владения: Хотя ранее в разговоре Крис уже касался семантики значений и передачи владения, именно «жадная деструкция» делает этот механизм интуитивно понятным для программиста.

Реализация такой системы — задача нетривиальная. Компилятору приходится анализировать все потоки управления (control flow), чтобы точно определить момент последнего использования переменной . По словам Латтнера, это пример того, как возможность построить язык с нуля позволяет «правильно уложить каждый кирпич», не оглядываясь на наследие прошлых десятилетий .

Крис также отмечает, что в Mojo уже встроена высокопроизводительная поддержка async/await, адаптированная для гетерогенных вычислений (CPU, GPU и другие ускорители) . Это особенно важно, так как в стандартном Python потоки никогда не были сильной стороной, а Mojo стремится сделать параллельное программирование естественным и быстрым .

Культура Modular: от «страданий индустрии» до удалёнки и офлайна 3:05:46

Создание новой технологической экосистемы требует не только гениального кода, но и уникальной команды. Крис Латтнер делится опытом построения компании Modular, которая находится в поиске «редких единорогов» — специалистов по компиляторам и инфраструктуре ИИ.

Философия найма в Modular строится на принципе «работы от обратного» — от страданий пользователей. «Мы смотрим на боль и страдания в индустрии и идем назад к решению», — объясняет Крис . Чтобы привлечь лучших инженеров из Big Tech, компания должна предложить не только высокую зарплату , но и свободу от корпоративной бюрократии.

Латтнер проводит параллели со своим опытом в Apple, отмечая важность продуктового мышления. Apple часто выпускает технологии, которые кажутся несовершенными (например, первый iPhone без функции «копировать-вставить»), но они фокусируются на ключевом пользовательском опыте, а затем итеративно дорабатывают остальное . Modular следует схожему пути: сначала заложить мощный фундамент, а затем добавлять «синтаксический сахар», даже если сообщество очень просит об этом прямо сейчас . В этом контексте Крис вскользь упоминает возможность использования эмодзи в качестве расширений файлов, о чем они говорили ранее, как пример гибкости и свежего взгляда на каноны .

Особое внимание уделяется культуре удалённой работы. Modular — компания, ориентированная на remote-first, что позволяет нанимать таланты по всему миру, но создает сложности с часовыми поясами и коммуникацией .

Для сплочения команды Крис выделяет следующие практики:

Регулярные офлайны: Раз в квартал вся компания собирается в одном месте. По мнению Латтнера, ни один Zoom не заменит совместного обеда или спонтанного обсуждения у маркерной доски .
Доверие через bonding: Личные встречи создают запас социального доверия. Когда инженер знает коллегу лично, он спокойнее реагирует на разногласия в GitHub .
Свобода принятия решений: Крис иронизирует, что в большой корпорации даже покупка футболок с логотипом превращается в процесс согласования на полгода. В Modular он может просто решить: «Лексу нужна футболка», и это произойдет мгновенно .

Завершая блок о культуре, Крис подчеркивает, что работа в стартапе над открытыми проектами вроде Mojo дает инженерам чувство сопричастности к чему-то, что меняет мир, а не просто увеличивает выручку рекламного гиганта . В самом конце этого фрагмента дискуссия плавно переходит к теме будущего ИИ и того, как LLM изменят сам процесс написания кода, что станет центральной темой финала их беседы .

🚀 Будущее программирования: ИИ как напарник и децентрализация технологий 3:20:45

В завершающей части беседы Лекс Фридман и Крис Латтнер обращаются к фундаментальным вопросам: как большие языковые модели (LLM) изменят повседневную работу инженера и стоит ли человечеству опасаться стремительного развития искусственного интеллекта. Крис Латтнер, опираясь на свой опыт создания языков и компиляторов, видит в ИИ не угрозу профессии, а мощнейший инструмент для борьбы со сложностью.

LLM как инструмент преодоления синтаксической строгости 3:21:12

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

По мнению Криса, появление LLM и инструментов вроде GitHub Copilot кардинально меняет этот ландшафт. Эти модели берут на себя «черновую» работу по написанию шаблонного кода, позволяя разработчику сосредоточиться на творческом потенциале . Программирование начинает смещаться от процесса механической реализации к процессу выражения намерений (intent).

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

Взгляд на риски AGI и инерция физического мира 3:24:10

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

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

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

Демократизация технологий и решение локальных задач 3:28:05

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

Латтнер видит в этом огромный потенциал для «нишевых» областей:

Медицина: разработка специализированных моделей для радиологии и диагностики редких патологий .
Локальное производство: адаптация ИИ под нужды конкретных небольших предприятий.
Персонализированные инструменты: создание ПО, которое решает задачи конкретного пользователя, а не усредненного рынка.

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

Советы будущему поколению инженеров 3:30:55

В финале диалога Крис дает совет молодым людям, которые только начинают свой путь в мире, меняющемся под влиянием ИИ. Его главный призыв — не ограничиваться теорией и «просто строить вещи» . Будь то мобильное приложение или обучение собственной модели, практический опыт создания продукта с нуля дает понимание, которое невозможно получить в учебниках.

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

Завершая беседу, Лекс Фридман благодарит Криса за его вклад в развитие инфраструктуры искусственного интеллекта и за то, что он остается «настоящим» — человеком, который не просто рассуждает о будущем, но и строит его своими руками, делая технологии доступнее для каждого.