Hacker News Digest

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

В статье представлены два основных подхода к представлению эффектов: битовые множества и списки диапазонов кучи. Автор подробно разбирает пример компилятора Cinder (Python JIT), который использует битсет под названием AliasClass для отслеживания эффектов работы с кучей. Каждый бит в этом множестве представляет отдельное расположение в куче, а операции объединения и пересечения выполняются с помощью побитовых операций. Интересно, что этот подход аналогичен представлению решетки типов в Cinder, где каждый бит неявно представляет множество, а операции над множествами реализованы через битовые операции И и ИЛИ.

• Пользователи ожидали, что статья будет про эффект Манделы или уязвимости Spectre из-за заголовка.
• Один участник отметил, что теперь они случайно прочитали про компиляторы.
• Завершающий комментарий содержит шутку про "Men in Black" и изменение логотипа Fruit of the Loom.

• Комментарии разделены на два лагеря: одни считают, что статья — это личный пиар, другие — что она может быть полезна как ориентир для тех, кто хочет попробовать себя в этой области.
• Участники обсуждают, что вакансии в этой области редки, и что большинство компаний предпочитают нанимать специалистов по контракту, а не держать штатных сотрудников.
• Некоторые участники подчеркивают, что важно не только знание теории, но и практический опыт с LLVM, и что это может быть решающим фактором при найме.
• Обсуждается, что вместо того, чтобы писать статьи о "как стать компилятором", лучше было бы написать практическое руководство по созданию компилятора.
• Участники также обсуждают, что вместо того, чтобы писать статьи о "как стать компилятором", лучше было бы написать практическое руководство по созданию компилятора.

SPy — это интерпретатор и компилятор для статически типизированного варианта Python с фокусом на производительность. Важно понимать, что SPy не является компилятором для полного Python — по дизайну он не поддерживает все динамические возможности языка. Код SPy будет находиться в файлах с расширением *.spy для четкого отличия от обычного Python. Хотя проект находится в разработке и пока не готов для серьезного использования, уже существует пример трассировки лучей, работающий в 200 раз быстрее CPython. SPy стремится к тесной интеграции с экосистемой Python, позволяя импортировать Python-библиотеки и наоборот.

Существующие подходы к ускорению Python делятся на две категории: реализация "полного Python" с JIT-компиляторами (PyPy, GraalPy, Pyston) и создание "подмножества Python" (Cython, Numba). SPy позиционируется как мысленный эксперимент, направленный на определение того, сколько динамичности можно удалить из Python, сохранив его "питоничность". Автор подчеркивает, что большинство "компиляторов для Python" не поддерживают полный язык, даже если заявляют обратное, и предпочитает быть более открытым о ограничениях SPy.

• Обсуждение вращается вокруг того, что статически-типизированный подмножество Python (SPy) может быть полезным, но вызывает вопросы о совместимости, экосистеме и цели проекта.
• Участники обсуждают, что неясно, как SPy будет взаимодействовать с существующими библиотеками Python, и что это значит для пользователей.
• Также обсуждается, что статическая типизация может не подходить для всех задач, и что динамическая природа Python может быть важной для некоторых задач.
• Некоторые участники высказывают, что вместо того, чтобы создавать новый язык, было бы лучше улучшить существующие инструменты, такие как Cython или Numba.

Fil-C - реализация C и C++ с безопасной памятью, позволяющая существующему коду работать безопасно без изменений. Несмотря на молодость проекта и одного активного разработчика, Fil-C уже компилирует весь безопасный пользовательский Linux. Это форк Clang с лицензией Apache v2.0, который изначально был медленным, но после оптимизации работает всего в несколько раз медленнее оригинала. Тест с Bash показал практически незаметную разницу в производительности.

Основная сложность проекта - обработка указателей. Текущая реализация "InvisiCaps" разделяет указатели на доверенную "capability" и недоверенную "address" части, позволяя им соответствовать естественному размеру архитектуры. Для поддержки безопасности Fil-C использует другую внутреннюю ABI, чем Clang, что требует полной перекомпиляции проекта. При выделении объекта в куче Fil-C добавляет два слова метаданных для проверки границ доступа и хранения дополнительной информации о указателях.

