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

Следует философии:

1. Статическая генерация. Никакой генерации в рантайме
2. Отсутствие зависимостей — сгенерированный парсер должен легко настраиваться
3. Вывод на несколько языков
4. Семантические действия и обработка ошибок прямо в грамматике, без её раздувания
5. Гибкость использования как в тривиальных, так и в очень крупных проектах
6. Простой в использовании API

Недавно в статический анализатор PVS-Studio была добавлена поддержка JavaScript/TypeScript, и он на старте умеет искать ошибки, связанные с потоком управления. Причём тут граф потока управления, как мы его добавили и чем это полезно — читайте в этой статье.

Хотя я считаю свой проект серьезным - не являюсь узким специалистом по разработке ОС. Проект пока любительский, и могу позволить себе некоторую свободу по разработке. Тут ставил для себя такие задачи:

Большинство курсов по FPGA начинаются со слов «установите Vivado». Мы пошли с другого конца: в каждом из 27 уроков есть рабочий виджет, собранный из реальных запусков на нашем стенде. Сначала разбираем, что такое FPGA и как числа становятся битами. Потом пишем спеку на t27, компилируем её t27c и превращаем в битстрим на плате. В конце — лаборатория из трёх уроков о наших собственных исследованиях, включая результаты, которые нам не понравились. Каждая картинка ниже — снимок живого виджета; нажмите, чтобы открыть его.

На фоне десятков языков с привычным английским синтаксисом появление «Сферы» выглядит почти вызовом: это полностью кириллический язык программирования с настоящим компилятором — не интерпретатор и не транспайлер, а генерация машинного кода через LLVM.

За внешней необычностью стоит вполне зрелая инженерия: автоматическое управление памятью, обобщённые типы, контракты, многопоточность, сеть, графика, пакетный менеджер поверх git и отладчик с полноценной поддержкой DWARF. «Сфера» не претендует на то, чтобы заменить индустриальные языки — но доказывает, что кириллический синтаксис способен быть не курьёзом, а рабочим инструментом. И в этой статье честно говорим не только о том, что уже получилось, но и о том, что ещё предстоит сделать.

Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.99.0 вам достаточно выполнить команду:

$ rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску 1.99.0.

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках!

Я написал транслятор CUDA/PTX в LLVM IR: он берёт PTX от настоящего nvcc и собирает его обычным clang. Восемь ядер уже исполнены на живой GeForce MX450 и побитово совпали с хост‑эталоном. А главное — как настоящий nvcc и видеокарта сломали мои зелёные тесты.

Я написал source generator для лексера HydraScript. Он собирал регулярное выражение из описаний токенов. После этого мне оставалось скопировать регулярку и руками вставить её в другой файл.

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

Проблема была в том, что результат моего генератора требовался другому генератору — тому, который стоит за атрибутом [GeneratedRegex] в .NET. Хотелось описать токен один раз и поручить остальное сборке. Для этого пришлось разобраться, в каком порядке Roslyn вообще выполняет генераторы.

HydraScript — мой интерпретатор на C#. В нём есть объекты, статическая типизация и вызовы методов. А class, interface и constructor я вообще не добавлял.

Точке на плоскости нужны две координаты, для вычисления расстояния до другой точки нужна функция. Хотелось, чтобы эти вещи работали без обязательной упаковки в класс.

Тут я вдохновлялся сразу двумя языками: структурной типизацией TypeScript и методами с явным получателем из Go. Подход Go заодно сильно упрощал жизнь мне самому — автору языка. Функции у меня уже работали, и методы можно было построить на их основе, не вдаваясь в реализацию классов.

Если энергопотребление ЦОДов будет и дальше расти, то для них придётся выкупать мощности АЭС, как это сделали Microsoft и Amazon. Но должен быть другой выход. Поэтому есть большая потребность в энергоэффективных CPU.

Год назад стартап Efficient Computer представил «самый энергоэффективный в мире» процессор Electron E1. Разработчики попытались заново изобрести универсальный CPU, ориентируясь именно на энергоэффективность. Правда, конкретно этот CPU предназначен для embedded-систем, но схожую архитектуру применяют и для ЦОДов.

Новый CPU в 10−100 раз эффективнее ARM на типичных embedded-задачах, таких как быстрое преобразование Фурье (по данным с сенсоров) или выполнение свёрток (вычисление карты признаков) в свёрточных нейросетях.

Сейчас E1 и компилятор проходят тестирование среди разработчиков. Участники закрытой программы тестирования могут проверить свой код С и С++ в веб-песочнице, оценить его энергоэффективность на новом CPU.

Мне хотелось, чтобы знакомство с HydraScript выглядело просто: скачал интерпретатор, запустил скрипт. Сомнительно предлагать человеку сначала установить подходящий .NET Runtime ради моего языка программирования.

Переход на Native AOT поначалу казался правкой .csproj. Включил настройку, опубликовал бинарник, пошёл дальше. На практике пришлось переписать всё. Досталось даже интеграционным тестам. А в процессе рефакторинга ещё и пропали логи.

