Hacker News Digest

SSA (Static Single Assignment) — это популярная форма промежуточного представления, используемая в большинстве современных компиляторов, включая LLVM, GCC, V8 и HotSpot. Её главная сила — в упрощении анализа и оптимизации программ. SSA преобразует императивный код с изменяемыми переменными в форму, где каждая переменная присваивается только один раз, что делает зависимости между значениями явными и легко отслеживаемыми.

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

• Обсуждение разошлось в сторону: от обсуждения SSA как формы IR и её влияния на оптимизации, к дискуссии о том, что такое SSA, как она соотносится с CPS и какие у неё есть trade-off'ы, а также к тому, что именно делает SSA «особенной» и как она влияет на компиляторы и языки.

Крупные компании, включая Google и Meta, вкладываются в развитие BPF для Linux, чтобы ускорить обработку сетевых пакетов и улучшить безопасность. Теперь инструментарий GCC тоже получает поддержку BPF, что расширяет возможности компиляторов для этой технологии.

Основное внимание уделяется интеграции BTF (формат типа BPF) и CTF (компактный формат типа C), которые позволяют эффективно работать с типами данных в BPF. Это важно, чтобы обеспечить совместимость и оптимизацию. В GCC добавлены атрибуты btf_decl_tag и btf_type_tag, которые помогают аннотировать код для лучшей проверки и безопасности.

Эти усилия направлены на то, чтобы GCC могла стать полноценной альтернативой существующим инструментам для BPF, таким как LLVM, что особенно важно для встраивания BPF в различные среды и системы. Работа также включает улучшения в тестировании и отладке, чтобы обеспечить надежность.

• Обсуждение вращается вокруг лицензии LLVM и Apache 2.0, их совместимости с GPL и влияния на свободное ПО.
• Участники спорят о том, что означает «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.
• Обсуждается, что означает «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.
• Участники обсуждают, что такое «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.

Проект JIT-компилятора для PostgreSQL сталкивается со сложностями из-за особенностей современных процессоров. Автор объясняет, что даже хорошо написанный интерпретатор может проигрывать в производительности из-за непредсказуемости переходов в switch-based интерпретаторах.

Используя технику "computed gotos" (динамических переходов), можно значительно ускорить интерпретацию, сделав шаблоны переходов более предсказуемыми для предсказателя ветвления процессора. Это может дать до 15-20% прироста производительности.

Автор также упоминает, что его JIT-решение для PostgreSQL будет использовать этот подход, а также другие оптимизации, такие как векторизация и inlining, чтобы превзойти стандартный интерпретатор PostgreSQL.

Кроме того, автор отмечает, что оптимизация под современные процессоры (особенно с их out-of-order исполнением и предсказанием ветвлений) требует осторожного подхода. Например, код должен быть структурирован так, чтобы минимизировать зависимости по данным и максимизировать параллелизм на уровне инструкций.

В итоге, проект направлен не только на создание JIT-компилятора, но и на то, чтобы переосмыслить, как должен работать интерпретатор, чтобы эффективно использовать современные процессоры.

• Обсуждение затронуло ограничения JIT в iOS из-за политики Apple, что влияет на производительность и возможности использования JIT в этой системе.
• Участники обсудили, что JIT-компилятор может быть полезен для оптимизации, но его отсутствие в iOS ограничивает возможности приложений.
• Также обсуждались различные аспекты производительности интерпретатора и JIT, включая влияние на предсказание переходов и спекулятивное исполнение.
• Участники упомянули, что JIT может быть полезен для DSL или других специализированных языков, но ограничения iOS могут затруднить это.

Аренная память в Rust предлагает альтернативу прямым ссылкам для структур с циклическими зависимостями, таких как двусвязные списки или графы объектов. Вместо указателей используются индексы (хэндлы) в заранее выделенном массиве (арене), что позволяет обойти ограничения системы владения Rust, сохраняя при этом детерминированное поведение и безопасность.

Ключевое преимущество — устранение недетерминированных сбоев и уязвимостей удалённого выполнения кода, характерных для традиционных ошибок управления памятью в C/C++. Ошибки в работе с хэндлами приводят к предсказуемым падениям или отказу в обслуживании, но не позволяют атакующему произвольно манипулировать памятью.

Таким образом, арены сочетают гибкость ручного управления памятью с безопасностью Rust, делая их практичным выбором для сложных структур данных в критических кодовых базах, таких как компиляторы или игровые движки.

• Обсуждается сложность реализации двусвязных списков и циклических ссылок в Rust из-за системы владения, предлагаются решения через арены, weak pointers и изменения в языке.
• Поднимаются вопросы безопасности памяти: арены и handles могут предотвратить неопределённое поведение, но не исключают ошибки в пределах границ, что может привести к уязвимостям.
• Сравниваются подходы к управлению памятью: ручное управление через арены vs. сборка мусора, отмечаются компромиссы между производительностью, безопасностью и сложностью разработки.
• Высказываются мнения о месте Rust среди других языков: он конкурирует с C++ по производительности и безопасности, а с GC-языками — по простоте, но имеет крутую кривую обучения.
• Обсуждается необходимость и сложность добавления в Rust стабильного API для аллокаторов и других низкоуровневых возможностей для большей гибкости и контроля.

jacobly0 предлагает полностью переписать линкер Zig с нуля, создав Elf2 вместо текущей реализации. Основная цель — повысить производительность, уменьшить потребление памяти и улучшить поддержку различных форматов объектных файлов. Новая архитектура позволит эффективнее обрабатывать символы, секции и релокации, избегая проблем существующего кода.

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