• Fil-C — это компилятор C → C, добавляющий проверки безопасности памяти, но при этом оставляющий программы полностью совместимыми с существующим кодом и не требующий изменений в исходном коде.
• Проект разрабатывается в рамках Nix, что позволяет легко собирать любые пакеты с Fil-C, а также предоставляет кэш сборок.
• Обсуждение выявило, что Fil-C в первую очередь ориентирован на безопасность, а не на производительность, и что он не решает проблему безопасности в полном объеме, но является важным шагом вперед.
• Некоторые участники обсуждения выразили обеспокоенность по поводу того, что Fil-C может быть непрактичен из-за производительности, но другие отметили, что для некоторых приложений безопасность важнее производительности.

D2 — декларативный язык для создания диаграмм из текста. Пользователь описывает желаемую диаграмму простым текстом, а D2 автоматически генерирует визуальное представление. Например, создается файл input.d2 с текстовым описанием сети, после выполнения команды CLI получается готовая диаграмма с элементами вроде CELL TOWER, SATELLITE, TRANSMITTER и связями между ними.

Для работы доступны CLI с режимом отслеживания изменений и интерактивный Playground для экспериментов. Исходный код D2 и документации размещены на GitHub. Тур по основам занимает 5-10 минут, а краткое руководство "Hello World" — около 2 минут. Для каждого примера в документации есть возможность открыть код в Playground для тестирования.

• Обсуждение в основном вращается вокруг инструмента D2 и его места в экосистеме диаграмм-как-кода, включая сравнение с Mermaid, PlantUML и прочими.
• Участники обсуждают визуализацию изменений в графах, анимацию переходов между снапшотами и влияние на восприятие изменений.
• Упоминается, что D2 — это компилятор, а не просто синтаксический сахар, и что он может быть использован как библиотека или как CLI-утилита.
• Поднимается вопрос о цене и лицензии: TALA стоит $3000 в год, что вызывает споры о целесообразности такого подхода.
• Участники также обсуждают, как D2 сравнивается с другими инструментами в терминах синтаксиса, возможностей и удобства использования.

Разработчик представил Pasta80 - компилятор, совместимый с Turbo Pascal 3.0, который генерирует машинный код для классических и современных компьютеров на базе процессора Z80. Проект поддерживает ZX Spectrum 48K/128K/Next и системы с CP/M, позволяя современным программистам создавать приложения для ретро-платформ. Код компилятора написан на C++ и открыт под лицензией MIT.

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

• Обсуждение всплеснуло ностальгией по простым 8-битным процессорам и первым компиляторам, вспоминая, как трудно, но вдохновляюще было писать компиляторы для них.
• Участники делились личными историями о первых опытах с Pascal и C, отмечая, что ранние компиляторы были однопроходными и как это влияло на разработку.
• Всплеск воспоминаний привел к обсуждению того, как языки и компиляторы эволюционируют, и как это влияет на безопасность памяти и стабильность программ.
• Тонко подметили, что современные языки и инструменты, возможно, заставляют разработчиков быть менее внимательными к низкоуровневым деталям.
• В конце обсуждение свелось к тому, что хотя технологии и стали более сложными, но некоторые считают, что это может отдалить нас от основ и что важно сохранять хоть какое-то взаимодействие с этими основами, такими как архитектура Intel 8086 и идея однопроходной компиляции.

• Появление аппаратной поддержки тегирования памяти в x86-64 — это ответ на уже существующие технологии ARM64 (MTE) и Apple (MIE), а не новая идея.
• Технически это не более чем перенос существующих подходов на x86-64, но важно, что это может быть сделано опционально и не сломает существующий код.
• Поддержка тегирования памяти в x86-64 может быть реализована в виде набора инструкций, которые будут использоваться компилятором и стандартной библиотекой, чтобы обеспечить безопасность кода, написанного на C/C++.
• Это не решит проблему безопасности памяти в целом, но может помочь в обнаружении ошибок и предотвращении эксплойтов.

