Google опубликовал руководство по стилю Rust — часть серии открытых стайлгайдов. Документ опирается на публичные правила оформления Rust и требует применять правила проектирования API с учётом контекста. Среди ключевых требований: предпочитать небольшие крейты, использовать плоскую структуру файлов для исходников rust_library, называть файлы и листовые модули по главному пользовательскому элементу, не реализовывать API в нелистовых модулях, избегать глобальных импортов через * и импортировать элементы одного модуля одним выражением use. Имена типов импортируются и используются без квалификации, а вызовы функций верхнего уровня — с именем модуля.

Отдельные разделы посвящены владению и заимствованию: рекомендуется избегать Rc и Arc, предпочитать заимствования глубоким копиям. Для входных и выходных параметров советуют принимать гибкие ссылки на неизменяемые данные, выбирать между итераторами и коллекциями осознанно, использовать Into, а также предпочитать enum вместо bool в API. Запрещён вызов panic::catch_unwind — исключение сделано лишь для защиты в глубину там, где код и так избегает паник, и только при panic=unwind; Chrome, Android и Fuchsia требуют panic=abort. Для конкатенации и подстановки строк предпочтительны format! и write! вместо + и str::replace. Тесты следует писать в рамках фреймворка конкретной кодовой базы: в Chrome — rust_gtest_interop, в Fuchsia — #[fuchsia::test].

В Chromium небольшие крейты ускоряют компиляцию и упрощают построение графа зависимостей, так как позволяют эффективнее использовать параллельность сборки. В Blaze/Bazel отсутствует инкрементальная компиляция крейтов, поэтому разделение кода на мелкие библиотеки ускоряет кеширование и пересборку измененных частей, а также уменьшает нелокальные эффекты при добавлении зависимостей в монорепозитории. При этом не следует путать мелкие крейты с микрофункциями. Рекомендации по коду: — использовать `#[non_exhaustive]` только для публичных `enum` с ожидаемыми новыми вариантами (хотя ведутся споры, не ослабляет ли это гарантии компилятора); — применять неквалифицированные имена импортов только для широко известных типов (например, `HashMap`), сохраняя полные пути для остальных; — использовать `Arc` или `Rc` вместо сложных жизненных времен, если ссылка живет дольше стека вызовов; — добавлять атрибут `#[rust_analyzer::prefer_underscore_import]` для расширяющих трейтов; — писать шестнадцатеричные литералы в нижнем регистре. Особенности и споры: — Запрет на `async/.await` в Chromium соответствует политике проекта и рекомендациям Rust for Linux. — Создание единого гайдлайна Google по Rust полезно для согласованности кода, настройки `fmt` и `clippy`, хотя есть мнение, что стиль-гайды сейчас нужны скорее для LLM, чем для людей. — Сохраняются разногласия о целесообразности геттеров и сеттеров.

Автор архивирует исходный код своих Ruby-библиотек, чтобы ясно показать: он больше не работает над ними. Причина — смена самой природы сообщества Ruby. Юкихиро Мацумото, создатель языка, в 2000 году писал, что цель жизни — радость, а программисты чувствуют её, когда могут сосредоточиться на творчестве, поэтому Ruby создавался, чтобы делать программистов счастливыми. В интервью 2019 года он повторял: «Я проектировал Ruby для людей, а не для машин». Именно в ту эпоху, когда язык был ради радости и людей, автор и написал свои библиотеки.

Теперь, по его мнению, эта эпоха прошла. Главное применение Ruby — веб-фреймворк Rails, который, будучи открытым, контролируется человеком, чьи взгляды автор считает отвратительными; есть попытки сделать форк. Судя по докладу на Rails World, этот человек уже не особенно интересуется ни Ruby, ни Rails, ни программированием: он генерирует приложения на Rust с помощью агентов на базе больших языковых моделей и даже не смотрит на результат. Сам язык Ruby теперь существенно развивается с помощью таких агентов, а Мацумото продвигает его как «язык программирования для эпохи ИИ», который должны порождать модели, для чего им нужно поглощать больше хорошего кода, написанного людьми.

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

Реакции на автоматизацию кода разделились. Большинство считает, что LLM убивают радость от программирования и разрушают взаимодействие в открытых проектах, что ведет к утечке талантов и дестабилизации экосистем. В сообществе Ruby это проявляется в росте числа уходящих из профессии разработчиков. Другие видят в AI полезного помощника, который освобождает от рутины для решения сложных задач. Рекомендуют использовать его как «24/7 junior engineer» при строгом контроле кода или для автоматизации (например, в переводах). Отмечаются проблемы с поддержкой open source: отсутствие обратной связи от мейнтейнеров вызывает разочарование, из-за чего некоторые советуют архивировать репозитории. Также существует риск роста «vendored forks» из-за AI-кода, что может усложнить совместимость и привести к коллапсу инфраструктуры.

Cloudflare и VoidZero совместно с Максом Швенком из Owner.com работают над tsrs — портом компилятора TypeScript на Rust, который развивается в составе инструментальной цепочки Oxc. Это не форк: команда TypeScript сохраняет полный контроль над языком, а порт обязан строго следовать её решениям, иначе со временем станет несовместимым. Ранние замеры обещают до 8 раз большей скорости и примерно на 70% меньше памяти по сравнению с TypeScript 7.0 при том же числе обработчиков проверки типов. При этом TypeScript 7.1 beta уже до 2.5 раз быстрее 7.0, и часть оптимизаций пришла из tsrs.

Попробовать экспериментальную версию можно через npm install tsrs и npx tsrs. Rust выбран не только ради скорости: важна и сборка в WebAssembly, что упрощает запуск полноценной среды разработки прямо в браузере. По умолчанию tsrs использует адаптивную конфигурацию, зависящую от типа машины: она потребляет больше памяти, но работает ещё быстрее. Авторы подчёркивают, что раньше масштабные порты почти не удавались, а теперь передовые ИИ-модели способны выполнять их за считанные дни.

Процесс сопровождается автоматикой: агенты ежедневно проверяют изменения, собирают диффы и заводят задачи, а ночью прогоняют тесты Next.js против Vinext, выявляя расхождения. Тот же подход применят к TypeScript, стараясь не вносить отличий в поведение и возвращая улучшения производительности в кодовую базу TypeScript на Go. Пока есть расхождения, например порядок вывода диагностик, но к стабильному релизу их сведут к минимуму. В планах — более глубокая интеграция tsrs в стек Cloudflare, в том числе для типозависимых правил линтера в Oxlint.

tsrs демонстрирует до 8-кратный рост скорости и снижение потребления памяти на ~70%. Эти показатели достигнуты не только за счет Rust, но и благодаря алгоритмическим оптимизациям, которые планируют перенести в TypeScript 7.1. Основным драйвером порта стала необходимость легкого компилятора для WASM-песочницы, где Rust предпочтительнее тяжелого Go-runtime. При этом арена-модель памяти в tsrs вызывает опасения, так как скрывает unsafe-код и может быть небезопасной. Также отмечается, что AI-генерация порта ускоряет разработку, но требует тщательного ревью из-за риска архитектурных ошибок. tsrs хорошо масштабируется при многопоточном запуске и поддерживает инкрементные проверки, хотя bun остается эффективнее по общим метрикам.

DeepSeek выпустила обновление DeepSeek-V4.1-Flash-1017 — минорную версию модели DeepSeek-V4.1-Flash, которая заметно улучшает рассуждения, написание кода, агентные задачи и визуальные бенчмарки. Одновременно модель сокращает время выполнения задач и длину вывода, что снижает стоимость и продвигает границу Парето «производительность–цена» сразу в нескольких агентных средах. Веса и репозиторий распространяются под лицензией MIT.

Ключевые цифры: на Terminal-Bench 4.0 результат вырос с 31,2 до 42,3, на ProgramBench — с 20,3 до 29,1, на Apex Bench v1.1 — с 64,6 до 72,1, на Automation-Bench v1.0.6 — с 54,8 до 60,5. На HLE без инструментов — 42,6 (44,0 для текстового подмножества), на DeepSWE v1.1 — 77,0, на NL2Repo-Bench — 68,2, на Agents' Last Exam — 35,4. В задачах с инструментами: Chartography — 83,0, BabyVision — 92,5, ZeroBench-main — 51,0.

В релизе нет шаблона чата в формате Jinja: вместо него в папке encoding лежит самодостаточная реализация на Python с тестами для многоходовых диалогов, вызова инструментов, режима размышления и изображений. Для продакшена отдельно выложен набор библиотек deepseek-recipe на Rust с привязками к Python. Рекомендуемые параметры сэмплирования: temperature 1.0, top_p 1.0, контекст 1M токенов, max_tokens не менее 256K.

Пользователи подтверждают высокую эффективность модели в кодинге и агентных задачах, выделяя её скорость и стоимость как решающие факторы. Сочетание высокой скорости генерации (tok/s), низкого TTFT и доступной цены делает модель предпочтительным «ежедневным драйвером» для итеративной разработки кода. При уровне reasoning_effort=1 модель генерирует в 2.5 раза меньше токенов без потери качества (по опыту @apejcic). Однако модель может уступать Opus 5.5 в сложных архитектурных решениях и UI-дизайне. В тесте на C++ кодовой базе @AmazingTurtle отметил, что модель предлагает слишком буквальные исправления (точно под размер теста), в то время как GPT 6.1 Sol закладывает запас (headroom). По мнению @a11r, модель склонна к «передумыванию» на сложных задачах, и в их воркфлоу GLM 5.3 Flash и Qwen 3.8 Flash показали себя лучше. Оптимальный воркфлоу по мнению @olavgg и @dw_arthur: использовать DeepSeek Flash для основной работы и Opus 5.5 в качестве экспертного рецензента/советника. Модель демонстрирует отличные результаты в локальном запуске на Mac (M5 Ultra): @liuliu сообщает о ~3400 tok/s при обработке промпта и ~50 tok/s при генерации (при RAM от 64 ГБ). Открытость модели (доступ к CoT) и отсутствие жестких блокировок по «кибер-безопасности» делают её более удобной для агентных систем, чем закрытые аналоги. Пользователи отмечают высокую эффективность модели в специфических задачах: @aizk использует её для реверс-инжиниринга старых игр (генерация 600k строк кода из ASM), а @nickludlam выделяет работу с Svelte.

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

Масштаб проблемы шире одного человека: шестеро или семеро знакомых из группы по «DevOps» потеряли работу или получили уведомление за последний месяц, включая сотрудника одной из FAANG-компаний, которому выдали шесть месяцев выходного пособия и уничтожили личные вещи. Другой нанимающий менеджер лишился должности через неделю после того, как генеральный директор запоздало опубликовал статью о том, что «ИИ меняет разработку». Автор подчёркивает: корректнее говорить не «ИИ забрал мою работу», а «ИИ поспособствовал упразднению моей роли».

При этом модели, по его мнению, всё ещё не заменяют опытного инженера: им не хватает вкуса в продуктовых решениях и предвидения последствий — роста издержек, сложности, доступности. Но они уже достаточно хороши, чтобы под присмотром переносить проверенное поведение между платформами: «Shopify» переписал приложение с «React Native» на нативный код, а порт «TypeScript» на «Rust» воспроизвёл даже исходные баги. В итоге модели не заменили людей — они убедили тех, у кого есть деньги, тратить их иначе.

Тред подтверждает, что компании увольняют инженеров ради экономии, заменяя их дешевыми подписками на AI-модели (например, Fable), или используют ИИ как предлог для сокращений ради краткосрочной прибыли (@glimshe, @philipodonnell). Это напоминает прошлый опыт замены сотрудников дешевым аутсорсингом (@voidifremoved, @TrackerFF). Мнения о возможностях LLM разделились. @gregwebs и @echelon считают, что модели уже способны генерировать готовый код, поэтому роль инженера трансформируется в техническое руководство и управление ИИ. Другие (@dofm, @TrisEck) уверены, что моделям не хватает вкуса и продуктового чувства. @jdw64 приводит пример приложения на моделях Astra и Fable, которое оказалось полно багов, что доказывает невозможность полной замены квалифицированного программиста. Пострадавшим инженерам советуют создавать собственные проекты с помощью тех же моделей для сохранения дохода (@laylower), а также относиться к работе как к средству, а не центру жизни (@sajithdilshan, @danw1979).

В 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 приближает язык к формальной верификации, но не гарантирует отсутствия скрытых багов.

DHH переписал Campfire Once с Ruby on Rails на Rust, Elixir и Go, используя ИИ-агента («clanker»), не читая и не пишя код сам. Результаты показали, что без чётких промптов и понимания требований ИИ принимает произвольные решения: например, Rust-версия отказалась от CSRF-токена и Redis ради упрощения кэширования, тогда как Elixir-версия сохранила близость к оригиналу. Эти различия не зависят от языка — они отражают неявные trade-offs, которые ИИ выбирает сам, когда не указаны приоритеты по совместимости, latency, throughput или использованию памяти.

Кроме того, в коде проявились серьёзные технические ошибки: в Elixir-версии SQL-запросы обрабатываются последовательно, даже если они могли бы выполняться параллельно; в Rust-версии некоторые БД-операции блокируют async-задачи, а синхронные мьютексы удерживаются слишком долго, блокируя весь worker-поток из-за кооперативной планировки Tokio. Увеличение буфера broadcast с 256 до 16384 улучшило доставку при 100 req/s с 14% до 90%, но привело к росту pMAX latency с 11с до >130с — что хуже, чем быстрый сброс и reconnect. При нагрузке Elixir-версия потребила 1.8ГБ памяти, ставя вопрос: лучше ли потерять сообщения или рискнуть OOM-kill? Вывод: никакой язык или ИИ не заменяют критического мышления — нужно понимать failure modes, устанавливать осознанные лимиты и не верить в «магические» решения. Benchmarks сложны, а надежность требует знания того, когда и как отказывать.

Из обсуждения

• @variety8675: This article just reminds me that workslop is so hard to counter because it takes no effort to produce and immense effort to debunk
• @discreteevent: It's worth noting that the context here is a system that was translated by an LLM which is the ideal use case for it. 90% of the thinking had already been done by developers of the existing system.

Я — низкоуровневый программист, чья идентичность строилась на глубоком понимании деталей: архитектуры процессоров, работы памяти, машинного кода и тонкостей языков вроде C или Rust. Я не просто писал код — я исследовал, как работает машина, считая такты, пишая OS-игрушки и отлаживая вручную. Для меня программирование было актом познания, а не создания утилит. Но индустрия сместилась в сторону абстракций, архитектурного мышления и «vibecoding», где ценят умение оперировать высокоуровневыми концепциями, а не знание того, что происходит под капотом. Возможности применить мои сильные стороны исчезают: компании предпочитают нанимать тех, кто работает с фреймворками, а не с ассемблером или кэш-линиями. Рост LLM усугубил кризис — теперь даже оптимизация кода и объяснение сложных концепций автоматизируются, делая мою экспертизу избыточной. Я физически не могу работать с большими кодовыми базами или архитектурой, поскольку мне нужно держать всё в голове, а LLMs, которые я пробовал, быстро превосходят моё понимание проекта, лишая меня смысла и контроля. Это привело к экзистенциальному кризису: я чувствую себя вытесненным, невостребованным, а моя страсть к низкоуровневому программированию — всё больше превращается в неприбыльное хобби, вытесняемое энтузиастами, ищущими признания, а не глубины. Я больше не вижу места для себя в индустрии.

Потеря глубокого понимания деталей в программировании вызывает эмоциональный кризис у низкоуровневых разработчиков, но выявляет ниши, где этот навык остаётся критически важным — кибербезопасность и оптимизация производительности, где LLM пока не могут заменить человеческое понимание архитектуры. Многие испытывают горе не из-за потери продуктивности, а из-за смерти идентичности, построенной на глубоком понимании машинных деталей — это не адаптация, а прощание с ушедшей эпохой. LLM не способны автоматически находить горячие участки кода или оптимизировать низкоуровневый код без чёткого понимания архитектуры и целей — они беспомощны без человеческого контекста. Работы в кибербезопасности — исследование уязвимостей, реверс-инжиниринг, анализ инцидентов — остаются областями, где детали определяют успех, и LLM не могут полностью заменить экспертов. Современные системы стали слишком сложны для удержания в голове — это не новость, но LLM усугубляют проблему, убирая стимул к глубокому пониманию, заменяя его поверхностным доверием к автоматизированным решениям. Спор: LLM генерируют ужасно неоптимизированный низкоуровневый код — например, снижение first paint с 4500ms до 1000ms в Claude, как заявлено, невозможно без ручной оптимизации, и это не достижение LLM. Спор: Один разработчик утверждает, что его коллега, почти не использующий LLM, остаётся самым ценным членом команды — он лучше всех понимает код, отвечает на вопросы и ловит баги в ревью, что опровергает тезис о неизбежной замене людей. Совет: Специализируйтесь на тех частях системы, где агентные потоки слишком рискованны — там, где ошибка может стоить миллионы, а не просто замедлить API — именно там глубокое понимание остаётся незаменимым. Совет: Используйте LLM как новый 'процессор' для логики — сосредоточьтесь на создании языков и систем для их контроля, что возвращает интерес к фундаментальным принципам информатики, а не к написанию кода. Совет: Ищите ниши, где ручная работа ценится — например, создание 'hand-made' ПО, где пользователи готовы платить за безупречный опыт, а не за быструю, но шаблонную автоматизацию. Совет: Переключитесь с написания кода на управление и поддержку — как один инженер, перешедший в менеджмент, заметил: люди, выполняющие агентную работу, требуют больше эмоциональной поддержки, и это новая возможность. Инженеры, которым важно понимание, а не построение, чувствуют себя потерянными — но это не слабость, а естественная реакция на уничтожение той культуры, где глубина ценилась выше скорости. Исторически, как и при промышленной революции, автоматизация уничтожает ремесло, но не устраняет потребность в мастерстве — она просто смещает его в более узкие, менее массовые ниши. Понимание компиляторов, кэширования CPU, TCP-стеков и пайплайнов остаётся ценным — даже если вы не пишете ассемблер, это знание позволяет находить скрытые узкие места, которые LLM не видят. Совет: Примите, что вы больше не сможете держать в голове всю систему — но это не значит, что вы перестали быть инженером; это значит, что ваша роль теперь — быть тем, кто понимает, что нельзя доверять автоматизации. LLM — это машина для интерполяции, а не для творчества; они не способны на открытия, как специальная теория относительности, если их обучали на данных до 1904 года — они не понимают, а пересобирают.

Quake-SRP — это браузерный порт оригинального Quake 1996 года, написанный на Rust и полностью программно отрисованный без использования GPU или внешних зависимостей. Игра запускается прямо в окне браузера, поддерживает полноэкранный режим, звук, управление клавиатурой, мышью и геймпадом, а также сохранение прогресса в локальном хранилище. Включена shareware-версия эпизода 1 (quake106.zip, 9,1 МБ), а пользователи могут загружать свои собственные файлы — pak1.pak для эпизодов 2–4, mission pack’и (hipnotic/pak0.pak, rouge/pak0.pak) и CD-музыку в формате OGG — которые сохраняются в браузере и не требуют повторной загрузки.

Управление гибкое: по умолчанию используется WASD + мouselook (с возможностью блокировки мыши кликом), но можно переключиться на оригинальные управления id Software через консольную команду idcontrols (стрелки для движения и взгляда, без мouselook и геймпада). Доступны пресеты classic (точное воспроизведение WinQuake) и slop (настройки порта), переключаемые через консоль (preset classic / preset slop) или параметры URL (?classic, ?slop). Игровой процесс дополняют консольные команды вроде god, noclip, give, map e1m2, impulse 9 и т.д., а также быстрые сохранения/загрузки по F6/F9. Меню вызывается клавишей Esc или любой клавишей во время демо, а F12 делает скриншот в формате PCX, сохраняемый в хранилище страницы. Поддержка миссий, кастомных контролей, видеоопций и сброса настроек делает Quake-SRP удобным и аутентичным способом пережить классику прямо в браузере.

Порт Quake в безопасный Rust продемонстрировал мощный метод визуального сравнения пикселей, но вызвал споры о ценности LLM‐ассистированных Rust‐портов, ограничениях браузерных игр, недопонимании «safe Rust» и необходимости значительных усилий, а также поднял вопросы о потенциальных злоупотреблениях такой техникой в критических системах. Визуальный diff‐harness позволяет точно сравнивать каждый пиксель с оригиналом, упрощая поиск и устранение графических багов. Спор: Некоторые считают, что LLM‐ассистированные порты в Rust заполнят репозитории тривиальными проектами; другие видят реальную ценность демонстрации, но полагают, что подход быстро утратит актуальность. Совет: Для сложных игр браузерный подход часто неэффективен; лучше разрабатывать десктопные версии, чтобы избежать проблем с производительностью. Совет: Термин «safe Rust» часто путают с полным отсутствием unsafe‐кода; на практике могут использоваться обходные пути, обходящие проверку заимствований. Портировать игру в браузер требует значительных усилий и опыта, как подтверждает пятилетний труд автора над Neverball. Совет: Отсутствие мультиплеера в текущем порте воспринимается как существенный недостаток, который пользователи хотели бы увидеть реализованным. Проект иллюстрирует синергию технологий: WASM, Rust и LLM, построенную на десятилетиях человеческого вклада в графику и эмуляцию. Спор: Некоторые опасаются, что метод визуального сравнения может быть использован для обратного инжиниринга критически важных систем, таких как банковские бэкенды, что вызывает тревогу о безопасности.

Penguin Mail — это настольный почтовый и календарный клиент для Linux, объединяющий поддержку Gmail, Microsoft 365, а также любых IMAP, POP3 и SMTP-серверов в едином интерфейсе. Он автоматически определяет настройки серверов по адресу электронной почты и позволяет просматривать все учётные записи в одном объединённом ящике или по отдельности, с синхронизацией из системного трея, счётчиком непрочитанных писем и действенными уведомлениями. Приложение включает полноценный календарь с видами день, неделя, месяц и повестка, поддерживая Google, Microsoft и CalDAV, а также контакты из тех же источников и CardDAV, с автодополнением при вводе получателя.

Для безопасности Penguin Mail интегрирует OpenPGP и S/MIME через локальный GnuPG, не храня ключи и не запрашивая парольные фразы. Оно поддерживает правила фильтрации писем в стиле Gmail, Microsoft и Sieve, представленные в понятной форме с возможностью добавления новых. Есть опциональный ИИ-ассистент, который можно запустить локально через LM Studio или Ollama — он отвечает на вопросы вроде «Какие отправленные письма ждут ответа?» или «Что в акциях?», анализируя почту через собственные инструменты приложения и требуя подтверждения перед отправкой писем или изменением настроек. Дополнительные функции включают отложенную отправку с возможностью отмены в течение нескольких секунд, разделение входящих на категории по типу Gmail (Основное, Обновления, Промо, Социальное) и функцию «Скрыть мою почту» — генерацию уникальных плюс-адресов Gmail для регистраций, которые можно отключать при спаме. Всё приложение работает полностью локально: нет собственных серверов, отслеживания или рекламы; соединения с Gmail и Microsoft идут напрямую через их официальные API, обеспечивая конфиденциальность данных. Penguin Mail распространяется бесплатно под лицензией GPL-3.0-or-later для 64-битных систем Linux.

Penguin Mail сталкивается с практическими проблемами, не упомянутыми в статье: необходимость надёжной санитизации HTML‐писем (sandbox‐iframe, CSP), отсутствие выбора отправителя и фавиконов, неприятие встроенного AI‐чата, сомнения в стабильности после месяца разработки, отсутствие поддержки JMAP для Fastmail, отсутствие Flatpak‐пакета, вопросы тестирования и изоляции, разногласия по UI‐инструментариям (GTK4 vs egui) и дизайну меню. Безопасный просмотр HTML‐писем требует полной санитизации и изоляции: sandbox‐iframe, CSP‐заголовки, отказ от доверенного происхождения. Многие пользователи предпочитают клиент без WebView — конвертирующий HTML в markdown или показывающий только текст. Встроенный AI‐чат воспринимается как навязчивый; лучше предоставить доступ к AI через внешние протоколы (MCP) или CLI. Отсутствие выбора адреса отправителя и фавиконов критично для пользователей с несколькими алиасами. Визуальное сходство с Mail.app привлекательно, но GNOME‐стиль меню (гамбургер‐кнопки) усложняет навигацию; рекомендуется полноценная строка меню с несколькими уровнями. Объявление версии 1.0 спустя месяц разработки преждевременно — пользователи ожидают зрелый продукт, учитывая сложность почтовых клиентов и долгосрочные баги. Отсутствие поддержки JMAP для Fastmail упускает шанс выделиться и упростить синхронизацию. Отсутствие Flatpak‐пакета ограничивает доступность в Linux‐дистрибутивах; добавление Flatpak востребовано. Тестирование и изоляция (sandbox) критичны из‐за риска багов; сообщество интересуется стратегией тестов и sandbox‐моделями. Некоторые разработчики считают, что вместо GTK4/libadwaita следует использовать Rust‐нативный UI‐фреймворк (egui) для лучшей интеграции и производительности.

Polars 2.0 стал значительным шагом вперёд, объединяя улучшения производительности, поддержку SQL как первого класса и переход к потоковой обработке по умолчанию. Теперь вызов collect на LazyFrame использует потоковый движок, что снижает потребление памяти и ускоряет большинство запросов, хотя требует явного указания порядка строк для операций вроде join и group_by, чтобы избежать неожиданных результатов. Добавлен новый тип данных Map, а контроль над типами стал строже — это ускоряет обратную связь и упрощает работу с ИИ-моделями.

В тестах TPC-H и TPC-DS Polars 2.0 показал лучшие результаты среди DuckDB (1.5.6 и 2.0 alpha) и DataFusion на машинах с 16 и 192 ядрами, особенно при ограничении потоков до 32 ядер на больших системах, где изначально наблюдался накладный расход при масштабировании. На больших данных (SF100) Polars с 192 ядрами оказался в 3.8 раза быстрее на TPC-H и в 2.2 раза на TPC-DS по суммарному времени запросов, опережая DuckDB и DataFusion в масштабируемости. Исходные данные и скрипты для воспроизведения тестов доступны в открытом репозитории. Разработчики обещают улучшить масштабирование на большом числе ядер и продолжить работу над out-of-core и GeoPolars.

Polars 2.0 почти полностью заменяет Pandas для обработки больших данных, за исключением геопространственных задач (нет аналога Geopandas, Geopolars в разработке), тонких строковых операций и совместимости с экосистемой SciPy, где Pandas доминирует из-за ожидания DataFrame-объектов. При работе с миллиардами строк Polars работает за 5 секунд против 4 минут 28 секунд у Pandas, а DuckDB использует в 19 раз меньше памяти. Потоковая обработка по умолчанию в Polars 2.0 устраняет утечки памяти от неправильного использования collect() в циклах. Пользователи отмечают лучший API и производительность Polars в greenfield-проектах, его логика ближе их мышлению. Для сложных строковых операций (например, конкатенации с текстом между столбцами) Pandas проще: df['col_a'] + 'text' + df['col_b'], тогда как Polars требует более громоздкого кода. Для научных библиотек (SciPy) Pandas предпочтительнее, так как многие инструменты ожидают DataFrame. Для сложных JOIN и агрегации на очень больших наборах данных DuckDB может быть предпочтительнее Polars. Есть противоречия в бенчмарках: некоторые утверждают, что DataFusion быстрее Polars, другие — что DuckDB уступает Polars. Также отмечается неоднозначность в поддержке наносекундных временных меток в Polars — некоторые пользователи сталкиваются с проблемой экспорта, другие нет. SQL в Polars 2.0 улучшен, но не поддерживает все операции (например, asof_join), ограничивая применение в некоторых аналитических сценариях. Пользователи, обрабатывающие миллиарды метеоданных, подтверждают, что версия 2.0 жизненно важна для их workflows. Для тех, кто использует SQL, Malloy предлагает более читаемый синтаксис, заменяя 40+ строк Polars/Pandas одной декларативной инструкцией.