• Участники высоко оценивают Zig как компилятор для C/C++ и инструмент кросс-компиляции за его простоту и самодостаточность.
• Отмечается мощная вертикально интегрированная система сборки Zig, включающая линкер и бэкенды генерации кода, что открывает возможности для оптимизаций.
• Обсуждаются ограничения использования линкера Zig (elf2) и самого компилятора вне экосистемы Zig, а также отсутствие неструктурированного goto.
• Некоторые пользователи выражают смешанные чувства: язык делает многое правильно, но отдельные изменения и особенности вызывают сомнения.
• Упоминается книга "Linkers and Loaders" и общее оживление в области разработки линкеров (ренессанс).

AI-кодинг: компилятор, а не магия

LLM — это компилятор: английский вместо C, выхлоп — код.
Работает лишь для тривиальных задач; чуть сложнее — приходится писать спецификации длиннее самого кода.
Английский не имеет спецификации, выхлоп недетерминирован, изменение в одном месте ломает всё.
Казаться быстрее на 20 %, реально медленнее на 19 % (arxiv.org/abs/2507.09089).

«ИИ заменит программистов» так же, как компиляторы заменили ассемблер и Excel — бухгалтеров: инструмент, а не чудо.
Миллиардные инвестиции в «vibe coding» — повторение провала self-driving.
Вместо хайпа стоит делать лучшие языки, компиляторы и библиотеки.

• Опытные разработчики спорят: кто-то экономит часы на рутине, кто-то теряет скорость из-за «зайцев» и недопонимания кода.
• AI-инструменты (автодополнение, Claude Code, Cursor) дают +20–50 % к старту, но требуют навыка «prompt-инженерии» и постоянного контроля.
• «Вайб-кодинг» без понимания архитектуры быстро даёт MVP, но приводит к техдолгу и невозможности поддержки.
• Независимые исследования пока не подтверждают значительного ускорения для сеньоров в сложных кодовых базах; выгода заметнее в шаблонных CRUD-задачах.
• Рынок и инвесторы толкают AI-хайп из-за страха пропустить «новое интернет», а не из-диоказанной эффективности.

LISP FROM NOTHING
344 стр., 2025, Lulu Press, 6"×9", 19 иллюстраций, код бесплатно.

Купить: мягкий переплёт | твёрдый | PDF
Исходники | Превью (PDF) | Опечатки | Видео-обзор

Книга исследует минимальный LISP, способный интерпретировать и компилировать себя, и показывает, каким был хакинг в эпоху перфокарт и мейнфреймов. Во втором издании добавлена глава о связи LISP с λ-исчислением, улучшены макросы и стиль.

Примеры кода

• Метациркулярный интерпретатор: CL, Scheme
• Компилятор (~400 строк): liscmp.lisp.html
• Система: lisp.lisp.html
• Сборщик мусора: gc.lisp.html

Весь код книги (~100 КБ)
λ-исчисление в Scheme (~6 КБ)
Генератор перфокарт Postscript
Обложка главы «Let There Be LISP»

• Читатели восторженно отзываются о сайте и книгах Нильса М. Хольма, называя их «личной поэзией» и «культурными артефактами», созданными ради самого процесса.
• Автор подтверждает: главное для него — красота и простота изложения, а не практическая польза или научная новизна.
• Покупатели жалуются на выбор: «хочется всё сразу», но автор советует начать с одной книги и прислал шпаргалку «какую выбрать».
• Обсуждаются входные требования: книга не для новичков; рекомендуют The Little Schemer, ANSI Common Lisp и A Gentle Introduction.
• Возник спор о названии «Lisp from Nothing» при пометке «не вводная книга»; автор уточняет, что «nothing» значит «с нуля», а не «для нулевых».

Go всё ещё плох

Кратко: автор 10+ лет критикует Go за архитектурные ошибки, которые легко было избежать.

1. Ошибки: неверная область видимости

bar, err := foo()
if err != nil { … }
if err = foo2(); err != nil { … }
// err висит до конца функции, хотя нужен только в двух строках

Читателю приходится тратить время, выясняя, где err ещё используется.

2. Два вида nil

var i interface{}
var s *S
fmt.Println(s == nil, i == nil, s == i) // true, true, false
i = s
fmt.Println(s == nil, i == nil, s == i) // true, false, true

Один «billion-dollar mistake» не хватило — сделали два.

3. Непереносимость

Условная компиляция через комментарии в начале файла — «аристотелевский» подход: теория без практики. Реальные проекты страдают.

4. append без чёткого владения

a := []string{"hello", "world", "!"}
foo(a[:1]) // внутри append
fmt.Println(a) // результат зависит от капасити слайса

Поведение неочевидно и требует знания внутренностей.

5. defer вместо RAII

В Java и Python ресурс закрывается автоматически при выходе из блока.
В Go приходится вручную писать defer foo.Close() и гадать, какие ресурсы вообще требуют закрытия.

• Go хвалят за простоту, быструю компиляцию, встроенные инструменты и удобную конкурентность.
• Критикуют «двойной nil», слабую систему типов, проблемы GC, неинтуитивный defer и скудные абстракции.
• Многие считают его «достаточно хорошим» для бэкендов и CLI-утилит, особенно при скорости разработки.
• Крупные проекты жалуются на «смерть тысячей порезов» и трудности отладки из-за строгости компилятора.
• Часть сообщества видит в Go компромисс между Node/Python и Rust, другие — устаревший язык без современных фич.