В Kotlin-компиляторе скрыта ошибка, срабатывающая при сборке проекта в турецкой локали. Из-за неё при попытке скомпилировать код в турецкой локали возникает ошибка парсинга XML от компилятора: строчка var category: CompilerMessageSeverity? = CATEGORIES[qName.toLowerCase()] в функции CompilerOutputParser некорректно обрабатывает турецкий символ I (U+0049), который при приведении к нижнему регистру становится не i (U+0069), а ı (U+0131) — точкой надстрочного i без точки. Из-за этого ключ i не находится в словаре CATEGORIES, и код ошибочно считает, что это неизвестный тег, и выдаёт сообщение об ошибке.

Ошибка скрывалась в коде с 2016 по 2021 год, пока не была обнаружена и исправлена. Теперь код корректно использует локально-независимый toLowerCase(Locale.ROOT), и проблема решена. Это яркий пример того, как тонкости локализации могут вызывать ошибки в интернационализированном ПО, особенно при обработке текста.

• Проблема "турецкое I" встречается везде, где не указывается локаль при работе со строками, и это приводит к багам, когда вместо "I" в турецкой локали превращается в "ı" (без точки) и наоборот.
• Современные языки и фреймворки должны предоставлять единообразные и предсказуемые API, но вместо этого они вынуждают разработчиков указывать локаль каждый раз, что приводит к ошибкам.
• Пользователи с турецкой локалью страдают от багов, которые не могут быть обнаружены автоматически, потому что большинство разработчиков тестируют только на английской локали.
• Это также является примером более широкой проблемы: API-функции, которые не принимают Locale параметр, вместо этого полагаясь на дефолтной локали, что может привести к ошибкам.

Ричард Столлман выступает против превращения GCC бэкенда в библиотеку, аргументируя это защитой свободного программного обеспечения. Он предупреждает, что компании неизменно стремятся сделать ПО несвободным, и некоторые создали бы несвободные дополнения к GCC, если бы им это позволили. Именно требование GPL заставило авторы фронтендов для C++ и Objective-C сделать их свободными, так как они не могли использовать их иначе. Столлман подчеркивает: "Все, что упрощает использование GCC бэкендов без фронтендов, ставит под угрозу наше влияние на то, чтобы новые фронтенды оставались свободными".

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

• Пропущенное предложение интегрировать LLVM в GCC стало ключевым событием в истории компиляторов, но оно было упущено из-за сбоя в почтовой переписке.
• Это стало причиной того, что LLVM вместо того, чтобы стать частью GCC, стал основой для большинства новых языков и проектов.
• Парадокс в том, что GCC и LLVM сегодня по сути предлагают одинаковую производительность, но LLVM лицензирован более свободно, что способствует его популярности.
• В то же время, GCC остаётся под GPL, что отталкивает некоторых разработчиков, которые не хотят, чтобы их код был связан с GPL.
• В конечном счёте, это привело к тому, что LLVM стал основой для большинства новых языков программирования, в то время как GCC медленно движется к облесению.

Cloudflare столкнулся с редким, но критичным багом в компиляторе Go для ARM64: при раскрутке стека может возникнуть race condition, что приводит к фатальному панику. Подробный разбор показал, что проблема в том, что компилятор неправильно генерирует барьер-инструкции, необходимые для безопасной работы с памятью. Это подтверждено исследованием исходников Go и ARM-мануалов. В итоге Cloudflare не только предоставила подробный отчет и тест-кейс в апстрим, но и предложила временное решение, которое уже встроено в их инфраструктуру и позволяет избежать проблемы до официального патча.

• Компилятор Go имел баг, из-за которого при определённом сочетании инструкций в ARM64-версии Go могла прерваться сборка мусора, что приводило к нестабильности. Исправление уже в коммите f7cc1e5 и войдёт в Go 1.20.
• Обсуждение подняло вопрос о том, насколько редки такие баги компиляторов в наши дни и какие факторы этому способствуют.
• Некоторые комментаторы поделились историями о том, как в прошлом им приходилось сталкиваться с багами компиляторами даже в таких "безопасных" языках как Go.
• Обсуждение также затронуло вопрос о том, насколько критично было быстрое обновление, и было отмечено, что Cloudflare уже использует ARM-серверы в продакшене.

