Hacker News Digest

В Rust обнаружена ошибка типа P-high, позволяющая обойти требования времени жизни полей структуры через ковариантное присваивание. Суть в том, что компилятор некорректно проверяет владение ссылками, помещёнными в обёртку, которая затем хранится в статическом контейнере.

В примере структура Q<T> хранит опциональную ссылку и при уничтожении переносит её в глобальный Mutex<Vec<Box<dyn Any + Send>>>. В main ссылка на локальную строку l присваивается полю q.0, область видимости l завершается, но q уничтожается позже — в момент выхода из блока. Поскольку Q объявлен как Send и 'static, компилятор считает ссылку валидной всё время жизни программы. В результате в статическом векторе оказывается ссылка на уже уничтоженную строку, которую можно безопасно привести к &'static String и распечатать.

Ошибка существует уже 11 лет и не имеет статуса P-critical исключительно из-за её давности — за это время она не была найдена в реальной практике. Для эксплуатации требуется намеренно вредоносная реализация Drop, поэтому случайная утечка памяти маловероятна. При включённом AddressSanitizer программа завершается с ошибкой stack-use-after-scope. Исправление входит в приоритетную программу Types Team по устранению некорректности системы типов.

Найденный баг — ошибка компилятора, а не типовой системы. Его исправление требует добавления проверки, но может сломать существующие библиотеки из-за простого репродуктора. В репозитории Rust более ста открытых проблем с несогласованностью; новый решатель трейтов обещает упростить их исправление. AI‐поиск ускоряет обнаружение таких багов, но полная надёжность недостижима из‐за неизбежных компромиссов и постоянного добавления новых функций. Редкое использование вариантных линтов позволяет ошибкам оставаться незамеченными годами, даже при обширном тестировании. Разработчикам рекомендуется проверить зависимости на наличие аналогичных паттернов перед применением фикса. AI‐поддерживаемый поиск в коде компилятора Rust приближает язык к формальной верификации, но не гарантирует отсутствия скрытых багов.

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

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

AI — инструмент, требующий новых навыков: умения формулировать запросы, проверять выводы и учитывать ограничения модели, а не глубоких технических знаний. Большинство комментаторов согласны, что ключевая компетенция — правильно задавать запросы и верифицировать ответы, а не знание кода. Существуют разногласия: jgord опасается, что быстрый рост AI приведёт к длительному падению когнитивных способностей; extr считает, что навыки prompt‐инжиниринга устарели, важнее знать, что спрашивать. Дzink и girvo советуют использовать AI как вспомогательный инструмент, но обязательно проверять выводы, учитывать ограничения контекста и стоимость запросов. Mosesman и vanuatu подчёркивают, что без опыта верификации и понимания ограничений модели нельзя полностью полагаться на её ответы — сравнивают это с использованием пилы без навыков. Whatever1 утверждает, что навыки разработки почти избыточны из‐за мощных запросов, однако schlack8 и strangescript указывают, что даже простые запросы требуют повторных уточнений и контроля. Shoebilyas_hanz отмечает, что AI ускоряет рутинные задачи, но при масштабировании проектов нужен опытный инженер для обеспечения надёжности. Bodge5000 замечает, что инвестиции направлены в замену человеческого труда AI, а не в обучение сотрудников работать с ним, вызывая опасения за будущие роли.

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

Человек не может существовать как изолированный интеллектуал — мы устроены так, чтобы вдохновляться и вносить вклад в общее. Даже если мотивация «чистая» и внутренняя, она не выживает без социального контекста. Когда AI берёт на себя всё: написание статей, доказательства теорем, обучение — исчезает не только ценность труда, но и сама потребность в нём. Будущее — не улучшенная интеллектуальная жизнь, а пустота: отдельные личности, живущие в своих садах, но без бazaar, где можно обменяться мыслями.

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

За последние два месяца компилятор Rust стал значительно быстрее: среднее время компиляции снизилось на 4,57%, при этом 555 из 629 бенчмарков улучшились, а только 74 ухудшились — многие показали двузначный процент роста производительности. Ключевые улучшения включают оптимизацию rustdoc от Ноя Лева, включение PGO для Clippy (до 18% ускорения в лучшем случае) и обновление LLVM до версии 23, которое дало среднее улучшение на 1,2% за один PR.

Одновременно были включены экспериментальные компоненты — новый заимствование-проверяющий Polonius Alpha и новый решатель trait’ов Pineapple Häagen-Dazs — которые, будучи более точными, увеличивают нагрузку в некоторых случаях (например, для crate serde), но их регрессии компенсируются общим прогрессом. Джек Хью уменьшил нагрузку Polonius через ленивые вычисления живучести и оптимизацию структур данных, а Яна Дёнцелманн работает над производительностью нового решателя. Кроме того, массовый приток PR с улучшениями привёл к созданию «rollup»-слияний — например, одного с 10 PR — чтобы не задерживать прогресс из-за ограничений CI, при этом каждый эффект проверяется постфактум через бенчмарк-сuiten. Автор поста скоро присоединится к Hexcat для работы над целью оптимизации производительности компилятора Rust на 2026 год.

Компиляция Rust остаётся узким местом при масштабных параллельных нагрузках, особенно без кэша. Сообщество предлагает практические решения: настройка sccache или kache для кеширования артефактов, использование инструментов вроде mbx для управления инкрементальной компиляцией, разделение тяжёлых crate‐ов на меньшие модули для повышения параллелизма, включение глобального блокировщика сборки (cargo wrapper) для избежания конкуренции за CPU (ускорение до 300 %), а также использование альтернативных линкеров (lld, mold) и инкрементальной линковки для ускорения линковки. Анонсированы будущие улучшения компилятора: раннее эмитирование метаданных (до 40 % ускорения wall‐time, требует доработки обработки ошибок), параллельный фронтенд и TPDE. Основные причины медленной компиляции — макросы, мономорфизация и кодогенерация в LLVM; переход на Cranelift может ускорить dev‐сборки, но пока не готов для продакшна. Некоторые пользователи переходят на Go из‐за текущих задержек, утверждая, что даже с кешем и модульностью Rust медленнее; другие считают, что правильная архитектура проекта устраняет проблему.

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.

В 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 параметр, вместо этого полагаясь на дефолтной локали, что может привести к ошибкам.

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

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

В репозитории представлено детальное сравнение решений 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.

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-переписей.