ascii.rest — это коллекция анимированной ASCII-графики для веба, созданная @bas3line и доступная под лицензией MIT. Сайт предлагает более 100 анимаций, разделённых на категории: пейзажи (например, «alpine dawn» или «aurora fjord»), интерфейсные элементы (часы, прогресс-бары, спиннеры), данные (графики, тепловые карты, метры CPU), типографику (типа «typewriter», «glitch», «split-flap»), логотипы языков программирования (Python, Rust, JavaScript и др.) и дистрибутивы Linux (Arch, Debian, Alpine). Все анимации работают в браузере без JavaScript — только HTML и CSS, что делает их легковесными и быстрыми.

Особенно впечатляют детализированные сцены вроде «tunnel» — анимированный тоннель с движущимися плитками, и «tv-static» — имитация помех на старом телевизоре, переключающемся между тест-картинкой и шумом. Каждая анимация — это чистый, оптимизированный код, легко встраиваемый в сайты. Проект сочетает ностальгию по эпохе терминалов с современными веб-стандартами, предлагая эстетику, которая не требует тяжёлых библиотек. Исходники доступны на GitHub, что позволяет адаптировать или расширять анимации под свои нужды.

Обсуждение уточняет, что анимации относятся к цветному Unicode‐шейдеру, а не к классическому ASCII‐арту. Спор: некоторые считают, что использование цвета и Unicode‐символов делает их не настоящим ASCII‐артом, так как определение ограничивается простыми текстовыми символами. Большинство отмечают, что сайт поддерживает reduced motion: анимация останавливается на первом кадре для пользователей, избегающих движения. Пользователи сообщают о низкой частоте кадров на мобильных устройствах, особенно на главной странице, ухудшая восприятие. Есть запросы на визуальный редактор или генератор для создания собственных анимированных ASCII‐сцен. Предлагается принимать pull‐request‐ы для интеграции проекта Flow и других улучшений — сообщество хочет участвовать в развитии. Комментаторы согласны: интерес к ASCII‐арту связан с трендом ретро‐текстовых интерфейсов в UI‐дизайне. Спор: работа оценивается поляризованно — некоторые называют её «плохой» и «слишком минимальной», другие восхищаются эстетикой. Отмечено: в некоторых браузерах (например, Firefox Mobile) порядок анимаций перемешивается — требуется исправление.

Chrome 155 добавил поддержку JPEG XL — современного формата изображений, обеспечивающего на 30–50% лучшую компрессию по сравнению с JPEG, включая lossless режим и нативную поддержку HDR. Реализация выполнена на Rust в библиотеке jxl-rs, что устраняет типичные уязвимости C++-кодеков (переполнение буфера, use-after-free) благодаря памяти-безопасному языку, при этом сохраняя высокую производительность через SIMD-оптимизации, вдохновлённые библиотекой Highway и использующие стабилизированную функцию target_feature_11. Разработчики подтвердили отсутствие memory safety багов после omfattющего fuzzing и AI-поддержки проверки кода. Поддержка JPEG XL в Chrome стала результатом давнего запроса сообщества, отражённого в Interop 2026, где формат был одним из самых популярных предложений. Команда призывает веб-разработчиков использовать .jxl в своих пайплайнах для более быстрой, богатой и безопасной веб-среды, обещая продолжать улучшать формат на основе обратной связи.

Firefox планирует добавить поддержку JPEG XL в версии 158, расширив кросс‐браузерную совместимость. Chrome ранее удалил поддержку в версии 110, но восстановил её в Chrome 155, что указывает на смену стратегии. Safari пока не поддерживает прогрессивную загрузку в libjxl, а также анимацию и прогрессивный рендеринг JPEG XL на iOS, отставая от Chrome и Firefox, которые уже включили эти возможности. По данным caniuse, поддержка JPEG XL составляет лишь ~17 % сайтов, в отличие от ~97 % для WebP, что отражает низкую текущую адаптацию. Совместимость с приложениями остаётся проблемой: Telegram, macOS и многие просмотрщики не открывают JXL‐файлы. Rust‐реализация обеспечивает защиту от типичных уязвимостей C++ (переполнение буфера, use‐after‐free), но её производительность может варьироваться — заявленная скорость «примерно так же быстро, как лучшая небезопасная альтернатива» требует проверки на реальной нагрузке. Для типичного веб‐контента AVIF обычно показывает лучшую компрессию и скорость, тогда как JPEG XL считается менее подходящим. По расширению .jxl нельзя определить, используется ли сжатие с потерями или без, что усложняет пользовательский опыт. Создание JPEG XL в некоторых графических редакторах (например, Affinity) даёт плохие результаты и нестабильную компрессию, отпугивая пользователей. Для научных изображений, требующих более 8‐битной глубины, лучше использовать AVIF, так как текущий декодер JPEG XL ограничивает внутреннее представление 8‐битами.

mold 3.0.0 — это первый релиз линкера, переписанного с C++ на Rust, и он позиционируется как drop-in-замена версии 2.42.1. Переписанная версия сохраняет те же параметры командной строки, поддерживает те же архитектуры и выдаёт идентичный вывод, за исключением исправленных ошибок. Производительность линкования осталась на уровне предыдущей версии, а совместимость проверена запуском тестов на всех целевых платформах, сравнением вывода на реальных нагрузках и сборкой всех пакетов Gentoo — регрессий не обнаружено.

Переход на Rust повысил безопасность: теперь при повреждённых входных файлах mold не падает с segmentation fault, а останавливается с паникой благодаря bounds-checked чтению памяти. Изменена система сборки — вместо CMake используется Cargo, требуется Rust 1.95+ и C-компилятор. Сборка выполняется через cargo build --release, установка — ./install-mold.sh с поддержкой PREFIX и DESTDIR. Убрана зависимость от oneTBB, оставлено статическое связывание mimalloc, а системный аллокатор можно включить через --features system-allocator. Тестовый запуск теперь осуществляется через cargo test, а зависимости для тестов устанавливаются скриптом install-test-deps.sh. Среди исправлений — устранение крахов при работе с version script, при совпадении входного и выходного файла, при использовании --gc-sections с --init/--fini, при обработке общих символов разного размера, а также улучшена работа ICF и обработки версионных ссылок в共享 библиотеках. Исправлены архитектурно-специфические ошибки для SH4 и SPARC64. Проект продолжает получать поддержку от спонсоров, включая Cybozu, SAP, Mercedes-Benz и других.

Переход mold на Rust вызывает споры из-за проблем бутстрапа: Rust-инструменты недоступны на ранних этапах сборки дистрибутива, что делает использование mold невозможным без поддержки C-версии mold2 как отдельного форка. Автор mold @rui314 признаёт проблему, но предлагает использовать mold 2.x для бутстрапа, а затем переходить на mold 3 после сборки Rust — как практичный компромисс. Пользователь @lrvick настаивает на необходимости сохранения C-версии для ранних этапов. Советы по решению: - @danudey и @karavelov предлагают использовать LLD для бутстрапа и линковки Rust, так как LLVM уже требуется для сборки Rust, что устраняет дополнительные зависимости. - @Orphis и @rui314 отмечают, что воспроизводимые и герметичные сборки с кэшированием бинарников позволяют использовать последнюю версию mold для сборки следующих версий Rust, минимизируя пересборки. - @mohamedkoubaa предлагает рассмотреть Eurydice как альтернативу для управления цепочками сборки, без уточнения деталей. - @nicce предлагает добавить #[no_mangle] и поддержку extern C в mold 3.0 для ABI-совместимости, но не связывает это с бутстрапом. - @avadodin предлагает использовать сэкономленное время на переписывании mold для создания chibirustc — упрощённого компилятора Rust для быстрой локальной сборки, чтобы решить проблему бутстрапа. Дополнительно: - @rui314 утверждает, что переписывание mold на Rust ускорено AI, называя AI-assisted coding крупнейшим прорывом в производительности за свою карьеру. - @tialaramex опровергает утверждение о транспиляции кода, отмечая, что для транспиляции нужен исходный код на другом языке, чего в случае mold нет. - @sillysaurusx подчёркивает, что Wild — другой быстрый линкер, но ориентирован на инкрементальную линковку, тогда как mold фокусируется на скорости полной линковки. - @BoingBoomTschak отмечает, что Cargo.lock mold содержит ~600 строк против ~2200 у Wild, что снижает поверхность атаки, несмотря на общую зависимость от крейтов в Rust. Все факты и оговорки сохранены, повторы и канцелярит удалены, мысли объединены. Ничего не добавлено. Текст на русском, латиница только в именах и терминах.

Supabase приобретает Turso, чтобы совместно построить инфраструктуру, способную поддерживать рост спроса на базы данных, вызванный ростом агентного ИИ. Агенты сейчас создают миллионы баз в неделю для прототипов, дашбордов и приложений, и текущая инфраструктура не справляется с таким масштабом. Цель — сделать создание баз данных таким же простым и дешёвым, как создание файла: без необходимости выделения dedicated-машин для малых нагрузок, с мгновенным доступом и плавным переходом в продакшен.

Turso уже реализовал именно такую архитектуру: переписал SQLite на Rust и построил облачную платформу, где один сервер может управлять миллионами баз, загружая их по требованию и приостанавливая при простое. Это позволяет provisioning баз для каждого агента по требованию — как в Turso Cloud, так и в собственных облаках клиентов (Superhuman, Sauna.ai, CTO.new, Mastra). Supabase продолжит развивать Postgres для масштабируемых приложений, Turso — SQLite для лёгких нагрузок, а вместе они обеспечат единый developer experience от прототипа до продакшена. Команда Turso во главе с Glauber Costa присоединяется к Supabase, чтобы вести это направление. Ничего не меняется для существующих пользователей: оба продукта продолжают развиваться независимо, но теперь с общей стратегией поддержки агентного будущего.

Пользователи рады покупке Turso Supabase и ожидают ускорения развития проекта благодаря новым ресурсам. Однако они сталкиваются с реальными проблемами: низкой производительностью при работе с ClickBench (загрузка данных 4 KB/s, зависания), задержками более 100 мс в некоторых регионах и отсутствием автоматического мониторинга, что привело к уходу части пользователей. Команда Supabase признаёт эти проблемы, но считает их не приоритетными. Ведётся спор о целесообразности замены SQLite: одни считают это бессмысленным и рискованным из-за проверенной надёжности SQLite, другие видят в Turso улучшенную версию с потенциальной совместимостью с Postgres. Некоторые советуют сохранять SQLite в текущем виде, чтобы избежать новых багов. Есть положительные отзывы о Turso в Rust‐проектах — хорошая производительность при асинхронных запросах. Также обсуждается необходимость базы для агентного ИИ, поддерживающей SQL, векторный поиск и графовые запросы, которой atualmente не обладает SQLite, поэтому Turso рассматривается как потенциальное решение. Однако некоторые сомневаются в нужде отдельной инфраструктуры для агентного ИИ. Существуют опасения, что открытый код Turso может стать закрытым после поглощения Supabase, и вопросы о финансовой устойчивости проекта.

За последние два месяца компилятор 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 медленнее; другие считают, что правильная архитектура проекта устраняет проблему.

Gemini 4 Argon — это новая флагманская модель Google, предназначенная для сложных, длительных рабочих процессов в инженерии ПО, корпоративной аналитике (юриспруденция, финансы) и кибербезопасности. Она уже используется внутри компании: тысячи сотрудников отмечают её эффективность в оптимизации квантовых алгоритмов (улучшение на 40% по сравнению с базой), автономном выявлении утечек памяти в дата-центрах (освободив более 300 TiB, с потенциалом до 1–2 PiB) и миграции больших кодовых баз с C/C++ на Rust. Argon запускается по цене $2 за миллион входных токенов и $10 за миллион выходных, с кешированным вводом со скидкой 95%.

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

Gemini 4 Argon используется внутри Google для масштабных миграций кода (до 800K строк C++ в Rust) и оптимизации квантовых алгоритмов, но недоступен внешним пользователям и имеет несогласованные релизы, вызывая недоверие. Миграция 800K+ строк C/C++ в Rust в ядре Zircon (Fuchsia) — уникальный практический пример применения ИИ в реальном продукте. Аргон демонстрирует низкий уровень галлюцинаций — 15%, лучше OpenAI (40–50%) и Anthropic (60–70%), что привлекательно для критических задач. Цены: $2/млн входных, $10/млн выходных токенов, с 95% скидкой на кэшированные токены — сопоставимы с Opus 5.5, экономически конкурентоспособны при доступности. Критика: задержки в выпуске Argon для клиентов несмотря на внутреннее использование (пользователи @deanc, @dom96); другие провайдеры быстрее выводят модели. Сомнения в достоверности бенчмарков Google: несогласованность после пересмотра весов, показ только максимальных уровней рассуждения (@pietz, @robertbarbe). Примеры использования: Gemini 3.8 Flash помог написать LD_PRELOAD C-шем для ROCm llama.cpp на Strix Halo (@taylorfinley); Argon позволяет делегировать домен-специфичные задачи — проверка результата дешевле ручного выполнения (@summerlight). Ключевое преимущество — переносимость рабочих процессов, не привязанность к одному провайдеру (@juanre). Важна прозрачность рассуждений и осторожность в обратной связи при обучении, чтобы не искажать способность находить несоответствия (@gopalv). В Gemini Pro-плане нет опции отключения обучения на данных пользователей — критический недостаток (@pritambarhate). Анонс Argon, возможно, связан с OKR-целями Q3, а не реальной готовностью продукта (@xnx). Реальная ценность зависит не только от способностей модели, но и от системы разрешений, управления контекстом и UX — здесь Google отстаёт (@dhanushnehru). Факт миграции C++ в Rust на уровне ядра Fuchsia — значимый индикатор независимо от качества модели; если попадёт в продакшн — революция (@filearts). Ирония: упоминание оптимизации квантовых алгоритмов как главного достижения — попытка выглядеть впечатляюще без реального влияния на повседневность (@elAhmo). Даже с продвинутыми моделями базовая функциональность (например, расписание уборки улиц) остаётся ненадёжной — прогресс в модели не всегда улучшает юзабилити (@vlenoach).

Фото-реактивная LED-скульптура Phyllotaxis воссоздаёт природный узор, встречающийся в подсолнухах и кактусах — спиральную структуру, основанную на золотом сечении. Автор написал простой код, который распределяет точки по радиусу, поворачивая каждую на множитель 1.618..., создавая визуально естественный паттерн. После визуализации в цифровом виде он перенёс его в физический мир: с помощью CadQuery и 3D-печати сформировал 89 ячеек, каждая из которых содержит RGB-светодиод Neopixel. Внутренние стенки ячеек вырезаны так, чтобы оставить прочную оболочку, а в центре каждой — отверстие под диод.

Пайка 89 светодиодов заняла месяцы из-за сложности монтажа — контакты расположены под самими чипами, что требует горячего воздуха. Вдохновлённый встречей на Recurse Center, автор завершил сборку с помощью друга и переписал прошивку на Rust под ESP32. Устройство теперь доступно через веб-интерфейс: посетители могут загружать свои анимации через WebAssembly. Для рассеивания света использована тонкая шелковая бумага, приклеенная снизу — она придаёт узору мягкость и органичность. Автор планирует улучшить проект: заменить светодиоды на более удобные для пайки, использовать PCB-производство, добавить защитный акрил и магнитные крепления.

Обсуждение дополняет статью практическими советами по сборке и настройке проекта. Предлагаются варианты автоматической пайки светодиодов на фабрике и контраргументы в пользу ручной пайки. Раскрывается метод реализации пяти‐кратной симметрии через вращение точек. Отмечаются проблемы с хрупкостью бумажного диффузора и способы их решения. Делются рекомендациями по увеличению площадок пайки, использованию CadQuery для органического моделирования и возможностям перенести проект на ESP32 с WLED. XRG советует передать сборку светодиодов фабрике, чтобы сэкономить время и снизить риск повреждения. asdfasdfe считает, что ручная пайка компонентов тривиальна и не требует дополнительных расходов. Для достижения пяти‐кратной симметрии автор вращает сгенерированные точки пять раз и использует обработку в Processing. Репозиторий теперь имеет MIT‐лицензию, что облегчает модификацию и повторное использование кода. Бумажный диффузор из мульберри‐бумаги оказался хрупким, а клей может просачиваться, вызывая неравномерную светопередачу. Автор планирует улучшить крепление и уменьшить риск протекания клея. Для удобства пайки советуют делать площадки SMT немного больше, чтобы обеспечить место для впитывания припоя. Neopixel‐LED (5050) легко паять вручную благодаря боковым выводам. QFN‐чипы тоже возможны при достаточной практике. CadQuery отлично подходит для создания органических форм. Пользователи интересуются аналогичными инструментами для проектирования печатных плат. Можно воспроизвести эффект на ESP32 с WLED, разместив 2‐D карту светодиодов. Это делает проект более доступным для хобби‐энтузиастов. Филлотаксис‐спирали, основанные на золотом угле, обеспечивают равномерную плотность точек, избегая искажения, характерного для концентрических колец. Важно правильно балансировать отклик на транзиенты и сглаживание, чтобы избежать дрожания светодиодов. Использование тонкой мульберри‐бумаги под прозрачной печатью дает хороший диффузор и может имитировать эффект витража, если подобрать подходящий рисунок. Автор добавил MIT‐лицензию в репозиторий, что облегчает модификацию проекта. Многие участники выразили желание собрать собственную версию и адаптировать её под свои нужды. Создание качественного финального вида требует тщательной работы с освещением и отделкой. Быстро собрать прототип легко, но достичь профессионального уровня сложно.

Дэвид Хайнемайер Ханссон объявил, что отошёл от профессионального программирования и теперь позиционирует себя как «мейкер», веря, что английский язык стал лучшим языком программирования благодаря LLM, а чтение сгенерированного кода больше не требуется. Он утверждает, что ручное написание кода перестало быть экономически продуктивным для большинства программистов, и что 37signals переписывают Hey на нативные приложения с использованием Rust на серверной стороне — языка, который он считает «ужасным» для людей, но идеальным для LLM, поскольку он не читает код anyway. За август он насгенерировал 150 тыс. строк кода (в основном «словного» Rust), тогда как раньше писал около 30 тыс. в год, и доля Ruby в его работе упала с 50% до 3%. Его видение: к концу года LLMs будут доминировать во всех сферах, а люди будут читать код лишь исключительно, как ошибку в Sentry. Он также хочет, чтобы у каждого сервиса был CLI для взаимодействия через агентов. На Rails World 2026 он использовал ключевую речь, чтобы объявить, что флагманское Rails-приложение Hey покидает фреймворк, хотя и отметил, что Rails остаётся хорошим для веб-приложений и разработки с ИИ. Однако его аргументы сводились к тому, что Rails был лишь временным обходным манёвром, а теперь его роль сведена к «веб-приложениям по необходимости», а «конвенция над конфигурацией» переосмыслена как «эффективность токенов». Критик отмечает отсутствие чёткой стратегии для Rails, заменённую оптимизмом без фактической основы, и выражает разочарование тем, что вместо обсуждения будущего Rails DHH предложил лишь веру в ИИ и отверг скептицизм как «чёрную таблетку для неудачников».

Rails не умирает из-за технологий, а из-за ухода DHH. Многие разработчики продолжают использовать его для CRUD- и LoB-приложений в 2026 году благодаря сильным конвенциям, упрощающим поддержку, даже если LLM генерирует большую часть кода. LLM-генерация делает производительность Ruby менее критичной, так как разработчики фокусируются на проверке и доработке сгенерированного кода. Один разработчик отмечает, что 90% его 25k строк продакшн-кода и тестов генерируются LLM — код надежен, легко расширяем и требует меньшего ручного вмешательства. SRE предупреждают, что если LLM генерирует код быстрее, чем человек его читает, чтение становится необязательным, что ставит под вопрос понимание системы на уровне инженеров. Производительность Rails (80–100 мс на запрос) остаётся приемлемой для большинства бизнес-приложений, и миграция не мотивирована скоростью, а удобством разработки. Компании не переходят на другие стеки из-за производительности, а из-за усталости от устаревших инструментов и отсутствия развития экосистемы без DHH. Критики утверждают, что DHH, как BDFL, не передал управление, что привело к фрагментации сообщества и необходимости форка — это системная проблема, а не техническая. Некоторые считают, что переход на нативные приложения или CLI-агенты — ответ на ограничения веб-фиделити, а не на устаревание Rails. LLM не генерируют код в WASM или нативной сборке, а используют высокоуровневые языки, значит, они ускоряют разработку фреймворков, а не заменяют их. Исторически Rails решал проблему медленной разработки в 2000-х — теперь эта проблема решена LLM, и фреймворки перестают быть конкурентным преимуществом, а становятся инструментом. Разработчики, ушедшие от Ruby, рекомендуют Kotlin+http4k как альтернативу: он сохраняет стиль Ruby с типизацией, поддерживает функциональный подход и лучше интегрируется с агентными системами.

Whiteboard — это открытое десктопное приложение, где люди и ИИ-агенты совместно проектируют ПО в едином рабочем пространстве. Оно интегрируется с инструментами вроде Claude Code и Codex, предоставляя агентам SDK для рисования на встроенном холсте: диаграммы последовательности, ER-модели или цитаты из трассировки становятся интерактивными — клик по элементу переходит к соответствующему коду с поддержкой LSP и горячих клавиш из VSCode.

Приложение включает семантический diff-просмотр на Rust, который скрывает шум (например, юнит-тесты и документацию), сводя большие добавленные функции в псевдокод, и ведёт журнал решений агентов для отслеживания автономных выборов. Основано на форке VS Code OSS — из-за сложности патчей для агентов и высокой доли Copilot (~45%) в апстриме, команда регулярно сливает обновления безопасности и функций. Поддерживает подсказки для анализа API-изменений и телеметрии, позволяя выделять фрагменты и передавать агенту для доработки. Лицензия — MIT.

Whiteboard интересен как визуальная связка кода и диаграмм, но вызывает вопросы: отсутствие редактирования файлов, отсутствие версии для Windows, сомнения в названии IDE, риск рассогласования диаграмм с кодом и необходимость интеграций (LSP, GitHub PR, другие LLM). Пользователи предлагают добавить LSP‐диаграммы, улучшить синхронизацию, расширить функциональность и уточнить бизнес‐модель. Невозможность редактирования файлов ограничивает практическую полезность и ставит под сомнение позиционирование как IDE. Рекомендуется разработать отдельный LSP для диаграмм, чтобы интегрировать их в существующие редакторы. Отсутствие версии для Windows считается серьёзным недостатком. Следует переименовать проект из "IDE" в более нейтральный термин (например, "brainstorming tool" или "architectonic harness"), чтобы избежать путаницы. Предлагается добавить возможность комментировать и ссылаться на GitHub pull‐request'ы прямо из Whiteboard — для удобства ревью. Есть опасения, что диаграммы могут устареть относительно кода без автоматической синхронизации; идея "semantic diff" отмечена положительно и рекомендуется к развитию как ключевая функция. Сравнение с открытыми проектами (likec4.dev, erode.dev) подчеркивает необходимость чёткой дифференциации и совместимости с их подходами. Вопрос о монетизации возник у нескольких комментаторов; стоит рассмотреть модель подписки или платные плагины для корпоративных пользователей. Пользователи видят ценность в визуальном связывании кода и диаграмм для упрощения обзора и понимания архитектурных решений. Запрошена поддержка Copilot CLI для расширения интеграций за пределы Claude. Запрошены тёмный и светлый режимы интерфейса для улучшения удобства работы. Предупреждается, что создание отдельного источника правды может привести к устареванию документации без постоянного обновления. Рекомендуется рассмотреть веб‐версию или возможность прямого редактирования файлов в приложении для повышения гибкости. Упомянута существующая альтернатива — whiteboard-mcp.com, которая предоставляет канвас, доступный Claude, подтверждая интерес к подобным решениям.

Fearless SIMD v1.0 устраняет необходимость в unsafe коде при работе с SIMD-операциями в Rust, предоставляя безопасный и производительный доступ к векторным инструкциям. Библиотека достигает этого благодаря макросу kernel!, который использует целевые признаки компилятора (target feature v1.1) для вызова intrinsics без unsafe, а также модулю безопасного трансмутирования, вдохновлённому bytemuck и zerocopy, который заменяет небезопасные загрузки и хранения через сырые указатели на безопасные абстракции. Это позволяет избежать тысяч unsafe блоков, типичных для других SIMD-абстракций, при сохранении полного контроля над производительностью.

Библиотека предлагает два варианта операций с платформозависимым поведением: точный (переносимый) и быстрый (платформозависимый), позволяя разработчикам выбирать между корректностью и скоростью в зависимости от ожидаемых данных. Она поддерживает как фиксированные, так и аппаратно-зависимые векторные размеры, обеспечивая полное использование аппаратных возможностей на любой платформе. При необходимости можно безопасно спускаться до платформенно-специфичных intrinsics без накладных расходов, сохраняя при этом переносимость остального кода. Fearless SIMD уже используется напрямую в 30 crate и косвенно — более чем в тысяче, что подтверждает её роль в экосистеме Rust. Несмотря на надежды на стабилизацию std::simd, библиотека останется актуальной благодаря своим уникальным возможностям: мультиверсионированию, поддержке аппаратной ширины векторов и планам по интеграции с будущими расширениями вроде SVE и RISC-V V без разрыва API. Обещаны три года обновлений безопасности для v1.0 и последующих версий.

Fearless SIMD v1.0 успешно заменил nightly-зависимые решения в продакшен-коде, позволив пользователям запускать высокопроизводительные SIMD-алгоритмы на стабильном Rust без unsafe, что подтверждено реальными кейсами вроде PhastFT и memchr-n.

• Fearless SIMD позволил пользователю O3marchnative перенести PhastFT с nightly std::simd на стабильный Rust, что стало критически важным для практического использования библиотеки.

• Dr_Emann использовал Fearless SIMD для создания memchr-n, который превзошёл по производительности официальный memchr-крейт даже для наборов из 1–3 байт, подтвердив практическую эффективность.

• Пользователь JMKH42, создавший ранний SIMD-крейт SIMDeez, признал сложность реализации подобных решений и выразил одобрение команде Fearless SIMD, подчеркнув значимость их достижения.

• Спор: modulovalue предполагает, что компиляторы не умеют трекать специфичные свойства float (например, отсутствие NaN), что мешает оптимизации SIMD, но athrowaway3z возражает, что такие условия редко сохраняются за пределами простых случаев и не влияют на производительность в реальных сценариях.