Мой язык программирования HydraScript, написанный на C#, уже умел выполнять такой код:

let x = 10 x = x + 1 >>> x

Получаем 11; >>> — это оператор вывода. Присваивание работает, сложение работает. Захотелось добавить привычное сокращение:

let x = 10 x += 1 >>> x

Результат должен остаться тем же — 11. Зачем учить весь компилятор ещё одной операции, если всё необходимое у него уже есть? Можно прямо в парсере превратить x += 1 в дерево для x = x + 1.

Эта часть уместилась в несколько строк. Основная работа досталась методу Clone().

У любого ускорителя Python есть число: во сколько раз он быстрее. Меряют его на ядрах - сортировка, обход дерева, арифметика в цикле. Сервис устроен не так: обработчик ходит в базу, считает в numpy, сериализует ответ, и байткода, к которому это число применимо, в нём может почти не остаться. CinderX ускоряет байткод, и за пределы байткода это число не распространяется. Доля байткода в вашем сервисе - свойство вашего кода, а не расширения, и пока она не посчитана, «ставить или нет» решается угадыванием.

Проще говоря, NEX CLI x Elbrus берет граф и модель e2k‑v6 и показывает: сколько насчитал жадный, сколько мог бы идеальный, и на какой операции и каком канале разница.

Мой ассемблер резал исходник построчными правилами: срезал комментарий, искал двоеточие, делил по запятым. Я заменил это одним проходом с состоянием и попутно проверил, нельзя ли было обойтись заплатками.

Нельзя: вторая заплатка ломает то, что починила первая.

Одна и та же операция — дедупликация списка типов — написана двумя способами: на шаблонах и на статической рефлексии из C++26. Обе реализации живут в одном дереве и проверены на идентичность результата, поэтому их можно честно вычесть друг из друга. Получилось так: шаблонная версия съедает 7,9 ГиБ памяти компилятора там, где рефлексивная не съедает ничего измеримого — ±21 МиБ на 32-кратном диапазоне размеров. А по времени обе квадратичны, и рефлексия выигрывает всего пятую часть. Разбираю, откуда берётся такая асимметрия, и заодно пять компиляторных стен, в которые упираешься по дороге, — включая sizeof…, который молча возвращает неверное число.

Личная история о том, как двадцатилетняя мечта о математически доказуемом коде неожиданно стала ответом на главный вызов эпохи ИИ-агентов.

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

Я написал маленькую утилиту, которая переводит исходный код Python между тремя синтаксисами: классические отступы, C-подобные фигурные скобки, S-выражения в духе Лиспа. Один и тот же quicksort, три вида:

Если у вас уже установлена предыдущая версия Rust через rustup, вы можете получить 1.98.0 командой:

$ rustup update stable

Если Rust ещё не установлен, вы можете получить rustup на соответствующей странице нашего сайта и ознакомиться с подробными release notes для 1.98.0.

Если вы хотите помочь нам, тестируя будущие релизы, рассмотрите возможность переключиться локально на beta-канал (rustup default beta) или nightly-канал (rustup default nightly). Пожалуйста, сообщайте о любых обнаруженных ошибках!

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

Проверка на переполнение есть в коде, проходит ревью и работает в отладочной сборке — а после оптимизации исчезает из бинарника. Разберём, почему компилятор имеет на это полное право, как неопределённое поведение влияет на указатели, память и проверки, и чем ловить такие ошибки до того, как они проявятся в рабочей среде.

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

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

Не сломал. Полная перестройка ядра — 350 строк — прошла все 444 проверки, и ни один эталон не пришлось трогать.

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

Плюс двенадцать дефектов, которые нашёл фаззер: равенство, переставшее быть симметричным; undefined, вылезающий наружу в языке, где его нет; += , вычислявший цель дважды. Два из двенадцати нашёл не фаззер, а я — когда писал тесты к его находкам.

Отдельно — про то, что четыре из пяти находок второго фаззера оказались враньём самого фаззера, и почему я довёл его до нуля ложных срабатываний вместо «ну там четыре из них шум».

В первой части мы разобрали язык, компилятор и байткод SwiftII — Swift-подобной среды для Apple II 1977 года. Но чтобы на этой машине действительно писать код, одного интерпретатора мало: клавиатура без строчных букв и обратного слэша, дисплей без половины нужных символов, 64 КБ памяти, которые приходится переключать банками. Во второй части — как автор всё это обошёл (собственный редактор, файловый браузер, ввод через диграфы) и, отдельно, как весь проект собирался с помощью Claude Code и Codex: честный разбор, где ИИ реально помог, а где им пришлось управлять вручную.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Недавно в Брно состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз началась работа над C++29 и как раз о новинках и хочется рассказать.

Что компилятор знает об окружении, когда начинает свою работу?

Из того, что он знает гарантированно, можно назвать только путь до бинарного файла, который послужил «пускачом». Откуда мы это знаем?

Три статьи я собирал файл и отдавал его эмулятору, ни разу в него не заглянув. Заглянул. Внутри два разных описания одних и тех же байтов, ответ на вопрос, откуда взялся адрес 0x80000000, и поле, которое я заполнял зря.