Виртуальная машина для языка Scheme реализована на C с использованием кучи для хранения пар. Основана на модели из работы Дабвига «Three Implementation Models for Scheme», что делает её компактным учебным примером интерпретатора Lisp-подобных языков.

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

• Обсуждение производительности и особенностей различных реализаций Scheme, включая Chez Scheme, MIT Scheme и другие.
• Упоминание роли Кента Дибвига как создателя Chez Scheme и его влияния как преподавателя и исследователя.
• Вопросы о технических деталях и возможных ошибках в представленном коде, включая проблемы с указателями и порядком вычислений.
• Идеи о бутстраппинге компиляторов и интерпретаторов, включая использование LLM для генерации ассемблерного кода.
• Общие положительные отзывы о минималистичных и элегантных реализациях Scheme, таких как обсуждаемый код.

В репозитории представлено детальное сравнение решений Advent of Code 2023, где анализируются подходы к решению задач, эффективность кода и производительность. Основное внимание уделено различиям в алгоритмах и структурах данных, используемых участниками, а также их влиянию на время выполнения и потребление памяти.

Приводятся конкретные примеры кода на разных языках программирования, демонстрирующие оптимизации и trade-offs. Упоминаются ключевые инсайты, такие как важность выбора правильных структур данных для сокращения сложности алгоритмов. Это полезно для разработчиков, стремящихся улучшить свои навыки решения алгоритмических задач.

• Участники отмечают сильные стороны Ada, такие как ограниченные числовые типы для предотвращения ошибок, выразительная система типов и удобочитаемость, но сожалеют о его недостаточном распространении вне сообщества safety-critical разработки.
• Rust ценится за безопасность памяти, фокус на надежности и растущую экосистему, но критикуется за отсутствие формальной спецификации (хотя она сейчас разрабатывается) и сложность с компилятором и асинхронностью.
• Поднимаются вопросы о различиях в подходах к строкам (Ada использует массивы символов, Rust — UTF-8), многопоточности (встроенные потоки vs. async) и индексации массивов (произвольные типы в Ada vs. словари в Rust).
• Обсуждаются практические аспекты: скорость компиляции, поддержка Unicode, необходимость спецификаций и влияние экосистемы (инструменты, библиотеки) на выбор языка.
• Упоминаются нишевые применения Ada (например, в 3D-печати) и потенциальные заимствования его функций (ограниченные типы) в другие языки, такие как Rust, C++ и Nim.

Разработан экспериментальный компилятор Scheme в WebAssembly, который автор сам называет «очень плохим» и минималистичным. Он написан преимущественно на C (97.2%) и способен преобразовывать код Scheme в валидный WASM-модуль, который затем можно запускать через Wasmtime.

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

• Упомянуты проекты на WebAssembly: минимальный OOP рантайм, Forth, компилятор в твите и книга о WebAssembly.
• Обсуждается компилятор Scheme в WebAssembly (Guile Hoot), его особенности и поддержка WASM-GC.
• Затронуты технические вопросы: возможность использования как интерпретатора, поддержка tail call и call/cc.
• Отмечается важность самодостаточных инструментов и независимости от платформ.
• Поднята тема различий между Asm.js и WebAssembly в контексте исторического развития.

Zig предлагает более простой подход к созданию CLI-инструментов по сравнению с Rust, особенно когда речь идёт о работе с памятью. В Rust строгий borrow checker предотвращает ошибки на этапе компиляции, но часто вынуждает переписывать код под его требования, усложняя разработку. Например, при попытке добавить новую запись в список, одновременно удерживая ссылки на существующие, компилятор Rust блокирует действие из-за конфликта владения и заимствования.

В Zig же разработчик напрямую управляет памятью через аллокаторы, используя указатели и мутацию без сложных правил времён жизни. Это требует дисциплины, но даёт больше гибкости и скорости написания кода. Для CLI-инструментов, где производительность и простота часто важнее абсолютной безопасности памяти, Zig оказывается практичнее. Безопасность — это не только отсутствие ошибок памяти, но и читаемость, скорость разработки и соответствие задаче.