• barchar указывает, что LLVM уже использует value tracking / known bits analysis, что означает, что частичная оптимизация по свойствам векторов возможна без изменения языка, но не применяется массово к SIMD-операциям.

• adastra22 предлагает NotNan<f64> из ordered-float как существующее решение для безопасного представления float без NaN, что может частично решить проблему, о которой спрашивает modulovalue.

• Archit3ch отмечает, что Julia позволяет расширять компилятор без патчинга, что контрастирует с Rust и подчёркивает уникальность подхода Fearless SIMD в рамках статической типизации.

• O3marchnative подтверждает, что Fearless SIMD был выбран после оценки других portable SIMD-крейтов, и именно его функциональность позволила завершить порт PhastFT, что указывает на его превосходство над альтернативами.

This is quite amazing. Fearless SIMD is what finally allowed my FFT crate, PhastFT, to run on stable Rust [0]. PhastFT previously depended on Rust’s std::simd (as well as multiversion), which still requires nightly [1].One of the main contributors to v1.0 of fearless_simd started out by helping me… — @O3marchnative

Переписав JSONPath из Rust в Zig, я оценил простоту и скорость Zig, но столкнулся с рядом непривычных моментов. IDE-поддержка оказалась слабой: только подсветка и базовое автодополнение, что заставило вернуться к работе через терминал. Однако система сборки build.zig оказалась удобной и гибкой — позволяла легко запускать тесты, отладку и проверку соответствия стандарту. Это даже вдохновило на переход на минималистичный стек: Helix + Alacritty + Zellij.

Структура проекта в Zig поощряет плоскую иерархию файлов — в отличие от Rust, где дробление на модули привычно, здесь вложенные папки создают трения при импорте без явной выгоды. Оказалось проще держать связанный код в одном файле и navigировать по разделам. При реализации столкнулся с нюансами управления памятью: в Zig нужно явно дублировать строки перед добавлением в вектор и использовать errdefer для очистки при неудаче — в Rust такая ситуация невозможна благодаря семантике move. Экосистема пока молода: отсутствуют зрелые библиотеки (например, regex без Unicode-свойств), а стандартная библиотека меняет API между версиями. Несмотря на это, Zig оставил впечатление современного, быстрого и перспективного языка — потенциального преемника C, который стоит развивать дальше.

Zig — молодой язык с потенциалом как преемник C, но его слабая IDE-поддержка, отсутствие автоматических деструкторов и фокус на аллокаторах вызывают сомнения в пригодности для продакшена. Rust уже обеспечивает безопасность памяти без GC и считается зрелым выбором для коммерческих проектов. Спор: Zig не требует мутаций из-за аллокаторов — иммутабельность возможна при явной передаче аллокатора. Мутация — выбор программиста, не требование языка. Спор: Отсутствие автоматических деструкторов в Zig критикуют как 'dead-end', но Rust также использует мутации под капотом, скрывая их за иммутабельным интерфейсом. Согласны: Rust — единственный язык, сочетающий высокую производительность, нулевой runtime-overhead и безопасность памяти без GC, незаменимый для продакшена. Совет: В Zig arena-аллокация с defer arena.deinit() упрощает управление памятью в циклах. Спор: IDE-поддержка Zig (ZLS) нестабильна несмотря на LSP — реальная проблема для разработчиков, привыкших к полноценным IDE. Спор: Для архивного порта K&R C C23 предпочтительнее Zig из-за минимальных изменений и стабильности; Zig слишком нестабилен для таких целей. Совет: LLM эффективен для перевода кода между языками, если поведение можно автоматически проверить — снижает риски. Согласны: Современные C-преемники (Zig, Odin, Jai) страдают от одержимости аллокаторами — полезно в нишевых сценариях, но не масштабируется на общие задачи. Спор: Цепочки итераторов в Rust критикуют как 'gaslighting', но защищают как нулевую стоимость абстракций — читаемость зависит от привычки. Согласны: Zig быстр и современен, но незрел из-за незавершённого синтаксиса, слабой инструментальной поддержки и отсутствия стандартов — в отличие от зрелого Rust. Совет: В Helix отсутствует сворачивание кода — затрудняет навигацию по большим файлам Zig, важно при выборе редактора. Согласны: Rust решает управление памятью на этапе компиляции без GC — несмотря на долгую компиляцию, надёжен для командной разработки. Совет: В Zig запуск конкретных тестов через build.zig проще, чем рутинные подходы в других языках — фильтрация по имени экономит время. Спор: Аналогия с выбором блюда в ресторане ошибочна, если есть инструменты (переводчик); в незнании выбор должен быть консервативным.

Cloudflare сократил потребление памяти в сервисе Pingora Backend Router на более чем 100 ТБ за счёт оптимизации алгоритма consistent hashing в библиотеке pingora-ketama. Проблема заключалась в том, что для каждого узла хранились полные копии хеш-кольца — структуры данных, используемой для распределения запросов между серверами. При росте числа узлов это приводило к квадратичному росту памяти: каждый новый узел дублировал всё кольцо, что при тысячах серверов и петабайтах RAM становилось неприемлемо дорогим.

Оптимизация заключалась в переходе от полного дублирования кольца к компактному представлению: вместо хранения всех хешей каждого узла, теперь хранится только базовое множество хешей на узел, а при поиске используется эффективный алгоритм сортировки и бинарного поиска по сжатому пространству. Это позволило уменьшить память на узел с O(N) до O(1) относительно числа узлов, сохранив при этом свойства consistent hashing — минимальную переназначенность при добавлении/удалении узлов и равномерное распределение нагрузки. Изменения были внесены как обратно совместимая функция v2 в pingora-ketama, позволяющая逐步 мигрировать без простоев. После полного перехода на новую версию наблюдался резкий спад потребления памяти — подтверждённый метриками — что эквивалентно экономии более 100 ТБ RAM по всему глобальному флоту Cloudflare. Это демонстрирует, как математическая прозорливость и аккуратная реализация в Rust могут превратить, казалось бы, незначительные алгоритмические улучшения в масштабную экономию ресурсов.

Оптимизация Cloudflare имеет смысл только на масштабе их инфраструктуры. Для обычных систем экономия 1% памяти не оправдывает сложность реализации. Спор: Некоторые считают, что оптимизация на 100 ТБ оправдана только из-за масштаба Cloudflare, а для большинства систем это не стоит усилий. Спор: Один участник предлагает заменить consistent hashing на tournament hashing с N битами ключа и wyhash — это сократит использование памяти на 600 ТБ и снизит задержку за счёт O(n) вместо O(n log n). Совет: Использовать B-дерево с суммированием весов узлов и бинарным поиском по хешу, масштабированному на общий вес — это снизит затраты на обновление дерева до ~8 узлов при добавлении/удалении сервера. Совет: Применить сжатие указателей в Rust — удаление по 2 байта с каждого указателя сэкономит сотни гигабайт при большом числе записей. Многие отмечают, что Cloudflare вернулся к качественному, человечески написанному контенту, в отличие от предыдущих постов, написанных ИИ — это воспринимается как позитивный сдвиг. Пользователи подтверждают, что оптимизации хеш-колец и хранения данных важны для крупных систем, где небольшие улучшения приводят к значительной экономии ресурсов. Совет: При небольшом масштабе профилирование и устранение избыточных байтов на запись эффективнее сложных алгоритмических оптимизаций, не протестированных на реальных данных. Спор: Некоторые критикуют статью за преувеличение технической глубины — математика в ней не революционна, а базова для команд, работающих с оптимизацией на уровне дата-центров. Совет: Использовать rendezvous hashing — алгоритм для балансировки нагрузки в прокси-кэшах, который может заменить ketama и сократить память без потери равномерности распределения. Пользователи отмечают, что эпоха изобилия памяти закончилась — рост стоимости RAM и масштаб инфраструктуры заставляют компании возвращаться к глубокой оптимизации, как в прошлом. Спор: Один участник утверждает, что экономия памяти ради снижения затрат не этична, если это приводит к росту цен на оборудование для малого бизнеса и рабочего класса. Совет: В Rust можно использовать структуры с layout-оптимизацией и struct-of-arrays для улучшения кэш-локальности при поиске в хеш-кольце — это снижает задержки без увеличения памяти.

Благодаря пожертвованиям через OpenCollective и GitHub Sponsors, Джош Боуман-Мэттьюс смог работать полставки над улучшением опыта участников проекта Servo. За год он номинировал 8 новых мейнтейнеров, проверил 1150 пул-реквестов и создал 114 issue, нацеленных на новичков — 92% из них уже решены. Он также написал новую документацию по ключевым темам: опасностям заимствований, экспериментальным функциям, политике использования ИИ, поиску задач и диагностике стабильных и прерывистых тестовых сбоев.

Особое внимание уделялось устранению нестабильности: Джош помог в масштабной переписке интеграции JS-движка, связанной с паниками при сборке мусора, выявил и исправил сломанное поведение window.open, стабилизировал множество флейковых тестов и поддержал успешное грантовое предложение другого участника. Эта роль позволила ему совмещать вклад в проект с семейной жизнью, делая Servo более доступ к Servo проще для новых участников. Он выражает благодарность всем донорам и с оптимизмом смотрит на будущее.

Servo не предназначен для замены полнофункциональных браузеров, но успешно используется в специализированных сценариях: встраиваемые интерфейсы, CAD-приложения, e-ink-дисплеи (10% памяти и 5% времени рендеринга по сравнению с headless Chrome), встраиваемые киоски с контролируемым контентом. Его ценность для экосистемы Rust и веб-стандартов признана даже без полной совместимости. Servo предоставляет альтернативную точку валидации веб-стандартов и WPT-тестов, помогая выявлять неоднозначности в спецификациях для долгосрочной совместимости браузеров. Tauri использует форк Servo — Verso — для рендеринга в десктоп-приложениях, демонстрируя практическую интеграцию в современные фреймворки без необходимости полной реализации веб-платформы. Благодаря простому API Servo легко интегрируется, позволяя строить собственные браузеры и инструменты без поддержки всего веб-стека. Проект возрождён в 2022 году благодаря финансированию Huawei, а также активной поддержке NLnet, подтверждая его промышленную и некоммерческую значимость. Годовое спонсорство составило $52,883.97, при зарплате разработчика до $4800/месяц — показатель эффективности микроспонсорства для открытых проектов. Servo не переписывает JS-движок SpiderMonkey, так как создание нового движка — огромная задача; приоритет — реализация рендеринга. Использование Rust не решает проблемы безопасности JS-движка: мемори-уязвимости в JIT-коде требуют архитектурных решений, а не выбора языка. Разработка Servo не направлена на конкуренцию с Chrome или Safari, а служит экспериментальной платформой для изучения архитектуры браузеров и возврата полезных компонентов в Firefox. Серверные и встраиваемые приложения не требуют использования всех ядер, поэтому усилия по параллелизации в Servo считаются избыточными без конкретных сценариев. Сообщество ценит Servo как доказательство того, что браузер можно построить с нуля небольшой командой — в отличие от монолитных решений вроде Chromium. Есть спор: некоторые считают Ladybird более перспективным проектом и критикуют смену фокуса Servo с обучающего на коммерческий; другие подчёркивают, что Servo остаётся более открытой и независимой альтернативой. Совет: не ждать от Servo полной совместимости с веб-платформой, а использовать его там, где ограничения не критичны — например, в закрытых приложениях с контролируемым контентом.

NVIDIA представила CUDA Rust — набор инструментов для написания GPU-ядер на Rust, устраняя необходимость использовать другие языки для ядер, даже если остальная часть стека уже на Rust. Поддерживаются две модели программирования: SIMT (как в CUDA C++), где разработчик указывает действия одного потока, и Tile — более абстрактная модель, где описывается обработка блока данных, а компилятор сам определяетMapping на архитектуру. Tile рекомендуется как отправная точка благодаря переносимости, а SIMT оставлен для случаев, требующих низкоуровневого контроля.

Для SIMT доступен проект cuda-oxide — собственный бэкенд rustc, который компилирует функции с атрибутом #[kernel] в PTX через MIR, Pliron и LLVM. Для Tile — cutile-rs, предоставляющий Rust-биндинги к cuTile API. Оба примера демонстрируют поэлементное сложение 1024 float-значений и выводят одинаковый результат. Требуются Linux, GPU с compute capability ≥8.0, CUDA Toolkit 12.x+, clang и зафиксированная ночная цепочка Rust. Инструменты проверяются через cargo oxide doctor. Документация, примеры и ссылки на репозитории доступны в блоге NVIDIA, а также планируется доклад на RustConf 2026. Interoperability с другими языками остаётся приоритетом.

Обсуждение подтверждает, что CUDA Rust может снизить сложность написания GPU-ядер, но вызывает опасения по поводу вендор-локкита, стабильности pre-1.0 инструментов и качества официальных анонсов.

• Спор: Некоторые считают CUDA вредным из-за вендор-локкита и требуют открытых альтернатив вроде Metal/OpenCL, другие утверждают, что CUDA — лучший GPGPU API на данный момент, и критика его только замедляет прогресс в UX.

• Спор: Один участник критикует ручной запуск ядер как ошибко-чувствительный и трудоёмкий, а другой отмечает, что компиляторная проверка и единое выражение для запуска ядра — ключевое преимущество CUDA, а не просто артефакт C++.

• Совет: Пользователи с опытом в CUDA отмечают, что CUDA Rust требует nightly Rust и pre-1.0 инструментов, что делает его нестабильным для продакшена и усложняет отладку из-за множества слоёв (Rust, cuda-oxide, CUDA, Tile).

• Многие согласны, что Rust для GPU-программирования — важный шаг вперёд, особенно для повышения надёжности кода ядер и уменьшения боли от отладки по сравнению с CUDA C++.

• Отмечается, что NVIDIA открыла CUDA Tile IR, что делает проект частично открытым, и это воспринимается как позитивный сигнал, несмотря на критику вендор-локкита.

• Совет: Опытные разработчики предупреждают, что использование CUDA Rust может привязать код к NVIDIA, если не использовать абстракции, и советуют оценивать альтернативы вроде rust-gpu или WebGPU.

• Поддержка Rust в GPU-программировании усиливается трендами: интеграция Rust в Linux-ядро, использование Rust в Amazon/Microsoft для верифицированного ПО и рост популярности Candle от Hugging Face.

• Спор: Некоторые критикуют стиль анонса NVIDIA как 'автоматически сгенерированный Claude', считая это признаком безразличия команды, в то время как другие воспринимают это как норму для корпоративных анонсов.

• Совет: Пользователь с опытом в WGPU и cudarc отмечает, что CUDA-oxide позволяет делить структуры между хостом и устройством, но требует перехода на экспериментальный диалект, что может быть риском.

• Несколько участников отмечают, что CUDA Rust — это шаг в правильном направлении, особенно для Rust-экосистемы, и благодарят NVIDIA за поддержку, несмотря на прошлые проблемы с Linux.

• Спор: Один участник спрашивает, можно ли использовать CUDA Rust для WebGPU/Vulkan, а другой отвечает, что это нецелевое использование — CUDA Rust ориентирован на CUDA-совместимые GPU, а не на веб-стандарты.

• Совет: Пользователь с опытом в GPU-программировании отмечает, что несоответствие порядка элементов в примерах (a,b,c vs z,x,y) указывает на непоследовательность в API, что может ввести в заблуждение новичков.

Cody Ho и Niklas создали полностью совместимый с OpenGL ES 3.0 GPU-драйвер для M4 Mac Mini и MacBook Neo за месяц — срок, обычно требующий лет разработки. Драйвер обеспечивает работу Chrome и Firefox с WebGL, включая трёхмерные демо three.js, и запускает Minecraft со скоростью 212 FPS на M4 Mac Mini. Разработка велась в условиях чистой комнаты: команда не смотрела на бинарники Apple, используя только аппаратные трассировки из ранее построенного гипервизора и собственные шейдеры. Для обхода необходимых Apple-блобов друг предоставил документацию, позволившую реализовать их функциональность с нуля. Все эксперименты опубликованы в репозиториях agx-re для проверки происхождения кода.

В ядре драйвер взаимодействует не с железом напрямую, а с прошивкой GPU, работающей на RTKit — кастомном RTOS от Apple. Reverse-инжиниринг ABI прошивки стал самой сложной частью: Apple фактически разделил типичный ядерный драйвер пополам, поместив половину в прошивку. ABI у M4, A18 Pro и M5 значительно различается — у A18 Pro из-за второго RTKit-сопроцессора прошивка ближе к M5, несмотря на сходство пользовательского пространства с M4. Команда reverse-инжинирила пользовательское пространство M4, A18 Pro и частично M5, построила собственный IR/шейдер-компилятор и билдер командных потоков, а также реализовала полноценный Linux-ядерный драйвер для ABI прошивки. Прошивка M5 полностью reverse-инженерирована, построен и протестирован прототип drm-shim, который близок к превращению в полноценный Rust-драйвер. Основные цели — M4 Mac Mini и MacBook Neo. Ошибки в работе прошивки требуют полной перезагрузки, а некорректные handshake приводят к молчаливой потере работы или скрытой коррупции памяти.

Разработка драйвера с помощью LLM стала возможной благодаря современным инструментам, но вызвала споры. Критики считают, что работа «загрязнена» опытом автора в Apple и использование LLM для реверс-инжиниринга является «отмыванием знаний». Сторонники возражают: опыт в компании не означает доступа к секретным данным GPU, а LLM — это естественное развитие инструментов, позволяющее обойти многолетние барьеры без доступа к бинарникам. Asahi Linux запрещает LLM-ассистированную разработку, что делает драйвер неприемлемым для их upstream. Однако часть сообщества считает эту политику устаревшей. Автор опровергает обвинения в сокрытии связей с Apple и использования LLM, ссылаясь на публичность своего резюме и GitHub. Большинство признает создание рабочего драйвера за месяц прорывом, доказывающим, что реверс-инжиниринг сложного железа больше не требует десятилетий ручного труда. Производительность в 212 FPS в Minecraft на M4 Mac Mini подтверждает готовность продукта к реальному использованию. Сообщество отмечает, что если бы Apple открыла спецификации, проблем бы не возникло, а LLM дают шанс использовать оборудование по назначению. Существует мнение, что драйвер можно переписать независимо («белый ящик»), что сделает его юридически воспроизводимым при раскрытии методологии. В связи с этим автору советуют опубликовать полную документацию и процесс разработки для расширения работы на чипах M5 и выше, а также попытаться отправить код напрямую в upstream Linux, чтобы узнать реакцию Линуса Торвальдса и сообщества. Относительно качества кода одни опасаются «одноразового» ПО, другие верят в архитектурную устойчивость при правильном руководстве. В целом разработка без доступа к бинарникам Apple признана значительным шагом вперед. В качестве следующего этапа реверс-инжиниринга Apple Silicon предлагают изучить TouchID. Сравнение этого процесса с анализом дешевых LTE-модемов признано справедливым, так как цель везде одна — взаимодействие с закрытым железом.

В статье рассматриваются альтернативы MinIO для локального S3-хранилища в однозузовом режиме, с акцентом на простоту замены в Docker Compose и минимальные изменения кода. Автор тестирует несколько решений, сохраняя клиент mc для совместимости.

S3Proxy — лёгкий вариант на Java с Apache 2.0 лицензией, Docker-образом (5M+ загрузок) и хорошей S3-совместимостью. Конфигурация простая, но зависит от jclouds, который был перемещён в Apache Attic в mid-2025 — хотя для локального использования это, вероятно, не критично.

RustFS — проект на Rust с GUI, Docker-образом (100k+ загрузок) и Apache 2.0 лицензией. Однако недавно обнаружен серьёзный уязвимость (GHSA-h956-rh7x-ppgj), что вызывает осторожность. Проект находится в альфа-стадии, интерфейс выглядит полированным, но некоторые ссылки ведут на одну страницу — «свежая покраска». Подходит для демо, если легко заменить.

SeaweedFS — зрелый OSS-проект с S3-поддержкой с 2018 года (release 0.91), Docker-образом (5M+ загрузок) и Apache 2.0 лицензией. Требует отдельного конфига для аутентификации, но проект обещает упростить это. Имеет базовый UI, хотя сайт выглядит как enterprise-продукт без явной ссылки на GitHub — что может ввести в заблуждение. Простой переход, минимальные правки.

Garage — упоминается как сложный в настройке из-за строгой валидации ключей (например, ключ должен начинаться с GK и содержать 12 hex-байт), что избыточно для локальных демо и создаёт барьер входа. Не подходит как «drop-in» замена.

Apache Ozone и Ceph Object Gateway — отвергнуты как слишком тяжёлые: Ozone требует минимум четырех узлов для работы, Ceph — избыточен для локального стека. Оба имеют Hadoop-наследие и не подходят для лёгкой интеграции в Docker Compose для демонстраций.

Итого: для простой замены MinIO в локальном режиме лучшие варианты — S3Proxy и SeaweedFS; RustFS — рискован из-за уязвимости и альфа-статуса; остальные — избыточны.

Обсуждение подтверждает потерю доверия к MinIO из-за смены лицензии и выделяет альтернативы с опытом эксплуатации в продакшене: * **Garage**: стабилен в одноузловом режиме (до 10 ТБ), но требует NVMe для метаданных. Не поддерживает перебуферизацию, политики хранения на уровне бакета и строгую согласованность, что делает его непригодным для Iceberg. * **SeaweedFS**: надежная замена с поддержкой IAM, OIDC и Iceberg, но требует больше настроек; ранее были проблемы с API удаления пользователей и отсутствием S3 expiry rules. * **RustFS**: подходит для архивирования, но CVE в прошлом подорвали доверие к надежности. * **S3Proxy**: легкий, популярен (5M+ загрузок), рекомендуется для локальной разработки и тестирования. * **pgsty/minio**: форк MinIO, используется в end-to-end тестах как быстрый локальный симулятор. * **VersityGW**: поддерживает POSIX-бэкенд, сохраняя multipart-загрузки как реальные файлы, что упрощает отладку. * **LocalStack**: простое решение для разработки, особенно при необходимости других AWS-сервисов. * **JuiceFS** (китайский проект) и **Scality S3 (Zenko)** (требует актуальный Docker-репозиторий) — рабочие решения. * **Incus**: имеет встроенный S3-сервер для пользователей LXD-экосистемы (совместимость с S3 API не детализирована). * **S2** и **Filestash** с S3-шлюзом упомянуты без деталей опыта использования. Для Iceberg критична поддержка conditional GET/PUT/DELETE и ETag (строгая согласованность), поэтому SeaweedFS предпочтительнее Garage. В дискуссиях отметили, что альтернативы часто являются компромиссом по функционалу. Для простых локальных задач предлагают s3fs или прямой файловый доступ вместо перегруженного MinIO, хотя другие настаивают на необходимости S3-совместимости для интеграции. Также упомянуто, что для сценариев «good enough» AI-инструменты (например, Claude) позволяют быстро создать простой S3-прокси.

Ubuntu 26.10 завершает переход на Rust-версии базовых утилит coreutils, включая cp, mv и rm, которые ранее оставались на GNU-версиях из-за уязвимостей TOCTOU (time-of-check to time-of-use). Эти проблемы были исправлены в upstream-версии uutils, что позволило дистрибутиву полностью перейти на memory-safe реализации. Теперь в «Stonking Stingray» поставляется полный набор Rust-утилит: ls, cat, chmod, du и другие, обеспечивая drop-in совместимость с GNU-версиями без функциональных изменений для конечных пользователей.

Переход начался в 2025 году Canonical начала «оксидировать» Ubuntu, заменяя критически важные компоненты на Rust-аналоги для повышения безопасности: язык ловит ошибки памяти на этапе компиляции, в отличие от C. Первым шагом стал Rust-базированный sudo в Ubuntu 25.10, а позже — аудит uutils от Zellic, который выявил именно те TOCTOU-проблемы, что задерживали миграцию. Canonical также ежегодно выделяет €40 000 фонду Trifecta Tech Foundation, поддерживающему разработку Rust-программного обеспечения, включая переписывание NTP на Rust, которое планируется сделать клиентом по умолчанию к Ubuntu 27.10. Релиз Ubuntu 26.10 «Stonking Stingray» стабильной версии ожидается 15 октября 2026 года.

Переход на Rust-версии coreutils в Ubuntu 26.10 вызывает сомнения из-за багов, падения производительности и нарушения совместимости. Основные проблемы: — Нестабильность: uutils rm вызывает segfault при удалении директорий с 32K элементами, в отличие от GNU rm. — Производительность: dd из uutils v0.8 на Ubuntu 26.04 снижает скорость передачи с 350MB/s до 30MB/s из-за некорректной обработки буферов (критично для Ganeti). @linsomniac рекомендует использовать bs=32k вместо bs=1M для обхода проблемы. — Безопасность и совместимость: Rust-утилиты тянут множество зависимостей, увеличивая поверхность атаки, и ломают политики AppArmor. sudo-rs не поддерживает все опции оригинального sudo, что делает его непригодным для продакшена. — Зависимости: build-essential и sudo-rs теперь зависят от uutils, что затрудняет откат на GNU-версии. Альтернативы и решения: — @linsomniac предложил установить coreutils-from-gnu с pinning на -10 приоритета для предотвращения обновления. — @WatchDog отметил, что Fil-C позволяет компилировать GNU coreutils с более строгими гарантиями памяти без потери совместимости и с меньшим падением производительности, чем у uutils. Участники обсуждения (@atoav, @dsign, @1saadcodes) призывают оценивать утилиты по реальным показателям корректности и совместимости, а не по предпочтениям к языку. Многие (@synergy20, @sehw, @forest_brothers) считают замену отлаженных компонентов незрелыми версиями введением нестабильности и поводом для перехода на Debian или Mint.

JPEG XL — технически впечатляющий кодек, превосходящий JPEG и более универсальный, чем WebP, но его место в браузерах под вопросом. Хотя он был отклонён Chrome в 2023 году, появление Rust-декодера в Firefox и Chrome может сигнализировать о пересмотре позиции, особенно на фоне уязвимости WebP 2023 года. Однако автор, ранее поддерживавший JPEG XL, теперь считает, что его преимущества для веба исчерпаны. По объёму веб-контента подавляющее большинство изображений обслуживается с потерями, а без потерь JPEG XL выигрывает лишь около 11,9% перед WebP — на искусственном наборе данных (157 Мп фото, 10 Мп иллюстраций, 27 Мп книг), неrepresenting типичный веб. Это слишком мало, чтобы оправдать внедрение нового кодекса в браузеры, особенно учитывая, что в lossy-сжатии JPEG XL уступает конкурентам.

Современные энкодеры, включая AV1, достигли лучшего соотношения скорости и качества на бит благодаря perceptual tuning на основе человеческих испытаний. AVIF теперь доминирует во всём диапазоне fidelity, нивелируя единственное реальное преимущество JPEG XL. Автор отмечает, что дискуссия вокруг JPEG XL часто отражает желание большего выбора для разработчиков, а не техническую необходимость, особенно на фоне политики вокруг Google и AV1. Тем не менее, JPEG XL остаётся ценным для профессиональных сценариев вне веба — фотографии, печать, медицинская визуализация — где его возможности могут быть востребованы. В браузерах же его внедрение сейчас не кажется оправданным.