Довайте соберем полный конвеер компиляции от исходного кода до готового бинарника из AI-моделей (нет, не соберем)

Написал рекурсию тем же приёмом, что во второй статье, и программа повисла навсегда: возвращаться ей было некуда. Чиню, завожу стек и по дороге выясняю, что регистра sp в наборе команд нет вовсе. А потом урезаю стек до 128 байт, и сборка об этом не говорит ни слова.

Swift — язык, на котором пишут приложения для iPhone и Mac. Apple II — 8-битный компьютер 1977 года с процессором на 1 МГц, где под всю вашу программу остаётся ровно 40 704 байта. Автор оригинала соединил эти два полюса и собрал SwiftII: работающее подмножество Swift, которое компилируется в байткод и исполняется виртуальной машиной прямо на «яблочной» восьмибитке — по той же идее, по которой в 1979-м на Apple II приносили Pascal. В первой части — как устроены язык, однопроходный компилятор и байткод и на какие жертвы пришлось пойти, чтобы код всё ещё читался как Swift.

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

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

Звучит странно. Но чтобы понять, зачем это нужно и почему это красиво, придется сначала заглянуть в обычные компиляторы и немного в азы ИИ. Без них дальше будет непонятно.

Это статья про разновидность языка Си с русским и оригинальным английским синтаксисом, работающими одновременно. «Если» и «if» работают как синонимы. Это не интерпретатор. Это компилятор, который способен собрать себя сам. Это даже не транспилятор русского в английский - оба набора слов работают равноценно. Код можно посмотреть https://кодыч.рф/administrator/rusi.

Создаю собственный DSL на C#: в этой части добавим инструменты диагностики. Построим инспектор дерева компонентов, научимся изменять состояния и параметры прямо во время работы приложения, подключим метрики через System.Diagnostics и настроим #line, чтобы исключения указывали на исходный .akbura-файл, а не на сгенерированный C#.

У нас тормозило всё: сборка, дев-сервер, svelte-check, LSP. Я пошёл писать свой компилятор Svelte на Rust. Пять с половиной месяцев ковырял руками и бросил. Через год вернулся с ИИ-агентом и доделал за 106 вечеров и $700.

В прошлой статье я писал о WIE - userspace эмуляторе, который через JIT позволяет запускать PE64 бинарники на Apple Silicon. Казалось бы проект шел хорошо - почему делаешь новое? Дело в том, что я уперся в ужасную скорость - 7zip реальный проект на 200+ мб сжимал в 80-100 раз медленнее, чем нативный macOS бинарник. И это исправить без радикальной переработки проекта и разрушения самой концепции невозможно. Поэтому его разработка к сожалению была приостановлена.

Но мне хотелось попробовать сделать то, что сохранит идею переноса бинарника одной OS на другую, но без JIT. И я нашел. И имя ему Kakehashi

Как часто вы слышали: «Не доверяй компилятору, пиши вручную»? Похоже, эту идеологию пора сдавать в архив.

Автор специально собрал примеры, в которых «умный» код современного C++ либо проигрывает наивному, либо не даёт выигрыша, но при этом ухудшает читаемость и мешает оптимизатору. Тут и легендарный Q_rsqrt, и бит-хаки для подсчёта единичек, и вездесущие const&, и даже опасные фокусы с фильтрацией диапазонов. Всё с воспроизводимыми бенчмарками на Clang 21 и Ryzen 9. Если вы готовы пересмотреть багаж старых привычек – просим под кат.

В прошлой статье я рассказывал, как мы делаем онлайн IDE для .NET — дизайн, компиляция и запуск приложений происходят прямо в браузере, без сервера. Проект живёт по адресу xaml.io. С тех пор мы много чего добавили, и в какой-то момент у нас стало получаться загружать в IDE довольно крупные .NET проекты — десятки XAML, сотни C# файлов, несколько референсных проектов и пакетов NuGet.

Одна из главных возможностей — это визуальный UI-дизайнер пользовательских приложений. И у него есть особенность: чтобы дизайнер вообще что-то показывал, приложение должно быть скомпилировано, причём в актуальном состоянии. Не «когда-нибудь», а после каждой правки.

Открыли как-то в IDE один реальный проект (FamilyShow — классическое демонстрационное WPF-приложение), поправили одну строку в .cs и 84 секунды наблюдали за анимацией прогресса. С таким UX никакой интерактивный дизайн невозможен.

Сейчас та же правка занимает 5 секунд, а правка XAML-разметки на типичной странице — меньше секунды. В этой статье — как мы к этому пришли, и какие сюрпризы нам приготовили по дороге Roslyn, OpenSilver, WASM и наш собственный код.

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

WIE — это исследовательский эмулятор пользовательского режима (userspace) для запуска 64-битных Windows-приложений (PE64) на архитектуре macOS Apple Silicon. Проект написан на Rust 1.97, а в качестве бэкенда компиляции используется Cranelift для трансляции x86-64 инструкций на лету в нативный ARM64.

Я больше года занимаюсь компиляторострением.