• Обсуждение затрагивает проблемы безопасности в C, связанные с ручным управлением памятью, и ироничные комментарии по этому поводу.
• Пользователи делятся мнениями о современных языках (Nim, Odin, V, D, Zig), отмечая их преимущества, такие как интероперабельность с C и гибкость в управлении памятью.
• Уточняется функциональность Zig: он не компилируется в C, но имеет инструмент для трансляции C-кода в Zig, при этом компилируясь напрямую в машинный код.
• В обсуждении присутствует юмористический тон относительно утверждения, что разработчики не являются идиотами.

Fil-C — это C/C++-совместимый язык с безопасной памятью и современным инструментарием. Его сердце — FUGC, параллельный, конкурентный, точный, неперемещающий сборщик мусора.

Ключевые черты FUGC

• Параллельность: маркировка и очистка выполняются на всех ядрах.
• Конкурентность: потоки-мутаторы не останавливаются; блокировки только на медленных путях аллокации.
• On-the-fly: нет глобальной паузы; «мягкие рукопожатия» просят потоки асинхронно сканировать стек.
• Grey-stack: повторное сканирование стеков до фикс-поинта; барьер только при записи, быстрая сходимость.
• Dijkstra-barrier: при записи указателя объект помечается CAS-relaxed.
• Точность: LLVM-плагин FilPizlonator точно знает, где все указатели.
• Неперемещаемость: объекты не двигаются; освобождённые блоки «перенаправляются» через InvisiCap.

Safepoint-механизм

• Компилятор вставляет pollcheck: быстрая проверка или колбэк для GC.
• «Мягкое рукопожатие» запускает колбэк на всех потоках.
• Состояния enter/exit позволяют блокироваться в syscall без pollcheck’ов; GC сам выполняет колбэк для «exited» потоков.
• Safepoint защищает от гонок: загруженный указатель будет жив до следующего safepoint’а.

По желанию можно включить полный stop-the-world (FUGC_STW=1) для fork(2) или отладки.

• Fil-C — это С-компилятор с точным параллельным GC (FUGC) и capability-указателями, позволяющий запускать «как есть» CPython, SQLite, OpenSSH и др., теряя в худшем случае 4× производительности.
• Вместо ручного free и UB-оптимизаций LLVM код живёт под барьером Дейкстры и soft-handshake safepoint’ами; указатели превращаются в «InvisiCap» (base+offset), теряющие силу при приведении к integer.
• Проект исследовательский, но уже промышленно полезен: нет сборок под 32-бит, Windows и embedded без MMU, нет пока поколенческого GC и ARM/RISC-V.
• Споры: «lock-and-key» предсказуемее RAM, но требует атомиков; GC = «мусор потом» vs compile-time проверки; можно ли дождаться AI-стат-анализа вместо Rust-переписей.

V как Go с шоколадкой
Go — это ваниль: просто, быстро, без фанатизма. V же — «ваниль++»: тот же вкус, но сверху посыпка из фич.

Карты

langs := {"elixir": {"score": 100}}
score := langs["elixir"]["score"] or { -1 }

Фиксированные типы, or {} вместо if err != nil, spread-оператор ... для слияния.

Структуры

struct Language {
pub mut:
    score int = -1
    name  string @[required]
}

Методы можно вешать прямо на массивы, поля можно помечать @[required], дефолты и флаги CLI задаются в одном месте.

WithOption

fn new_server(opts ServerOptions) ! { ... }

Встроенный «функциональный» паттерн: new_server(port: 8080, debug: true).

Enum и лямбды

Enum’ы есть, лямбды короткие: nums.filter(it % 2 == 0).

Подводные камни

• net.http пока не дотягивает до Go.
• veb (веб-фреймворк) сырой.
• Сборка сложнее: нужен v и C-компилятор.
• Параллелизм есть, но экосистема молода.

Итог

V — это Go с синтаксическим сахаром и парой острых углов. Для экспериментов — огонь, для продакшена — пока нет.