Обсуждение подтверждает сомнения автора в перспективах JPEG XL для веба, добавляя данные о производительности, сложности реализации и ограничениях аппаратного декодирования, а также подчёркивая политические и патентные факторы, влияющие на его принятие, но указывает на потенциальные ниши в профессиональном фото‐ и RAW‐рабочем процессе. libjxl и cjpegli позволяют получать компактные, высококачественные изображения даже для контента с высоким частотным спектром, например комиксов, где другие кодеки требуют компромиссов. WebP‐lossless ограничен 8‐битным RGB, поэтому отдельный формат для истинно lossless‐изображений остаётся необходимым. JXL‐preview в macOS сильно нагружает процессор и память из‐за вычисления «prime», что делает его потенциальным вектором DoS даже для небольших файлов. JXL выигрывает в lossless‐сжатии над WebP и PNG, но в lossy‐режиме часто уступает AVIF и даже обычному JPEG. Аппаратные декодеры AVIF ограничены профилем Main (4:2:0), что делает его менее подходящим для фотосъёмки, где предпочтителен 4:4:4 и 10‐бит. Спор: Некоторые считают, что отсутствие поддержки браузерами препятствует использованию JXL вне веба, в то время как другие указывают, что основные сценарии (например, отправка фото по e‐mail) всё равно требуют транс‐кодирования. Спор: Вопрос открытости: JXL полностью открытый, тогда как AVIF основан на AV1, который хотя и royalty‐free, но имеет патентные споры (Sisvel/Access, Dolby vs Snap), что меняет баланс сравнения. Камеры пока не поддерживают JPEG XL; поддержка ограничивается HEIF, а JPEG остаётся доминирующим форматом из‐за совместимости. Adobe включил JPEG XL в PDF, что может заставить браузеры добавить поддержку формата для корректного отображения PDF‐документов. Совет: Для веб‐публикаций рекомендуется удалять метаданные и транскодировать в уже поддерживаемый формат, поскольку экономия трафика от JXL не компенсирует совместимостиных проблем.

Rust получил статус Tier-1 языка в Microsoft, став одним из четырёх основных языков внутренней разработки наряду с C++, C# и TypeScript. Это означает, что внутренние команды получают полностью поддерживаемый путь от локальной разработки до продакшена: надёжные сборки инструментария, продуктивные инструменты для разработчиков, качественные рабочие процессы, глубокую интеграцию с платформой и соответствие требованиям Security Development Lifecycle (SDL). Microsoft активно инвестирует в Rust Project и поддерживает его стратегическое значение, что подтверждается выступлением Марка Руссиновича на RustConf и долгосрочной эволюцией Windows и MSVC alongside C и C++.

Статус Tier-1 подразумевает не только техническую поддержку, но и организационную готовность: Rust теперь используется в критически важных системных компонентах, где важны безопасность и производительность. Интеграция с Windows и MSVC обеспечивает совместимость с существующей экосистемой, а соблюдение SDL гарантирует, что код на Rust проходит те же строгие проверки безопасности, что и код на других поддерживаемых языках. Это укрепляет позицию Rust как языка выбора для системного программирования в масштабах предприятия.

Microsoft перешёл на Rust как tier-1 язык, главная мотивация — снижение 70% CVE, связанных с уязвимостями памяти, как отметил Mark Russinovich. Rust интегрирован с MSVC-бэкендом (rustc_codegen_utc), что критично для совместимости с внутренней инфраструктурой, а не только с LLVM. Rust не заменяет C++, а внедряется через интероперабельность — акцент на interop с C++, Python и JS, а не на ревайт. Проблемы: долгая компиляция в крупных проектах, отсутствие полноценной отладки в Visual Studio — ключевой барьер для массового внедрения. Интеграция с WinRT и Windows UI-фреймворками неясна, нет публичных нативных библиотек для WinRT 3.0. Споры: есть сомнения в реальной поддержке Rust в VS, но её появление считают логичным следствием статуса tier-1. Одни предлагают писать на C++, другие — постепенно внедрять Rust через обёртки и WASM (как в KTextEditor и WebGL). Советы: не ждать полного ревайта — начинать с новых модулей; Rust Foundation должен сохранять открытость rustc_codegen_utc, чтобы Microsoft не ограничила доступ, как с другими технологиями. Статус tier-1 подтверждает зрелость Rust как серьёзного конкурента C++ и C# в системном программировании.

Cloudflare оптимизировала хранение записей в DNS-кэше Big Pineapple, сократив потребление памяти на 100 ТБ без потери производительности. Кэш содержит более 250 млрд записей, и даже экономия одного байта на запись эквивалентна 250 ГБ. Пять последовательных улучшений уменьшили размер одной записи с 953 до 420 байт — на 56% — за счёт устранения избыточности в структурах данных: замена Vec<T> на более компактные типы там, где длина известна или ограничена, оптимизация выравнивания и удаление неиспользуемых полей. Это также снизило количество аллокаций на запись с 1,1 КБ до 461 байт.

Производительность при этом выросла: пропускная способность вставки увеличилась на 43% (с 625 тыс. до 893 тыс. записей/с), а латентность поиска снизилась на 19% (с 828 до 670 нс) благодаря лучшей локальности памяти и меньшему числу операций分配. В продакшене наблюдалось снижение резидентной памяти на 42–43% на перцентилях p90 и p99. Освободившиеся ресурсы планируется использовать для увеличения ёмкости кэша, что повысит коэффициент попаданий и уменьшит нагрузку на апстрим-DNS. Дальнейшие улучшения кэша находятся в исследовании.

Оптимизация памяти на сотнях терабайт требует глубокого понимания структур данных и системного программирования, а не только масштабирования железа, и даёт кратные выигрыши на практике. Экономия даже одного байта на записи критична: в Cloudflare это сэкономило 250 ГБ на миллиардах записей. Одно крупное выделение памяти вместо множества мелких (single malloc) сокращает потребление в 20+ раз (опыт MaraDNS с чёрными списками). Выравнивание полей в Go экономит до 8 байт на объекте, что значимо при миллионах экземпляров. Хранение данных в сериализованном виде вместо разобранных структур улучшает локальность, если основная операция — чтение с повторной сериализацией. Радикальные оптимизации возможны и в прикладных задачах: в игре Wavetale потребление снизили с 20+ ГБ до 3 ГБ. Спорный момент: замена нескольких Vec на один смещённый буфер в Rust технически корректна, но лишает гарантий безопасности границ подсрезок. Советы: - Для DNS-ключей с общими префиксами (com.site.www) подходит radix tree. - Использование Box для указателей избыточно при низком потреблении памяти: 4–8 байт вместо 16. - jemalloc не всегда оптимален для многопоточных нагруженных систем. - Сжатие данных в памяти эффективно при редком декодировании и высокой повторяемости (как домены). - Формат в памяти отличается от сериализованного — компактные структуры эффективнее стандартных языковых объектов. Оптимизация должна быть частью проектирования, а не последним шагом: многие системы становятся избыточными из-за игнорирования масштабируемости на ранних этапах.

LLM-ассистент для кода стал практичным после перехода от хаотичных запросов к системному управлению через файл agent.md в корне проекта. Раньше генерация кода давала компилируемые, но нечитаемые монолиты — например, сложный бинарный кучу в Rust с скрытыми багами в polling-библиотеке. Качество росло только после внедрения «агента»: теперь LLM получает чёткие инструкции по стилю, структуре и архитектуре прямо в prompt, что позволяет фокусироваться на дизайне, а не на правке мусора.

Ключевые правила agent.md: минимум слов в комментариях, константы вместо магических чисел, короткие имена функций (<30 символов), ранние возвраты вместо вложенных блоков и строгое соблюдение слоёв абстракции. Особенно важно — не трогать чужой код, добавлять комментарии только к изменённым участкам и использовать пустые строки для «дыхания» читателя. Без этого даже мощные модели теряют контекст («context dilution»), особенно в длинных сессиях. Решение — короткие сессии и явный вызов «reload agent.md» при падении качества. Теперь я вижу, как LLM пишет код, похожий на человеческий, но только если я сам задаю тон: без похвалы, с жёсткими ограничениями и фокусом на читаемость.

AGENTS.md устаревает: современные модели (Opus, Fable, SOTA) требуют меньше процедурного коучинга, а детальные инструкции игнорируются или загрязняют контекст. Базовые правила форматирования (например, скобки в if) должны enforced линтерами, а архитектурные контексты — в CONTRIBUTING.md или CODING_STANDARDS.md. AGENTS.md должен содержать только специфичные для ИИ инструкции. Эффективнее использовать краткие позитивные директивы («делай Y»), а не запреты («не делай X»), и многопроходный подход: сначала добиться работы, потом ревью по гайдлайнам. Правило «Convergence» (завершение успехом, прогрессом или честной остановкой с доказательством) предотвращает бесконечную генерацию патчей. ASD-STE100 снижает вербозность ответов. Явно запрещать трогать несвязанный код — критично. Вместо статичных файлов — динамическое обновление AGENTS.md ИИ по мере проблем. Эффективнее заставлять агента самому определять применимые правила — это даёт 100% консистентность и экономит контекст. «Перечитай AGENTS.md» — баг harness-а; контекст должен композиться автоматически. Ключевые слова SHALL/MUST помогают локальным LLM. Споры: длина имён функций — ограничения vs. целостность контекста; необходимость AGENTS.md вообще — код как спецификация vs. явные архитектурные указания. AGENTS.md считают «костылём» — новые модели лучше работают без него.

Rust Glancer — альтернативный LSP для Rust, разработанный с фокусом на минимальное потребление памяти. Проект реализует полноценный индексирующий движок с поддержкой типовой инференции, trait‑solver (chalk) и большинством стандартных LSP‑действий: переход по определению, подсказки, автодополнение. Ключевая особенность — возможность поддержания индекса после перезапуска, что устраняет повторную индексацию и экономит время. На тестах на MacBook Pro M1 (2020, 8 ГБ RAM) среднее время индексации составило 6 секунд против 7 секунд у rust‑analyzer, а использование RAM оставалось ниже 100 МБ.

В отличие от rust‑analyzer, который опирается на salsa‑базу и rowan‑дерево, вызывающие значительные накладные расходы на память из‑за инкрементального хранения и фрагментации, Glancer использует собственный engine‑as‑subprocess‑model, выравнивает жизненные циклы выделений и шардирует кэш, что позволяет сократить фрагментацию и держать отпечаток памяти в узком диапазоне. Планируется дальнейшее ускорение, улучшение поддержки синтаксиса и расширение функций (code actions, более точная типовая инференция, ограниченный proc‑macro‑подход). Пока проект находится в стадии «daily‑driver», но уже доступен через VS Code‑extension и готовый к самостоятельной установке.

Rust Glancer — альтернатива rust-analyzer, решающая проблему чрезмерного потребления памяти, особенно в крупных проектах. В отличие от rust-analyzer, он сохраняет индекс на диске и загружает его по необходимости, снижая пиковое потребление ОЗУ — критично при ограниченных ресурсах. Пользователи рекомендуют его как полезный компромисс, особенно при нехватке памяти и использовании Neovim с LSP. Автор popzxc отмечает, что приоритезация открытых файлов компенсирует отсутствие инкрементальности, делая подход приемлемым для повседневной работы. Сомнения вызывают: почему rust-analyzer потребляет больше памяти, чем диск-кэш (potamic), и насколько корректен Rust Glancer без формальной спецификации Rust (bip-bop-robot). LSP — общеизвестный термин в Rust-сообществе.

Cobalt — открытая платформа, превращающая Kobo‑ридер в мини‑маркет приложений. После единожды установленного через USB‑кабель каждый новый софт загружается, обновляется и удаляется по Wi‑Fi, а процесс каждого приложения изолирован в отдельном unprivileged‑процессе. Главное преимущество — полная автономность: после перезагрузки возвращается обычный Kobo‑интерфейс, а установленные приложения живут независимо от платформы.

Особенно стоит отметить несколько ярких решений: arXiv просматривает новые предпечати и отображает их полностью на экране; Sudoku и Morse демонстрируют работу UI‑элементов и даже Morse‑код на переднем свете; Gutenbird позволяет читать любые OPDS‑библиотеки, включая Project Gutenberg. Всё это работает на реальном железе — ARM‑бинарники запускаются без root‑доступа, подписи проверяются перед запуском, а установка требует лишь rustup и cargo для сборки. Главное правило: поддерживаются только проверенные модели (на данный момент — Clara BW), и любые изменения можно откатить, перезагрузив устройство.

Тред отражает поляризацию между пользователями, ценящими расширяемость ридеров (Obsidian, Zotero, Libby, KOReader, NickelMenu) и теми, кто настаивает на изоляции от цифрового шума, считая ридер одноканальным инструментом. Критики отмечают, что e-ink не гарантирует фокус — Kindle с браузером и iPad с отключенными уведомлениями демонстрируют это. Технически: двухъядерный процессор критичен для стабильной работы модификаций — он есть в цветных моделях Kobo (Color), но отсутствует в черно-белых (BW). На некоторых устройствах (например, Clara) возможна установка PostmarketOS для Linux-приложений, но это сложнее, чем Cobalt. Пользователи требуют нативную интеграцию с Libby, Zotero, Obsidian и RSS-сервисами, чтобы избежать конвертации в EPUB. Некоторые критикуют использование LLM для описаний и кода как «slop», другие шутят, что ИИ заметил детали, упущенные людьми. Владельцы Kindle выражают зависть к открытости Kobo, полагая, что аналогичная платформа вернула бы их к активному использованию. Для чистого текста черно-белые экраны считаются четче, чем цветные, несмотря на лучшую производительность последних.

В августе 2026 года в cargo.io появилась поддельная версия arrayref 0.3.10. В её зависимостях скрыт типосквот proc-macro1, чей скрипт сборки скачивает и запускает удалённый бинарный файл во время компиляции. Поскольку выполнение происходит на этапе сборки, любой проект, использующий эту версию, автоматически активирует вредоносный код.

Ключевой факт: злоумышленники использовали поддельный аккаунт dtolney, имитируя dtolnay, и разместили в proc-macro1 build‑script сервер‑команду hxxps://23[.]254[.]165[.]112:9089. Декодированные фрагменты указывают на адрес 23.254.165.112 и порт 9089 (payload) и 443 (C2). На Linux‑системах бинарник сохраняется в /tmp/rust-setup и запускается в фоне, а на Windows — в %TEMP%\rust-setup.ps1 через скрытый VBScript‑launcher, что позволяет процессу продолжать работу после завершения сборки.

Эти детали позволяют быстро распознать индикаторы компрометации: запросы к 23.254.165.112:9089 и 443, появление /tmp/rust-setup или %TEMP%\rust-setup.ps1. Удалённый код может выполнять любые действия, пока сборка уже завершена, поэтому важно сразу откатывать все зависимости от arrayref 0.3.10 и ниже, а также проверять целостность публикуемых crates.

Rust-экосистема уязвима к атакам на этапе сборки из-за отсутствия sandboxing для build.rs и proc-macro, слабого контроля зависимостей и чрезмерной фрагментации — что повторяет ошибки npm. Вредоносный код скрывается от сканеров, не попадая в финальный бинарник, а действуя только во время компиляции. Атаки типа left-pad (например, append-only-vec) показывают, что даже тривиальные зависимости увеличивают поверхность атаки. Необходимо: — реализовать sandboxing для build.rs (например, через Seatbelt на macOS, Landlock/seccomp на Linux, microVM или bubblewrap); — ввести min-release-age для зависимостей, чтобы дать время на обнаружение вредоносных пакетов; — требовать явного разрешения на новые build.rs и proc-macro, как в pnpm; — выполнять сборки в изолированных средах, исключающих доступ к ключам и чувствительным данным хоста; — применять статический анализ и AI-сканирование изменений перед публикацией на crates.io; — развивать стандартную библиотеку, чтобы снизить зависимость от сторонних пакетов для базовых операций; — внедрять языковые механизмы эффектной типизации для декларативного запрета сетевого доступа, FFI и записи в файл до компиляции; — использовать локальные репозитории для контроля версий, как в Conan для C++; — избегать автоматических обновлений зависимостей без проверки (пример: arrayref 0.3.10). Спор о том, хуже ли Rust, чем npm, несущественен: проблема — не в языке, а в политике управления зависимостями и отсутствии изоляции.

Sonic Pi v5 представляет собой фундаментальный перезапуск популярной среды для живого кодирования музыки, теперь построенной на Rust и новом звуковом ядре. Главное нововведение — интеграция Link-протокола, позволяющая синхронизировать несколько экземпляров Sonic Pi между собой и с другими приложениями, такими как Ableton Live, без задержек. Это превращает его из одиночного инструмента в узел в распределённой музыкальной сети. Также добавлены новые синтезаторы, улучшенная поддержка MIDI и переработанный интерфейс с более плавной анимацией и улучшенной читаемостью кода.

Версия v5 сохранила простоту Ruby-синтаксиса, которая сделала Sonic Pi популярным в образовании, но теперь работает в 3–5 раз быстрее благодаря оптимизациям на уровне ядра. Поддержка многопоточности стала более предсказуемой, а ошибки в коде теперь реже приводят к полной остановке звука. Разработчик Sam Aaron подчеркивает, что цель — не просто улучшить производительность, а сделать живое кодирование более надёжным и масштабируемым для сценических выступлений и совместных проектов.

Тред дополняет статью опытом использования Sonic Pi, его сравнением с другими инструментами (например, Strudel) и обсуждением лицензирования. Пользователи подтверждают, что Sonic Pi — удобный инструмент для начинающих и профессионалов, подходящий как для хобби, так и для профессиональной работы. Обсуждается риск нарушения авторских прав при использовании семпла Amen Brother breakbeat. Также затрагивается вопрос о названии: некоторые предлагают изменить его, чтобы избежать путаницы с Raspberry Pi.

В версии ripgrep 15.2.0, собираемой под x86_64‑unknown‑linux‑musl, иногда возникает SIGSEGV при поиске по очень большим каталогам при высокой степени параллелизма. Ошибка проявляется в момент вызова calloc внутри opendir, когда проверка целостности кучи в MUSL‑mallocng падает. Для воспроизведения требуется массив файлов порядка 20 GiB и 1.8 млн файлов; достаточно запустить цикл rg <незначающаяся строка> и дождаться сбоя, что обычно происходит через минуту на 24‑ядерной машине с достаточным свободным RAM. Сборка производилась с debug‑символами через cross‑toolchain, а в бинарнике включены функции PCRE2 10.45 с поддержкой JIT.

Следствие backtrace указывает, что сбой происходит в get_meta (../src_musl/src/malloc/mallocng/meta.h:141) и заканчивается в цепочке вызовов std::fs::read_dir → ignore::walk::Worker::run → std::thread::spawn. При этом в стеке виден вызов calloc из opendir и падение в std::panic::catch_unwind. Таким образом, проблема связана с некорректной работой динамического распределения памяти в MUSL при одновременном обходе большого количества директорий, что приводит к повреждению метаданных кучи и аварийному завершению процесса. Кроме того, в стеке видно, что сбой происходит в контексте пула потоков ignore::walk, где каждый поток одновременно читает каталоги, что усиливает конкуренцию и ускоряет появление ошибки.

Тред обсуждает причины SIGSEGV в ripgrep при поиске по большим каталогам, включая проблемы с musl-аллокатором при многопоточности, которые могут снижать производительность. По опыту @Orphis, замена musl на mimalloc улучшает производительность в 20 раз. Проблемы могут быть связаны не только с аллокатором, но и с подходом к поиску и обработке данных. Рекомендуется использовать альтернативные аллокаторы, такие как mimalloc.

Кто‑то заявляет, что проект Bun переписали на Rust с помощью Anthropic‑инструмента, потратив за 11 дней около $165 000, то есть $15 000 в день, и слили код в main. При этом релизный тег не появился уже несколько недель, а количество открытых pull‑request‑ов от Claude‑бота выросло с 1277 до 2475, а каждый merge занимает от 40 минут до полутора часов, значит для закрытия всех PR потребуется около 86 дней непрерывного цикла. При этом в CI/CD Buildkitecluster задействованы тысячи минут вычислительных ресурсов, о которых в публичных цифрах не сообщается.

Эти цифры вызывают сомнения: $15 000 в день — это лишь часть расходов, а реальная стоимость может быть в несколько раз выше, включая затраты на инфраструктуру. Вопрос остаётся открытым — оправдано ли вкладывать такие суммы в «AI‑переписку», если компания оценивается в миллиарды, а результат пока не виден в виде готового продукта. Именно поэтому стоит относиться к таким заявлениям с осторожностью.

Bun переписывается на Rust и уже используется в Claude Code; команда фокусируется на исправлении ошибок и доработке кода, а не на выпуске новой версии. Пользователи и разработчики обсуждают использование LLM для переписывания кода: одни видят в этом способ ускорить разработку, другие — риск снижения качества и потери контроля. Рекомендуется тщательно тестировать и проверять код, полученный с помощью LLM.

Клауд Код версии 2.1.181 и новее использует русти‑порт Бан, о котором Джед Сэмнер объявил, что ускорил старт на Linux примерно на 10 %, но в остальном изменения незаметны — «Скучность хороша». При проверке собственного бинарника я обнаружил строку «Bun v1.4.0 (macOS arm64)», хотя официальная версия Бан на GitHub находится на 1.3.14, что указывает на предварительную поставку новой версии. Кроме того, поиск по шаблону «src/….rs» выдал 563 файл‑пути, среди них «src/runtime/bake/dev_server/mod.rs», «src/runtime/bake/production.rs», «src/bundler/bundle_v2.rs», что подтверждает наличие полностью русти‑реализации.

Таким образом, Бан, переписанный на Русте, уже работает в продакшене на миллионах устройств, и его использование остаётся в тени, как и планировалось. Цитата Джеда подчёркивает, что «скучность» — признак зрелого решения, которое не требует рекламных шумов. Эти детали подтверждают, что команда Бан переписала свой движок полностью на Русте, заменив прежний JavaScript‑вариант, и что такой подход уже применяется в реальном времени у миллионов пользователей, не вызывая заметных проблем. Именно поэтому такие изменения часто остаются незамеченными, но они формируют основу будущих улучшений.

Клауд Код использует Бан, написанный на Русте, что подтверждает @mrothroc и @aureate (не последняя версия), и ускорил старт на Linux на ~10%. Однако @gabrieledarrigo критикует подход Anthropic к переписыванию Бан как неадекватный, а @embedding-shape и @throwatdem12311 выражают обеспокоенность прозрачностью управления. @softwaredoug сомневается в выгодах от переписывания Бан на Русте, @rekttrader считает, что у Anthropic нет мотивации улучшать код. @weakfish и @harrisi недоумевают по поводу использования JavaScript для ТУИ, @GuB-42 предлагает переписать Клауд Код напрямую на Русте. Клауд Код стал более баги, сложным и нестабильным — это подтверждают @Aeveus, @codethief, @512colors, а @LAC-Tech и @jason_s опасаются стабильности и безопасности. @hmokiguess отмечает, что Клауд Код использует и другие технологии.

Команда проекта ROC переписала около трёхсот тысяч строк кода, написанного на Rust, на язык Zig, чтобы создать новый компилятор. После полугода работы они достигли полной функциональности, что позволило запустить игру Rocci Bird, написанную на Roc, в браузере через WebAssembly. Размер скомпилированного wasm‑файла сократился до 31 КБ, тогда как прежний компилятор генерировал бинарник более чем в два раза больше. Для этого в новый компилятор были внедрены важные возможности: поддержка новых конструкций, улучшенный тип‑cheker и система разрешения лямбд. Благодаря этим изменениям проект получил более компактный и быстрый код, а также более предсказуемую модель памяти.

Следующий шаг — выпуск версии 0.1.0 нового компилятора к концу года, при этом ночные сборки уже доступны для тестирования. Автор отмечает, что более ста примеров из курса Exercism были обновлены, а команда благодарна за помощь Anthony Bullard, Sam Mohr, Jared Ramirez и других, которые доработали парсер, тип‑cheker и систему разрешений. Проект поддерживается фондом ROC, принимающим пожертвования; средства идут на оплату разработчиков. Если вы хотите помочь, вы можете присоединиться к обсуждениям в Zulip или стать спонсором.

Обсуждение добавляет к статье различные мнения о выборе языка для проекта Roc, включая опыт эксплуатации, возражения и цифры из практики. Комментарии подтверждают, что команда проекта выбрала Zig из-за его incremental builds и контроля памяти, но также высказываются мнения о том, что Rust мог бы быть улучшен для достижения аналогичных результатов.

• Спор: Некоторые участники обсуждения сомневаются в необходимости перехода на Zig, указывая на то, что Rust мог бы быть улучшен для достижения аналогичных результатов. @onlyrealcuzzo считает, что incremental builds Zig - это killer feature, но задается вопросом, можно ли ожидать появления аналогичной функциональности в Rust в ближайшем будущем.

• Совет: @lioeters предлагает добавить borrow checker к Zig вместо ожидания более быстрого компилятора в Rust.

• Участники обсуждения согласны с тем, что incremental builds Zig - это значительное преимущество. @KoleSeise1277 считает, что 35ms incremental rebuild - это то, что продает Zig.

• Спор: @norir и @munificent спорят о том, что производительность компилятора определяется алгоритмами, а не языком программирования. @norir утверждает, что его опыт показывает, что алгоритмы доминируют над производительностью компилятора.

• Совет: @dnautics упоминает проект clr, который пытается объединить безопасность Rust с features Zig.

This piece would have been a lot more compelling if they had actually done science on selecting a language for compiler development. From what I can tell, they had an untested hypothesis that a low level systems language is necessary for a high performance compiler… — @norir

SQLite по умолчанию игнорирует ограничения внешних ключей и допускает хранение данных неверного типа, что приводит к скрытым ошибкам. В частности, ограничения foreign key отключены, а ROWID может переиспользоваться, поэтому удаление пользователя без удаления его записей не вызывает ошибки, а при создании новой записи с тем же id получается ссылка на чужой пост; включив PRAGMA foreign_keys=ON, получаем сообщение «Runtime error: FOREIGN KEY constraint failed (19)». Эти особенности делают базу уязвимой, хотя и обеспечивают совместимость со старым кодом.

Автор предлагает ввести «редацию» SQLite, аналогичную системе версий Rust, где PRAGMA edition=2026 будет включать набор pragmas: foreign_keys=ON, busy_timeout=5000, journal_mode=WAL, synchronous=NORMAL и включать строгий режим таблиц. Такое изменение сохраняет обратную совместимость, но позволяет постепенно улучшать параметры, например в будущих версиях добавить WAL2. Настройки повышают надёжность (проверка внешних ссылок), производительность (WAL, NORMAL) и упрощают миграцию на новые версии.

Эти pragmas также включают busy_timeout=5000, чтобы избежать блокировок, и включают строгий режим, который требует указания всех обязательных полей, что упрощает поддержку схемы. Таким образом, пользователь получает набор «безопасных» настроек, который можно активировать одной командой, не ломая старый код.

Обсуждение добавляет к статье практические примеры использования SQLite, возражения против введения 'изданий' и опасения по поводу совместимости и фрагментации.

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

• Совет: Участники рекомендуют использовать wrapper-библиотеки, которые устанавливают sensible defaults, или использовать альтернативные базы данных, такие как PostgreSQL, для проектов, требующих более строгих гарантий.

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