• Участники спорят, действительно ли V лучше Go: одни отмечают быструю компиляцию и «красивые» фичи, другие — нестабильность компилятора и отсутствие надёжности.
• Поддерживающие Go указывают на его зрелость, стабильность GC, удобство кросс-компиляции и отказ от «лишнего».
• Сторонники V хвалят синтаксис (const по умолчанию, sum types, простой С-интерфейс), но признают, что язык пока «сырой».
• Некоторые считают V «предупреждением» о том, почему Go часто говорит «нет» новым возможностям.
• Есть мнение, что ни Go, ни V не решают задачу «лёгкого C для приложений»; предлагают смотреть на Zig или Free Pascal.

Как заменить код функции «на лету»

Python позволяет переписывать тело функции во время работы программы:

1. Берём исходник новой функции как строку.

   new_src = "def f(x): return x * 2"
   

2. Компилируем:

   code = compile(new_src, "<magic>", "exec")
   

3. Выполняем в нужном пространстве имён:

   ns = {}
   exec(code, {}, ns)
   

4. Подменяем старую функцию:

   f = ns["f"]
   

f(21) теперь возвращает 42.

Зачем это нужно

Такой трюк позволяет LLM-агентам генерировать и сразу запускать код с доступом к текущему контексту. Это удобно для ToolBot, но открывает огромную дыру в безопасности: любой сгенерированный код получает доступ ко всем переменным процесса.

• @breuleux показал jurigged — библиотеку для горячей перезагрузки только изменённых функций без перезапуска модулей.
• Участники сравнили приём с monkey-patching, Lisp-овой «код как данные» и REPL, отметив плюсы и отладочные грабли (стек-трейсы вида <magic>).
• Обсуждали, где ещё работает такое: JVM/CLR, Erlang, динамические библиотеки в C/C++ и игровые движки.
• Кто-то считает это мощным, кто-то — анти-паттерном; всплыли ссылки на autoreload, forge и swanky-python.
• Наконец, всех достала навязчивая привязка любой темы к AI-хайпу.

Как я ускорил Ruby до скорости Ruby

P2 — новая библиотека шаблонов, где HTML описывается чистым Ruby. В отличие от ERB, исходный код шаблона не исполняется: он компилируется в эффективный Ruby-код, который генерирует HTML. Это делает P2 первой библиотекой, использующей компиляцию исключительно.

Как работает компиляция

Шаблон — это Proc:

->(title:) {
  html { body { h1 title } }
}.render(title: 'Hi')

При вызове #render код превращается в:

->(buf, title) {
  buf << "<html><body><h1>"
  buf << ERB::Escape.html_escape(title.to_s)
  buf << "</h1></body></html>"
  buf
}

1. Парсинг: Sirop читает файл и строит AST через Prism.
2. Трансформация: TagTranslator заменяет CallNode на TagNode, если вызов соответствует HTML-тегу без получателя.
3. Обратный код: подкласс Sourcifier преобразует AST обратно в Ruby, подставляя строки буфера и экранирование.

Оптимизация

Jean Boussier указал узкие места и направления. В результате генерация стала заметно быстрее «чистого» Ruby.

• Автор создал альтернативу ERB, ускорил её до сопоставимой скорости, но, по мнению @swombat, выводит ошибочное заключение.
• @ciconia (автор) спорит: производительность Ruby важна, его системы выдают >1K RPS.
• @barrkel: Ruby медленнее, но быстрее Python; у каждого свои пути к скорости.
• @Alifatisk: сравнивать Ruby с Rust бессмысленно — языки для разных задач.
• Остальные комментарии свелись к старому мему «yo dawg».

Коллега нашёл в ARM-дизассемблере кучу «лишних» инструкций d4d4 (bmi #-0x58), которые никогда не выполняются.

Минимальный пример:

00020100 <one>:
   20100: 4770  bx lr
   20102: d4d4  bmi …

bx lr возвращает из функции, так что d4d4 недостижима.
Мысль: выравнивание? Thumb-команды 16-битные, но компилятор не выравнивает функции на 32 бита.

Добавляем вторую функцию — d4d4 исчезает.
Третья — d4d4 снова появляется, но только после последней функции.

Смотрим объектный файл: компилятор d4d4 не вставляет. Значит, линковщик lld добивает секцию до 32-битной границы именно этой командой.
Меняем порядок файлов — «лишняя» инструкция перемещается в начало следующего модуля, подтверждая гипотезу.

GNU ld вместо d4d4 ставит нули.

• Коммит 2017 года в OpenBSD закладывал «trapsleds» — заполнение «дырок» в исполняемых секциях инструкциями-ловушками (trap), чтобы сорвать NOP-sled-эксплойты.
• На ARM32/Thumb ожидалось 0xD4 (BRK) или 0xBE (BKPT), но в режиме Thumb та же последовательность байтов декодируется как условный переход назад, превращая «ловушку» в потенциальный ROP-гаджет.
• Это делает защиту нерабочей на Cortex-M (только Thumb), что участники признают ошибкой/«сломанной» митигацией.
• Некоторые считают, что описание механизма в коммит-сообщении достаточно, другие требуют комментариев в коде, чтобы избежать подобных недоразумений.

Краткий обзор

• Проблема: компилятор Solidity (solc) падает на Ubuntu 22.04 при компиляции корректного кода.
• Причина: сочетание трёх факторов
  1. 12-летний баг G++ (< 14) в разрешении перегрузок.
  2. Устаревший паттерн сравнения в Boost.
  3. Новые правила симметричных сравнений C++20.

Цепочка событий

1. Баг G++ (2012, GCC-53499): при boost::rational<T> == 0 компилятор до 14-й версии выбирает нечлен-шаблон вместо член-шаблона.
2. C++20 добавляет автоматическую перестановку аргументов: 0 == rational<T> → rational<T> == 0.
3. Boost 1.74 предоставляет обе версии оператора, что приводит к бесконечной рекурсии и переполнению стека.

Минимальный пример

template<typename T>
struct rational {
    template<class U>
    bool operator==(const U&) const { return true; }
};

template<class U, class T>
bool operator==(const rational<T>&, const U&) { return false; }

int main() {
    rational<int> r;
    return r == 0;   // g++11 выбирает free-функцию
}

Как починить

• Обновить GCC ≥ 14 или Clang, или
• Собрать Solidity без C++20 (-std=c++17), или
• Патч Boost/использовать свежий Boost ≥ 1.82.

Итог
Ни один компонент по отдельности не «сломан», но их комбинация приводит к крашу компилятора на валидном коде.

• 12-летний баг разрешения перегрузок в GCC + новый оператор <=> C++20 = краш компилятора Solidity.
• Проблема в том, что «каждый компонент по отдельности не сломан», но вместе дают сбой.
• Участники обвиняют чрезмерную сложность C++, отсутствие тестов при обновлении стандарта и «бесконечные надстройки» вроде spaceship-оператора.
• Кто-то предлагает «python2to3-момент» для C++, другие считают смарт-контракты плохой идеей из-за неизбежных багов.
• Лицензия SPDX в примере вызывает вопросы, но Solidity требует её наличие, иначе ошибка компиляции.

Переписал Ghuloum-туториал на Python (~300 строк). Убрал читалку S-выражений и бинарный код — теперь текстовая ассемблерная печать.

Lambda-lifting требует:

• знать связанные переменные;
• собирать свободные переменные лямбд;
• накапливать создаваемые code-объекты.

Связывают let и lambda; для них обновляем окружение.

Lifter

class LambdaConverter:
    def __init__(self):
        self.labels = {}

    def convert(self, expr, bound, free):
        match expr:
            case int() | Char() | bool():
                return expr
            case str() if expr in bound or expr in BUILTINS:
                return expr
            case str():
                free.add(expr)
                return expr
            case ["if", t, c, a]:
                return ["if",
                        self.convert(t, bound, free),
                        self.convert(c, bound, free),
                        self.convert(a, bound, free)]

lift_lambdas запускает обход и возвращает (labels …).

Lambda

Лямбда:

• связывает параметры;
• выделяет код;
• захватывает внешнее окружение.

Пример:

(lambda () x)  ; x свободна

превращается в

(labels ((f0 (code () (x) x)))
  (closure f0 x))

Даже если x связан снаружи, внутри лямбды он считается свободным.

• Участники рекомендуют три современные книги по компиляторам, вдохновлённые статьёй Ghuloum: «Writing a C Compiler» (Sandler), «Essentials of Compilation» на Racket и Python (Siek).
• Обсуждали «lambda lifting»: преобразование, выносящее замыкания наверх, уменьшая их размер вплоть до полного исчезновения.
• Уточнили, что «lambda lifting» в статье связан с разделом 3.11 о сложных константах в Scheme.
• Разбирали, почему современный ИИ использует Python, а не Lisp: удобство как «клея» для C++/CUDA, упадок доли рынка Lisp и смена парадигмы ИИ.

• Исправления

  • Уточнено сообщение об ошибке с некорректной терминологией. (Louis Pilfold)
  • JS: устранён сбой при использовании echo в модуле с функцией process. (Peter Saxton)
  • Форматер: не переносит комментарий перед assert за него; корректно форматирует сообщения после echo/panic/todo/assert/let assert с комментарием перед ними; компилятор не генерирует неверный код для assert с пайпами на JS. (Giacomo Cavalieri)

• Форматирование битовых массивов

  • Трейлинг-Запятая управляет разбиением: с запятой — много строк; без — в одну строку.
  • Если несколько сегментов на строке и убрана завершающая запятая, форматер сохраняет сегменты по одному на строку. (Giacomo Cavalieri)

• Компилятор и генерация кода

  • echo поддерживает пользовательское сообщение: echo 11 as "lucky number" печатает контекст и значение в stderr. (Giacomo Cavalieri)
  • В сгенерированном JS doc-комментарии превращаются в JSDoc. (Giacomo Cavalieri)
  • Уменьшен размер кода case на JS. (Surya Rose)
  • Удаление неиспользуемого кода на этапе генерации (usage-based DCE). (Louis Pilfold)
  • Улучшена поддержка echo для списков символов, ошибок и циклических ссылок JS. (Louis Pilfold)
  • Улучшен внешний вид ошибок и предупреждений: контекстные метки выделяются иначе, чем источник проблемы. (Giacomo Cavalieri)
  • Подсказка при импорте с точкой вместо слеша, с примерами корректного синтаксиса. (Zij-IT)
  • Предупреждение при затенении импортированного имени верхнеуровневой константой/функцией. (Aayush Tripathi)
  • Улучшено сообщение об неизвестной переменной, если, вероятно, имелась в виду проигнорированная (_x → x), с подсказкой. (Giacomo Cavalieri)
  • Оптимизирован матчинг-паттернов на JS.

• Обсуждение посвящено релизу Gleam: многие хвалят дизайн языка, читаемость, статическую типизацию и паттерн-матчинг; приводят пример кода и делятся позитивным опытом использования в проектах.
• Есть ссылки на пост о версии 1.12.0 и доклад на YouTube; некоторые ждут дальнейшего созревания экосистемы и возможности шаринга кода между фронтендом и бэкендом.
• Критика: отсутствие интерфейсов/тайпклассов и оператора композиции; кому-то синтаксис и «Error -> Error» кажутся неэлегантными; snake_case непривычен после TypeScript.
• В ответ отмечают осознанную простоту языка и официальную позицию Gleam по отказу от тайпклассов.
• Существенная часть треда уходит в спор о «идеологичном» футере сайта (инклюзивность, антинацистская позиция, права транс-людей): часть считает это лишним, другие — важным для безопасности и качества сообщества.
• Подчеркивается, что Gleam — это не только язык, но и сообщество с явным кодексом поведения; отсутствие позиции тоже является позицией.
• Некоторые участники призывают вернуться к техническим темам релиза, чтобы не повторять одни и те же дискуссии.

A really good accompaniment to this is Carruth's "C++, bounds checking, performance, and compilers" [1]:> ... strong belief that bounds checks couldn’t realistically be made cheap enough to enable by default. However, so far they are looking very affordable. From the above post,