• Спор: @kccqzy возражает против введения 'изданий' в SQLite, поскольку это может нарушить совместимость с более старыми версиями и усложнить использование базы данных.

• Совет: @Rendello предлагает обсудить эту идею на форуме SQLite, поскольку разработчики могут быть заинтересованы в рассмотрении этого предложения.

I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. — @bambax

Grok Build — инструмент от SpaceXAI для автономной работы ИИ в терминале. Он работает как полноэкранный TUI-интерфейс, способный редактировать код, выполнять команды shell, искать в интернете и управлять длительными задачами. Поддерживает три режима: интерактивный, головной (для скриптов и CI) и встраивание в редакторы через Agent Client Protocol. Бинарник grok написан на Rust, первое запуск требует аутентификации через браузер, а его ядро синхронизируется с монорепозиторием SpaceXAI.

Система построена как модульный каскад: от TUI-обёртки (xai-grok-pager-bin) до инструментов вроде редактора файлов и поиска (xai-grok-tools), хоста файловой системы и санкбоксов. Сборка требует Rust и protoc, поддерживает macOS и Linux, Windows — экспериментально. Документация включает руководства по клавишам, плагинам, настройке тем и головному режиму. Лицензия Apache 2.0 покрывает основной код, а сторонние компоненты — включая порты OpenAI Codex и OpenCode — указаны в отдельных NOTICE-файлах.

Обсуждение добавляет к статье информацию о том, что Grok Build уже используется и forked другими разработчиками, которые добавляют новые функции и исправляют проблемы, а также критику за большой размер кода и количество зависимостей.

• Разработчики приветствуют открытость Grok Build и считают это шагом в правильном направлении.

• Спор: Некоторые разработчики критикуют Grok Build за большой размер кода (1318853 строки) и количество зависимостей (182 top-level внешних зависимости).

• Совет: Рекомендуется использовать альтернативные инструменты, такие как pi.dev, из-за проблем с приватностью и безопасностью данных.

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

• Спор: Некоторые разработчики сомневаются в искренности SpaceX в отношении открытости и безопасности данных, учитывая недавний скандал с exfiltration данных.

I like that the trailing players strategy (Meta, xAI) is to open source the moat of the leaders. I think we will all benefit from it. and hopefully both the leaders and the trailing players will be much less powerful in the end. — @drdrek

Anthropic активно продвигает сценарий, что программирование исчезнет, а за ним последует исчезновение большинства человеческого труда, при этом привлекает более 130 млрд долларов инвестиций и планирует IPO стоимостью>$1 трлн, что делает её историю «ненадёжным рассказчиком». Этот амбициозный нарратив уже формирует решения в архитектуре, продукте и персонале, часто основываясь на страхе потери работы.

В центре спора — переход Bun, когда‑то написанного на Zig, в Rust. Bun заявлял о почти 100 % AI‑генерации кода, тогда как Zig официально запрещает использование ИИ, но в реальности код был «переписан» в unsafe Rust и быстро слит в основную ветку. Создатель Zig Эндрю Келли публично отреагировал резким, почти «меланхоличным» ответом, назвав ситуацию «переполохой», но многие читатели нашли в нём честный крик. Оценка этой истории требует скептицизма: миграция оказалась выгодной для обеих сторон, а детали остаются предметом интерпретаций. Bun был одной из крупнейших кодбаз на Zig, а его founder экспериментировал с агентным переписыванием, которое привлекло внимание СМИ и породило заголовки о «быстром AI‑переписывании». Этот процесс показывает, как крупные компании используют споры, чтобы формировать восприятие технологий, тогда как реальная проблема — сложность управления памятью в Zig.

• Обсуждение спора между сторонниками Zig и Rust حول перенос проекта Bun, включая критику стиля и мотивов авторов.
• Участники отмечают, что перенос в Rust был использован как маркетинговый ход Anthropic, а не чисто техническим улучшением.
• Вызываются вопросы о конфликте интересов, поскольку Zig‑сообщество открыто враждебно к ИИ‑генерируемому коду.
• Дебат подчёркивает разницу между созданием конечных продуктов и инструментарием/языками, а также роль человеческого контроля в AI‑помощных проектах.

Когда стартап, построенный вокруг JavaScript‑раннера, получил инвестиции, его подход резко изменился: вместо свободного развития он стал гоняться за быстрым выходом на рынок, а управление превратилось в «гонку», где требовалось «grind» даже в первые девять месяцев. Основатель публично заявлял, что «Oven будет тяжёлым», и требует от команды работать без баланса, что вызвало бурю недовольства среди бывших соискателей и сотрудников, которые описывали его как «плохого менеджера» с нереалистичными требованиями и низкой эмпатией.

В то же самое время качество кода в проекте ухудшалось: в репозитории скопилось множество костылей, злоупотребление ассертами и спешка в добавлении функций приводили к росту технического долга и рискам памяти, что вызывало критику со стороны сообщества Zig, где безопасность стала главным аргументом отстранения от проекта. Несмотря на ежегодную поддержку в размере $60 000, после покупки компанией Anthropic доноры прекратили встречи и пожертвования, оставив фонд без средств. Поэтому команда приветствовала переписывание на Rust, считая её шансом избавиться от «недостойственного» примера и вернуть доверие. Эта ситуация стала катализатором для перехода на Rust, который воспринимался как возможность очистить репозиторий и восстановить репутацию языка среди разработчиков.

• Автор обвиняет Джейрда в нечестности и личных нападках, несмотря на заявления о нейтральности.
• Обсуждается несоответствие заявлений о фузинге Zig и реальном отсутствии его использования в Bun.
• Критики считают пост эмоциональным, непофессиональным и ухудшающим имидж Zig.
• Есть мнение, что фокус на личных конфликтах мешает конструктивному техническому анализу.
• Некоторые видят в этом попытку монетизации или PR‑продвижения, а не объективный разбор.

Bun изначально появился как Zig‑порт esbuild, получивший сразу набор функций: транспилятор JavaScript/TypeScript, пакетный менеджер, тест‑раннер, HTTP‑клиент и др. За год он стал скачиваться более 22 млн раз в месяц и поддерживается компаниями Vercel, Railway, DigitalOcean и другими. Однако из‑за низкоуровневого кода на Zig в проекте накопилось множество критических багов — use‑after‑free, утечки памяти, гонки, которые приходилось фиксировать вручную.

Переписав ядро на Rust, команда добавила AddressSanitizer, постоянно запускает fuzzing и выпускает безопасные Release‑Safe‑билды. Это позволило полностью устранить use‑after‑free, утечки в crypto.scrypt, tlsSocket.setSession и другие уязвимости, а также сократить размер бина и ускорить warm‑install в 7 раз. Rust‑реализация обеспечивает системную защиту от подобных ошибок, делает Bun более надёжным и готов к дальнейшему развитию.

• Исключительно быстрый переход от Zig к Rust с помощью Claude Code, протестировавшего 100 % тестов за 11 дней.
• Стоимость переписывания оценивается в $165 000 токенов, что дешевле найма полноценной команды.
• Критика направлена на отсутствие открытого анализа проблем, а не на эмоции; многие отмечают рост надёжности и уменьшение размера бинарника.
• Дискуссия подчёркивает, что такой подход возможен только при наличии зрелых тест‑сьютов и опыта автора, а также вызывает вопросы о долгосрочной поддержке и выборе стека.

Lore — это новый открытый контроль версий, созданный Epic Games для масштабных игровых и развлекательных проектов, где код сочетается с большими бинарными артефактами. Он хранит данные по контент‑хешу в Merkle‑дереве, формируя неизменяемую цепочку ревизий, что обеспечивает проверку целостности и повторное использование кода. Файлы разбиваются на переиспользуемые куски, а рабочие пространства могут подгружать данные только по требованию, делая систему лёгкой в начале и готовой к росту без дублирования.

Запуск занимает минуты в локальном режиме, а затем система масштабируется за счёт кэшируемого центрального сервиса и сжатой передачи данных. Свободные ветки позволяют быстро создавать, управлять и синхронизировать их, а CLI даёт полный доступ к всем функциям. Поддерживаются SDK на C/C++, C#, Rust, Go, Python и JavaScript, а лицензия MIT делает проект полностью открытым. Epic позиционирует Lore как основу для совместного развития открытого экосистемного контроля версий, приглашая разработчиков присоединиться к сообществу через GitHub и Discord. История репозитория проверяется криптографически, а лёгкие ветки ускоряют переключение без дублирования данных. Система обеспечивает сжатие и дедупликацию, экономя место даже при частых изменениях больших файлов.

• Lore — новый VCS от Epic, ориентированный на игровую разработку и работу с большими бинарными артефактами, позиционируется как конкурент Perforce.
• Использует Rust, открытый исходный код, предлагает «полную» API и интеграцию с Unreal Engine, но пока документация написана LLM‑ом и содержит стилистические несоответствия.
• Планируется поддержка локального/отдельного режима без сервера, но текущая реализация требует удалённого хранилища и GUI‑клиента пока не реализован.
• Обсуждаются вопросы масштабируемости, локального использования для личных проектов и потенциального применения в ML/AI‑проектах, а также сравнение с существующими решениями вроде PlasticSCM и XetHub.

Автор выражает усталость от шаблонных постов в LinkedIn о сбое CloudFlare: все копируют друг друга через ChatGPT, фокусируясь на .unwrap() без проверки пост-мортема. Реальная проблема — отсутствие автоматизированных тестов или QA, даже feature flag выявил бы баг заранее. Посты отражают бездушный корпоративный подход: менеджеры дружат с ИИ, не заботясь о фактах или карьере, только о внешнем виде.

В компании автора изначально было мало менеджеров, фокус на инструментах и обучении — всё работало. Теперь 3 менеджера на 1 dev (автора), 40% времени уходит на busywork и тикеты в Linear вместо разработки. Менеджеры не снижают context switching, меняют приоритеты mid-cycle по клиентским хотелкам (не нуждам), винят dev в дрейфе проекта. Автор на PIP, увольняют в январе вместе с другими; компания стала стартапом с корпоративным адом, но он желает коллегам удачи. Дисклеймер: пост эмоциональный, из-за усталости продуктивность упала.

• Критика LinkedIn за кринжовый, AI-генерированный контент, контраст с реальной речью и корпоративный слоган, делающий платформу "адом".
• Полезность как инструмент для поиска работы, networking, продаж и контактов с коллегами, несмотря на плохой фид (рекомендуют игнорировать его).
• Предложения: использовать блокировщики, фокусироваться на профиле/поисках, вести блоги; сравнения с Twitter/FB как платформами самопрезентации.
• Обсуждение корпоративного ада (PIP, мотивация деньгами), эхо-камере и отсутствия альтернативы для рынка труда.

Facepunch Studios (создатели Garry's Mod и Rust) выпустили s&box — бесплатную sandbox-игру на движке Source 2 в раннем доступе на Steam. Это эволюция Garry's Mod с мультиплеером до 128 игроков, где любой может создавать миры, мини-игры и моды. Игра фокусируется на инструментах: встроенный asset browser с тысячами бесплатных моделей, текстур и звуков от сообщества; поддержка Lua и C# для скриптинга; хабы для шаринга контента.

Ключевые фичи — полная свобода редактирования в реальном времени, сетевой код для коллаборативного строительства, аватары и кастомизация. Код открыт под лицензией MIT, моды монетизируются через Steam Workshop. Команда обещает еженедельные обновления, борьбу с читерами и переход к полноценному релизу через 1–2 года. Уже 100+ хабов с проектами вроде Among Us или Fortnite-клонов.

• Facepunch (создатели Garry's Mod и Rust) открыли исходники S&box — движка на базе Source 2, эволюционировавшего от Garry's Mod 2 к Roblox-подобной платформе с собственным редактором.
• Успех компании: от гаража до $100 млн/год; критика за слабую Linux-поддержку в Rust из-за античита.
• В коде много мата в комментариях; MIT-лицензия, но зависимость от закрытого Source 2 вызывает вопросы о будущем и конкуренции с Unity/Godot/Roblox.
• Обсуждение потенциала для standalone-игр, монетизации и инструментов вроде Hammer, скепсис по поводу поддержки Valve.

18 ноября 2025 года Cloudflare столкнулся с масштабным сбоем сети, начавшимся в 11:20 UTC. Проблема проявлялась пользователям как страница ошибки с указанием сбоя в сети Cloudflare. Инцидент не был вызван кибератакой, а возник из-за изменения разрешений в системе баз данных, что привело к удвоению размера файла функций, используемого системой управления ботами. Программное обеспечение для маршрутизации трафика имело ограничение на размер файла, ниже удвоенного значения, что вызвало его сбой.

Сначала Cloudflare ошибочно подозревал DDoS-атаку, но позже определил корень проблемы. К 14:30 UTC основной трафик был восстановлен, а к 17:06 все системы работали нормально. Система демонстрировала необычное поведение — периодические восстановления каждые 5 минут, когда генерировались хорошие файлы конфигурации. Компания принесла извинения за влияние на клиентов и интернет, признав, что сбои в их системе неприемлемы.

• Использование .unwrap() в критическом коде привело к панике и сбою системы после обновления конфигурации.
• Отсутствие staged rollout для конфигураций и недостаточный мониторинг замедлили диагностику сбоя (3 часа).
• Обсуждаются архитектурные риски зависимости от крупных провайдеров и необходимость отказоустойчивых систем.
• Предлагается усиление обработки ошибок, глобальных kill switches и проверки конфигураций как пользовательских данных.
• Подчеркивается важность наблюдаемости (telemetry) для быстрого обнаружения паник и сбоев в критических сервисах.

Автор создал заголовочный файл safe_c.h (600 строк), добавляющий в C современные средства безопасности из C++ и Rust, сохраняя при этом производительность и простоту языка. Этот файл используется для создания высокопроизводительного grep-клона cgrep, демонстрируя, как можно обуздать "опасные возможности" C. safe_c.h предоставляет семантику RAII через атрибуты [[cleanup]] с обратной совместимостью для старых компиляторов, а также умные указатели UniquePtr и SharedPtr для автоматического управления памятью.

Заголовочный файл включает макросы LIKELY/UNLIKELY для оптимизации ветвления и гарантирует очистку ресурсов даже при раннем возврате или goto. UniquePtr автоматически освобождает память при выходе из области видимости, устраняя утечки, а SharedPtr реализует автоматический подсчёт ссылок. Автор утверждает, что с помощью таких инструментов C остаётся языком свободы и гибкости, позволяющим писать безопасный код без потери производительности.

• Обсуждение показало, что безопасность в C требует компромисов: либо платить за счёт производительности (POSIX-мьютексы), либо отказаться от переносимости кода.
• Участники спорят, стоит ли вообще пытаться эмулировать современные примитивы безопасности в C, или лучше просто использовать C++ там, где это возможно.
• Поднимается вопрос, что макросы и обёртки в C ведут к созданию "мини-языка" внутри проекта, что затрудняет понимание кода для новых участников команды.
• Обсуждается, что C++ уже реализовал всё, что пытаются эмулировать в C, и что это не избежно ведёт к "переизобретению велосипеда".
• Участники обсуждают, что встроенные в компилятор возможности C++ вроде std::unique_ptr и std::shared_ptr не только более безопасны, но и более производительны, чем попытки их эмулировать в C.

Разработчик представил Brimstone - новый JavaScript-движок, полностью написанный на Rust. Проект стремится создать альтернативу существующим движкам таким как V8 и SpiderMonkey, но с акцентом на безопасность и производительность за счет использования системы типов Rust и его современных возможностей. Rust обеспечивает безопасность памяти и потоков, что может снизить количество уязвимостей в движке по сравнению с традиционными реализациями на C++.

На данный момент проект находится на ранней стадии разработки, но уже демонстрирует потенциал для создания более безопасных и эффективных JavaScript-движков. Использование Rust для реализации движка JavaScript - это интересный тренд в индустрии, который также наблюдается в других проектах, таких как Deno и Boa, что указывает на растущий интерес к альтернативным языкам для критически важных компонентов веб-платформы.

• Обсуждение началось с благодарности за включение проекта в список и запуск бенчмарков, но быстро перешло к сравнению размеров бинарников Brimstone и Boa, где последний оказался в 3,5 раза больше из-за включённых ICU-таблиц Unicode.
• Участники обсудили, что "написано на Rust" стало маркетинговым клише, и как оно влияет на восприятие проекта, а также затронули тему лицензий и отсутствия лицензии в репозитории.
• Разговор затронул вопросы безопасности памяти и использования unsafe в контексте Rust, где участники обменялись мнениями о том, что именно подразумевается под этим и как это соотносится с выбором языка программирования.

Проектирование языка программирования — это итеративный процесс, включающий четыре фазы, которые необходимо повторять многократно. При реализации компилятора часто обнаруживается, что некоторые части языка спроектированы некорректно, что требует возврата к предыдущим этапам. Успех в создании языка зависит от глубоких знаний в трех ключевых областях: программных парадигмах (императивной, декларативной, объектно-ориентированной и др.), концепциях языков (последовательность выполнения, типизация, параллелизм и др.) и знакомстве с существующими языками. Автор рекомендует изучить десятки языков — от Python и Smalltalk до Haskell и Rust, а также ознакомиться с классическими работами по проектированию языков.

• Предложение включить Raku в список языков из-за встроенных грамматик для парсинга и объектно-ориентированной природы.
• Вопросы о компиляции целевых языков, их пайплайне сборки и контексте выполнения.
• Размышления о создании нового языка: необходимость, наличие ресурсов/команды, сроки выпуска MVP.
• Критика исходного материала как "AI slop", рекомендация использовать "programming language checklist".
• Споры об AI-происхождении текста (находки 2017 года) и упоминание забавного элемента (SnekQL).

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

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

• Статья преувеличивает инновативность Zig, не подкрепляя заявления о "революционности" реальными уникальными фичами.
• Пользователи отмечают практические преимущества: простота установки (через PyPI), кросс-компиляция, явный синтаксис и компиляция C-кода.
• Критика включает отсутствие безопасности памяти, спорные решения (политика идентификаторов, отсутствие данных в ошибках) и сравнение с Rust/Ada как более зрелых альтернатив.
• Отдельные хвалят метапрограммирование (comptime), простоту навигации по коду и удобство для низкоуровневого программирования.
• Обсуждение подчеркивает субъективность восприятия: для одних Zig "меняет подход к программированию", для других — лишь "улучшенный C" без уникального позиционирования.

Автор делится своим опытом работы с различными языками программирования, объясняя, почему OCaml стал его любимым языком. Он начал с Haskell, который оценил за функциональное программирование и статическую типизацию, но столкнулся с его сложностью и медленной компиляцией. Позже он попробовал Go, который понравился своей простотой, скоростью компиляции и хорошими инструментами, но разочаровал многословностью обработки ошибок и отсутствием функциональных возможностей. OCaml, по мнению автора, сочетает в себе лучшее из обоих миров: функциональные конструкции, статические гарантии, быструю компиляцию, простую семантику выполнения и отличную документацию. Особо отмечается, что OCaml компилируется в один статический бинарный файл, как Go, но при этом имеет более мощную систему типов и REPL. Автор считает, что создатели OCaml обладают хорошим вкусом, а язык представляет собой идеальный баланс между простотой и выразительностью.

• OCaml не стал мейнстримом из-за синтаксиса, отсутствия нативных библиотек и слабой экосистемы, но его идеи (pattern-matching, type inference, algebraic data types) уже давно живут в Rust, Swift, TypeScript и даже Go.
• Фактически OCaml — это «нативный» вариант F#, но без .NET-экосистемы, а F# — это OCaml без его синтаксиса и с .NET вместо OCaml-стандартной библиотеки.
• Попытка ReasonML привнести более C-подобный синтаксис вместо ужасающего синтаксиса OCaml закончилась тем, что Facebook забросил проект, а вся индустрия JS-инструментов осталась без единого стандарта.
• Попытка Facebook-а внедрить Reason вместо TypeScript внутри Facebook показала, что даже если синтаксис и не является проблемой, то отсутствие единого стандарта для сборки и пакетов в JS-мире оставляет язык без шанса.
• Несмотря на то, что OCaml — это язык с 25-летней историей, он не имеет ни мультиплатформенной сборки, ни нормального менеджера пакетов, ни нормального REPL, что делает его неподготовленным к работе вне Unix-подобных систем.

Filip Pizlo выпустил проект Fil-C, добавляющий проверку безопасности памяти в clang и включающий параллельный сборщик мусора. Инструмент демонстрирует высокую совместимость с существующим кодом, позволяя с минимальными исправлениями собирать полный Linux userspace. По измерениям, производительность составляет 1-4x (и более широкий диапазон по другим тестам), что для многих рабочих нагрузок является приемлемым. Проект основан на долгой линии исследований в области безопасности памяти, включая работы самого автора в Apple, где некоторые предыдущие итерации уже используются в производстве.

Несмотря на преимущества, Fil-C имеет ограничения: он динамически, а не статически предотвращает ошибки, программы все еще могут аварийно завершаться, есть накладные расходы на память (3-6x), и он не решает проблему гонок данных. Автор отмечает интересную возможность применения - проверки границ Fil-C могут сделать указательный код на C безопаснее, чем небезопасный Rust, и предлагает идею адаптации для компиляции небезопасных блоков Rust с дополнительными проверками.

• Почти все программы имеют пути, которые могут привести к краху, но это не означает, что они будут достаточно часто встречаться, чтобы быть проблемой.
• Fil-C обеспечивает безопасность памяти, но требует сборщика мусора и может быть медленнее, чем Rust.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.

Ratatui — библиотека для создания терминальных интерфейсов (TUI) на Rust, предлагающая инструменты для построения интерактивных консольных приложений. Она предоставляет богатый набор виджетов (таблицы, графики, календари, списки), гибкие системы компоновки и стилизации, а также поддержку различных архитектурных подходов, включая The Elm Architecture, Component и Flux. Библиотека работает с несколькими бэкендами, поддерживает обработку событий, работу с сырым режимом терминала и захват мыши.

Документация структурирована по разделам: от базовой установки и флагов возможностей до подробных туториалов (создание счётчика, JSON-редактора), примеров приложений и концепций. Особое внимание уделено рецептам решения конкретных задач: компоновка интерфейсов, рендеринг, кастомизация виджетов, тестирование и разработка приложений. Проект активно развивается, с активным сообществом в Discord, Matrix и других платформах.

• Rust-разработчики выбирают TUI, потому что в Rust нет приемлемого GUI-решения, а Ratatui «просто работает».
• Сообщество в основном согласно, что Qt в Rust нет и не предвидится, и что это не проблема, которую можно решить внешним крейтом.
• Терминальные приложения в Rust-экосистеме в основном используют Ratatui, потому что он «просто работает» и не требует сложной настройки.
• Несколько участников поделились ссылками на свои проекты, в которых используется Ratatui, включая игру Rebels in the Sky и чат-клиент termchat.
• Обсуждение также коснулось того, что TUI-инструменты в Rust-экосистеме в основном используют Ratatui, потому что он «просто работает» и не требует сложной настройки.

В 2025 году SIMD в Rust продолжает развиваться, предлагая значительный прирост производительности до 64x для операций с u8 на современных процессорах. Основная проблема - фрагментация наборов инструкций: ARM использует обязательный NEON (128 бит), WebAssembly - 128-bit packed SIMD, а x86 имеет сложную иерархию от SSE2 до AVX-512 (512 бит). Для x86 разработчики выбирают между указанием target-cpu (например, x86-64-v3) и использованием function multiversioning для поддержки различных процессоров.

В Rust существует четыре подхода к SIMD: автоматическая векторизация (самый простой), продвинутые итераторы, портируемые абстракции и сырые интринсики. В то время как ARM стандартизировал NEON, а WebAssembly требует компиляции двух бинарных файлов, x86 остается самой сложной платформой из-за множества расширений и необходимости обеспечения обратной совместимости.

• Обсуждение показало, что Rust пока не может предложить стабильный и удобный способ работы с SIMD, в отличие от C# и C++.
• Основная причина — std::simd всё ещё в nightly, а стабильная альтернатива отсутствует.
• Участники также отметили, что даже в ночной ветке API нестабилен и может измениться, что делает его использование в production-окружениях проблематичным.
• Некоторые участники выразили обеспокоенность тем, что отсутствие стабильной SIMD-поддержки может отпугнуть потенциальных пользователей Rust, особенно в областях, где эффективное использование SIMD критично.
• В то же время, другие участники подчеркнули, что Rust всё ещё молодой язык и что сообщество может в конце концов решить эту проблему, как это было с другими функциями в прошлом.

Инженеры часто иррационально подходят к выбору языков программирования, принимая решения на основе идентичности, эмоций и эго, а не технических преимуществ. Автор делится историей о компании Takkle, где опытный CTO инициировал переход с PHP на Perl, что привело к девятимесячной задержке, увеличению расходов с $200K до $500K в месяц и, в конечном итоге, к банкротству компании. Несмотря на то, что PHP был «достаточно хорош» для Facebook, подобного решения не приняли.

В течение своей карьеры автор наблюдал повторяющуюся эту модель в Google, MongoDB и других компаниях. Он описывает случай, когда VP Engineering представил руководству обоснование выбора Rust, хотя Go объективно соответствовал заявленным критериям лучше. Оказалось, что другие языки даже не рассматривались — решение было основано на хайпе. Автор подчеркивает, что при обсуждении языков программирования всегда происходит два диалога: видимый технический и невидимый, связанный с идентичностью инженера.

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

Debian планирует внедрить обязательные зависимости от Rust в APT не ранее мая 2026 года. Изначально это коснется компилятора Rust, стандартной библиотеки и экосистемы Sequoia. Разработчики отмечают, что код для парсинга .deb, .ar, .tar файлов и верификации HTTP-подписей значительно выиграет от использования безопасного с точки зрения памяти языка и улучшенного подхода к юнит-тестированию.

Мейнтейнерам портов без работающего инструментария Rust дано 6 месяцев на внедрение поддержки, в противном случае их порты будут закрыты. "Важно для проекта в целом иметь возможность двигаться вперед и полагаться на современные инструменты и технологии, а не быть сдерживаемыми попытками втиснуть современное ПО на ретро-устройства", — говорится в сообщении. Это решение отражает стратегический сдвиг Debian в сторону повышения безопасности и надежности системных компонентов.

• Дискуссия вокруг требования к Rust в Debian выявил, что спор касается не только безопасности, но и поддержки архитектур, лицензий и долгосрочной стабильности.
• Участники обменялись взаимными обвинениями в «религиозной вовлечённости», «попытке монополизировать инфраструктуру» и «попытке вытеснить C и C++».
• Некоторые участники подняли вопрос о том, что выбор языка программирования не должен быть предметом политики, а также о том, что влияние на совместимость с другими архитектурами и надежность инструментария.
• Обсуждение также затронуло вопрос о том, какие именно архитекруры считаются "живыми", и как это влияет на поддержку устаревших систем.
• В конце концов, участники согласились, что важно сохранить возможность выбора инструментария для разработки, но при этом не забывать о практических последствиях такого выбора.

В статье описывается концепция "futurelock" — особый тип дедлока, возникающий в асинхронном Rust, когда ресурс, принадлежащий Future A, требуется для Future B, а задача, ответственная за оба Future, перестала опрашивать A. Oxide обнаружила эту проблему в проекте omicron.

Пример демонстрирует программу, которая надежно замирает: фоновая задача захватывает блокировку на 5 секунд, основная задача использует tokio::select! для ожидания двух конкурентных Future. Один Future ждет блокировку, другой — таймаут. Когда таймаут срабатывает, создается новый Future, который также ждет блокировку, но задача больше не опрашивает исходный Future, что приводит к дедлоку.

• Проблема в том, что tokio::select! отменяет все futures, кроме одного, и это может привести к deadlock, если оставленные в стороне future владеет ресурсом (например, MutexGuard).
• Возможность отмены future в Rust в целом не определена, и это приводит к тому, что tokio::select! ведёт себя непредсказуемо для разработчика, что может привести к утечке ресурсов или deadlock.
• В отличие от других языков, где отмена future ведёт к её уничтожению, в Rust модель владения и заимствования не позволяет гарантировать, что ресурсы будут очищены.
• Это приводит к тому, что в Rust нет способа защититься от таких ситуаций на уровне языка, и единственное, что может сделать разработчик - это не использовать select! и вместо этого вручную управлять состоянием.
• В конце концов, это делает async Rust более сложным в использовании, чем он должен бы быть, и создаёт уязвимости, которые не существовали бы в других моделях параллельности.

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

Хороший вкус формируется через использование разных инструментов, отбор подходящих и отказ от неподходящих. Автор подчеркивает, что «никакое время, потраченное на обучение, не пропало зря». Он призывает сомневаться в общепринятых нормах, экспериментировать и ломать вещи. Важно найти баланс: автор не тратит все время на настройку neovim, но регулярно пробует новые технологии (GLSL, Rust, Swift), чтобы расширить кругозор и развить способность отличать посредственность от мастерства.

• Обсуждение свелось к тому, что «taste» и «tinkering» — это не про элитарность, а про любознательность и готовность экспериментировать.
• Участники обменялись историями о том, как раньше они тоже «игрались» с настройками, но со временем пришли к минимализму и перестали это делать.
• Поднялась тема о том, что «taste» в разработке ПО — это не про эстетику, а про умение выбирать правильные инструменты и не тратить время на бессмысленные оптимизации.
• Некоторые участники выразили обеспокоенность тем, что статья не раскрывает, что именно делает «taste» важным и почему он важен.
• В итоге обсуждение сошлось на том, что «taste» — это не врождённое качество, а навык, который развивается с опытом и вовремя отпускает человека от бессмысленных занятий.

Библиотека Rust GUI компонентов для создания кроссплатформенных десктопных приложений с использованием фреймворка GPUI. Проект предлагает готовые интерфейсные элементы, упрощающие разработку визуальных приложений на Rust. Компоненты обеспечивают единый пользовательский опыт на разных платформах, включая Windows, macOS и Linux.

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

• Сообщество обсуждает, что "native" может означать как отсутствие web-технологий, так и просто нативный виджет ввода текста, и это влияет на выбор инструментов.
• Участники отмечают, что многие open-source проекты спонсируются криптокомпаниями, что вызывает смешанные чувства, но при этом признаётся вклад этих компаний в OSS.
• Обсуждается нехватка готовых компонентов в экосистеме Rust, несмотря на обилие GUI-фреймворков, и сравнивается с другими языками, где такие коллекции есть.
• Поднимается вопрос о размере бинарника (около 10 МБ), который вызывает у людей вопросы о встроенных данных ICU и прочих ресурсах.
• Участники делятся мнением, что хотя фреймворки быстро развиваются, но они всё ещё не покрывают все потребности, и это тормозит более широкое принятие.

Автор изначально не интересовался Zig, считая его нишевым языком для аудиопрограмм, но решил переписать индекс AcoustID на Zig как возможность изучить новый язык. Результат превзошёл ожидания — новая версия оказалась быстрее и масштабируемее, чем предыдущая на C++. Однако при добавлении серверного интерфейса возникли сложности с сетевыми возможностями Zig, что привело автора к созданию библиотеки Zio — асинхронной I/O и библиотеки для конкурентности в стиле Go.

Zio реализует стековые корутины с фиксированным размером стека, поддерживает асинхронную сетевую и файловую I/O, примитивы синхронизации и каналы в стиле Go. Главная особенность — контекстный переключение практически бесплатен, сравним с вызовом функции. В однопоточном режиме Zio обгоняет все протестированные фреймворки, включая Go и Rust Tokio. Интересно, что благодаря стандартным интерфейсам reader/writer, внешние библиотеки могут использоваться без модификаций, даже не зная, что работают внутри Zio.

• Обсуждение показало, что Zig не имеет встроенной поддержки async/await, а вместо этого используется библиотечный код, что вызывает вопросы о том, как это скажется на производительности и удобстве использования.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.

Инженеры Nanit сэкономили $500,000 в год, создав собственную систему хранения N3 на Rust вместо использования AWS S3 для обработки видео. При тысячах загрузок в секунду, плата за запросы PutObject в S3 становилась основной статьей расходов, а минимальный период хранения в 24 часа правил out стоимость обработки, занимавшей всего 2 секунды.

N3 работает как in-memory landing zone, используя S3 только как буфер перегрузки. В исходной архитектуре камеры загружали видео чанками напрямую в S3 через presigned URL, после чего Lambda отправлял ключи в SQS FIFO очередь для обработки. Подход сохранил надёжность и строгую последовательность данных, но исключил плату за запросы на основном пути и сократил затраты на хранение.

• Стоимость S3 для короткоживущих файлов оказалась настолько высокой, что компания вместо него реализовала собственное in-memory хранилище, что позволило сэкономить $500k, но оставляет вопрос о том, что будет, если этот кэш упадёт.
• Обсуждение вылилось в критику концепции "serverless" архитектуры, где-то между линиями прочиталось, что сама архитектура была проблемой, а не решением.
• Участники обсуждения также подняли вопросы о приватности: камера в детской комнате передаёт аудио/видео в облако без шифрования, и кто-то может прослушивать ваш дом.
• Несколько комментаторов отметили, что вместо того, чтобы писать собственные сервисы, компании могли бы использовать существующие open-source решения, такие как MinIO или SeaweedFS, но при этом они также отметили, что даже эти решения не предоставляют той же степени удобства, что и делает S3.

Synadia и TigerBeetle совместно выделили $512,000 на поддержку Zig Software Foundation в течение двух лет. Synadia, создатель NATS.io, помогает крупным предприятиям проектировать и масштабировать архитектуры в облаке и на периферии, обслуживая клиентов в финансовой сфере, электронной коммерции, гейминге и промышленном IoT. TigerBeetle, финансовая база данных, разработанная на Zig с философией "TigerStyle", подчеркивает правильность, ясность и надежность.

Основатель Synadia Дерек Коллисон отметил, что Zig переопределяет возможности современного системного программирования благодаря своему подходу к контролю, производительности и простоте. Основатель TigerBeetle Йоран Дирк Гриф выразил уверенность, что Zig сыграет основополагающую роль в следующем поколении надежных распределенных систем. Обе компании разделяют видение предсказуемого, простого и заслуживающего доверия программного обеспечения, поддерживая Эндрю Келли и весь Zig-сообщество.

• Оценивали Rust, Zig и Ada/SPARK для критически важного ПО; Rust имеет поддержку корпорации и сообщества, но не применяется в кибер-физических системах.
• TigerBeetle получил $512k в течение 2 лет от Synadia и TigerBeetle, что вызвало вопросы о стратегии финансирования и приоритете языков.
• Обсуждение вылилось в обмен любезностями и техническими деталями, включая предположения о переходе на Zig и оставлении Rust без должной поддержки.

Команда Asahi Linux продолжает работу над поддержкой чипов Apple M3, хотя на данный момент базовая функциональность позволяет только загружать систему до мигающего курсора. Разработчики активно портируют загрузчик m1n1 на язык Rust, что повысит безопасность и поддерживаемость критически важного компонента. Параллельно ведется работа над патчами ядра Linux для версий 6.17 и 6.18, где уже добавлены Device Trees для устройств Apple M2 Pro/Max/Ultra.

Успехи также отмечены в игровой сфере — Wine теперь работает вне muvm, а поддержка графики продолжает совершенствоваться. Несмотря на прогресс с M1 и M2, чипы M3, M4 и недавно анонсированный M5 все еще находятся в стадии обратной разработки. Как отмечают разработчики: "Базовая поддержка M3 существует давно, но она ограничивается возможностью загрузки до мигающего курсора, что полезно только для низкоуровневого реверс-инжиниринга".

• Пользователи обсуждают, что владельцы Mac на M1-M4 чипах по-прежнему не могут полноценно использовать Linux на своих машинах, и это вызывает тревогу, особенно учитывая, что Apple не проявляет особого интереса к поддержке Linux на своих устройствах.
• Участники обсуждения отмечают, что даже несмотря на это, сама по себе поддержка Asahi Linux остается важной, так как она позволяет продлить жизнь этих устройств, когда Apple прекратит поддержку macOS.
• Некоторые участники подчеркивают, что ситуация с Linux на Apple Silicon выглядит как бесконечная борьба, и что это может быть неразрешимой проблемой, если Apple не изменит свою политику.
• Также обсуждается, что в то время как Apple продолжает выпускать новые чипы, Asahi Linux может не успевать за ними, что делает невозможным поддерживать актуальные версии ядра и драйверов.
• Наконец, участники обсуждения отмечают, что существует альтернатива в виде ноутбуков от других производителей, которые лучше подходят для Linux, но они не такие же качественные, как MacBook, что делает выбор сложным для тех, кто предпочитает Linux, но привык к премиальному качеству MacBook.

В Ubuntu 25.10 обнаружен баг в Rust-версии команды date из пакета uutils, нарушающий автоматические обновления системы. Проблема затронула облачные развертывания, контейнеры, десктоп и серверные версии. Системы с rust-coreutils версии 0.2.2-0ubuntu2 или ранее подвержены уязвимости, исправленной в версии 0.2.2-0ubuntu2.1. Интересно, что баг не влияет на ручные обновления через apt.

Ubuntu реализует проект "окисления" дистрибутива, переходя на uutils и sudo-rs для версии 25.10, чтобы оценить пригодность Rust-утилит для долгосрочного выпуска в апреле. Этот переход вызвал дискуссию: одни считают, что замена проверенных десятилетиями C-утилит неизбежно приведет к краткосрочным проблемам, другие поддерживают инициативу как необходимую. Также поднимаются вопросы лицензирования MIT вместо GPL и управления проектом uutils.

• Обсуждение вокруг замены GNU coreutils на Rust-версию свелось к тому, что проблема лицензии (GPLv3 vs MIT), а не безопасность, и что в конце концов, как и следовало ожидать, никакой "серьёзной" уязвимости там не было.
• Участники обсуждения отмечают, что даже если бы это была уязвимость, то это была бы не более чем типичная для мейнтейнеров Ubuntu ошибка пакетов, которые не были бы исправлены в нужное время.
• Сообщество высказывает опасения по поводу переписывания критически важных утилит, которые были проверены временем, на новом и потенциально менее стабильном языке программирования.
• Некоторые комментаторы подчеркивают, что обсуждение не касается безопасности, а вопрос лицензии и что это не более чем естественное течение времени и что в конце концов, как и следовало ожидать, никакой "серьёзной" уязвимости там не было.

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

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

В 2012 году автор, работая с Ruby и Rails, обнаружил Rust и увидел в нём потенциал. Он оценил три ключевых фактора успеха языка: рыночную нишу (безопасность памяти без сборщика мусора как инновация в низкоуровневом программировании), команду (поддержку Mozilla) и пользователей (планы использовать Rust в Firefox). Этот подход помог ему принять решение присоединиться к проекту Rust, написать руководство "Rust for Rubyists" и в итоге войти в команду.

Сейчас автор применяет тот же анализ к jj — новой системе контроля версий, написанной на Rust. Как и в случае с Rust, он видит у jj хорошую рыночную нишу (возможность работать с Git-репозиториями для постепенного внедрения), сильную команду (Google использует jj) и растущую пользовательскую базу. На первой конференции jj создатель马丁 отметил важный аспект, хотя детали в статье не раскрываются.

• Обсуждение в основном вращается вокруг того, что Git остаётся доминирующим, но jj и другие инструменты могут предложить улучшенный UX и модель данных, что делает их привлекательными для некоторых пользователей.
• Участники обсуждали, что отсутствие интеграции с GitHub и другими платформами может быть препятствием для широкого внедрения jj.
• Некоторые участники выразили обеспокоенность относительно того, что новые системы могут не поддерживать критические функции, такие как LFS и инструменты для работы с бинарными файлами.
• Обсуждались также вопросы документации, обучения и поддержки сообщества, которые могут быть недостаточными для новых систем.
• Наконец, обсуждались личные мотивации и карьерные шаги, включая влияние на открытый исходный код и его влияние на развитие инструмента.

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

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

• Servo выпустил первый релиз 0.0.1 после 50 000 коммитов, но это всё ещё экспериментальный движок, а не полноценный браузер.
• Сообщество обсуждает, что единственный релиз не делает проект готовым к продакшн-использованию, но модульная архитектура Servo позволяет использовать его компоненты в других проектах.
• Несколько участников высказали надежду, что Servo может стать альтернативой Electron-ноде в будущем, но пока что это не более чем надежда.
• Участники также обсуждали, что разработка ведется в рамках Linux Foundation, и что Mozilla, начавший проект, не имеет к нему отношения.

Rust продолжает развиваться, и новые языковые функции, такие как проекции полей, инициализация на месте и произвольные типы self, становятся важными для разработки ядра Linux. Эти функции упрощают работу с указателями, позволяют избежать двойной инициализации и делают код более выразительным. Рядом с этими изменениями, Rust for Linux активно работает над стабилизацией существующих функций и разработкой новых, чтобы код ядра был не только безопасным, но и элегантным. Разработчики подчеркивают, что сообщество, включая участников Rust for Linux, играет ключевую роль в определении приоритетов разработки языка.

• Обсуждение охватывает вопросы от безопасного доступа к полям структур до сложных вопросов владения памятью в Rust, а также влияние этих обсуждений на разработку ядра Linux и взаимодействие с другими языками программирования.
• Участники обсуждали, что сложность Rust может быть препятствием для новых разработчиков, но также отметили, что сложность C++ может быть еще более запутанной.
• Обсуждались вопросы о том, как влияет на разработку ядра Linux внедрение Rust, и были высказаны мнения, что это может быть экспериментом, который следует проводить в другом месте.
• Также обсуждались вопросы о том, какие функции Rust могут быть полезны для разработки ядра Linux и какие функции Rust могут быть полезны для разработки ядра Linux.
• В конце обсуждение перешло к вопросу о том, какие функции Rust могут быть полезны для разработки ядра Linux и какие функции Rust могут быть полезны для разработки ядра Linux.

Разработчики создали IRC-клиент Halloy в Rust. Проект примечателен тем, что это не просто кроссплатформенный инструмент для чата, но и open-source проект, доступный на GitHub. Вместо стандартного подхода, Halloy предлагает современный интерфейс и функционал, вроде поддержки расширений и тем оформления, что редкость для IRC-клиентов, которые часто застревают в прошлом.

Основная идея — сделать IRC доступным и удобным для современных разработчиков, интегрируя его с современными инструментами. Например, Halloy поддерживает встраивание медиа и интеграцию с сервисами вроде GitHub. Проект набирает популярность, так как сочетает ностальгический протокол IRC с современными практиками разработки.

• Halloy — современный IRC-клиент, написанный на Rust и использующий iced.
• Пользователи отмечают высокую скорость, стабильность и удобство настройки через TOML-файл.
• Поддержка нескольких серверов и каналов, но пока нет вкладок; вместо этого используется буфер-менеджер.
• Проект открытого кода, активно развивается и принимает PR.
• Некоторые пользователи отмечают, что Halloy всё ещё не поддерживает некоторые функции, такие как вкладки, минимизация в трей и полная поддержка экранных читателей.

SQLite написан на C, а не на более современных языках, по нескольким ключевым причинам.

Производительность и контроль: C позволяет разработчикам писать код, который выполняется максимально близко к аппаратному уровню, что критично для низкоуровневых библиотек, таких как SQLite. Хотя некоторые языки могут заявлять о схожей производительности, C остается эталоном. Кроме того, его "портабельность" (работа практически на любой платформе) делает его универсальным.

Совместимость и стабильность: Библиотеки на C могут использоваться практически из любого другого языка программирования, что делает SQLite доступным для разработчиков на разных платформах и в разных экосистемах. C также является зрелым и стабильным языком, что минимизирует риски, связанные с изменчивостью более молодых языков.

Минимальные зависимости: В отличие от многих современных языков, которые требуют объемные среды выполнения, код на C имеет минимальные зависимости. Это делает развертывание легким и надежным, что критично для встраиваемых систем, где SQLite часто используется.

Хотя существуют аргументы в пользу использования объектно-ориентированных или "безопасных" языков (таких как Rust), эти варианты были либо недоступны, либо незрелы, когда начиналась разработка SQLite. Более того, переход на новый язык потребовал бы значительных усилий без гарантии улучшений, особенно учитывая, что SQLite уже хорошо отлажен и оптимизирован в своей текущей реализации на C.

• Обсуждение вращается вокруг того, стоит ли переписывать SQLite на другие языки, но аргументы сводятся к тому, что существующий код уже безупречен, а переписывание может внести новые баги и даже замедлить работу.
• Подчеркивается, что SQLite — это не только код, но и 100% покрытие тестами и 25 лет отладки, что делает язык менее важным, чем для других проектов.
• Участники обсуждения отмечают, что языки вроде Rust всё ещё молоды и меняются, а также не предоставляют преимуществ в контексте уже готового кода.
• Поднимается вопрос о том, что важнее — язык или разработчики, и подчеркивается, что последние могут писать на любом языке, если бы это действительно было нужно.

Meta представила Pyrefly — новый статический анализатор для Python, способный проверять до 1,85 млн строк кода в секунду. Он работает в 10 раз быстрее, чем основные конкуренты, такие как Pyright и MyPy, при этом сохраняя высокую точность.

Pyrefly интегрируется как сервер языка (LSP) для VS Code и других редакторов, предлагая автодополнение, подсветку ошибок и навигацию по коду. Инструмент уже протестирован на крупных проектах, включая код PyTorch.

Разработчики подчеркивают, что Pyrefly не требует аннотаций для старта, но улучшает качество кода при их использовании. Инструмент доступен как open-source и поддерживается через Discord-сообщество.

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rrrr

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

MAML уже реализован в нескольких языках, включая JavaScript, Python, Rust, C и PHP. Эти реализации находятся на разных стадиях разработки: от готовых к использованию до находящихся в активной разработке.

Проект полностью открыт, с кодом на GitHub, и распространяется по лицензии MIT, что позволяет свободно использовать, модифицировать и распространять его.

• Обсуждение вновь подтвердило, что вместо улучшения JSON/YAML/TOML появляется всё больше новых конфиг-языков, но никто не решает их проблемы с синтаксисом, датами, комментариями и т.д.
• Участники обсуждения отмечают, что большинство этих новых языков не решают фундаментальные проблемы, такие как отсутствие типов данных, дат и комментариев в JSON.
• Некоторые комментаторы подчеркивают, что вместо того, чтобы изобретать новые языки, лучше бы улучшить существующие инструменты, такие как JSON5 или TOML.
• Другие участники поднимают вопрос, что если бы разработчики потратили усилия на улучшение существующих инструментов, вместо создания новых, это было бы более продуктивно.

Julia Evans рассказала, как за три месяца перешла с Vim на Helix. Главное, что языковые серверы работают без настройки, а поиск показывает контекст совпадений. Минусов мало: нет автоперезагрузки файлов, не хватает приёма undo и редко падает. Но она привыкла и даже не чувствует, что потеряла 20 лет мускульной памяти Vim.

• Пользователи обсуждают преимущества и недостатки Helix и Neovim: кто-то ценит «из коробки»-конфигурацию Helix, кто-то — гибкость Neovim; спор о том, какой редактор «лучше» ведётся в основном вокруг личных привычек и потребностей.
• Участники обмениваются советами по настройке LSP, автосохранению и другим функциям, но в целом признают, что оба редактора требуют документации и что «из коробки»-конфигурация Helix может быть проще в использовании.
• Некоторые участники подчеркивают, что Helix всё ещё молод и не реализует все функции, в то время как Neovim имеет 20-летнюю историю и большое сообщество плагинов и интеграций.
• Участники также обсуждают, что Helix требует меньше конфигурации, но Neovim требует больше настройки, чтобы достичь схожего уровня функциональности.
• Некоторые участники высказывают, что Helix не имеет столь же развитой экосистемы плагинов и интеграций, как Neovim, и что это может быть препятствием для пользователей, которые ищут расширяемость.
• Несколько участников упоминают, что Helix написан на Rust и может быть более производительным, в то время как Neovovim может быть более «гибким» в плане настройки и конфигурации.
• Участники также обсуждают, что Helix имеет встроенную поддержку LSP и tree-sitter, в то время как Neovim требует установки и настройки LSP и tree-sitter вручную.
• Некоторые участники упоминают, что Helix не имеет встроенной поддержки терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки макросов, в то время как Neovim может использовать макросы для автоматизации задач.
• Некоторые участники упоминают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для макросов, в то время как Neovim может использовать макросы для автоматизации задач.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексоры для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексора для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексора для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексора для разделения окон.
• Участники также обсуждают, что Helix не имеет встроенной поддержки для встроенного терминала, в то время как Neovim может использовать tmux или другие терминальные мультиплексора для разделения

Igalia получил грант от Sovereign Tech Fund на поддержку движка Servo. В течение года команда займётся тремя направлениями: внедрение базовой поддержки специальных возможностей, завершение WebView API для встраивания Servo в приложения и рутинная поддержка проекта. Это позволит движку оставаться жизнеспособным и совместимым с экосистемой Rust.

• Финансирование и гранты: Немецкий Sovereign Tech Fund выделяет гранты на разработку Servo, но суммы (€545,400) вызывают сомнения в их адекватности, особенно на фоне сравнения с другими инициативами.
• Проблема зависимости от США: Обсуждение подчеркивает, что ЕС по-прежнему зависит от технологий США, и вопрос остаётся открытым, несмотря на усилия по финансированию open-source проектов.
• Сравнение с другими проектами: Участники обсуждения отмечают, что в отличие от других проектов, таких как Ladybird, у которого есть 8 разработчиков, Servo не имеет столь же широкой поддержки, что может затруднить его развитие.
• Финансирование open-source: Участники подчеркивают важность устойчивого финансирования open-source проектов, особенно в контексте государственных инвестиций в такие проекты как Servo.

Python 3.14 вышел 8 октября 2025 года. Автор сравнил его с 3.9-3.13, а также с PyPy 3.11, Node.js 24 и Rust 1.90. Для тестов использовались два скрипта: рекурсивный расчет 40-го числа Фибоначчи и пузырьковая сортировка 10 000 элементов. Все тесты запускались на ноутбуке с Intel Core i5 под Ubuntu и ноутбуке Apple M2 под macOS.

Результаты: CPython 3.14 оказался на 10-15% быстрее 3.13 и примерно вдвое быстрее 3.9. JIT в 3.14 работает стабильно, а в 3.13 еще может выдавать сбои. Free-threading в 3.14 показал себя как надежный способ распараллеливать задачи, но прирост не столь драматичен, как ожидалось. PyPy 3.11 оказался в 2-3 раза быстрее CPython 3.14, но требует в 2-3 раза больше памяти. Node.js и Rust оказались в 2-3 раза быстрее, но это сравнение не совсем корректно, так как они не тестировали рекурсию.

• Пользователи обсуждают производительность Python 3.14, сравнивая его с PyPy и другими языками, и обсуждают, почему сообщество продолжает тратить усилия на ускорение CPython вместо перехода на PyPy.
• Несколько комментаторов отмечают, что 3.14 всё ещё значительно уступает PyPy и даже Node.js в ряде тестов, хотя и демонстрирует прогресс.
• Обсуждается, почему Python не может быть переименован в π-thon, несмотря на то, что это было бы логично, и почему не используется возможность перехода на PyPy, несмотря на то, что он быстрее.
• Участники также обсуждают, что, несмотря на то, что Python всё ещё остаётся медленным, он остаётся незаменимым для прототипирования и имеет огромную экосистему библиотек, что делает его незаменимым для многих задач.
• Наконец, обсуждается, что, несмотря на то, что Python медленный, он всё ещё может быть использован для большинства задач, и что важнее всего - он всё ещё может быть использован для большинства задач.

Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

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

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.

Wagtail CMS обновил свой веб-сайт, добавив новую страницу «О нас», где описаны основные преимущества и возможности CMS. Вместо традиционных пунктов меню теперь используются интерактивные карточки с иконками, что улучшает пользовательский опыт. На сайте также представлена информация о команде Wagtail, его функциях, доступности и устойчивости, что делает его более прозрачным и доступным для новых пользователей. Обновление подчеркивает важность открытости и удобства, что может привлечь больше разработчиков и контент-менеджеров.

• uv стал фактическим стандартом для управления зависимостями и окружениями, потому что он быстрый и простой в использовании, но это вызвало споры о том, действительно ли он лучше, чем pip и другие инструменты, особенно в контейнерах и CI/CD.
• Некоторые разработчики утверждают, что uv не подходит для контейнеров, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.
• Пользователи, которые привыкли к pip и другим инструментам, иногда утверждают, что uv не предоставляет никаких преимуществ, и что это просто "Rust фанатство", но другие считают, что скорость и простота использования делают его лучшим выбором.
• Некоторые разработчики считают, что uv не подходит для использования в контейнерах, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.
• Некоторые разработчики считают, что uv не подходит для использования в контейнерах, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.

Rust-разработчик взглянул на Vec<T> и обнаружил, что вместо ожидаемых трёх полей ptr, len, capacity внутри структура скрыта целая иерархия обёрток: RawVec, RawVecInner, Unique, NonNull и NonNull<T> — всё ради безопасности и гибкости. Это вызвало вопрос: зачем такая сложность, если можно было обойтись тремя полями? Ответ оказался в том, что каждый слой добавляет безопасность и абстракцию, защищая от ошибок с указателями.

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

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

niri — это тайлинговый композитор для Wayland с поддержкой прокрутки, написанный на Rust. Он фокусируется на минимализме, стабильности и производительности, предлагая плавную работу без лишних зависимостей. Композитор поддерживает стандартные функции Wayland, включая XDG-Shell, и обеспечивает настраиваемое управление окнами через конфигурационные файлы.

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

• Пользователи высоко оценили Niri за его скроллируемое тайлинг-менеджмент, который позволяет организовывать окна в непрерывную горизонтальную ленту, что повышает продуктивность по сравнению с традиционными тайлерами (i3, xmonad).
• Отмечается стабильность и производительность Niri (написан на Rust), особенно в сравнении с Hyprland, а также простота настройки и работа на ультрашироких мониторах.
• Обсуждаются недостатки: отсутствие панели для виджетов (батарея, часы), возможность "потеряться" в большом количестве окон, ограниченная конфигурация (ранее — один файл).
• Некоторые пользователи выражают скепсис к скроллируемому тайлингу, предпочитая классический пейджный подход (рабочие столы), и сомневаются в готовности Wayland.
• Упоминаются возможные альтернативы и дополнения: COSMIC (желание добавить скроллируемый тайлинг), расширения для Hyprland (hyprscrolling), PaperWM для GNOME.

DARPA запускает программу TRACTOR для автоматизированного перевода уязвимого наследуемого кода на C в безопасный язык Rust. Проблема памяти — наиболее распространённый тип уязвимостей, возникающих из-за прямого управления памятью в C и неопределённого поведения. Несмотря на осознание проблемы, масштабный ручной переписывание кода был невозможен из-за огромного объёма legacy-систем, включая критическую инфраструктуру и оборонные проекты.

Программа использует прорывы в машинном обучении, включая большие языковые модели, для автоматизации перевода с сохранением идиоматичности и качества Rust-кода. TRACTOR будет сочетать статический и динамический анализ с ИИ, проводя публичные соревнования для тестирования решений. Цель — устранить целый класс уязвимостей безопасности, переложив ответственность с программиста на язык, который принудительно обеспечивает корректность работы с памятью.

• Критика синтаксиса Rust и его неидиоматичности для некоторых задач по сравнению с TypeScript, C#, Go или Python, при признании превосходства его инструментов (Cargo, система сборки).
• Обсуждение возможности создания безопасной реализации C (как Fil-C) и аргументы, что проблема не в языке, а в выборе реализации, жертвующей безопасностью ради производительности.
• Сомнения в эффективности автоматической трансляции C/C++ в Rust и риске получения "C с акцентом Rust" вместо идиоматического и безопасного кода.
• Дебаты о применимости Rust в оборонной сфере и его сравнение с другими языками (Zig, Go) по простоте сборки, зависимостям и размеру стандартной библиотеки.
• Споры о философии дизайна Rust: фокус на композиции вместо наследования, сложности borrow checker и несовместимости некоторых идиом C++ с моделью безопасности Rust.

Typst — это новая система вёрстки документов, написанная на Rust и позиционируемая как современная альтернатива LaTeX. Она сохраняет высокое качество вывода, особенно для технических и научных материалов с формулами, таблицами и иллюстрациями, но предлагает более простой синтаксис разметки, быстрое компилирование и удобную кастомизацию. Проект развивается с 2019 года, уже насчитывает сотни контрибьюторов и постепенно получает признание в академической среде.

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

• Пользователи отмечают значительное преимущество Typst перед LaTeX в скорости компиляции, удобстве синтаксиса и понятности диагностических сообщений.
• Многие перешли на Typst для генерации документов в продакшн-средах (инвойсы, отчёты, книги) благодаря его простоте интеграции с данными (JSON) и программируемости.
• Подчёркивается проблема принятия Typst в научном сообществе из-за доминирования LaTeX-шаблонов журналов и конференций, а также отсутствия полной поддержки инструментов вроде Zotero.
• Некоторые пользователи выражают скептицизм по поводу замены LaTeX для сложных математических формул и опасения по поводу долгосрочного развития и обратной совместимости Typst.
• Typst часто используется как замена Markdown для простых документов и заметок благодаря интуитивному формату и мгновенному предпросмотру.

Firefox переписывает свой стек UDP для QUIC на Rust, чтобы использовать современные системные вызовы и повысить производительность. Около 20% HTTP-трафика браузера уже идёт через HTTP/3 поверх QUIC/UDP, а старый код на NSPR не поддерживает многопакетные операции вроде sendmmsg или аппаратное ускорение сегментации (GSO/GRO).

Новый движок построен на основе библиотеки quinn-udp и показывает впечатляющие результаты: в CPU-нагруженных сценариях пропускная способность выросла с менее 1 Гбит/с до 4 Гбит/с. Основная сложность заключалась в поддержке старых версий ОС, включая Android 5. Проект также усиливает безопасность благодаря использованию memory-safe языка и тесной интеграции с существующей Rust-реализацией QUIC во Firefox.

• Увеличение пропускной способности UDP до 4 Гбит/с и снижение нагрузки на CPU благодаря оптимизациям в библиотеке quinn-udp
• Критика скорости в 4 Гбит/с как недостаточной для высокоскоростных сетей и обсуждение ограничений системных вызовов и шифрования
• Вопросы о работе механизмов GSO/GRO для UDP и обработки пакетов, приходящих не по порядку
• Обсуждение поддержки проектов с открытым исходным кодом, в частности, вклад Mozilla в Quinn кодом, но не финансированием
• Дебаты о целесообразности использования самоподписанных сертификатов в HTTP/3 для LAN и соображения безопасности

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

Ограничения включают размер файла до 193 ТБ и до 4 миллиардов файлов на томе. RedoxFS совместима с Redox и Linux через FUSE, а также поддерживает полное шифрование диска на уровне загрузчика. Это пример того, как современные концепции хранения данных адаптируются под безопасные и модульные операционные системы.

• Высказываются опасения по поводу сложности и надежности создания собственной файловой системы, сравнимой с ZFS или btrfs, для проекта Redox OS.
• Обсуждаются технические проблемы интеграции монолитной архитектуры ZFS с микрокернельным дизайном Redox, а также возможные альтернативы.
• Отмечается, что Redox OS является в большей степени исследовательским проектом и инкубатором идей для экосистемы Rust, а не готовой к производству ОС.
• Поднимаются вопросы о практической применимости Redox на реальном железе, поддержке оборудования и лицензионных ограничениях.
• Упоминаются другие нишевые ОС и файловые системы (например, Genode, HAMMER2) как возможные источники вдохновения или альтернативы.

Python-разработчики всё чаще используют аннотации типов, чтобы повысить надёжность кода в условиях роста проектов от прототипов до промышленных систем. Гибкость динамической типизации, которая раньше ускоряла эксперименты в AI и data science, теперь становится риском для стабильности. Решение предложено в PEP 484 (2014) — постепенная статическая типизация, позволяющая добавлять аннотации без полного переписывания кода.

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

• Критика Python type hints как нарушающих дух языка, добавляющих излишнюю сложность и не дающих преимуществ в производительности.
• Поддержка type hints как ценной документации, улучшающей читаемость, рефакторинг и предотвращающей ошибки.
• Сравнение с другими статически типизированными языками (TypeScript, Rust), где система типов интегрирована лучше.
• Прагматичный подход: использование type hints выборочно, как подсказок, а не строгого требования.
• Влияние type hints на работу с ИИ-инструментами, улучшая автодополнение и понимание кода.

Python сохраняет лидерство благодаря своей универсальности в машинном обучении и веб-разработке, а JavaScript остаётся незаменимым для фронтенда. Rust продолжает расти из-за акцента на безопасность и производительность, особенно в системном программировании. Go набирает популярность в облачных сервисах и микросервисной архитектуре благодаря простоте и эффективной параллельной обработке.

Стоит отметить рост TypeScript как более строгой альтернативы JavaScript, а также стабильное присутствие Java в корпоративных приложениях. Интерес к Julia увеличивается в научных вычислениях, а Kotlin укрепляет позиции в мобильной разработке под Android. Практический вывод: выбор языка всё больше зависит от конкретной области, а не только от общей популярности.

• Сомнения в методологии рейтинга языков программирования IEEE из-за использования ненадёжных источников (поисковые запросы, устаревающий StackOverflow), что может искажать реальную картину.
• Удивление высокой позицией Java (2-е место), объясняемой её доминированием в enterprise-секторе (финансы, страхование, здравоохранение) и миграцией legacy-систем с COBOL.
• Обсуждение искусственного завышения позиции Python из-за его популярности у новичков, в академических статьях и как основного языка вывода для LLM.
• Предложение объединить рейтинги близких языков (JavaScript/TypeScript, Java/Kotlin, C/C++) для более точного отражения популярности экосистем.
• Размышления о влиянии AI-ассистентов на будущее языков: возможная стагнация из-за зависимости LLM от популярных языков или, наоборот, упрощение изучения нишевых.

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

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

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

zoxide — это умная замена команды cd, которая запоминает часто посещаемые каталоги и позволяет быстро переходить по ним с помощью частичного совпадения имён. Она поддерживает все основные оболочки, включая bash, zsh и fish, и использует алгоритм ранжирования для предложения наиболее релевантных путей.

Инструмент работает быстрее аналогов вроде autojump, так как написан на Rust, и интегрируется с fzf для интерактивного выбора. Практический бонус — экономия времени при навигации в сложных проектных структурах.

• Критика zoxide за нечёткость работы и потенциальные ошибки при навигации, а также предпочтение встроенного поиска по истории ZSH или комбинации с fzf.
• Положительные отзывы о значительном ускорении навигации и интеграции zoxide в рабочий процесс, особенно в сочетании с другими инструментами (fzf, bat, starship).
• Обсуждение альтернатив и схожих инструментов (autojump, z, navita, CDPATH в bash/zsh), их сравнение с zoxide.
• Варианты настройки и использования zoxide, включая алиасы для cd, флаг basedir и интерактивный режим zi.
• Замечания о том, что для многих пользователей нативные возможности оболочки или другие инструменты покрывают большинство потребностей.

Новый интерфейс std.Io.Reader в Zig может приводить к неопределённому поведению при использовании с буфером произвольного размера. Например, при передаче ридера из zstd-декомпрессора в функцию вывода с буфером 64 байта код либо аварийно завершается в режиме отладки, либо зацикливается в релизе. Проблема в том, что некоторые ридеры требуют конкретного размера буфера у писателя, но это требование не всегда очевидно или документировано.

Ситуация усугубляется тем, что сбой может зависеть от входных данных: с одними данными код работает, с другими — нет. Это создаёт риски для библиотек, где тип ридера неизвестен заранее, например, при обработке HTTP-заголовков. Автор спрашивает, не ошибся ли он, но если нет — это серьёзный изъян в дизайне API.

• Обсуждается потенциальная проблема безопасности или баг в Zig, но участники склоняются к тому, что это скорее единичная ошибка, а не системная уязвимость.
• Участники дискутируют о ценностном предложении языка Zig, описывая его как современную альтернативу C с лучшей эргономикой, компиляцией во время выполнения (comptime), явным управлением памятью и меньшим количеством неопределённого поведения.
• Критикуется реакция создателя Zig, Эндрю Келли, на конструктивную критику, которую некоторые участники сочли резкой и недружелюбной.
• Zig позиционируется как мощный инструмент для низкоуровневого программирования с ультранизкой задержкой (например, для HFT или игр), где безопасность не является приоритетом, в противовес Rust.
• В качестве альтернатив для модернизации C++ упоминаются другие языки, такие как Carbon.

В проекте Git предложено постепенное внедрение Rust в ядро системы, начиная с версии 3.0. Это тестовый шаг, аналогичный прошлым экспериментам с C99, чтобы дать сообществу время адаптироваться к новым требованиям инструментария. Первым кандидатом для перевода выбран модуль varint.c из-за его простоты и отсутствия зависимостей — уже реализованная версия на Rust прошла все тесты.

Пока поддержка Rust добавлена только в систему сборки Meson, с планами расширения на Makefiles. Также предстоит настроить CI-задачи для проверки сборки, форматирования кода и других аспектов. Это позволит поэтапно развивать инфраструктуру без немедленных обязательств, фокусируясь на процессе интеграции, а не на конкретных функциях.

• Предложение сделать Rust обязательной частью инфраструктуры сборки Git 3.0, пока как опциональная зависимость, с переходом на обязательную после появления поддержки в GCC.
• Высказаны опасения о снижении портируемости из-за ограниченной поддержки платформ Rust, сложности инструментария и повышении порога входа для новых разработчиков.
• Часть сообщества видит в этом ненужное усложнение для зрелого проекта и сомневается в целесообразности из-за малого объема нового кода.
• Другие считают, что Rust улучшит безопасность и консолидирует код, заменив существующие скриптовые языки, и что изучение нового языка — норма для разработчиков.
• Обсуждение включает технические детали о кросскомпиляции, поддержке различных архитектур и влиянии на такие проекты, как libgit2.

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

В контексте генерации текста цепочки Маркова применяются для предсказания следующего слова на основе предыдущих. Автор, разочаровавшись в сложности и «магии» современных языковых моделей, обратился к этой прозрачной и фундаментальной технике, реализовав автодополнение на Rust и WebAssembly. Это подчёркивает ценность понимания базовых принципов вместо слепого использования сложных систем.

• Обсуждаются ограничения и природа марковских цепей: их линейность, неспособность учитывать контекст за пределами текущего состояния и проблемы с обработкой двумерных данных.
• Упоминаются исторические и юмористические примеры использования марковских цепей для генерации текста: Mark V. Shaney, KingJamesProgramming, спам-сайты и чат-боты в IRC/Slack.
• Проводятся паралле

В защиту C++

Почему C++ остаётся мощным и актуальным языком программирования в современном технологическом ландшафте.

Репутация C++

C++ часто критикуют за сложность, крутую кривую обучения и способность позволить разработчикам не просто выстрелить себе в ногу, но и оторвать всю ногу. Но выдерживают ли эти критики проверку?

В этом посте я постараюсь разобрать некоторые распространённые критические замечания и представить сбалансированный взгляд на сильные и слабые стороны языка.

C++ «сложен»

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

Не совсем. Преждевременная оптимизация — корень всех зол. В C++ можно писать прекрасный код, не беспокоясь о сложных функциях языка. Можно создавать простой, читаемый и поддерживаемый код без шаблонов, перегрузки операторов и других продвинутых возможностей.

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

C++ «устарел»

C++ очень стар — он вышел в 1985 году. Но означает ли это, что он устарел?

Ни в коем случае. C++ активно развивается уже более 40 лет. Последняя версия стандарта, C++20, добавила множество новых функций, а C++23 расширил возможности стандартной библиотеки, концепций, диапазонов и сопрограмм, делая язык более мощным и выразительным.

C++ остаётся одним из самых widely используемых языков с огромной экосистемой библиотек и инструментов. Он применяется в играх, высокопроизводительных вычислениях и embedded-системах. Многие популярные приложения написаны на C++.

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

C++ «небезопасен»

А вот и главный аргумент. Да, я сравню с Rust, поскольку его часто называют «безопасным» языком, который должен заменить C++.

Переписывание кодовых баз C++ на Rust всегда даёт более безопасные результаты.

Многие компании сообщают об улучшении безопасности и уменьшении количества ошибок после перехода на Rust.

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

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

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

• C++ и C полагаются на навыки и дисциплину разработчиков вместо автоматических проверок безопасности, что часто приводит к уязвимостям в больших проектах.
• Сложность C++ считается чрезмерной и архаичной, многие функции языка (шаблоны, перегрузка операторов) сложны для понимания и неизбежны в реальных проектах.
• Безопасность памяти в C++ проблематична даже для опытных разработчиков, в отличие от языков с автоматической проверкой, таких как Rust.
• Идиоматичный C++ сильно отличается от C, и попытки писать на C++ «как на C» противоречат современным практикам и стандартам.
• Переписывание кода с C++ на Rust часто повышает безопасность и удобство сопровождения, но обратный процесс сложнее и рискованнее.
• C++ останется важным языком из-за его распространённости в legacy-системах и критичных к производительности областях.
• Инструменты и экосистема C++ (пакетные менеджеры, форматтеры) часто считаются устаревшими по сравнению с современными языками.

Safe C++ больше не развивается.
Год назад появился черновик, обещавший «ржавую» безопасность без ломки старого кода: память, типы, потоки — всё через явный safe-контекст. Комитету идея не зашла: модель Rust назвали чуждой, голоса отдали Profiles — набору ограничений на уже существующий C++, которые на этапе компиляции блокируют UAF, data-race, deadlock, утечки.

Profiles не добавляют синтаксиса, только запрещают опасные паттерны; включаются опцией, обратно совместимы. Safe C++ требовал новых квалификаторов и заимствовал проверки времени жизни — слишком радикально.

Автор Safe C++, Шон Бакстер, признал:

Дальнейшая работа бесполезна; все силы — в Profiles.

Вывод: Profiles слабее, но реалистичнее; ждём их в C++26.

• Комитет C++ фактически отверг Safe C++ и ограничился «Profiles» — набором флагов, запрещающих часть небезопасных конструкций.
• Участники сходятся: главная проблема не техническая, а культурная — сообщество не хочет ограничений, считая «если код работает — значит, он безопасен».
• Profiles критикуют за примитивность: они не решают temporal safety, не выражают лифтаймы и не требуют изменения синтаксиса, поэтому дают лишь иллюзию защиты.
• Большинство считает, что без полного отказа от C-подобного подмножества и без внедрения lifetimes C++ никогда не станет «безопасным»; проще перейти на Rust.
• Практический вывод: крупные проекты продолжат игнорировать Profiles, а новые кодовые базы будут выбирать Rust либо двухъязычный подход «C++26 + внешние анализаторы».

Краткий обзор проблемы C++ модулей

1. Главное требование
   Если модули не ускоряют сборку минимум в 5 раз (желательно 10×) на реальных проектах, их нужно удалить из стандарта. Все остальные плюсы не стоят вложенных ресурсов.

2. Что обещали vs. что получили

   • Изначально: «уберём O(N²) из-за заголовков, компиляция станет мгновенной».
   • Сейчас: упор сместился на «изоляцию сборки» (макросы, пространства имён). Это полезно, но редко встречается и не решает главную боль — медленную сборку каждый день.

3. Почему всё так плохо

   • Модули приняли в C++20, несмотря на предупреждения о невозможности реализации.
   • Реализация заняла >5 лет и всё ещё не готова.
   • Стандарт не описывает, как именно компилятор и сборочная система должны взаимодействовать: имена файлов, каталоги, зависимости — всё на совести разработчиков.
   • Компиляторные команды отказываются «превращаться в систему сборки» и блокируют любые предложения.

4. Итог
   Проект превратился в «интеграционный ад». Пока нет массовых 5-10-кратных ускорений, дальнейшие инвестиции — просто затягивание «затратной ямы».

• Участники сетуют: вместо простого «import = include без утечек контекста» получили громоздкий механизм, который мало кто использует.
• Старые пре-компил-хедеры 90-х и сторонние решения вроде zapcc уже давали 5× ускорение, но были проигнорированы стандартом.
• Модули обещали избавить от forward-declaration и макро-ifdef, но на практике вызывают лавину пересборок и несовместимы с большим объёмом существующего кода.
• Многие считают, что модули заточены под «большой тех» с кэшированными билдами, а малый бизнес и хобби-проекты «попали в пролёт».
• Итоговое настроение: «убейте модули, C++ всё сломали», «мир ушёл в Rust», но «на C++ всё ещё держится пол-мира, так что просто так не выкинешь».

grok-code-fast-1 — новая модель xAI для агентного кодинга: быстрая, дешевая, заточена под ежедневную работу.

• Скорость: архитектура с нуля, оптимизация инференса, кеш >90 %. Десятки вызовов инструментов до того, как вы прочтёте первую строку мыслей.
• Цена: 0,20 $/1 M входных, 1,50 $/1 M выходных, 0,02 $/1 M кешированных токенов.
• Языки: TypeScript, Python, Java, Rust, C++, Go.
• Инструменты: grep, терминал, редактирование файлов — «родная» работа в IDE.
• Партнёры: временно бесплатно в Cursor, GitHub Copilot, Cline, Roo Code, Kilo Code, opencode, Windsurf.

Производительность

• 190 токенов/сек, SWE-Bench-Verified 70,8 %.
• Оценки реальными разработчиками: быстро и надёжно для рутинных задач.

• Кто-то хвалит grok-code-fast-1 за скорость и качество, сравнивая с gpt-5-mini, другие считают «быстро, но тупо».
• Основная критика: упор на скорость вместо качества, неточные или вредные изменения кода, сомнительные внутренние бенчмарки.
• Несколько человек жалуются, что модель случайно удаляет код и скрывает кнопки «стоп».
• Подняты этические и экологические вопросы: нелегальные газовые турбины и «обученный нацистский бот».
• Часть пользователей просто рада быстрой бесплатной модели в Cursor/VS Code для простых задач.

Rust повышает производительность разработки, несмотря на сложность.
Ключевые факторы:

• Жёсткий компилятор ловит ошибки до запуска, уменьшая время отладки.
• Модель владения устраняет гонки и утечки памяти, снижая количество багов.
• Инструменты: Cargo, Clippy, rustfmt и rust-analyzer ускоряют цикл «написание → проверка → запуск».
• Сообщество предлагает качественные крейты и быструю помощь.
• Производительность кода сравнима с C/C++, но без segfault и UB.

В итоге меньше времени тратится на отладку, больше — на новые функции.

• Автор статьи рассказал, как Rust позволяет безболезненно рефакторить большие кодовые базы благодаря строгой типизации и проверкам компилятора.
• Многие участники согласились, что статическая типизация (Rust, Haskell, OCaml-подобные языки) повышает уверенность при изменениях, особенно в многолюдных проектах.
• Часть комментаторов считает сравнение с TypeScript «нечестным»: TS компилируется в JS и наследует его недостатки, а приведённый баг с window.location.href — это особенность DOM, а не языка.
• Некоторые отметили, что Rust тоже не идеален: async/синхронные блокировки, медленная компиляция и «множество способов сделать одно и то же» могут снижать удобство.
• Общий вывод: преимущество Rust в безопасности и рефакторинге особенно заметно на больших проектах, но язык требует времени на изучение и не всегда лучше «классических» статически типизированных альтернатив.

rv — новый Ruby-менеджер
Десять лет я мечтал о менеджере, который одновременно управляет Ruby-версиями, ставит уже скомпилированные интерпретаторы и запускает любой скрипт без конфликтов. Такой инструмент уже есть — это Python-утилита uv. Вдохновившись ею, я начал делать rv.

Что умеет rv

• Написан на Rust ⇒ всё мгновенно: установка Ruby 3.4.x на macOS/Ubuntu занимает 1 с.
• rv tool run — запуск любой gem-команды (gist, rubocop, …) в изолированном окружении без предварительной настройки.
• rv tool install — ставит CLI-утилиту с собственным Ruby и гемами, не трогая проект.
• Однофайловые скрипты: внутри .rb хранятся версия Ruby и lock-файл; rv run script.rb — и всё работает.
• Единая команда вместо цепочки rvm install, bundle install, bundle exec.

Команда и статус
Уже подключились Samuel Giddins (RubyGems) и Sam Stephenson (rbenv). Сейчас rv умеет переключать Ruby в zsh и ставить готовые сборки.
Попробовать: spinel-coop/rv и roadmap.

• Участники обсуждают новый инструмент rv для Ruby, вдохновлённый uv из Python-мира.
• Одни рады скорости и «одному инструменту для всего» (Ruby + gems + инструменты), другие считают, что Bundler и так работает нормально.
• Часть разработчиков предпочитает универсальные менеджеры (mise, asdf, Nix), чтобы не плодить отдельные утилиты под каждый язык.
• Есть опасения, что Ruby может пойти по пути «venv-ада» Python или потребовать Rust для вклада.
• Несколько человек просят сравнительную таблицу с rvm/rbenv и поддержку .tool-versions.

Перешёл в компанию, где стек — Python. Выбор был не из-за языка: Python мне всегда казался гигантским красным флагом. Тем не менее, начинаю к нему привыкать.

Почему я любил Ruby

Ruby — мой первый «язык-любовь»: всё объект, if можно переписать блоками, method_missing позволяет метапрограммировать. Он черпал у Smalltalk и Lisp, и это вдохновляло.

Почему ненавидел Python

Python казался «хуже Ruby» и «ещё хуже Scheme». if — оператор, а не выражение; lambda уродливые; до Python 3 print вообще был оператором. Один «правильный» способ делать всё раздражал.

Типы для нетипизированного

Потом пришёл TypeScript: мощная система типов, narrowing, conditional types. Плохие конструкции языка прощаются статическим анализом.

Я изменился

TypeScript научил: отсутствие match или if-выражения пережить, если компилятор проверит инициализацию. Rust показал, что мутабельность — не зло.

Python изменился

Теперь в Python есть type hints, match с деструктуризацией, а print — функция.

• Автор рассказал, как после появления VSCode и LSP перестал использовать языки без типов и теперь не хочет возвращаться к Ruby без нормальной типизации.
• Участники обсуждают, что Ruby остаётся элегантным и «радостным», но его отказ от постепенной типизации (включая Sorbet) отталкивает многих.
• Python, напротив, эволюционирует: появились аннотации типов, LSP, но язык стал сложнее и уже не «выучить за выходные».
• Некоторые считают, что страсть к Ruby — это ностальгия, а промышленность требует стабильности и инструментов, которые дают статические языки.
• Общий вывод: выбор языка всё чаще диктуется экосистемой, инструментами и личными приоритетами, а не чистой «красотой» синтаксиса.

CLI-утилитам не место в ~/Library/Application Support

Популярные библиотеки (Python platformdirs, JS env-paths, Rust dirs, Go adrg/xdg) по умолчанию кладут конфиги в ~/Library/Application Support, но это каталог для GUI-приложений. Пользователи ожидают увидеть настройки CLI-программ в ~/.config, как Git, Vim, Tmux и сотни других. Это ожидание закреплено стандартом XDG и принципом «наименьшего удивления».

Почему это важно

• Неожиданное расположение ломает привычки и усложняет версионирование.
• Даже менеджеры dotfiles (chezmoi, dotbot, yadm, rcm, GNU Stow) игнорируют ~/Library/Application Support, что подтверждает: сообщество считает ~/.config единственным разумным местом для конфигов CLI-утилит на macOS.

• Автор утверждает, что CLI-утилиты macOS должны хранить конфиги в ~/.config по XDG, но участники показывают: ни одна поставляемая с macOS утилита этого не делает.
• Большинство считает XDG спецификацией для Linux/Unix-сред и не видят оснований навязывать её macOS, у которой есть собственные места: ~/Library/Preferences и ~/Library/Application Support.
• Разработчики CLI-инструментов, портированных с Linux, действительно часто используют ~/.config, что вызывает у местных пользователей ощущение «плохого порта».
• Предлагаются компромиссы: использовать XDG-переменные, если они заданы, или делать симлинки между ~/.config и ~/Library/Application Support.
• В Rust-экосистеме крейт dirs-rs игнорирует XDG на macOS; участники обсуждают создание форка, который бы следовал спецификации.

В JavaScript "🤦🏼‍♂️".length == 7 — не ошибка, а результат подсчёта UTF-16 кодовых единиц.
Эмодзи состоит из 5 скалярных значений Unicode, но в UTF-16 они занимают 7 code units:

• 🤦 U+1F926 → 2
• 🏼 U+1F3FC → 2
• ZWJ U+200D → 1
• ♂ U+2642 → 1
• VAR-16 U+FE0F → 1

Итого 7 — именно это и возвращает .length.

Другие языки считают по-своему:

• Python 3 → len("🤦🏼‍♂️") == 5 (кодовые точки, но допускает суррогаты).
• Rust → "🤦🏼‍♂️".len() == 17 (байты UTF-8).
• Swift → "🤦🏼‍♂️".count == 1 (расширенный графем-кластер).

Каждый подход отвечает на свой вопрос: «сколько code units / bytes / графем». Ни один не универсален; выбор зависит от задачи.

• Обсуждение вокруг статьи показало, что «длина строки» не имеет единого определения: бывают байты, UTF-16/UTF-32 код-юниты, скалярные значения Unicode и расширенные графем-кластеры.
• Пользователи жалуются, что разные языки и API возвращают разные числа для одного и того же эмодзи, что ломает UI-ограничения, индексы БД и обработку текста.
• Часть участников считает, что нужно явно различать «длину для хранения», «длину для отображения» и «длину для человека»; другие мечтают вернуться к чистому ASCII.
• Примеры кода на Java, Python, Raku и JS показывают, как получить каждый из вариантов длины, но подчеркивают отсутствие общего стандарта.
• Итог: «length» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.

• История: от pre-fork до epoll — каждый шаг уменьшал сисколлы, но они всё ещё оставались узким местом.
• io_uring — кольцевые очереди в памяти: сервер пишет команды, ядро асинхронно их выполняет и кладёт результат обратно. При высокой нагрузке strace не покажет ни одного сисколла.
• 1 поток = 1 ядро без разделяемых структур; память берётся только из локального NUMA-узла.
• Память: заранее выделяем фиксированный буфер на соединение — без brk/mmap, без фрагментации.
• kTLS — после рукопожатия шифрование переходит в ядро. Плюсы:
  1. Работает sendfile, данные не копируются в userspace.
  2. Возможно аппаратное ускорение NIC.

• io_uring даёт «zero-syscall» при высокой нагрузке, но требует ручного управления памятью: безопасность не обеспечивается ни borrow checker, ни runtime.
• На большинстве облачных платформ io_uring выключен по умолчанию, поэтому остаётся нишевым.
• Автор статьи сначала чистит код, а потом будет мерить производительность — что вызвало одобрение читателей.
• Обсуждаются альтернативы: epoll, kTLS, DPDK, eBPF, а также споры «один поток на ядро» vs oversubscription.
• Некоторые считают, что сложность io_uring и async Rust — цена за неспособность ОС ускорить syscalls без нарушения обратной совместимости.

Без futex всё тленно

Книга The Art of Multiprocessor Programming (2-е изд., 2021) считается канонической, но она обходит стороной futex — ключевой примитив современной многопоточности. Это упущение делает пособие бесполезным для практиков.

Futex ≠ mutex
Название происходит от «fast userspace mutex», но futex — это не мьютекс, а основа для всех высокоэффективных примитивов синхронизации. До него всё строилось на громоздких System V IPC, которые не масштабировались: при 1000 потоков futex в 2002-м оказался в 20–120 раз быстрее sysv-блокировок. Windows и macOS добавили аналоги только в 2012 и 2016 гг.

Суть futex
Он разделяет блокировку и ожидание/пробуждение:

• В user-space проверяем состояние; если свободно — захватываем без системного вызова.
• При конфликте вызываем futex_wait(addr, expected), засыпаем в ядре на конкретном адресе.
• Пробуждение — futex_wake(addr, n), где n обычно 1 или «все».

Передаваемое в wait значение защищает от «просыпания» после уже случившегося события: если память изменилась, системный вызов мгновенно возвращает ошибку.

Такой подход убирает лишние системные вызовы и позволяет строить быстрые мьютексы, rw-lock’и, семафоры и пр. без поллинга и экспоненциальных бэкоффов.

Итог
Любая современная библиотека (pthreads, C++ std::mutex, Rust std::sync) опирается на futex. Учебник, игнорирующий этот примитив, не готовит к реальной разработке.

• Futex — это быстрый примитив синхронизации, который экономит системные вызовы при отсутствии конфликтов и не требует выделения ядром объектов.
• В отличие от Benaphore и старых SysV-механизмов, futex не требует предварительной инициализации в ядре и исчезает, когда нет ожидающих.
• Обсуждение подчёркивает, что современные учебники по многопроцессорному программированию обязаны упоминать futex, но «The Art of Multiprocessor Programming» этому не уделяет внимания.
• Улучшения futex2 (Linux ≥5.16) добавили NUMA-поддержку и аналог Windows WaitForMultipleObjects, а io_uring теперь умеет работать с futex.
• Для надёжности при падении потока существуют robust-locks и списки futex, которые ядро автоматически разблокирует.

Я написал What the Fork — кроссплатформенный визуализатор сборки C/C++ (и не только).
Запуск: wtf make, wtf cargo build, wtf gradle build, wtf -x для Xcode и т.д.

Инструмент показывает все процессы, включая скрытые вызовы ld, и ищет типичные проблемы:

• отсутствие -j у make,
• однопоточная компиляция,
• повторяющиеся cmake/make-шаги,
• непараллельные CI-сборки.

Как работает
Сборка = дерево команд. Чтобы увидеть всё, ловим системные вызовы fork/exec/exit:

• macOS — Endpoint Security API,
• Linux — ptrace,
• Windows — Event Tracing (самое мерзкое API).

Что уже нашли

• cargo собирал зависимость одним потоком вместо 10× ускорения.
• ninja при сборке LLVM держит 12 задач на 10 ядрах — почти идеал.
• CMake 85 раз подряд вызывает xcode-select, sw_vers, cmake/make → clang, не используя параллелизм.

Инструмент открыт для тестов — попробуйте на своём проекте.

• Пользователи восторженно реагируют на новый визуализатор сборки, особенно те, кто застрял на CMake/GCC/Make без clang/ninja и не может понять, почему сборка тормозит.
• Просят сразу показать GIF-демонстрацию под заголовком статьи и спрашивают, будет ли macOS-версия и открытый код.
• Некоторые делятся опытом: strace/dtruss, ninjatracing, vcperf, cargo --timings, Instruments и другие инструменты уже решали похожие задачи.
• Предложения расширить функциональность: добавить flame-графы процессов, поддержку fork(), интеграцию с Bazel Build Event Protocol, оценку «осталось времени» по историческим данным.
• Отдельные комментарии касаются маркетинга (сменить название), сравнения с VS/Xcode, а также шуток про TEEP/OEE завода и «LLVM, завари кофе».

Zig выглядит почти как Rust, но делает синтаксис ещё приятнее за счёт более простой семантики и ряда изящных решений.

Числа
Литералы 92 всегда имеют тип comptime_int; при присваивании они неявно приводятся к нужному типу. Суффиксов нет.

Строки
Многострочные «сырые» строки пишутся через \\ в начале каждой строки; \ не экранируется, отступы не портятся, а лексер работает построчно.

Структуры
.{ .x = 1, .y = 2 } — запись поля через .x = совпадает с присваиванием, что позволяет грепом находить именно записи, а не чтения.

Типы
Все типы префиксные: u32, [3]u32, ?[3]u32, *const ?[3]u32. Разыменование постфиксное: ptr.*.

Идентификаторы
Синтаксис @"имя с пробелом" позволяет обходить ключевые слова и экспортировать любые имена.

Функции
fn add(x: i32, y: i32) i32 — без стрелки ->, так как лямбд нет, а возвращаемый тип всегда обязателен. pub fn main() void {}.

Переменные
const и var; часто используемое const короче, чем в Rust, но всё же длиннее Kotlin-овского val.

• Обсуждение разделилось: кому-то синтаксис Zig кажется «прекрасным» минимализмом, другим — «шумным» и «капризным».
• Спор о порядке «имя: тип» vs «тип имя»: одни хотят видеть тип первым, другие — имя.
• Критика деталей: @-префиксы, .{}, отсутствие лямбд, перенос строк, orelse без пробела.
• Плюсы: raw-строки Zig решают проблему отступов; обработка ошибок через try нравится многим.
• Сравнения: Kotlin, C#, Go, Rust, D — каждый считает «своё» лучше.
• Итог: «красота» синтаксиса субъективна и во многом привычна; после практики Zig начинает нравиться.

Debian GNU/Hurd 2025 — неофициальный релиз Debian, но официальный порт.
Основан на «sid» в момент выхода «Trixie».

• ISO: hurd-i386 | hurd-amd64
• Образы и инструкции: hurd-install

Архитектуры: i386, amd64; покрытие ~72 % архива Debian.

Новое

• 64-бит полностью готов, драйверы дисков через Rump (NetBSD).
• xattr по умолчанию для трансляторов; mmdebstrap из других ОС.
• Порт Rust, USB-диски и CD через Rump.
• SMP, xkb-раскладки, framebuffer, acpi, rtc, apic, hpet.
• Исправления irqs, nfsv3, libports, pipes и др.

Документация

• FAQ
• Translator primer

Присоединяйтесь: contributing

• Hurd — давний проект с микроядром Mach, фактически движимый одним человеком (Samuel Thibault), и сегодня выглядит скорее хобби-экспериментом, чем реальной альтернативой Linux.
• Участники обсуждают низкую поддержку железа, архаичную архитектуру и отсутствие прогресса: «ждать совершенства — значит никогда не стать готовым».
• Предлагаются новые микроядра (seL4, L4, Viengoos) и языки (Rust, Zig), но критика считает это погоней за хайпом.
• GUIX/Nix и GNU Shepherd упоминаются как более живые GNU-ориентированные проекты; GUIX уже умеет запускать Hurd в виртуалке.
• Итог: Hurd остаётся интересным музейным экспонатом и источником идей, но не готов к «повседневному» использованию.

Debian 13 «trixie» вышел 9 августа 2025 года после 2 лет разработки.
Поддержка — 5 лет (Security + LTS).

Десктопы: GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1, Xfce 4.20.
Пакетов: 69 830 (+14 100 новых, –8 840 устаревших, 44 326 обновлённых).
Размер: 403 ГБ, 1,46 млрд строк кода.
Ядро: 6.12 LTS; первый релиз с официальной поддержкой riscv64.
Архитектуры: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x.
i386 больше не поддерживается; armel последний релиз.

Ключевые обновления: Apache 2.4.64, Bash 5.2.37, BIND 9.20, GCC 14.2, LibreOffice 25.2, MariaDB 11.8, Nginx 1.26, OpenJDK 21, PHP 8.4, PostgreSQL 17, Python 3.13, Rust 1.85, systemd 257 и др.

Облако: образы для EC2, Azure, OpenStack, PlainVM, NoCloud с cloud-init и оптимизированным загрузчиком.
Live-образы: amd64/arm64, GNOME/KDE и др.; установка через Calamares или стандартный установщик.

• Debian 13 «Trixie» вышла: 63 % пакетов обновлены, поддержка 7 архитектур, включая RISC-V.
• i386 теперь только как «amd32»-совместимый, официального ядра/инсталлятора нет.
• Появился новый формат APT-репозиториев debian.sources, старый sources.list пока работает.
• 95 % пакетов достигают bit-for-bit воспроизводимости на amd64/arm64/riscv64.
• /tmp теперь tmpfs по умолчанию (до 50 % ОЗУ), но можно вернуть старое поведение.
• Пользователи хвалят стабильность, скорость обновления «stable→stable» и отсутствие snap.

LLM-разработка: краткий итог

• Мифы: LLM не делают код продакшн-готовым, требуют понимания задачи и хорошо структурированных кодовых баз. Использование LLM снижает навыки чтения документации и глубокого мышления.
• Агенты — это просто цикл «LLM → вызов локального API → ответ → LLM снова». Инструменты: навигация, редактирование, shell, поиск, MCP-серверы.
• Проблемы продуктов
  • Нестабильность: модели и цены меняются еженедельно.
  • Нет детерминизма, приходится постоянно обновлять промпты и MCP.
• Тесты
  • Python, TypeScript, Rust, Flutter, сложные рефакторинги — справляются.
  • Не справились: Token Field во Flutter (редкий компонент, сложное управление состоянием). Claude Opus 4.1 и GPT-5 провалили задачу.

Продукты

• GitHub Copilot

  • Плюсы: быстрое автодополнение, стабильность, низкая цена.
  • Минусы: слабые «агенты», нет контекста всего проекта.

• Claude Code Pro

  • Плюсы: лучший «умный» режим, хорошо работает в больших кодовых базах.
  • Минусы: дорого, медленно, иногда «теряется».

• Gemini CLI / Jules

  • Плюсы: бесплатный CLI, быстрый.
  • Минусы: слабые модели, ограниченные возможности.

• Kiro, Cursor, Windsurf

  • Плюсы: встроенные редакторы, удобные интерфейсы.
  • Минусы: дороже, часто баги, привязка к конкретному редактору.

Когда LLM полезны

• Лучшие языки: Python, TypeScript/JavaScript, Go.
• Лучшие задачи:
  • Репетитивный код, тесты, миграции.
  • Документация, примеры, объяснение legacy.
• Плохо:
  • Редкие фреймворки, сложные UI, архитектурные решения.
  • Надёжность и безопасность.

Вывод
LLM — полезный инструмент для рутины и прототипов, но не заменяет мышление и глубокое понимание.

• Многие спорят с тезисом «использовать LLM в коде тривиально»: на практике нужны месяцы, чтобы понять, что делегировать, как формировать промпты и управлять контекстом.
• Кто-то сравнивает LLM с «однорукими бандитами»: результат часто случаен, а «навыки» сводятся к удаче и базовому гуглению.
• Другие делятся успешным опытом: при жёсткой архитектуре, тестах и узких промптах Claude Code и аналоги дают 9/10 полезных патчей.
• Утверждение, что LLM «заставляют» выбирать мейнстек, опровергают разработчики на Clojure, D и других нишевых языках.
• Общий вывод: LLM — мощный инструмент, но требует экспериментов, критического ревью и понимания своих ограничений; без этого он быстро превращается в источник технического долга.

Почему наём — боль

Компании теряют время: 9 раундов, охота за «трендовыми» разрабами, не могут отличить программиста от LLM. Кандидаты страдают: лучшие разрабы (Rust, Haskell) проваливают стресс-интервью, рекрутеры называют их «не-технарями», а потом пропадают на месяцы.

Каким должен быть хороший процесс

1. Различать сеньора и маркетолога с ChatGPT.
2. Применимо к работе: код, архитектура, ревью, документация.
3. Долгосрочно: люди не взаимозаменяемы, уход дорого, специализация под стек выучивается за месяц.
4. Экономно: инженерное время дорого.
5. Уважительно: неуважение отпугивает лучших.
6. Вкус: быстрое, но грязное решение — долгий долг команде; «клей» (поддержка коллег) множит продуктивность.

Почему популярные форматы не работают

• Live-coding / LeetCode
  Не различают, не про работу, уничтожают уважение и вкус, дорогие при многократных раундах.

• Take-home
  Легко сгенерировать ChatGPT, неуважительны к времени кандидата, отпугивают сильных.

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

• Современные «интервью» больше похожи на серию экзаменов, чем на профессиональный разговор.
• Многие считают, что достаточно 1-2 коротких встреч или пробы через контракт «temp-to-perm», чтобы понять, подходит ли человек.
• Популярные live-coding и leetcode почти не отражают реальную работу и отбирают не тех специалистов.
• Лучше обсуждать реальные задачи, ревьюить существующий код или решать мелкий баг в паре — это ближе к ежедневным обязанностям.
• Кандидаты теряют время и энергию на домашние задания и 9-часовые циклы, поэтому всё чаще «интервьюируют» и сами компании.

Задача: перенести TypeScript-утилиту Ruler на Rust, проверить идентичность через bash-тест.
Модели: GPT-5 (новый, превью) и Claude 4 Sonnet.

GPT-5

• Сразу прочитал код, составил подробный plan.md, получил одобрение.
• Работал почти без остановок, дважды отчитывался о статусе.
• Сначала написал bash-скрипт, который запускает оригинал и порт во временной папке и сравнивает вывод.
• Затем сгенерировал структуру src/, Cargo.toml, CLI-аргументы, логику apply/init/revert, обработку конфигов и MCP.
• Итеративно правил код, пока тест не прошёл «зелёным».
• Время: ~20 мин, 1 коммит, ветка feat/rust-port.

Claude 4 Sonnet

• Та же инструкция.
• Сразу начал писать Rust, но упустил bash-тест; пришлось напомнить.
• Тест написал быстрее, но менее читаемый.
• Порт делал «пачками»: сначала CLI, потом логика, потом MCP.
• После 3-х итераций тест прошёл.
• Время: ~30 мин, 3 коммита.

Вывод

• GPT-5 агентнее: сам планирует, реже спрашивает, меньше ошибок.
• Claude надёжнее в деталях, но требует чётких шагов.
• Оба справились, но GPT-5 ощущается «ближе к одной команде — один результат».

• Пользователи сомневаются в объективности сравнений: результаты сильно зависят от системных промптов, харнесов и задач.
• Критика выбора моделей: вместо топ-версии Claude Opus сравнивали более дешёвый Sonnet, что искажает оценку «лучшей» модели.
• Стоимость vs качество: большинство разработчиков не готовы платить 10× за Opus, поэтому GPT-5 рассматривают как «cost-effective» вариант.
• Опыт в продакшене: многие находят Claude Code (Sonnet/Opus) надёжнее при работе с большими кодовыми базами и TDD, тогда как GPT-5 хорош для разовых скриптов.
• Нет единой метрики: из-за недетерминированности моделей и субъективных критериев «хорошего кода» каждый получает разные результаты.

Представьте, вы пишете проект и вам нужна библиотека — назовем ее libpupa.

Вы находите текущую версию 1.2.3 и добавляете в зависимости: "libpupa": "1.2.3" Автор libpupa 1.2.3 в свою очередь зависел от liblupa версии 0.7.8 и записал это: "liblupa": "0.7.8" То есть libpupa 1.2.3 навсегда зависит от liblupa 0.7.8. Алгоритм разрешения зависимостей простой и детерминированный: берем версии верхнего уровня, затем версии их зависимостей, и так далее. Достаточно указать только верхние уровни — транзитивные получатся одинаковыми всегда. Зачем отдельный lockfile?

Но люди изобрели lockfile из‑за диапазонов версий. Диапазоны делают сборку зависимой от времени: сегодня вы получите liblupa 0.7.8, через 10 минут — 0.7.9. Это определяется не при публикации, а при сборке: вы можете подтянуть версию, которой не существовало на момент выпуска libpupa 1.2.3. Откуда автор libpupa знает, что будущая 0.7.9 не сломает его код? Семантическое версионирование — это лишь намек, не гарантия.

И смешно то, что эти диапазоны все равно «замораживают» в lockfile, и вы не получаете предполагаемой пользы. «Перегенерируй lockfile и обновись» — это ничем не отличается от обновления верхнеуровневых зависимостей. «Lockfile решает конфликты версий?» — нет: библиотека либо работает с новой версией, либо нет; запись «0.7.*» не помогает — все равно нужно выбрать рабочую версию.

«Но раз lockfile существует, значит, нужен!» — не обязательно. Пример: Maven. Экосистема Java 20 лет обходится без lockfile, при этом тянет сотни библиотек — и все детерминировано.

Вывод: lockfile усложняет без достаточных причин. Менеджеры зависимостей могут работать без него.

UPD: В Maven при конфликте транзитивных зависимостей выбирается версия, ближайшая к корню. Это детерминированно и позволяет переопределять версии. Если вышла d 2.1 с патчами безопасности, добавьте ее в корень — она и будет выбрана, не дожидаясь обновлений у всех. Если автоматически брать самую большую версию, вы потеряете возможность переопределения.

• Обсуждение крутится вокруг необходимости lock-файлов и версионирования: одни считают, что фиксированные версии и детерминированные алгоритмы достаточно, другие настаивают, что lock-файлы критичны для воспроизводимости и безопасности.
• Приводят примеры из экосистем Maven/Java, Go (MVS), Cargo/Rust, .NET, Scala: у каждого свои компромиссы; даже при детерминированном резолве сеть/репозитории делают сборки недетерминированными без lock-файлов и хэшей.
• Аргументы за версии-диапазоны: автоматическое получение патчей безопасности без вмешательства авторов верхнеуровневых библиотек; но это ломается при конфликтующих транзитивных зависимостях и несовместимых API/ABI.
• Много комментариев о том, что lock-файлы особенно нужны приложениям (прод, стейджинг, аудит), а для библиотек — меньше, но всё равно полезны из-за пересборок и целостности (хэши артефактов).
• Подчёркивают проблемы разных языков: в компилируемых — типы из разных версий несовместимы; в JS Node могут сосуществовать несколько версий, но это не решает безопасность/детерминизм.
• Некоторые отмечают, что главная путаница — не в lock-файлах, а в культуре семвера, централизованных репозиториях и UX инструментов; предлагают BOM/snapshot-подходы и периодические обновления с тестами/реновейтом.
• Отдельная ветка критикует дизайн сайта с анимированными иконками, мешающими чтению.

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

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

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
    return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world'))  # type: ignore

Чекер доволен, но семантика сложения уже другая. Аннотации бесполезны для оптимизации и скорости, если их не гарантирует рантайм. Более того, в Python легально перегружать операции, меняя поведение в рантайме, что разрушает предпосылки для агрессивных оптимизаций.

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.

• Сгенерированное ИИ изображение, где ИИ руками «отвергает» меня. Очень мета.

В октябре 2024 Anthropic представила «Claude Computer Use», позволяющую ИИ управлять компьютером, копировать данные из браузера в таблицы и т.п. Я поддерживаю библиотеку для управления компьютером и этой весной решил разобраться, как они это делают. К моему удивлению, Anthropic использует мою библиотеку enigo.

Проверить использование enigo в Claude Desktop для macOS можно так:

• 7z x Claude.dmg
• perl -nle 'print $& while /.{0,67}enigo.{0,30}/g' Claude/Claude.app/Contents/Resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод содержит путь к enigo-0.2.1/src/macos/macos_impl.rs

На Windows:

• 7z x Claude-Setup-x64.exe
• 7z x AnthropicClaude-0.11.6-full.nupkg
• perl -nle 'print $& while /.{0,75}enigo.{0,26}/g' Claude-Setup-x64/AnthropicClaude-0.11.6-full/lib/net45/resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод указывает на enigo-0.2.1/src/win/win_impl.rs

Я горжусь, что enigo дорос до продакшена у компании с огромным бюджетом. Эмуляция ввода сложна из‑за слабой документации и платформенных особенностей. На мой взгляд, enigo — отличный выбор: работает на Windows, macOS, *BSD и Linux (Wayland, X11, libei) без root; написан на Rust (безопасность памяти, высокая скорость); самый популярный на crates.io (~300k загрузок, 1200+ звёзд). И всё же тревожно, что мой хобби‑проект установлен на тысячах устройств.

Сколько я на этом заработал? Нисколько: enigo под MIT‑лицензией — можно бесплатно использовать. Взамен — звёзды на GitHub и счётчик загрузок.

Интересно, что Claude Desktop — Electron‑приложение, но есть только для macOS и Windows. Сообщество запустило его на Linux, заменив вызовы enigo заглушками, хотя enigo кроссплатформенна — любопытный выбор.

Через знакомых я узнал об открытой роли в команде, делавшей секретную, ещё не выпущенную функцию Claude Desktop с enigo. Подал заявку, ждал. В итоге пришло письмо: команда не успевает рассматривать дополнительные заявки.

Я бы с радостью поработал в Anthropic: сделать аналог Computer Use, довести Claude Desktop до Linux, вложить свой опыт в эмуляцию ввода и полноценно отполировать enigo, чтобы Anthropic концентрировалась на моделях, а не на капризах ввода.

В целом я счастлив, что enigo в Claude Desktop, и всем об этом рассказываю. Забавно думать, что я метафорически дал Claude руки и ноги — и получить отказ. Письмо написал человек или сам Claude? По крайней мере, теперь я, наверное, в безопасности…

• Обсуждение вокруг автора OSS-библиотеки enigo, которую, по словам поста, использует Claude Desktop; при попытке податься в Anthropic он получил авто‑отказ без рассмотрения, что вызвало резонанс.
• Многие считают, что заявку, вероятно, даже не читали из‑за перегруженных или автоматизированных HR/ATS‑процессов; советуют искать тёплый интро к менеджеру, а не подаваться «в общий ящик».
• Поднята тема лицензий: permissive (MIT) позволяет корпорациям брать код без вклада; участники предлагают рассмотреть MPL/EUPL, Fair Source или даже целевые ограничения, хотя применимость и исполнение спорны.
• Несколько комментаторов призывают Anthropic хотя бы поблагодарить автора, дать консультационный контракт или символическую компенсацию; другие напоминают, что компания волна отбирать кого хочет.
• Обсуждаются возможные факторы отказа: геолокация (США vs Европа), визы, несоответствие профиля «AI‑инженеру», парадоксы найма и предпочтение «низкопрофильных» кандидатов.
• Приводятся похожие кейсы из индустрии: от игнора мейнтейнеров до неудачных интервью у компаний, зависящих от их софта.
• Общий вывод: современный тех‑набор страдает от автоматизации и перегрузки; для кандидатов критичны нетворкинг, прямой контакт с нанимающим менеджером и стратегия видимости, а для OSS — осознанный выбор лицензии.

Открытые модели OpenAI

Продвинутые модели с открытыми весами для любого кейса и запуска где угодно.

Ссылки:

• Загрузить на Hugging Face
• Исходники на GitHub
• Попробовать демо

Модели:

• gpt-oss-120b — крупная модель для дата-центров и мощных ПК/ноутбуков.
• gpt-oss-20b — средняя модель, работает на большинстве ПК/ноутбуков.

Преимущества:

• Разрешительная лицензия: Apache 2.0 — свободная разработка, без копилефта и патентных рисков; подходит для экспериментов, кастомизации и коммерческого использования.
• Для агентных задач: сильное следование инструкциям и работа с инструментами в ходе рассуждений (веб-поиск, запуск Python-кода).
• Глубокая настраиваемость: выбор уровня «усилия рассуждений» (низкий/средний/высокий) и полно-параметрический финтюнинг под ваш кейс.
• Полная «цепочка рассуждений»: доступна для удобной отладки и повышения доверия к ответам.

Интерактивное демо:

• Простой playground для запуска обеих моделей в браузере.

• Обсуждение посвящено выходу открытых моделей OpenAI gpt-oss (20B и 120B), которые по бенчмаркам близки к o3/o4-mini и местами обгоняют открытые лидеры; многие отмечают, что 20B уже реально запускается локально на Mac/мобильных устройствах.
• Пользователи делятся первыми впечатлениями и ссылками на обзоры/модель-карты, отмечая конкурентную производительность, совместимый токенайзер и адекватное лицензирование; есть поддержка в llama.cpp, Ollama, LM Studio, Harmony формат ответов и растущая роль Rust в инструментах OpenAI.
• Скорости инференса сильно варьируются: от очень быстрых облачных провайдеров (Cerebras/Groq на OpenRouter) до заметных задержек локально при больших контекстах; производительность зависит от GPU/платформы и параметров квантования.
• Отмечают стратегический сдвиг OpenAI к модели Meta: открытые веса как средство захвата экосистемы и снижения порога входа; звучат предположения, что релиз предвосхищает скорый анонс ещё более сильной закрытой модели.
• Сообщество обсуждает экономику: гибридные пайплайны (локально — простые задачи, в облако — сложные), возможность заменять платные подписки локальным запуском, и общий тренд в пользу OSS при минимальной разнице в качестве.
• Есть критика: у 120B встречаются галлюцинации на фактах, часть пользователей недовольна агрессивной безопасностью/отказами, отсутствием оптимизаций под RTX 50, а также неполной мультимодальностью.
• В целом настроение позитивное: многие благодарят за «настоящий» открытый релиз с сопутствующими инструментами и ожидают независимых бенчмарков, которые могут закрепить лидерство gpt-oss среди текстовых открытых моделей.