Стандартный алгоритм Ланцоса для вычисления матричных функций требует значительных ресурсов памяти: хранение n×k базисной матрицы, которая растёт с каждой итерацией. Для задачи с 500 000 переменными и 1000 итерациями это около 4 ГБ только для базиса. В статье представлен двухпроходной вариант алгоритма, требующий всего O(n) памяти ценой удвоения числа матрично-векторных произведений. При грамотной реализации этот подход не только экономит память, но и может работать быстрее для определённых задач.

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

• Обсуждение охватывает редкий случай, когда матрица и векторы помещаются в кэш, но базис не помещается, и показывает, что алгоритм Ланцоша может быть реализован без реортогонализации, что экономит O(n²) памяти и O(n²) FLOP в обмен на O(n) дополнительных итераций.
• Участники обсуждают точность двухпроходного подхода, влияние потери ортогональности на точность и применимость метода, а также то, что влияние на точность может быть меньше, чем погрешность самого алгоритма Ланцоша.
• Также обсуждается выбор языка для реализации алгоритма, причем участники делятся опытом и мнением о том, какие языки лучше всего подходят для высокопроизводительной численной линейной алгебры.
• В конце обсуждение сдвигается к тому, что автор может в будущем опубликовать расширенную версию статьи, и что читатели могут ожидать увидеть ее в будущем.

Команда Zed перешла на новую облачную инфраструктуру под названием Zed Cloud, построенную на Rust и WebAssembly через Cloudflare Workers. Это решение заменяет старый бэкенд Collab, использовавшийся с основания компании, и призвано снизить операционные затраты на обслуживание сервисов, позволив команде сосредоточиться на развитии основного продукта. Cloudflare Workers обеспечивает простое масштабирование, а такие сервисы, как Hyperdrive для Postgres, Workers KV для временного хранения и Queues для асинхронной обработки задач, обеспечивают необходимую функциональность.

В основе новой системы лежит фреймворк с трейтом Platform, позволяющий писать код независимо от платформы, сохраняя при этом доступ ко всем возможностям Cloudflare Workers. Для этого реализованы две платформы: CloudflarePlatform для работы в продакшене и локальной разработки, и SimulatedPlatform для тестирования, имитирующей практически все компоненты системы. Такой подход обеспечивает гибкость и тестируемость всей инфраструктуры Zed Cloud.

• Обсуждение в основном вращается вокруг трёх тем: использование WebAssembly в облачных сервисах, сравнение производительности и стоимости Rust vs JavaScript в Cloudflare Workers, и перспективы FOSS альтернатив.
• Участники обсуждают, что на данный момент Rust в WASM всё ещё имеет существенные накладные расходы по сравнению с нативным кодом, но при этом отмечается, что Cloudflare Workers и Supabase Edge Functions предоставляют открытые исходники своих рантаймов, что снижает vendor lock-in.
• Также поднимается вопрос о том, что хотя WASM в браузере может и не достигает нативной скорости, он предоставляет беспрецедентную переносимость и безопасность, что делает его идеальным для серверлесс вычислений.
• Наконец, участники высказывают, что хотя Cloudflare и Supabase предоставляют открытые исходники своих рантаймов, что снижает vendor lock-in, но всё ещё остаётся вопрос о том, какие именно преимущества предоставляет использование Rust в WASM в контексте редактора кода, если учесть, что большинство пользователей не будут замечать разницу в производительности, но при этом будут страдать от ограничений вендора.

Статья рассматривает проблемы ABI (Application Binary Interface) при обработке ошибок в программировании. Распространённое мнение, что заполнение информации об ошибках "бесплатно" из-за их редкости, неверно. Наивное составление ошибок из алгебраических типов данных (ADT) ухудшает "счастливый путь" выполнения кода. Объекты ошибок, рекурсивно составленные из перечислений, tend to be large, увеличивая size_of<Result<T, E>>, что заставляет функции по всей стеку вызовов использовать возврат больших структур через память. "Вирусность" ошибок означает, что даже одна большая ошибка на редко выполняемом пути ухудшает производительность везде.

Поэтому зрелые библиотеки обработки ошибок скрывают их за тонким указателем, как в Rust (failure и anyhow), но это требует глобального аллокатора, что тоже не бесплатно. Автор предлагает три подхода к возврату результатов: стандартный (как пользовательский тип), более умный (ABI как у T с зарезервированным регистром для E) и радикальный (полное совпадение ABI с -> T и разворот стека для ошибок). Последний, по мнению автора, может быть оптимальным, несмотря на отсутствие надёжных бенчмарков. Вывод: обработка ошибок должна быть специальной для компилятора, особенно в языках со средним уровнем абстракций.

• Адаптивные ABI для статически линкуемых программ могут оптимизировать производительность за счёт контекстного анализа использования функций.
• Проблема "вирусности" больших типов ошибок: даже редкие большие ошибки могут ухудшить производительность всего стека вызовов.
• Альтернативные подходы к обработке ошибок включают тонкие указатели с vtable (anyhow/failure) и разделение Result<T,E> при значительном различии размеров T и E.
• Добавление исключений в Rust вызывает споры: одни видят в этом угрозу производительности, другие — потенциальное решение проблем обработки ошибок.
• Checked exceptions в Java критикуют за необходимость изменения кода при модификации исключений, хотя другие видят в этом преимущество для надёжности кода.

Разработчик Саймон Уиллисон обратно проанализировал CLI-инструмент Codex, чтобы получить прямой доступ к новой модели GPT-5-Codex-Mini, которая пока доступна только через этот инструмент. OpenAI выпустил более компактную и экономичную версию GPT-5-Codex, но официального API доступа еще не предоставил. Уиллисон использовал сам Codex для модификации исходного кода на Rust, добавив новую подкоманду "codex prompt", позволяющую напрямую отправлять запросы к модели через тот же API, что и оригинальный инструмент.

Процесс включал клонирование репозитория openai/codex, запуск в "опасном режиме" и использование самой модели для написания кода новой функции. После нескольких итераций Уиллисон смог успешно протестировать модель, попросив ее создать SVG-изображение пеликанa, едущего на велосипеде. Несмотря на некоторые проблемы с режимом работы модели, эксперимент показал возможность прямого доступа к новой модели через обратную инженерию официально еще не выпущенного API.

• Критика чрезмерной зависимости от LLM для простых задач, таких как установка Rust-проектов (cargo install), которая решается за минуты без ИИ.
• Подтверждение трудностей новичков с документацией и сборкой проектов в незнакомых системах (Rust/Cargo), требующих активного поиска.
• Предложение альтернативных тестов для оценки AGI (например, "медведь на уницикле"), так как тест SVG-генерации считается неадекватным показателем интеллекта.
• Упоминание OpenRouter как поддерживаемой платформы для тестирования множества моделей через Codex.

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

За десять лет автор прошёл путь от веб-разработчика до специалиста по базам данных, присоединившись к EnterpriseDB, где работает над pglogical и Postgres Distributed. Его карьера началась в 2014 году с JavaScript и Python, затем он стал менеджером инженеров. Прорывным моментом стало 2020 год, когда проблемы с производительностью его сервиса заставили его изучить индексы и структуры данных. Он создал образовательные проекты, включая простую in-memory SQL базу данных, и построил сообщества вроде Software Internals Discord и /r/databasedevelopment.

После неудачной попытки запустить собственный стартап в 2021-2023 годах и работы в TigerBeetle автор искал позицию именно разработчика баз данных, а не DevOps-инженера для работы с базами. Несмотря на нетрадиционный путь (он бросил колледж) и сомнения работодателей, он получил три предложения на работу над расширениями Postgres на C и Rust. Выбрав EnterpriseDB, компанию с 20-летней историей и одним из крупнейших вкладчиков в развитие Postgres, он предпочёл стабильность ранним стартапам, в которых работал последние три года.

• Сообщество обсуждает, как трудно сменить специализацию, если ты уже «записан» в базе данных как специалист в области X, и как это влияет на найм и карьерные возможности.
• Участники делятся личным опытом: кто-то ушел в разработку на C/C++ и Rust, кто-то перешел в SRE или DevOps, кто-то пытается попасть в компиляторы.
• Обсуждается, что рекрутеры и системы найма не видят за пределами ключевых слов в резюме и не учитывают site-reliability, DevOps и прочие смежные навыки, что делает смену специализации еще более сложной.
• Участники делятся советами, как обойти эту систему: делать сайд-проекты, которые демонстрируют навыки в новой области, участвовать в open-source, писать блоги и статьи, и так далее.
• Также обсуждается, что важно не только выждать подходящий момент, но и быть готовым пойти на уменьшение зарплаты и не бояться начать с более низкой позиции, что может быть ключом к переходу в новую область.

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

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

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

• Разнообразие технологий охватывает от классических стеков (Java/Spring, C++, Python) до современных стеков (TypeScript, Next.js, Rust, Go) и специализированных инструментов (Unity, Unreal, embedded, data engineering, QA, low-code, etc.)
• Участники демонстрируют глобальный охват: от США и Канады до Европы, Азии, Австралии и Латинской Америки, что подчеркивает международный характер рынка.
• Почти все открыты к удаленной работе, но при этом большинство не готовы к релокации, что подчеркивает гибкость и предпочтение к удаленной работе.
• Некоторые участники подчеркивают свою готовность к релокации, особенно внутри США или в крупных технологических центрах.
• Некоторые участники подчеркивают свою готовность к релокации внутри ЕС или в Северной Америке, что может быть важно для компаний, которые ищут таланты в этих регионах.

Cloudflare представила Oxy - новый прокси-фреймворк, написанный на Rust, который служит основой для нескольких ключевых продуктов компании, включая Zero Trust Gateway и iCloud Private Relay. Разработанный с учетом опыта создания высоконагруженных прокси, Oxy позволяет реализовывать современные протоколы связи и строить сложные сервисы для обработки огромного трафика.

Фреймворк предоставляет программный контроль над всеми аспектами проксирования: от декапсуляции протоколов и анализа трафика до маршрутизации и DNS. Oxy тесно интегрирован с внутренней инфраструктурой Cloudflare, но при этом настраивается под нужды приложений. Инженеры могут начать с базового решения, которое не требует написания кода, и постепенно добавлять функции через расширяемые точки. Например, для создания HTTP-файрвола достаточно реализовать обработчики запросов и ответов, а для L4-файрвола - добавить аутентификацию или георouting.

• Обсуждение в основном вращается вокруг негативного опыта с Cloudflare Tunnels и их IPv6-ограничений, а также сравнения с другими решениями вроде Tailscale и ngrok.
• Участники жалуются на плохую документацию, отсутствие прозрачности и "vendor lock-in" при использовании продуктов Cloudflare.
• Обсуждение также затрагивает вопросы лицензий, сравнение с другими решениями и влияние на разработчиков.
• Некоторые участники делятся личным опытом и альтернативными инструментами вроде localtunnel и Tailscale.
• В целом, обсуждение подчеркивает сложность выбора между удобством и контролем над инфраструктурой, особенно в контексте разработки ПО.

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

Библиотека crossfire-rs предоставляет безблокировочные (lock-free) реализации очередей MPMC (множественные производители/потребители) и MPSC (множественные производители/один потребитель) для асинхронного программирования на Rust. Проект основан на популярной библиотеке crossbeam, которая специализируется на низкоуровневых примитивах параллелизма.

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

• Обсуждение вращается вокруг тонких различий между различными моделями каналов (SPSC, MPMC и т.д.) и их влиянии на безопасность отмены и производительность.
• Участники обмениваются ссылками на документацию и обсуждают, какие именно гарантии предоставляет каждая реализация.
• Появляется вопрос о том, как именно Kanal и другие библиотеки реализуют оптимизации, которые могут влиять на безопасность отмены.
• Участники обсуждают, какие именно факторы производительности (например, latency vs throughput) имеют наибольшее значение для их конкретного варианта использования.
• В конце обсуждение сводится к тому, что выбор канала зависит от специфики рабочей нагрузки и что сравнительные бенчмарки могут не отражать реальную эффективность в продакшене.

• Python-оптимизация часто сводится к выносу «горячих» участков в C/NumPy, а не к микро-оптимизации кода.
• Сам факт, что в CPython «всё является объектом» влечёт за собой неизбежные накладные расходы, которые нельзя убрать без отказа от части философии языка.
• JIT (PyPy) и отсутствие GIL в будущем могут решить 90 % проблем производительности, но это не касается CPython.
• Сообщество в целом согласно с тем, что вместо попыток «оптимизировать» Python-стильный код, стоит либо полностью переписать узкие места на C/Rust, либо вовсе перейти на Julia/Go.

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

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

• Проект Charlotte OS стремится к современной архитектуре, но пока не реализованы драйверы для большинства оборудования, что делает его практически непригодным для ежедневного использования.
• Проект использует GPLv3 с дополнительным разрешением на линковку с проприетарными драйверами, что вызывает споры в сообществе.
• Проект написан на Rust и использует микроядро, что делает его уникальным среди существующих альтернатив.
• Проект не имеет собственной системы портов пакетов и полагается на переносе пакетов из других систем, что может вызвать проблемы.
• Проект не имеет собственной системы портов пакетов и полагается на переносе пакетов из других систем, что может вызвать проблемы.

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

При оптимизации кастомной ограниченной приоритетной очереди автор столкнулся с парадоксальным случаем, когда уровень оптимизации O3 работал на 123% медленнее, чем O2. Этот результат был подтверждён на процессорах Intel Haswell и AMD Zen 3, что указывает на системную проблему, а не на специфичную для архитектуры. Бенчмарки проводились с использованием criterion, а результаты демонстрировали устойчивую регрессию производительности при повышении уровня оптимизации.

Реализация использует отсортированный Vec с бинарным поиском вместо бинарной кучи, что эффективнее для данного случая из-за требования уникальности id элементов. Ключевую роль играет функция сравнения, работающая с числами с плавающей запятой, которые известны своей сложностью в сравнении. Для анализа производительности автор использовал flamegraph, чтобы выявить разницу в поведении между уровнями оптимизации.

Nice read. Last week I wrote a blog post about two noteworthy cases of O3 being slower than O2 in C++: https://barish.me/blog/cpp-o3-slower/ In the branchy function, id is only compared if distance is equal, and since distance is a random float, this almost never happens and the

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

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

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

Выпущен iroh-blobs 0.95 с несколькими значительными новыми функциями, главной из которых является пул соединений (util::connection_pool). Этот компонент оптимизирует работу с большим количеством конечных точек, сохраняя верхнюю границу одновременных соединений — критически важно при загрузке blobs из множества провайдеров. Пул через метод get_or_connect либо возвращает существующее соединение, либо создает новое, автоматически управляя временем жизни и закрывая простаивающие соединения по необходимости.

Доступны продвинутые опции настройки: максимальное количество соединений, таймауты подключения и простоя, а также колбэк on_connected для выполнения дополнительной логики перед выдачей соединения. Например, можно настраивать передачу только через прямые соединения для повышения производительности. Важно отметить, что пул возвращает ConnectionRef, а не Connection, для корректного отслеживания времени жизни — клонирование Connection из ConnectionRef нарушит этот механизм. После выпуска iroh 1.0 пул будет перемещен в отдельный крейт.

• Iroh предоставляет P2P-соединения, но при разработке возникают проблемы с подключением к серверу, а Windows Defender блокирует бинарники, что делает невозможным безопасную поставку клиенту.
• Пользователи отмечают, что Iroh упрощает создание проектов, обеспечивает безопасную передачу данных и предоставляет гибкие возможности для хранения и синхронизации данных.
• Некоторые участники обсуждения сравнивают Iroh с другими инструментами, такими как Tailscale и vanadium, и задаются вопросом о различиях в использовании и функционале.
• Вопросы о версионировании, масштабируемости и производительности при использовании Iroh для хранения и синхронизации данных поднимаются в контексте обсуждения.

Библиотека 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.

Создание эмулятора RISC-V на Rust — это активно развивающийся проект, позволяющий собрать 64-битный эмулятор с нуля. После завершения курса вы сможете запускать в нем xv6 — простую Unix-подобную операционную систему. Проект охватывает основы компьютерной архитектуры: ISA, привилегированный режим, исключения, прерывания, периферийные устройства и системы виртуальной памяти. Исходный код доступен на GitHub в репозитории d0iasm/rvemu-for-book.

Проект разделен на два основных раздела: в первом рассматриваются аппаратные компоненты, необходимые для работы xv6, включая процессор с двумя инструкциями, память, системную шину, регистры управления и состояния, а также контроллеры прерываний и UART. Второй раздел посвящен наборам инструкций, начиная с базового RV64I Integer и включая расширения "M" для умножения и деления, и "A" для атомарных операций.

• Доступны только первые три главы из десяти.
• Рекомендация использовать ассемблер для реализации.
• Наличие rv64-интерпретатора на x86_64 ассемблере.

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

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

• Пользователи обсуждают различные инструменты для диаграмм: Mermaid.js, D2, PlantUML и Graphviz, а также их ограничения и возможности.
• Обсуждается необходимость улучшения автоматического размещения для Mermaid.js и возможность встроить инструмент в качестве layout engine.
• Участники поднимают вопросы о лицензии (отсутствие файла LICENSE), отсутствии функционала вроде всплывающих подсказок и коллапсинга нод, а также о том, что проект не предоставляет встроенного способа взаимодействия с инструментами вроде Excalidraw.
• Разработчик отвечает, что проект находится в стадии разработки и что он открыт к вкладу со стороны сообщества.

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 без должной поддержки.

Автоматические инструменты перевода кода с C на Rust полезны, но создают небезопасный и неидиоматичный код. Авторы Jaemin Hong и Sukyoung Ryu исследуют эти проблемы и предлагают решения с использованием статического анализа. Основные трудности включают различия в управлении памятью, типах данных и моделировании ресурсов между двумя языками.

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

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

Команда 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 ошибка пакетов, которые не были бы исправлены в нужное время.
• Сообщество высказывает опасения по поводу переписывания критически важных утилит, которые были проверены временем, на новом и потенциально менее стабильном языке программирования.
• Некоторые комментаторы подчеркивают, что обсуждение не касается безопасности, а вопрос лицензии и что это не более чем естественное течение времени и что в конце концов, как и следовало ожидать, никакой "серьёзной" уязвимости там не было.

Проект h3o представляет собой полную переработку библиотеки Uber H3 на языке Rust, а не просто обертку. Основные цели - упрощение интеграции в Rust проекты (особенно для WASM), создание более безопасного API с использованием строгой типизации, достижение сопоставимой или превосходящей производительности и 100% покрытие API H3 версии 4.0. Для обеспечения качества использовалось дифференциальное тестирование против эталонной реализации, включая 756 тестов, 166 интеграционных тестов, 42 юнит-теста и 15 fuzz-целей.

Бенчмарки, состоящие из 911 тестов, показывают, что в 862 случаях h3o превосходит оригинальный H3 по производительности. В 463 тестах h3o работает в 2-5 раз быстрее, в 117 тестах - в 5-10 раз быстрее, и в 24 тестах - более чем в 10 раз быстрее. Однако в 44 тестах H3 все еще быстрее, особенно при работе с пятиугольными ячейками и преобразованиями координат. Основные оптимизации h3o включают использование предвычисленных таблиц вместо формул на лету и применение битовых операций вместо циклов для достижения постоянного времени выполнения.

• H3/Hexagonal tiling vs. S2/Square tiling: обсуждение сфокусировалось на том, что H3 обеспечивает равные расстояния между соседними ячейками, что важно для анализа данных и моделирования потоков, в то время как S2 не обеспечивает равные расстояния между соседними ячейками. Однако, S2 имеет преимущество в том, что он может быть более эффективен для запросов, которые включают родительские и дочерние ячейки, тогда как H3 может быть более удобен для визуализации и анализа данных, особенно если важно сохранить равные расстояния между ячейками.

• Использование H3 в различных контекстах: обсуждение включало примеры использования H3 в различных контекстах, включая Uber, FCC, ClickHouse, Overture Maps и другие. Это показывает, что H3 используется в различных контекстах, включая телематика, анализ данных, визуализация и хранение данных.

• Сравнение H3 с другими системами: обсуждение также коснулось сравнения H3 с другими системами, включая S2 и другие геометрические системы. Это показывает, что H3 имеет свои уникальные преимущества и недостатки, которые важно учитывать при выборе системы для конкретного применения.

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

Fly.io столкнулся с крупнейшим сбоей в истории 1 сентября 2024 года из-за ошибки в Rust-коде их системы распределенного состояния Corrosion. Ошибка в if let выражении над RWLock привела к мгновенному и "заразному" deadlock, который парализовал все прокси-серверы платформы. Авторы подчеркивают, что распределенные системы — это "усилители взрывов": они распространяют данные по сети, а вместе с ними — и ошибки в системах, зависящих от этих данных.

Эта катастрофа стала следствием архитектурных решений Fly.io. В отличие от Kubernetes с его централизованной базой данных, Fly.io использует децентрализованную модель, где серверы являются источником правды о своих рабочих нагрузках. Чтобы масштабироваться по всему миру, они перешли от HashiCorp Consul и SQLite-кэшей к собственной системе Corrosion. Авторы предупреждают: если распределенная система еще не испортила вам выходные или не заставила не спать всю ночь, вы еще не до конца ее понимаете.

• Баг с if let и RWLock в Rust приводил к мгновенному глобальному дедлоку, что вынудило перейти от единого кластера к региональной двухуровневой схеме данных.
• Использование cr-sqlite (CRDT SQLite) для согласованности вызвало проблемы с nullable-колонками и масштабируемостью, что привело к критике выбора SQLite вместо Postgres.
• Gossip-протокол (SWIM) показал ограниченную масштабируемость (~2K-3K узлов), что потребовало иерархической структуры и разделения на региональные кластеры.
• Дизайн блога и отсутствие дат в статьях вызвали нарекания, но технические решения (регионализация, отказ от мгновенного глобального состояния) признаны необходимыми.

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

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

Проект hist-rs представляет собой высокопроизводительный утилиту для подсчета уникальных строк, написанную на Rust. Его ключевое преимущество — скорость работы, которая в 25 раз превышает производительность классической команды sort | uniq -c в Unix-системах. Это делает его идеальным инструментом для анализа больших лог-файлов и наборов данных, где важна скорость обработки.

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

• Обсуждение началось с вопроса о производительности различных инструментов для подсчёта уникальных строк в файле, где был упомянут clickhouse-local как самый быстрый способ.
• Участники обсуждали различные инструменты, включая sort, uniq, awk, uniq -c, sort | uniq -c | sort -n, tsv и csv, а также их производительность и использование памяти.
• Были упомянуты такие инструменты как tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, `tsor

Cuq — это фреймворк, преобразующий MIR (промежуточное представление Rust) в Coq для формальной семантики и верифицированного перевода Rust-ядер GPU. Проект нацелен на PTX (язык ассемблера NVIDIA) и обеспечивает математически строгую основу для GPU-программирования на Rust.

Фреймворк позволяет формально доказывать свойства GPU-кода и обеспечивает верифицированный перевод из Rust в PTX. Это критически важно для безопасности и надежности вычислений на GPU, где ошибки могут иметь серьезные последствия. Cuq заполняет пробел между высокоуровневым Rust-кодом и низкоуровневым GPU-исполнением, предоставляя формальные гарантии корректности преобразований.

• Проект, который переводит MIR Rust в Coq для формальной верификации ядра CUDA, вызвал бурную дискуссию из-за имени «cuq».
• Участники спорят, звучит ли название как «кук» или «кью-кью»; критика имени превратилась в обсуждение культурных различий.
• Некоторые предлагают переименовать проект в «rocuda», «rocq» или «rocq», чтобы избежать нежелательных коннотаций.
• Автор отвечает, что имя строится на словах CUDA и Coq, и что он не осознавал двусмысленность; вопрос о переименовании остаётся открытым.
• Несмотря на спор, техническая ценность проекта в том, что он может формально верифицировать параллельные вычисления и уменьшить гонки за счёт формального доказательства корректности.

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

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

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

• Выпущена библиотека rs-merkle-tree — высокопроизводительная, модульная реализация Merkle-дерева с фиксированной глубиной и строго аппенд-онли.
• Пользователи отметили её применимость в криптографических и блокчейн-сценариях, а также попросили рекомендации по обучающим материалам для новичков в этой области.
• Сообщество отметило, что документация и примеры кода помогут новичкам лучше понять, как использовать Merkle-деревья в сертификатах прозрачности и других примерах.

В асинхронных рантаймах, таких как async Rust, задачи могут приостанавливаться и порождать новую работу, что приводит к двум основным подходам: thread-per-core и work-stealing. При work-stealing потоки могут "воровать" задачи друг у друга, обеспечивая лучшую балансировку нагрузки, хотя это требует возможности перемещения задач между потоками (что вызывает сложности в Rust с требованием Send) и может нарушать локальность данных. В обработке данных долгое время доминировал подход thread-per-core, так как он минимизирует перемещение данных между ядрами и упрощает реализацию, особенно при случайных ключах.

Однако в последние годы наблюдается сдвиг в сторону динамического перераспределения работы на уровне обработки данных. Растущее количество ядер делает неравномерное распределение данных более болезненным, а улучшение производительности ввода-вывода снижает значимость старых ограничений. Подход Morsel-Driven Parallelism предлагает, что системы обработки данных могут быть лучшим местом для динамического перераспределения работы. Это подкрепляется культурными факторами: при масштабировании и мультиарендности проблемы неравномерной нагрузки становятся сложнее для решения на верхних уровнях, требуя встроенной гибкости в самих системах.

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

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

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

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

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

Проект создан разработчиком Will Crichton и доступен на GitHub. Flowistry стремится решить распространенную проблему в больших кодовых базах - необходимость просматривать множество несвязанного кода для понимания контекста. Плагин предоставляет инструменты для визуализации зависимостей и определения путей данных в программе, что значительно ускоряет процесс отладки и рефакторинга кода на Rust.

• Инструмент Flowistry показывает, как данные течут в коде, но требует MIR и работает только с Rust.
• Обсуждение развилось вокруг того, почему это нельзя сделать для других языков и почему это не входит в rust-analyzer.
• Некоторые участники выразили желание увидеть подобные визуализации для TypeScript, C#, Python и других языков.
• Обсуждались вопросы товарного знака VSCode и ограничений, которые накладывает набор инструментов на то, что можно включить в IDE.
• Участники также обсудили, какие еще инструменты могли бы помочь в понимании кода и какие еще есть инструменты для других языков.

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

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

включ) 3. При (0) в 0. (0 и 0 в 0. Ты в ко 0. (0) и не и (0) сок в

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

Разработчики создали 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 всё ещё молоды и меняются, а также не предоставляют преимуществ в контексте уже готового кода.
• Поднимается вопрос о том, что важнее — язык или разработчики, и подчеркивается, что последние могут писать на любом языке, если бы это действительно было нужно.

Kaitai Struct — декларативный язык для описания и разбора бинарных форматов, позволяющий определить структуру данных один раз, а затем использовать это описание в различных языках программирования. Поддерживается 12 языков, включая C++, Java, Python, JavaScript и Rust, что делает его универсальным инструментом для работы с бинарными файлами и сетевыми протоколами. Проект бесплатный и открытый, включает компилятор, веб-IDE, визуизатор и обширную библиотеку популярных форматов.

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

• Kaitai Struct — декларативный язык описания бинарных форматов, который генерирует код на разных языках.
• Пользователи отмечают, что он удобен как для работы, так и для хобби-RE, но жалуются на отсутствие поддержки записи и громоздкий YAML.
• Появилась экспериментальная поддержка сериализации в Python и Java, но она пока не покрывает все типы полей и требует ручной работы.
• Сравнение с Wuffs и Construct показывает, что Kaitai фокусируется на описании форматов, тогда как Wuffs — на безопасном коде, а Construct — на удобстве использования.
• Сообщество обсуждает, что нехватка поддержки других языков (Rust, Zig) и отсутствие поддержки полного цикла чтение-изменение-запись делает Kaitai менее универсальным, чем можно было бы.

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

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

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

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

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

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

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

Статья демонстрирует процесс создания макроса в Rust на примере query!, вдохновлённого SQL-подобными DSL.

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

Основные шаги создания включают:

• Написание самой простой возможной версии макроса (например, query!(from db select title))
• Постепенную реализацию одной функциональности за раз (начиная с поддержки select для выборки полей)
• Использование встроенных инструментов Rust (как macro_rules!) для декомпозиции задачи

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

В статье разбирается конкретный пример с песнями (структура Song с полями title, artist, rating), показывая, как макрос преобразует декларативный синтаксис в действительный код на Rust, извлекающий данные из коллекции.

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

• Обсуждение показало, что Rust-макросы вывают много споров: кто-то считает их неотъемлемой частью экосистемы, другие — что это «тёмная магия», которой следует избегать.
• Участники обсуждения отмечают, что макросистема Rust сложна и требует отдельного крейта, что делает даже простейшую метапрограммирование громоздкой.
• Некоторые участники подчеркивают, что большая часть экосистемы Rust фактически построена на макросах, что ставит под сомнение совет «не пиши макросы».
• Обсуждение также затронуло вопрос, почему в Rust нет неявного преобразования типов, что ведёт к необходимости часто писать .to_string() и .into(), и как это связано с макросами.

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

Выбор между Ada, SPARK и Rust вместо C/C++ зависит от целей проекта. C/C++ остаются стандартом для встраиваемых систем из-за привычной экосистемы и обученных кадров, но они несут риски для безопасности — десятилетия разработок не сделали их по-настоящему безопасными без значительных затрат.

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

• Участники обсуждают сравнительные преимущества систем типизации в Ada и Rust, включая возможность создания отдельных типов для единиц измерения (например, мили и километры) для предотвращения ошибок.
• Высказываются мнения о применимости языков (C++, Ada, Rust, SPARK, Zig, D) в высоконадёжных и критических системах, таких как аэрокосмическая отрасль, с акцентом на строгие процессы разработки и верификации, а не только на выбор языка.
• Поднимается тема, что безопасность кода зависит в большей степени от методологии разработки и тестирования (интеграционного, системного), чем от самого языка программирования.
• Обсуждается эргономика и удобство использования возможностей языков (например, newtype в Rust, контролируемые типы в Ada) для обеспечения типобезопасности и предотвращения ошибок на этапе компиляции.
• Некоторые участники выражают скептицизм по поводу необходимости замены C/C++, предлагая вместо этого лучше изучать и использовать существующие языки, совершенствуя навыки и процессы разработки.

Написанная на Rust утилита ut предлагает разработчикам набор инструментов для повседневных задач, вдохновляясь функциональностью it-tools.tech. Она включает конвертеры, генераторы хешей, кодировщики и другие инструменты для работы с данными, кодом и системами. Проект стремится объединить распространённые утилиты в одном месте, упрощая доступ без переключения между сервисами.

Использование Rust обеспечивает высокую производительность и безопасность, а модульная архитектура позволяет легко расширять функционал. Это решение особенно полезно для команд, ценящих локальные инструменты без зависимости от облачных сервисов.

• Предложения по распространению: упаковать как Python и NPM модули для удобного запуска через uvx или npx, использовать cargo-dist для автоматизации.
• Критика архитектуры: обсуждается целесообразность единого бинарника (по аналогии с BusyBox) против множества отдельных утилит в духе UNIX-философии "делай одно дело хорошо".
• Вопросы к функционалу: предостережения против включения слишком большого количества функций (например, HTTP), предложения добавить конкретные команды (uuidv7, retry).
• Замечания по реализации: критика требований к вводу (только UTF-8, чтение stdin до EOF), отсутствие тестов для кода, созданного с помощью ИИ.
• Общая оценка: инструмент воспринят как удобный "швейцарский нож" с продуманными умолчаниями, но вызвал дискуссию о разумных пределах его роста.

Универсальный раннер и умный REPL на Rust, который автоматически определяет язык программирования по расширению файла или shebang и выполняет код без предварительной настройки. Поддерживает Python, JavaScript, Ruby, Go и другие популярные языки, экономя время на переключении между средами.

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

• Автор представил инструмент run как унифицированный REPL для множества языков, позволяющий выполнять код разных языков одной командой без переключения между отдельными REPL.
• Обсуждаются технические детали и сравнение с существующими инструментами: шебанг-строка, задачами just, магическими командами IPython/Jupyter и возможностью запуска скриптов через Bash.
• Уточняется классификация языков (Swift, Kotlin) как компилируемых или интерпретируемых в контексте работы инструмента.
• Поднимается вопрос о мотивации создания инструмента и терминологии ("polyglot"), а также простоте добавления поддержки новых языков через реализацию trait на Rust.
• Автор поясняет, что инструмент — это эксперимент новичка в 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.

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

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

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

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

Отмена в асинхронном Rust — мощный, но сложный механизм. В синхронном коде отмену часто реализуют через проверку флагов или паники с особыми типами, но это плохо масштабируется. В асинхронной версии проблема глубже: при использовании timeout с операциями вроде tx.send сообщение может быть потеряно, если таймаут сработает во время ожидания места в канале. Это происходит потому, что будущее отменяется на определённой точке приостановки (await), не гарантируя отката уже выполненных действий.

Корень проблемы — в семантике отмены: асинхронные задачи прерываются в состоянии ожидания, но не отменяют побочные эффекты (например, частично отправленные данные). Это приводит к тонким багам, особенно при работе с ресурсами вроде каналов или сетевых соединений. Решения включают аккуратное проектирование API с явной поддержкой отмены, использование деструкторов для очистки и внедрение идиом вроде "отмены через прерывание" с гарантиями целостности.

• Обсуждаются проблемы безопасности отмены (cancel safety) в асинхронном Rust, когда операции могут прерываться в точке .await, что приводит к неожиданным побочным эффектам и потере данных.
• Поднимается вопрос о необходимости "асинхронного Drop" и более строгих гарантий выполнения для критических секций кода, которые не должны прерываться.
• Отмечается, что семантика отмены сильно зависит от контекста, и термин "cancel safety" может вводить в заблуждение, так как не относится к безопасности памяти (safety) в Rust.
• Участники делятся практическими примерами ошибок, связанных с отменой, и предлагают решения, например, буферизацию сообщений или явную пометку функций в документации.
• Обсуждается сложность ручного управления состоянием при реализации асинхронных структур и проводятся параллели с аналогичными проблемами в других языках, например, в Go.

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.

• Компании ищут инженеров для работы с AI/ML, включая роли Senior Machine Learning Engineer, ML Scientist и разработчиков для создания AI-инструментов в различных областях, таких как биология, недвижимость и безопасность.
• Предлагаются позиции в software development, включая Full Stack, Backend, Frontend и MLOps инженеров, с использованием технологий Python, Kotlin, TypeScript, Rust и других, для удаленной, гибридной или офисной работы.
• Есть вакансии в сфере облачных технологий и инфраструктуры, такие как Cloud Engineer, SRE и DevOps, с фокусом на AWS, GCP, Azure и управление масштабируемыми системами.
• Несколько ролей связаны с разработкой в нишевых областях: квантовые вычисления, 3D-моделирование, финансовые технологии (алготрейдинг), видеоигры и управление цепочками поставок.
• Предложения включают позиции разного уровня, от начинающих до ведущих инженеров и архитекторов, с вариантами визовой поддержки, релокации и конкурентными зарплатами в диапазоне от $120k до $240k+ в зависимости от опыта и локации.

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

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

• Критики выражают сомнения в целесообразности использования Zig для крупных проектов из-за отсутствия гарантий памяти, как в Rust или Swift, и нестабильности языка до версии 1.0.
• Сторонники Zig отмечают его сильные стороны: простоту, явный контроль над выделением памяти, отличную совместимость с C и возможность писать код без использования кучи.
• Обсуждаются практические примеры успешного использования Zig в реальных проектах (Tiger Beetle, Ghostty), несмотря на нестабильность.
• Поднимается вопрос о своевременности выхода книги по языку, который всё ещё активно меняется, что может быстро сделать издание устаревшим.
• Утверждается, что безопасность памяти — это спектр, а не бинарный выбор, и что простота Zig может снижать количество логических ошибок в целом.

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

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

• Обсуждается перспектива широкого внедрения функционального программирования благодаря его теоретической основе, аналогично устойчивости реляционных баз данных и SQL.
• Поднимается вопрос о применении теории типов в императивных языках, с примерами из Rust и C++, где типы улучшают безопасность и выразительность.
• Высказывается критика функционального программирования как сложного и непрактичного, порождающего "ужасный код", в противовес его восприятию как более безопасного и элегантного.
• Участники делятся рекомендациями по литературе для изучения темы (TTOP, Types and Programming Languages) и отмечают её сложность, но ценность.
• Отмечается, что чистые функциональные языки непопулярны (TIOBE), но их идеи (лямбды, монады) проникают в мейнстрим (например, для асинхронного программирования).

Разработчики создали формат blockdiff для мгновенных снапшотов дисков виртуальных машин, сократив время создания с 30+ минут на EC2 до нескольких секунд — ускорение в 200 раз. Это стало возможным благодаря хранению только изменённых блоков данных, что экономит место и ускоряет операции. Формат работает поверх CoW-механизмов XFS в Linux, обеспечивая нулевые накладные расходы и мгновенное создание снапшотов без полного сканирования диска.

Ключевые применения включают сохранение сред разработки, быстрое пробуждение ВМ из сна и откат изменений. Решение обошло ограничения бинарных диффов и OverlayFS, предложив простую и надёжную реализацию на Rust. Открытый исходный код доступен на GitHub, что позволяет сообществу адаптировать инструмент для схожих задач.

• Удивление отсутствием рассмотрения формата QCOW2 и технологии тонкого provisioning VDO с LVM2 для решения аналогичных задач.
• Вопросы о выборе XFS вместо ZFS/BTRFS, использовании LVM-снимков и возможности интеграции решения с другими гипервизорами и файловыми системами.
• Обсуждение технических деталей реализации: использование флагов для синхронизации файлов, поддержка copy_file_range в qemu-img, сравнение с OverlayBD.
• Интерес к применению технологии для ускорения подготовки виртуальных машин в CI/CD и публичном облаке.
• Замечания о необходимости альтернативного текста для изображений и выбора лицензии для проекта.

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

Особенно уязвимы комбинации пакетов или нестандартные типы данных — Euclidean Distance не работает с векторами Unitful, а макрос @distributed ломается при использовании OffsetArrays. Многие ошибки приводят к выходу за границы памяти или тихим неверным вычислениям, что ставит под сомнение надёжность любых сложных расчётов. Практический вывод: в проектах, где важна точность, Julia может представлять неприемлемый риск.

• Участники обсуждают проблемы с корректностью и стабильностью экосистемы Julia, включая критические баги в базовых пакетах и проблемы совместимости.
• Высказываются опасения, что эти проблемы делают язык неподходящим для проектов, где важна точность, несмотря на его элегантность и производительность.
• В качестве альтернатив для научных вычислений упоминаются Python с библиотеками (PyTorch, Jax, TensorFlow), R (и tidyverse), а также Rust и Go.
• Некоторые пользователи делятся негативным опытом из-за невыполненных обещаний (например, быстрая компиляция) и переходят на другие языки.
• Обсуждается актуальность критики, поскольку некоторые примеры проблем датируются 2024 годом, несмотря на то, что исходный пост мог быть написан ранее.

Многие библиотеки для параллельных вычислений в C++ и Rust, такие как Taskflow и Rayon, оказываются в 10 раз медленнее OpenMP в задачах типа fork-join из-за избыточных абстракций. Автор выделяет четыре ключевых фактора снижения производительности: блокировки с системными вызовами, аллокации памяти в очередях задач, дорогостоящие атомарные операции и ложное разделение кэш-линий.

В ответ создана минималистичная библиотека Fork Union объёмом около 300 строк, которая использует только стандартные средства C++ и Rust и демонстрирует производительность в пределах 20% от OpenMP. Бенчмарки на AWS Graviton 4 с 96 ядрами показывают, что Fork Union достигает 467 МБ/с против 585 МБ/с у OpenMP, в то время как Rayon и Taskflow отстают значительно. Вывод: для блокирующих fork-join нагрузок асинхронные пулы задач неоправданно тяжелы.

• Автор библиотеки fork_union сообщает об улучшениях, особенно для Linux NUMA-систем, и приветствует предложения по её развитию.
• Пользователи отмечают значительное ускорение работы по сравнению с другими решениями (например, Rayon), но указывают на проблемы с потреблением CPU из-за busy wait.
• Обсуждаются технические детали реализации: диспетчеризация работы, обработка неоднородных нагрузок, энергоэффективность busy-wait и отсутствие аллокаций после инициализации.
• Проводятся сравнения с альтернативными библиотеками и подходами (TBB, heartbeat scheduling, Tokio) и обсуждаются возможные варианты применения, например, в веб-серверах.
• Отмечается сложность создания удобных и безопасных API для Rust из-за особенностей работы с памятью в высокопроизводительном параллельном коде.

Handy — это бесплатное приложение с открытым исходным кодом для преобразования речи в текст, которое работает локально на вашем компьютере. Оно позволяет диктовать текст в любое поле ввода, просто нажимая и удерживая комбинацию клавиш (по умолчанию Ctrl+Z), а затем вставляя расшифровку после отпускания. Настройки включают переключение между режимом удержания и однократного нажатия для начала и остановки транскрипции.

Приложение полностью приватное — аудио не отправляется в облако, всё обрабатывается на устройстве. Handy позиционируется как доступный инструмент, свободный от подписок, с возможностью кастомизации и поддержкой сообщества через спонсоров like Wordcab и Epicenter. Проект приглашает к участию в разработке и финансировании.

• Пользователи обсуждают высокое потребление ресурсов современных десктопных приложений, приводя примеры, где даже простые действия занимают значительный объем памяти (~120MB).
• Представлены альтернативные и похожие инструменты для преобразования речи в текст (STT), такие как Whispy (Linux), hns (CLI), Gnome расширение и VoiceInk, с акцентом на локальность и минимализм.
• Обсуждаются технические детали проектов: использование моделей Whisper и Parakeet, поддержка GPU/CPU, кроссплатформенность, языки разработки (TypeScript, Rust, Go) и вопросы шумоподавления.
• Участники сравнивают качество и удобство локальных решений с облачными сервисами (например, Groq) и встроенными функциями ОС (macOS dictation, iPhone STT).
• Затрагиваются темы приватности, производительности на слабом железе, удобства использования для программирования и запросы на аналогичные инструменты для преобразования текста в речь (TTS).

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) как возможные источники вдохновения или альтернативы.

На RustConf 2025 обсуждалась совместимость Rust и C/C++, где Чендлер Каррут сравнил подходы Rust и экспериментального языка Carbon. Rust предлагает инструменты вроде bindgen и cxx для взаимодействия, но они слабо подходят для сложного legacy-кода C++ (brownfield), где тесные связи и большой API усложняют миграцию. Carbon же задуман как полностью совместимый с C++ язык, позволяющий постепенно переписывать проекты файл за файлом без смены компилятора, с акцентом на аннотации для безопасности памяти.

Каррут считает, что Rust не скоро решит проблему полной интероперабельности с C++, тогда как Carbon предлагает эволюционный путь, аналогичный переходу от JavaScript к TypeScript. Это даёт пространство для Carbon, особенно в крупных legacy-проектах, где полный переход на Rust непрактичен. Вывод: два языка могут сосуществовать, решая разные аспекты миграции к безопасным языкам.

• Обсуждается сложность и подходы к миграции с C/C++ на современные языки (Rust, Kotlin, Swift), включая инструменты для конвертации и постепенного перехода.
• Поднимаются вопросы о важности качественной интероперабельности между языками и недостатках C как языка-«клея» из-за отсутствия современных функций безопасности.
• Высказываются сомнения в универсальности Rust для полного переписывания из-за архитектурных несовпадений с идиоматическим C++.
• Отмечается, что такие проекты, как Carbon, нацелены на крупные кодобазы (вроде Google) и инкрементальный рефакторинг без полного переписывания.
• Упоминается, что принятие Rust в Linux пока ограничено (драйверы, отдельные подсистемы), а будущее Kotlin и Swift вне их экосистем (Android/Apple) остается под вопросом.

Разработка Rustroid началась с увлечения Minecraft в детстве, когда на мобильном телефоне пришлось создавать моды без нормальных инструментов — только базовый редактор JSON. Это выявило острую нехватку developer tools под Android. Позже автор экспериментировал с Java, портируя игры через приложение CodeAssist, и освоил основы Android SDK.

С появлением ПК интерес сместился на Rust из-за его целостного инструментария (Cargo) и популярности. Выбор пал на Rust IDE, а не Java, из-за отсутствия аналогов и личной симпатии к языку. Проект начался на Java, но быстро перешел на Kotlin и Jetpack Compose — это оказалось эффективнее. Rustroid работает локально на устройстве, используя встроенный компилятор и пакетный менеджер Rust.

• Обсуждается возможность и опыт программирования на телефоне с использованием различных инструментов (Termux, tmux, vim, внешние клавиатуры) и IDE.
• Отмечается, что кодинг на телефоне может быть актуален для пользователей без доступа к ПК, в поездках или в развивающихся странах.
• Поднимаются технические вопросы о работе конкретных приложений, их офлайн-доступности и интеграции с периферией (DeX, внешние экраны).
• Высказывается мнение, что рынок IDE для телефонов недостаточно развит, но имеет потенциал для быстрого прототипирования и работы "на ходу".
• Участники дискутируют, является ли скорость печати (WPM) ключевым фактором продуктивности в программировании, особенно с учетом развития ИИ-инструментов.

Представлен новый однопроцессорный аналитический движок базы данных, где геопространственные данные являются ключевым элементом архитектуры. Он оптимизирован для работы с геометрическими объектами и растрами, поддерживая стандартные пространственные операции, такие как объединения, кластеризация и анализ расстояний. Движок интегрируется с популярными форматами данных, включая GeoJSON, Shapefiles и GeoParquet, что упрощает обработку сложных геоданных без необходимости распределённых систем.

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

• Подчеркивается необходимость SedonaDB для больших геопространственных рабочих нагрузок, где традиционные решения (DuckDB, PostGIS) не подходят, особенно из-за поддержки CRS и производительности.
• Высказываются сомнения в целесообразности нового инструмента, так как PostGIS и DuckDB с их расширениями покрывают потребности большинства пользователей.
• Отмечаются ключевые преимущества SedonaDB: высокая производительность при работе с данными не из БД (например, GeoParquet), поддержка дополнительных CRS и отсутствие зависимости от работающего сервиса.
• Обсуждаются технические особенности: реализация на Rust для производительности, интеграция с экосистемой Apache Arrow (DataFusion) и поддержка нескольких языков программирования.
• Упоминаются текущие ограничения других инструментов: "сырые" края пространственного расширения DuckDB и блокировка развития GeoPolars из-за отсутствия поддержки типов расширений Arrow в Polars.

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 от популярных языков или, наоборот, упрощение изучения нишевых.

В Rust есть встроенная атомарная операция fetch_max, которая отсутствует в Java и C++. Она позволяет безопасно обновлять максимальное значение в многопоточной среде без явного написания цикла CAS. Исследование показало, что fetch_max генерируется макросом atomic_int! в стандартной библиотеке Rust, который создаёт методы для атомарных типов.

На уровне компиляции LLVM эта операция превращается в цикл сравнения и обмена, скрытый от программиста. Это демонстрирует, как Rust абстрагирует сложные низкоуровневые детали, предоставляя удобные и безопасные примитивы для конкурентного программирования.

• Автор обнаружил, что Rust имеет встроенную атомарную операцию fetch_max, которой нет в Java и C++ (хотя она планируется в C++26).
• Обсуждение затронуло технические детали реализации атомарных операций (например, на ARM и x86), их производительность при высоком уровне конкуренции и возможность компилятором оптимизировать циклы CAS в нативные инструкции.
• Участники отметили, что подобные низкоуровневые операции существуют и в других средах, таких как GPU (HLSL/GLSL/CUDA) и RISC-V.
• Многие выразили признательность автору за познавательную статью, углубившую их понимание модели памяти и атомарных операций.
• Несколько человек поинтересовались, был ли нанят кандидат, упомянутый в исходной статье, на что автор ответил, что тот не подошел по культуре.

Объектные хранилища вроде Amazon S3 стали основой для современных систем данных благодаря почти неограниченной ёмкости, низкой стоимости и высокой долговечности. Однако их высокая задержка и стоимость каждого запроса создают серьёзные проблемы для приложений, требующих низкой задержки, таких как потоковые системы вроде RisingWave. Задержки в сотни миллисекунд накапливаются при частых чтениях, делая систему медленной и дорогой.

Для решения этой проблемы разработан гибридный кеш Foyer на Rust, объединяющий память и локальный диск. Он снижает количество обращений к S3, ускоряя доступ к горячим данным в памяти и тёплым — на диске, что сокращает задержки и затраты. Архитектура Foyer включает шардированный кеш в памяти для высокого параллелизма и дисковый кеш с эффективным управлением данными, координируемые единым компонентом. Это позволяет достичь баланса между скоростью и ёмкостью, критически важного для реального времени.

• Обсуждение библиотеки Foyer для гибридного кеширования (память + диск) и сравнение с альтернативами (CacheLib, rclone, S3 Mountpoint, AWS Storage Gateway).
• Вопросы о производительности S3 и целесообразности кеширования из-за задержек и стоимости запросов.
• Технические детали реализации: инвалидация кеша, запись в S3, поведение в гибридном и in-memory режимах.
• Проблемы с работой сайта Medium (модальные окна, блокировка прокрутки) в Firefox.
• Критика формата комментариев и призыв к содержательным обсуждениям.

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

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

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

В Wild-линковщике для Rust применяют несколько продвинутых техник оптимизации параллельной работы. Например, используют split_off_mut для безопасного разделения мутабельных срезов Vec<SymbolId> между потоками, что позволяет обрабатывать символы каждого объекта параллельно без блокировок, сохраняя кэш-локальность.

Для инициализации вектора без задержек на основном потоке задействуют крейт sharded-vec-writer: предварительно аллоцируют память, разбивают её на сегменты по числу символов в объектах и заполняют их параллельно через VecWriter, что ускоряет стартовую фазу.

В случаях, когда требуются случайные записи в общий вектор (например, для обработки дубликатов символов в C++), переходят на атомарные операции. Вместо стабильного, но ограниченного AtomicU32::from_mut_slice (только nightly) или постоянного использования атомиков (что снижает производительность), временно преобразуют &[SymbolId] в &[AtomicSymbolId] через unsafe-конверсию, экономя на издержках синхронизации в основном коде.

• Обсуждаются оптимизации Rust, такие как преобразование Vec в IntoIter и обратно для эффективного повторного использования аллокации, что реализовано в стандартной библиотеке как специальный случай.
• Высказываются предостережения против некоторых "трюков производительности", например, перемещения аллокации в другой поток для освобождения, из-за особенностей работы аллокаторов и сомнительной выгоды.
• Поднимается вопрос о надёжности оптимизаций компилятора (LLVM) в релизных сборках, которые могут меняться между версиями и сложны для верификации, что контрастирует с медленными debug-сборками.
• Отмечается, что многие трюки направлены на обход ограничений borrow checker для получения разрешения на выполнение операций, а не на решение аппаратных задач производительности.
• Обсуждается преимущество Rust в безопасном параллелизме (например, с Rayon) по сравнению с C/C++, где обеспечение потоковой безопасности значительно сложнее.

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.
• Проводятся паралле

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

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

Корень проблемы не в выборе языка (YAML vs. альтернативы), а в том, что мы недооцениваем конфигурационные файлы как пользовательские интерфейсы. Они должны обеспечивать отличный UX: предотвращать ошибки, вести пользователя к успеху и работать как «велосипед для ума».

Пример реализации такого подхода — проект KSON, который позиционируется как более эффективная альтернатива YAML/JSON/TOML. KSON является верифицированным надмножеством JSON, поддерживает JSON Schema и предлагает инструменты для улучшения работы с конфигурациями.

• Критика KSON за отсутствие чувствительности к пробелам, что может приводить к неочевидным ошибкам парсинга, как в примере с вложенным списком портов.
• Обеспокоенность рисками безопасности из-за единственной реализации на Kotlin и сложностей сборки для других языков, таких как Python и Rust.
• Предложение использовать полноценные языки программирования (например, Python) для конфигурации вместо специализированных форматов, чтобы дать пользователям больше инструментов.
• Аргумент в пользу того, что конфигурационные форматы должны быть выразительными, но ограниченными (как Cue, Starlark или Dhall), а не просто данными, как JSON или YAML.
• Подчёркивание различия между форматами для людей (конфигурация) и для компьютеров (данные), и критика попыток совместить их в одном формате.
• Замечание, что сложная конфигурация часто указывает на проблемы в дизайне ПО, и что лучше предоставить пользовательский интерфейс вместо сложных файлов.
• Упоминание альтернатив, таких как TOML, HJSON, HOCON, KDL и Jsonnet, с различными подходами к простоте, выразительности и проверке типов.

Введение в гипервизоры на Rust

1. Введение

• Предварительные требования
• Цели курса
• Мотивация
• Как достигаются цели
• Что вы изучите
• Дизайн фаззера
• Дизайн гипервизора
• Что этот курс НЕ охватывает
• Демо: фаззер на основе гипервизора
• Зачем использовать гипервизор для фаззинга
• Приложения UEFI
• Язык Rust
• Классификация гипервизоров
• Гипервизор vs хост, ВМ vs гость
• Типы гипервизоров

2. Настройка и цикл работы гипервизора

• Включение: активация аппаратной виртуализации
• Настройка: создание структуры контекста гостя
• Переключение: запуск в гостевом режиме
• Возврат: переход обратно в режим хоста
• Обработка: эмуляция событий
• Цели и упражнения главы
• Тестирование с Bochs
• Подготовка к упражнениям
• E#1: Включение VMX/SVM
• E#2: Настройка VMCS/VMCB
• E#3: Конфигурация гостевого состояния
• Причины VM-выходов
• Альтернативный дизайн гипервизора

3. Виртуализация памяти

• Терминология
• Традиционная страничная организация x64
• Вложенная страничная организация
• Связь с гипервизором
• Ошибки страниц во вложенной организации
• Структурные элементы вложенной организации
• Сравнение традиционного и вложенного подходов
• Цели и упражнения главы
• E#4: Включение вложенной организации
• E#5: Построение структур и трансляция адресов
• E#6: Реализация copy-on-write и быстрого восстановления памяти
• Продвинутые темы

4. Интроспекция ВМ для фаззинга

• Проблема 1: Ненужное выполнение кода

• Пользователи высоко оценивают качество и полезность материалов по созданию гипервизора и операционной системы, связывая их с предыдущей работой автора.
• Высказывается критика в адрес формата материалов (Markdown/HTML) и пожелание иметь возможность скачивания в PDF для архивации.
• Отмечается, что материал представляет собой конспект/слайды курса и может быть сложен для понимания без предварительных знаний или посещения занятий.
• Возникает дискуссия о практической ценности таких материалов для самообразования без наличия глубоких базовых знаний.
• Упоминается растущий интерес к теме создания гипервизоров, о чём свидетельствует частое появление подобных руководств.
• Предлагаются технические решения для создания PDF-версии (например, печать в PDF через браузер).
• В комментариях присутствует лёгкое обсуждение терминологии (значение слова "hypervisor") и личный опыт работы в данной области.

Hyperion — это игровой движок для Minecraft, написанный на Rust, предназначенный для масштабных событий с поддержкой до 10 000 игроков в одном мире при стабильных 20 TPS. Его ключевое преимущество — высокая надёжность благодаря Rust, что исключает сбои из-за утечек памяти или SEGFAULT.

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

• Обсуждение технических аспектов сервера: совместимость с Java Minecraft, оптимизация производительности для 10k игроков, симуляция мира и нагрузка на память.
• Вопросы о функциональности: защита от гриферства, система прав доступа, совместимость с существующими плагинами и античитами.
• Интерес к переходу с других платформ (Spigot, Forge, Fabric) и потенциальные сложности миграции.
• Уточнение терминологии (TPS - ticks per second) и обсуждение архитектуры плагинов на Rust с использованием Bevy ECS.
• Комментарии о названии проекта и его долгосрочной перспективе в контексте жизненного цикла Minecraft.

В защиту 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++ (пакетные менеджеры, форматтеры) часто считаются устаревшими по сравнению с современными языками.

Блог asciinema

• Начало работы
• Исследовать
• Форум
• Нанять меня!

3.0 Опубликовано 15 сен 2025, Марчин Кулик

Рад объявить о выпуске asciinema CLI 3.0!

Это полная переписывание asciinema на Rust с обновлением формата файлов записи, добавлением live-стриминга терминала и множеством улучшений.

В этом посте я расскажу о ключевых моментах релиза. Подробности смотрите в примечаниях к выпуску и истории изменений.

Переписывание на Rust было сделано из-за моего предпочтения этого языка перед Python для работы с системными вызовами и параллелизмом. Это привело к ускорению запуска, упрощению установки (статический бинарник) и интеграции виртуального терминала asciinema.

Формат файла asciicast v3

Новый формат asciicast v3 использует интервалы времени вместо абсолютных временных меток, что упрощает редактирование записей. Заголовок был реструктурирован, добавлена поддержка события выхода ("x") и комментариев через #.

Пример записи:

{"version": 3, "term": {"cols": 80, "rows": 24, "type": "xterm-256color"}, "timestamp": 1504467315, "title": "Demo", "env": {"SHELL": "/bin/zsh"}}
[0.248848, "o", "Hey Dougal...\n"]
[0.248848, "o", "Yes Ted?\n"]
[1.001376, "o", "Is there anything on your mind?\n"]
[3.500000, "m", ""]
[0.143733, "o", "No."]
[2.050000, "r", "90x30"]
[1.541828, "o", "Bye!"]
[0.8870, "x", "0"]

Формат уже поддерживается сервером и плеером asciinema.

Live-стриминг терминала

Новый CLI позволяет транслировать сессии терминала в реальном времени с двумя режимами:

• Локальный режим использует встроенный HTTP-сервер для просмотра в доверенных сетях
• Удаленный режим публикует поток через сервер asciinema с shareable URL

Примеры:

$ asciinema stream --local
::: Live streaming at http://127.0.0.1:37881

$ asciinema stream --remote  
::: Live streaming at https://asciinema.org/s/TQGS82DwiBS1bYAY

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

Локальный приоритет

Ранние версии asciinema автоматически загружали записи на asciinema.org. Теперь CLI позволяет сохранять записи локально в файл формата asciicast v1 с выбором публикации или локального хранения.

• Участники высоко оценили Asciinema, особенно за простоту использования CLI, высокое качество GIF и новую функцию live-стриминга терминала.
• Было отмечено, что сервис, несмотря на высокую нагрузку, стабильно работает всего на двух маломощных виртуальных машинах (2 ГБ RAM каждая), что демонстрирует эффективность Elixir/Phoenix и BEAM.
• CLI-часть утилиты была переписана на Rust, что также было воспринято положительно.
• Некоторые пользователи выразили пожелания, такие как нативная поддержка экспорта в SVG/GIF и встроенные инструменты для скрытия секретов в записях.
• Обсуждались возможные сценарии использования live-стриминга, в том числе для стриминга программирования без дополнительного оборудования.

Простое введение в z3

Изучение мира решателей ограничений на простых примерах.

Что такое решатели?

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

Терминология

В документации z3 много жаргона. Например, «Sort» означает тип, а «constants» — это переменные, которыми оперирует решатель. Solver работает со своим языком SMT-LIB2, а библиотеки переводят код в этот язык.

Простое уравнение

Решим уравнение x + 4 = 7. Вот код на Rust:

use z3::{Solver, ast::Int};
fn main() {
    let solver = Solver::new();
    let x = Int::new_const("x");
    solver.assert(&(x + 4).eq(&7));
    assert_eq!(solver.check(), SatResult::Sat);
    let model = solver.get_model().unwrap();
    println!("x = {}", model.eval(&x, true).unwrap());
}

Решатель находит x = 3. Это базовый пример, но он показывает принцип работы.

• Обсуждение причин некорректных ответов в задаче о сдаче (coin change) при использовании решателя Z3 без нижних границ, что приводит к минимизации до отрицательной бесконечности.
• Рекомендации ресурсов для изучения SAT/SMT-решателей, включая конкретные PDF-документы и статьи.
• Обсуждение практического применения решателей (Z3, OR-Tools, MiniZinc) для различных задач, включая игры и оптимизацию запросов.
• Сравнение и рекомендации по выбору решателей для начинающих на Python, с упоминанием Z3, OR-Tools и CPMpy.
• Трудности моделирования проблем для решателей и важность правильной постановки ограничений для избежания неинтуитивного поведения.
• Обсуждение технических особенностей интеграции решателей в языки программирования, таких как перегрузка операторов в Rust.
• Упоминание о применении решателей для доказательства теорем и поиска контрпримеров, например, к гипотезе Гольдбаха.

Встраивание Rust в ядро Linux продвигается с новым API для безопасной обработки ненадёжных данных из пользовательского пространства. Benno Lossin предложил тип Untrusted<T>, который помечает данные как непроверенные и предотвращает их случайное использование в ядре. Этот тип работает на уровне системы типов без накладных расходов в runtime, что делает его эффективным инструментом для маркировки данных из сетевых соединений, съёмных носителей или пользовательских вводов.

API включает утилиты для работы с распространёнными структурами данных, такими как срезы и векторы, и рекомендует интерфейсы вроде read_from_userspace(buf: &mut [Untrusted<u8>]) для безопасного копирования. Для валидации данных введён трейт Validate, хотя его реализация пока требует доработки. Greg Kroah-Hartman предложил добавить пример использования в драйверах, особенно для уязвимых мест вроде ioctl(), где непроверенные данные исторически вызывали переполнения буфера.

• Обсуждаются преимущества строгих типов (например, Untrusted<T>) для повышения безопасности, особенно при обработке пользовательского ввода в веб-приложениях и ядре ОС.
• Отмечается, что подобные подходы уже эффективно реализованы в Rust (для embedded и системного программирования) и Perl ("tainting"), делая код более надежным.
• Подчеркивается, что в C++ также возможна подобная типобезопасность, но она редко используется на практике из-за сложности и инерции сообщества.
• В контексте ядра ОС отмечается, что "ненадежные" данные не только потенциально вредоносны, но и нестабильны (могут меняться конкурентно, быть недоступными).
• Утверждается, что система владения и проверки заимствований (borrowck) в Rust делает подобные API более эргономичными и безопасными по сравнению с C++.

RustGPT

Трансформерная языковая модель, полностью написанная на Rust.

• Проект представляет собой реализацию LLM (языковой модели) на Rust "с нуля" как учебный эксперимент для понимания принципов работы.
• Отмечается читаемость и лаконичность кода по сравнению с большими фреймворками вроде PyTorch/TensorFlow.
• Обсуждаются технические детали реализации: использование констант из lib.rs, структура трансформерных блоков, применение крейтов ndarray, rand.
• Поднимаются вопросы о данных для обучения: источник, объём (в проекте используется небольшой встроенный набор), возможности для непрерывного обучения.
• Упоминаются проблемы и сложности: отладка backpropagation, отсутствие GPU-ускорения, потенциальная неэффективность реализации.
• Высказываются мнения о экосистеме: преимущества cargo над "dependency hell" в Python, но и риски лёгкого включения зависимостей.
• Обсуждаются возможные улучшения: добавление численного тестирования градиентов, лицензии, GPU-акселерация, бенчмарки.
• Проект сравнивают с другими аналогичными реализациями на Rust и Zig, а также с кодом, сгенерированным ИИ.
• Отмечается впечатляющая скорость генерации первого токена и простота запуска (cargo run).

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 + внешние анализаторы».

Mago — набор инструментов для PHP, помогающий писать чище и быстрее.
Анализ кода, форматирование, линтинг и прочие утилиты в одном месте.

• Mago — это новый набор PHP-инструментов (форматтер, линтер, LSP) на Rust, но пока в бета-статусе: не парсит PHPDoc, не понимает встроенные классы без \, выдаёт тысячи ложных ошибок.
• Автор признал README обманчивым и обещает уточнить roadmap и неготовые фичи (магические @method/@property, type-инференд).
• Пользователи сравнивают проект с uv/ruff для PHP, но сомневаются в необходимости: у PHP уже есть Composer, PHPStan, Psalm, которые развиваются быстрее и без разрыва экосистемы.
• Основной аргумент «на Rust» воспринимается слабо: сообщество не видит, почему переписывать инструменты на другом языке, если нет денег и людей (в отличие от Sorbet/tsgo, у которых спонсоры).
• PHP Foundation и крупные проекты (WordPress, Laravel, Википедия) деньги имеют, но пока никто из них Mago не финансирует.

• На этой неделе после атаки на npm целью стал crates.io.
• Рассылается письмо «Инцидент безопасности: взлом инфраструктуры».
• Просят перейти по ссылке и войти через «внутренний SSO» — это фейк.
• Сайт копирует GitHub-авторизацию, крадёт токены.
• Подделка заметна по домену, отсутствию HTTPS и странному URL.
• Настоящий crates.io никогда не просит войти через сторонние формы.
• Получили письмо — удалите, не кликайте; включите 2FA и проверьте токены.

• Фишинг снова в тренде: мошенники массово атакуют разработчиков через «сломанные» пакеты (npm, crates.io), подделывают e-mail от PayPal и GitHub.
• Самые опасные письма подписываются реальным доменом (paypal.com, github.rustfoundation.dev) и ведут на поддельный «внутренний» логин; звонки «от банка» тоже подменяют номер.
• Правило «ноль доверия»: не кликайте, не звоните по указанным ссылкам/номерам; заходите на сайт вручную или набираете официальный номер из надежного источника.
• Даже опытные разработчики чуть не ведутся: письмо выглядит срочным, без опечаток, с корректным логотипом и SSL, но просит «подтвердить» учётку на стороннем домене.
• Защита: включайте passkey / 2FA, не вводите пароль на незнакомых доменах, после любого изменения безопасности временно блокируйте публикацию пакетов.

• YouTube
  О платформе, прессе, авторском праве, контактах, авторах, рекламе, разработчикам.
  Условия, конфиденциальность, безопасность, как работает YouTube, тест новых функций, NFL Sunday Ticket.
  © 2025 Google LLC

• Участники спорят, «победил» ли Rust: кто-то считает, что язык уже получил признание индустрии и государства, другие — что говорить о победе рано.
• Ключевой аргумент «за» — широкое распространение знаний: после увольнений в Mozilla бывшие разработчики разошлись по большим компаниям, и ни одна корпорация теперь не контролирует язык.
• Главное преимущество Rust называют не безопасность, а юзабилити: понятные ошибки компилятора, привычный синтаксис и рабочие инструменты сделали «функциональное программирование массовым».
• Качество экосистемы вызывает вопросы: 90 % опубликованных крейтов — заброшенные или низкокачественные, поиску мешает отсутствие курации на crates.io.
• Тем не менее число живых, аудированных и развивающихся библиотек растёт экспоненциально, а крупные проекты (ripgrep, wgpu, iroh) уже используются в продакшене.

NGINX теперь с ACME
12 авг. NGINX официально добавил встроенный модуль ngx_http_acme (на Rust), который сам получает и продлевает сертификаты Let’s Encrypt.

Зачем

• никаких внешних клиентов;
• работает из коробки: от домашнего лаба до кластеров Kubernetes;
• меньше рутины, больше шифрования.

Кто ещё
Traefik, Caddy, Apache уже умеют; теперь к ним присоединился самый популярный веб-сервер и прокси.

Разработчикам
Протокол ACME, библиотеки и обсуждение — на форуме Let’s Encrypt.

• Кто-то рад встроенному ACME в nginx, кто-то считает, что «сертификат должен получать отдельный клиент», а не каждый сервис в отдельности.
• Спор о безопасности: модуль на Rust, но в нём много unsafe-блоков для взаимодействия с Си-ядром nginx.
• Вопрос «зачем ждать столько лет?» — ответ: корпоративные заказчики F5/medленный релиз-цикл.
• Практика: можно отключить встроенный ACME и продолжать использовать certbot/cert-manager.

Асинхронное программирование 2.0
Автор: Ankur Goyal, 19 авг 2025

Я перестал писать код руками. Описываю задачу — агент пишет TypeScript/Rust/Python, тесты и коммитит. Я возвращаюсь только на ревью. Это не «вайб-кодинг», а новый цикл: чётко определяю → делегирую → проверяю.

Как работает

1. ТЗ как код: «снизить задержку поиска с 800 до 200 мс, убрав аллокацию в цикле».
2. Автопроверка: юнит- и интегра-тесты, типы, бенчи, линтеры — всё в CI.
3. Жёсткое ревью: агенты ошибаются, поэтому читаю PR дольше, чем писал раньше.

Плюсы

• Параллельно веду 4–5 задач: одну в фокусе, остальные в фоне.
• Система всё равно моя: архитектура и решения остаются моими.

Braintrust
Собственный агент Loop принимает описание eval-задачи и в фоне улучшает промпты, датасеты и скоры.

• «Async programming» в статье — это не про async/await, а про делегацию коду ИИ-агентам; название вызывает путаницу и споры.
• Ключевой шаг — чётко описать задачу; критики считают это самым трудным и редким навыком.
• Опасения: атрофия собственных навыков, взрыв технического долга, потеря удовольствия от программирования.
• Сторонники отмечают высокую скорость итераций и полезность ИИ для «скучного» кода (тесты, скрипты).
• Опыт офшоринга показывает: без точных спеков результат — задержки и недопонимание; ИИ ускоряет получение «среднего» кода, но не решает проблему спецификаций.

Rust: «неразумная» скорость сортировки

• Сортировка в Rust быстрее C++ и Go благодаря LLVM, агрессивному векторизатору и ручным оптимизациям.
• Алгоритм: pdqsort (pattern-defeating quicksort) + векторизованный партиционер.
• Ключевые приёмы:
  • 128-битные SIMD-операции (SSE/AVX) для фильтрации элементов;
  • branchless-код, предикты, минимизация кэш-промахов;
  • специализированные пути для малых типов (u8, u16, u32, u64, f32, f64) и копируемых структур;
  • ручная развёртка циклов, инлайн, отказ от стандартных абстракций.
• Сравнение: на случайных u64 Rust ~2× быстрее libstdc++, ~3× быстрее Go; на почти отсортированных — ещё больше.
• Память: всё делается in-place, доп. буфер 1 КБ максимум.
• Сложность: O(n log n) в среднем, O(n log n) worst-case (pdqsort гарантирует).
• Код открыт, можно подсмотреть и перенести на другие языки.

• Универсальный лайфхак: «сначала отсортируй данные» — и задача часто сводится к O(log n).
• Но глобальная сортировка дороже с ростом объёма; иногда проще пересмотреть подход или использовать хэш-таблицу.
• Современные unstable-sort и foldhash настолько быстры, что ручные оптимизации часто проигрывают и требуют лишней памяти.
• Для 4 уникальных значений подсчёт или perfect-hash проще и быстрее полной сортировки; эксперимент ставит границы, а не решает продакшен-задачу.

JiraTUI — терминальный клиент Jira: ищи, создавай, обновляй задачи не отрываясь от кода.

Возможности

• Поиск: быстрый фильтр по статусу, исполнителю, приоритету; продвинутый JQL с сохранением выражений.
• Создание: новая задача из консоли — заголовок, описание, приоритет за секунды.
• Обновление: статус, исполнитель, метки, дедлайн — всё правится командой.
• Комментарии: добавляй/удаляй прямо из терминала.
• Связи: линкуй/отвязывай подзадачи и зависимости без GUI.

Плюсы

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

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

• Пользователи в восторге от Jira-TUI: быстрый поиск, красивый интерфейс, спасение от тормозов веб-версии.
• Просят аналоги для GitHub, Linear, Asana, Slack; ищут TUI-библиотеки Rust/Go такого же уровня.
• Хотят кликабельные ссылки из почты/Slack сразу в TUI, но это требует кастомного URI-обработчика.
• Кто-то просит CLI-версию для массового импорта задач, кто-то — классический Kanban-доску.
• Поднимаются вопросы безопасности (API-ключ в стороннем проекте) и поддержки on-prem Jira API v2 (не поддерживается).

Гипервизор за 1000 строк

Практическое руководство по созданию минимального RISC-V гипервизора, способного загружать Linux. Продолжение книги «ОС за 1000 строк», но теперь на Rust и с нуля (type-1, bare-metal). Используем только важное: сторонние крейты экономят код.
Репозиторий: github.com/nuta/hypervisor-in-1000-lines
Лицензии: текст — CC BY 4.0, код — MIT.

Содержание:
0. Введение

1. Старт
2. Загрузка
3. Hello World
4. Менеджер памяти
5. Режим гостя
6. Страницы гостя
7. Привет из гостя
8. Сборка ядра Linux
9. Запуск Linux
10. SBI
11. MMIO
12. Прерывания
13. Заключение

• Демо-гипервизор на 1000 строк — интересная техническая игрушка, но без паравиртуальных драйверов и прочей инфраструктуры непригоден для реального использования.
• Чтобы запустить RISC-V гипервизор на x86, нужен QEMU, потому что это эмуляция другой архитектуры.
• Желающим увидеть «тот же объём, но на C» скидывают 500-строчный SimpleVisor и репозиторий kvmsample.
• В дискуссию вмешалась философия: «OS» можно уложить и в 5 строк EFI-кода, если не требовать от неё ничего, кроме «Hello, world».

Vicinae — минималистичный лаунчер для ПК:

• нативный, быстрый, расширяемый
• Rust + Tauri
• плагины на JS/TS
• MIT

• Пользователи в восторге: Vicinae — качественный лончер-аналог Raycast для Linux, лёгкий в установке и работе на i3, Hyprland и др.
• Основной плюс — совместимость с расширениями Raycast, но часть из них пока не работает (например, raindrop.io).
• Разработчик планирует улучшить поддержку расширений, добавить ресайз окна и порт под macOS ARM.
• Проект открыт к контрибуциям, но слияние с другим форком маловероятно из-за разных стеков.

Скалярные типы

• u8…u128, i8…i128 — целые фикс. размера
• usize/isize — целые под указатель
• f32/f64 — вещественные
• bool, char — логика и UTF-4

Составные

• (T, U) — кортеж
• struct — имен. поля
• enum — варианты
• union — перекрытие
• [T; N] — массив фикс. длины
• () — юнит

Безразмерные

• [T], str, dyn Trait — сами не компилятся, живут за ссылкой
• &[T], &mut [T], &str, &mut str, &dyn Trait, &mut dyn Trait — срезы и трейт-объекты

Ссылки

• &T, &mut T — заимствование

Диапазоны

• a..b, ..b, a.., a..=b, ..=b, .. — полу- и замкнутые

Утилиты

• Option<T>, Result<T, E>, Ordering, Arguments — стандартные обёртки

Асинхронность

• Poll<T>, Context, Pin<P> — фундамент async

Анонимки

• fn(), |x|, async fn, async ||, impl Trait — функции, замыкания, existential

unsafe

• UnsafeCell<T>, ManuallyDrop<T>, PhantomData<T> — сырые/мета-инструменты

Указатели

• *const T, *mut T, fn(T)->U — сырые и функц. указатели

Прочее

• PanicInfo, Location, ! — паника и «никогда»

• Пользователи хвалят cheats.rs за визуальные схемы lifetimes и memory-layout, удобную мобильную прокрутку и напоминание диапазонов целых.
• Отмечают, что таблица «как таблица Менделеева» — компактна и полезна.
• Вопрос: почему PhantomData в группе unsafe — ответ: она нужна dropck для указателей-владельцев.
• Побочное обсуждение: «а не сделать ли signed-целые симметричными с NaN» — быстро отвергли как лишённое смысла.

desktop-tui — графикс-фри десктоп: терминальное окружение без X/Wayland.
Управляется клавиатурой, рисует рамки/окна в консоли, запускает TUI- и CLI-приложения.
Лёгкий, зависит только от ncurses и libc; конфиг на YAML.
Сборка: cargo build --release; запуск: ./target/release/desktop-tui.

• Пользователи сравнивают проект с DESQview, TWIN и TurboVision, спорят о целесообразности «переизобретения» оконного TUI-интерфейса.
• Основные плюсы: минимализм, низкое потребление ресурсов, удобство работы по SSH, возможность запуска на слабом железе (Raspberry Pi, VPS).
• Главные минусы: отсутствие браузера и современных коммуникационных приложений, проблемы с ресайзом, непонятные хоткеи, необходимость докачивать библиотеки.
• Некоторые советуют проверенные альтернативы: tmux+Emacs/Vim+SLIME, TWIN, Wordgrinder, browsh.
• Общий вывод: интересное решение для низкоуровневого или «отвлечённого» окружения, но пока требует документации и доработки.

• Сортировка с хешем быстрее хеш-таблиц: на больших данных 1,5–4×, несмотря на «O(n log n)».
• Память: хеш-таблица тянет 128 Б на 8-Б ключ (64 чтение + 64 запись), радикс-сорт 3 прохода — 48 Б (вся линия кэша используется).
• Плохие распределения (мало заполненных корзин) замедляют радикс-сорт; решаем хешем hash(key) перед сортировкой. Берём обратимую функцию (Murmur3, MulSwapMul), хешируем «на лету» в первом проходе.
• Результат: 2 ГиБ уникальных uint64 за 1,9 с против 2,6 с у оптимизированной хеш-таблицы.
• Подходит, когда порядок не важен, а нужны только уникальные значения; иначе остаёмся на хеш-таблицах.

• Улучшенная нестабильная сортировка Rust почти догнала по скорости специально настроенный radix-sort, несмотря на разницу в O(n log n) vs O(n).
• Хэш-таблица «побеждает» лишь при ограниченном размере ключа и хорошем кэше; при росте данных снова проигрывает из-за промахов и O(n log n) внутри.
• Radix можно ускорить, выделяя buckets через MMU, а не вручную управляя памятью.
• На очень больших объёмах (≥120 ГБ) константы radix снова могут перевесить, но пока доминирует кэш-эффективность сортировки.
• Всё обсуждение подчёркивает: конкретные константы и архитектура CPU важнее «чистой» Big-O.

GitHub-репозиторий BeaconBay/ck
Публичный проект без описания.
Кнопки: «Code», «Issues», «Pull requests», «Actions», «Projects», «Wiki», «Security», «Insights».
Последний коммит: 2 года назад.
Язык: C.
Лицензия: отсутствует.

• Утилита ck — это «семантический grep» на Rust: строет локальный векторный индекс файлов и ищет по смыслу, а не только по ключевым словам.
• Работает через embeddings (BAAI/bge-small-en-v1.5, планируется Gemma), повторное индексирование запускается автоматически при изменении файлов.
• Поддерживает почти все языки, но для точного семантического чанкинга требуется донастройка tree-sitter; grep-режим остаётся дефолтом.
• Пользователи жалуются на медленный поиск в больших проектах, отсутствие TypeScript-LSP и «разрезание» эмодзи; README считают «AI-флаффным».
• Альтернативы: Codanna, Serena, Roo с Qdrant, SemTools; автор приглашает тестеров и PR для доведения до зрелости.

Проблема выражений и её решения

Проблема выражений: нужно добавлять новые типы данных и новые операции без изменения старого кода.
В ООП-языках легко добавлять типы (наследование), но сложно — операции (менять интерфейс).
В функциональных языках наоборот: легко добавлять функции, сложно — варианты данных.

Пример на C++
Базовый класс Expr с двумя методами: Eval() и ToString().
Новый тип — просто новый класс-наследник.
Новая операция — правим базовый класс и все наследников, нарушая OCP.

Функциональный подход (Haskell)
Типы данных и функции разведены:

data Expr = Constant Double | BinaryPlus Expr Expr
eval (Constant x) = x
eval (BinaryPlus a b) = eval a + eval b

Добавить операцию легко: пишем новую функцию.
Добавить вариант Expr — правим сам тип и все функции, pattern-match’и которых его затрагивают.

Как быть

• Визитор (ООП) — двойная диспетчеризация, но код всё равно растёт.
• Мультиметоды (CLOS, Clojure) — выбор по типу всех аргументов, код не трогается.
• Type-class / протоколы (Haskell, Clojure) — «открытые» функции, реализуемые вне исходного модуля.
• Tagless-final / finally-tagless — выразить язык как набор операций, интерпретаторы добавляются без изменения AST.

Итог: ни один стиль не побеждает; выбираем язык и технику, которая даёт нужную сторону расширяемости.

• Суть проблемы: нужно добавлять новые типы данных и новые операции без переписывания старого кода и без потери статической безопасности.
• Классический подход: O·T матрица — каждая операция реализуется для каждого типа; при росте O или T взрывается boilerplate.
• Языковые решения:
  – трейты/impl в Rust, typeclass в Haskell, протоколы в Swift позволяют добавлять операции «сбоку»;
  – enum (суммарные типы) упрощают добавление операций, но затрудняют новые варианты данных.
• Продвинутые техники: tagless-final, object algebras, data types à la carte, multiple dispatch, visitor-pattern.
• Ограничения: «сиротское правило», отсутствие виртуальных extension-методов, необходимость заранее знать все комбинации при раздельной компиляции.
• Вывод: идеального языка нет; выбор зависит от того, что важнее — расширять типы или операции — и насколько нужна статическая типизация.

• "строка" – ищет фразу целиком, без учёта регистра
• from:ник – посты конкретного автора
• lang:код – фильтр по языку (en, ru…)
• #тег – по хэштегу
• условие условие – логическое И
• условие OR условие – логическое ИЛИ
• ( ) – группировка

• Спор о «парсинге, а не валидации»: кто-то пишет собственные проверки, кто-то берёт готовые библиотеки (Zod, Clap, argparse, docopt, yargs и др.).
• Rust/PowerShell/argparse хвалят за строгие типы и понятные ошибки; JS/TS-рантайм критикуют за лишние зависимости.
• Проблема: как сообщить сразу ВСЕ ошибки, а не падать на первой; как выдавать человекочитаемые сообщения.
• «Непредставимые состояния» хороши в ядре программы, но на границе ввода нужны гибкие структуры и recovery.
• CLI ≠ API: парсим только синтаксис, доменные ограничения уносят глубже; иначе получаем перегруженный интерфейс.

musl-аллокатор тормозит в 7 раз
Добавь в main.rs:

#[cfg(target_env = "musl")]
#[global_allocator]
static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc;

и в Cargo.toml:

[target.'cfg(target_env = "musl")'.dependencies]
mimalloc = "0.1"

Проблема — конкуренция потоков за malloc. Чем больше потоков, тем хуже.
Замена аллокатора нужна даже для однопоточных программ: забудешь — потом дорого.

Почему musl? Статика + 2 МБ distroless-контейнер = старые RH и быстрый cold-start.

Кейс: сервер обрабатывал данные в 7 раз медленнее хоста.
Виноват 200 000 контекст-переключений/сек vs 1 200 у glibc.
strace показал 6,7 с в futex у musl против 0,5 с у glibc.

• musl-аллокатор медленен в многопоточных Rust-программах из-за одного глобального замка.
• Альпийские образы компактны, но «размер» ≠ «скорость»; в проде чаще берут Debian/RHEL.
• Замена: jemalloc, mimalloc или Wolfi (glibc, apk, busybox) без смены менеджера пакетов.
• glibc тоже фрагментирует память; MALLOC_ARENA_MAX=jemalloc спасает.
• Новый mallocng musl не решает конкуренцию потоков: цель musl — минимум кода и харднинг, а не perf.

### Скалярные типы
- `u8` 0…255  
- `i8` -128…127  
- `bool` true/false  
- `u16`, `i16`, `f32`, `u32`, `i32`, `u64`, `i64`, `f64`, `u128`, `i128`, `usize`, `isize`, `char`

### Составные
- `(T, U)` кортеж  
- `struct` именованные поля  
- `enum` варианты  
- `union` пересекающиеся данные  
- `[T; N]` массив фикс. длины  
- `()` юнит

### Безразмерные
- `[T]` слайс  
- `str` строковый слайс  
- `dyn Trait` трейт-объект  
- `&[T]`, `&mut [T]`, `&str`, `&mut str`, `&dyn Trait`, `&mut dyn Trait`

### Ссылки
- `&T` shared  
- `&mut T` mutable

### Диапазоны
- `a..b`, `..b`, `a..`, `a..=b`, `..=b`, `..`

### Утилиты
- `Option<T>`  
- `Result<T, E>`  
- `Ordering`  
- `Arguments` (format!)

### Асинхронность
- `Poll<T>`  
- `Context`  
- `Pin<T>`

### Анонимные
- `fn()` item  
- `|x| …` closure  
- `async fn` / `async ||`  
- `impl Trait`

### unsafe
- `UnsafeCell<T>`  
- `ManuallyDrop<T>`  
- `PhantomData<T>`

### Сырые указатели
- `*const T`, `*mut T`

### Указатели на функции
- `fn(T…) -> U`

### Паника
- `PanicInfo`, `Location`

### Недостижимый
- `!` never

• Пользователи сравнивают визуализацию «Elements of Rust» с периодической таблицей и другими подобными гайдами (например, cosmic.mearie.org), отмечая, что она выглядит красиво на десктопе, но неудобна на мобильных и требует горизонтального скролла.
• Некоторые находят подборку полезной для быстрого погружения, особенно если уже знакомы со статически типизированными языками.
• Критика: «таблица» кажется произвольной в группировке типов, не объясняет, почему важные концепты рядом, и из-за плотности информации может отпугнуть новичков.
• Упоминаются аналоги из C/C++, а также ссылки на другие Rust-гайды, попадавшие на HN.
• Для строковых представлений в стандартной библиотеке есть трейты Display и Debug; сериализация JSON доступна через сторонние крейты (например, serde).

• Рисование
  Терминал умеет только моноширинные символы и escape-последовательности. Используем нижний полублок ▄, задавая цвет фона (верхний пиксель) и символа (нижний).

  fn print_pixels_pair(top, bottom, (x, y)) {
      println!("\x1b[{};{}H\x1b[48;2;{t}m\x1b[38;2;{b}m▄", y+1, x+1, t=top, b=bottom);
  }
  

• Текст
  Создаём TextCaptureDevice в Skia: перехватываем onDrawGlyphRunList, преобразуем glyph → Unicode, вызываем Rust-функцию draw_text.
  Добавляем очистку текста при заливке прямоугольников:

  if (paint.getStyle() == kFill_Style && paint.getAlphaf() == 1.0)
      clear_text(rect);
  

• Ввод
  Читаем stdin, парсим escape-коды клавиш/мыши, передаём их в Chromium через DOM-события.

• Pipe-режим
  carbonyl --pipe рисует в stdout, позволяя встраивать браузер в скрипты.

• Mojo
  Заменяем GPU-процесс на заглушку, отключая лишние сервисы.

• Layout
  Подгоняем device_scale_factor и viewport под размер терминала, чтобы 1 px = ½ клетки.

• LoDPI
  На 1×-экранах включаем сглаживание, чтобы символы не «дребезжали».

• Цвет
  Палитра 6×6×6 или 24-бит truecolor; приводим цвета к ближайшему доступному.

• Заголовок
  ESC-операторы меняют заголовок окна и вкладки tmux.

• Итог
  Carbonyl запускает весь веб в терминале без X11/Wayland: cargo install carbonyl.

• Carbonyl — терминальный браузер на движке Chrome, удивительно шустрый и юзабельный, особенно с --zoom=300 --bitmap.
• Пользователи просят добавить Kitty Graphics Protocol, sixel/chafa для нормального вывода картинок без ASCII-арта.
• Проект вдохновлён browsh, но работает быстрее; автору даже помог получить работу.
• Запускается в podman, показывает YouTube «кубиками» и почти справляется с капчей (могут помочь мультимодальные LLM).
• Под капотом — Skia и Mojo из Chromium, что позволяет рендерить всё, включая PDF.

• 20+ специалистов из 4 континентов ищут удалённую работу; большинство — full-stack, DevOps, ML/AI и мобильные разработчики.
• Регионы: США (Austin, SF, NYC, Florida), Латинская Америка (Буэнос-Айрес, Богота, Медельин), Европа (Лондон, Осло, Хорватия), Азия (Бангкок, Ханой), Африка (Лагос) и др.
• Ключевые стеки: Rust/Go/Python, React/Node, AWS/GCP, Docker/K8s, LLM/AI-инструменты, iOS/Android, а также редкие — DSP, C++, embedded.
• Готовность к релокации: ~30 % «да», ~60 % «только удалённо», остальные — «возможно при убедительном предложении».
• Уровни: от стажёров и new-grad до 20-летних ветеранов и CTO; многие предоставляют портфолио и рекомендательные письма.

Краткий обзор проблемы 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++ всё ещё держится пол-мира, так что просто так не выкинешь».

Гибридный PHP: PHP + Go и Rust

Раньше у нас был монолит на PHP 8.3 («мама») и несколько микросервисов на Go («дети»). Такой стек давал скорость там, где нужно, и скорость разработки везде остальном.

По правилу 80/20 20 % эндпоинтов приносят 80 % нагрузки. Раньше мы выносили их в Go-сервисы, но это усложняло инфраструктуру. Теперь можно оставить логику в монолите и всё равно получить высокую производительность.

Новые инструменты

• FFI – вызов C-кода прямо из PHP.
• Расширения на Rust – безопасный и быстрый код без C.
• FrankenPHP – worker-режим до 4× быстрее; теперь можно писать расширения на Go и вызывать их из PHP.

Зачем не переписать всё на Go или Rust?

• Переписывание дорого и рискованно.
• PHP отлично справляется с 80 % задач, а критичные 20 % можно ускорить расширениями на Rust/Go.

Итог: современный PHP даёт и скорость разработки, и максимальную производительность там, где это критично.

• Участники жалуются, что монолитные фреймворки (Spring, Laravel, Phoenix) быстро дают результат, но превращают legacy-код в кошмар при обновлении зависимостей.
• Обсуждают гибридные схемы «PHP + Rust/Go/C», но предупреждают о росте сложности отладки и найма.
• Некоторые считают современный PHP (≥8.x) недооценённым и упрекают индустрию в стереотипах 5.x-времён.
• Упоминаются альтернативные рантаймы (FrankenPHP, RoadRunner, Workerman) и эксперименты с встраиванием PHP в nginx.
• Пакетный менеджер Composer критикуется как «не тот уровень», ждут «Astral для PHP».

Agent Client Protocol (ACP) — единый стандарт связи между редакторами кода и агентами-разработчиками на базе ИИ.
Протокол в разработке, но уже позволяет строить полезные интеграции.

Зачем ACP?

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

Как устроено

• Агент запускается как подпроцесс редактора.
• Обмен — JSON-RPC через stdio.
• Используются типы MCP, дополнены собственными (например, для диффов).
• Текст для пользователя — Markdown, без необходимости HTML.

Поддержка

Редакторы:

• Zed
• neovim (через плагин CodeCompanion)

Агенты:

• Gemini
• Скоро — ещё.

• Предложен новый протокол (ACP) для связи агентов-ИИ с IDE/редакторами, плюс библиотеки на Node, Python, Rust и сайт.
• Название ACP вызывает путаницу с уже существующим agentcommunicationprotocol.dev и IBM/Google A2A.
• Некоторые считают, что достаточно расширить LSP или MCP, другие предлагают «Neovim внутри Claude Code», а не наоборот.
• Уже есть первые реализации для Claude Code и Zed, но остаются проблемы с поиском несохранённых файлов и UI-дифами.
• Обсуждают риск фрагментации стандартов и желание, чтобы любой редактор мог подключиться без переписывания под каждого агента.

TPDE-LLVM: 10-20× быстрее -O0
Новый open-source бэкенд TPDE-LLVM ускоряет компиляцию в режиме -O0 в 10–20 раз при сопоставимой скорости выполнения и увеличении кода на 10–30 %. Поддерживаются x86-64 и AArch64, типичное IR Clang O0/O1.

SPEC 2017 (x86-64)	Ускорение	Размер
perl	11.4×	1.27×
gcc	12.5×	1.32×
mcf	9.7×	1.27×
omnetpp	21.5×	1.24×
xalanc	19.0×	1.24×
x264	10.5×	1.26×
deepsjeng	9.6×	1.25×
leela	21.4×	1.24×
xz	11.0×	1.30×
geomean	13.3×	1.27×

Как работает
Три прохода: очистка IR, анализ (циклы + живость), кодогенерация (lowering, регистры, код) за один проход. Подробности — в статье.

Планы

• DWARF, улучшенный регистровый аллокатор.
• Поддержка Flang/Rust неполная (векторы, FP-операции).
• Нет non-ELF, других целей.

Использование
Библиотека, llc-подобный инструмент, патч для Clang.

Почему не ускорить LLVM?
LLVM 18→20 стал быстрее на 18 %, но 10× требует радикальных изменений.

Что мешает ещё быстрее

• ConstantExpr внутри функций.
• Структуры/массивы произвольного размера.
• Прямой доступ к TLS-глобалам.
• Арифметика произвольной битности (i260).

Факты

• 4 байта padding в Instruction для служебных номеров.
• PHINode::getIncomingValForBlock квадратичен при >1 k предков.
• 90 % времени tpde-llc — парсинг биткода.

• TPDE — новый бэкенд, генерирующий код на 10–20× быстрее LLVM, но чуть медленнее -O0.
• Участники спорят, насколько «парето-улучшение» реально: поддерживается лишь «типичное» подмножество LLVM-IR, векторные инструкции и экзотика не работают.
• Некоторые вспомнили Copy-and-Patch и другие подходы, где LLVM используется для библиотеки патчей, но теряется 2,5× в рантайме из-за регистров.
• Основная узкость теперь — фронтенды (rustc, Clang), которые даже при TPDE занимают >98 % времени сборки.
• Желают скорейшего переноса в Swift и Wasmer, но сомневаются в готовности сообщества LLVM что-то менять.

Я написал учебник по созданию гипервизора с нуля за 1 000 строк кода: 1000hv.seiya.me. Это тип-1 гипервизор для 64-битного RISC-V с расширением H в QEMU. Подойдёт тем, кто уже прошёл OS in 1 000 Lines.

Код на стабильном Rust — без nightly. Сообщество Rust наконец-то добавило всё необходимое, включая inline-assembly.

Идея книги: гипервизор — это «обработчик событий»:

const vcpu = new VirtualCPU(memory);
while (true) {
    try { vcpu.resume(); }
    catch (e) { handle(e); } // MMIO, прерывания…
}

Он запускает гостевую ОС, перехватывает выходы из VM и возвращается. Это позволяет строить не только классические ОС, но и безопасные среды вроде gVisor или Hyperlight.

Книга уже доступна онлайн. Приятного кодинга!

• RISC-V можно полностью виртуализировать методом «ловушка-и-эмуляция» без аппаратного расширения, но обход таблиц страниц будет медленным.
• @drob518 уточнил: обход таблиц страниц выполняется программно, а не аппаратно.
• @nerpderp82 спросил, можно ли использовать RVV для обхода таблиц страниц.
• @anchovy_ попросил литературу по гипервизорам; @dmitrygr дал ссылки на академическую теорию и практику VMware.
• @TZubiri посоветовал учиться по документации производителей и исходному коду, а не по университетским книгам.

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 для простых задач.

Debian 13 «trixie» вышла после двух лет разработки: 14 000 новых пакетов, APT 3.0 по умолчанию и официальная поддержка 64-битного RISC-V.
Версии ПО: GNOME 48, Plasma 6.3, Xfce 4.20, Emacs 30.1, LibreOffice 25.2, ядро 6.12.41 LTS, GCC 14.2, Rust 1.85, Python 3.13, systemd 257.
Поддерживаемые архитектуры: amd64, armhf, arm64, ppc64el, s390x, riscv64. i386 исчез, armel последний релиз.

Обновление из bookworm возможно: конвертируйте sources.list в DEB822 (команда apt modernize-sources появится только в trixie), удалите сторонние пакеты и проверьте, что имена сетевых интерфейсов могут измениться.

Установка: от 64 МБ netboot-ISO до образов Blu-ray; для больших образов рекомендуют BitTorrent или jigdo.

• Некоторые пользователи считают «unstable» (sid) вполне стабильной для ежедневной работы, другие подчеркивают, что всё же бывают серьёзные сбои.
• Многие узнали о новом инструменте extrepo для подключения внешних репозиториев, но на Trixie пока встречаются проблемы с зависимостями.
• Trixie хвалят за «дружелюбие» к пользователю и свежие пакеты, однако NVIDIA-драйверы и CUDA-репы пока не обновлены, что вызывает головную боль.
• Для более новых версий ПО советуют backports, Flatpak или официальные deb-пакеты Mozilla, чтобы не ждать ESR.
• Серверные админы считают Debian лучшим выбором для продакшена, но на десктопе ему иногда не хватает свежести.

Плюсы Nim 2

• Память: по умолчанию ORC/ARC (RAII, деструкторы, move/copy), а не трассирующий GC. Можно --mm:none или --mm:atomicArc.
• Компилируется в C/C++/Obj-C/JS; выбираем компилятор (gcc, nvcc, …).
• Лёгкая интеграция: {.importc.}, {.importcpp.}, {.importjs.}, {.compile.} для сторонних файлов.
• Метапрограммирование: макросы, static исполнение кода на этапе компиляции, генерация CUDA.
• Краткость: мало шаблонного кода (чат на 70 строк).
• Производительность ≈ C/C++/Rust; поддержка SIMD, CUDA.

Минусы и подводные камни

• Генерируемый C/C++ код нечитаем — не цель проекта.
• Нет атомарных счётчиков в ORC по умолчанию (требуется флаг).
• Некоторые старые статьи/комментарии описывают Nim 1.x (GC по умолчанию).
• Синтаксис чувствителен к отступам и регистру (но это субъективно).

Мини-пример: простой key/value формат

import std/[tables, strutils]

type Config = object
  host*: string
  port*: int

proc loadConfig(path: string, T: typedesc): T =
  let data = readFile(path).splitLines()
  var kv = initTable[string, string]()
  for line in data:
    let parts = line.split('=')
    if parts.len == 2:
      kv[parts[0].strip()] = parts[1].strip()

  result.host = kv.getOrDefault("host", "localhost")
  result.port = parseInt(kv.getOrDefault("port", "8080"))

let cfg = loadConfig("app.conf", Config)
echo cfg.host, ":", cfg.port

Файл app.conf:

host = 0.0.0.0
port = 9000

Всё компилируется в один бинарник без GC-задержек.

• Пользователи отмечают редкую, но полезную возможность Nim — определять собственные операторы.
• Хвалят макросы, интегрированные в систему типов и перегрузку, сравнивая язык с «статически типизированным Lisp».
• Критика: сложности с Windows (Nimble-зависимости тянут GCC, Defender блокирует бинарники) и неоднозначная «фантастическая» интеграция с C++.
• Обсуждают объём JS-артефактов: для мелких примеров — десятки килобайт, но без оптимизации могут быть мегабайты.
• Для WASM рекомендуют компилировать в C и прогонять через Emscripten, но стандартные JS-биндинги не работают.
• Вопросы IDE: есть nimsuggest и быстрая настройка для Neovim, но плагинов для JetBrains почти нет.

Булево значение почти всегда маскирует более точный тип.
Проверь, не дата-время ли это: is_confirmed лучше заменить на nullable confirmed_at. Вы получите момент подтверждения и сможете анализировать баги по времени.

Если поле описывает роль или статус (is_admin, failed), превращайте в enum.

enum UserRole { User, Admin, Guest, SuperAdmin }
enum JobStatus { Queued, Started, Failed, Done }

Enum упрощает добавление новых состояний и защищает от забытых веток.

Проверка прав тоже не должна возвращать bool.

enum PermissionCheck { Allowed, NotPermitted(reason: String) }

Так код читабельнее и можно вернуть причину отказа.

Когда же использовать bool? Только как временную переменную-флаг для сложного условия, чтобы не вычислять его дважды или дать имя.

• Основной спор: стоит ли хранить «события» как булевы флаги или как nullable-даты/enum’ы, чтобы не терять данные (время события).
• Противники: это нарушает KISS, раздувает схему и вводит двусмысленность (null = не случилось или ошибка?).
• Сторонники: булевы поля не «помнят» контекст, легко образуют недопустимые комбинации флагов, а дата или enum выразительнее.
• Для параметров функций булевы флаги считаются плохо читаемыми; спасают именованные аргументы, отдельные функции или бит-маски.
• Встраиваемые/индустриальные системы часто считают булевы типы оптимальными по памяти и не применяют совет к себе.

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; участники обсуждают создание форка, который бы следовал спецификации.

fenster — сверхкомпактная кроссплатформенная GUI-библиотека.

• Особенности:

  • Окно, пиксельный буфер, ввод с клавиатуры/мыши.
  • Один .h файл, ~400 LOC, зависимости: X11 (Linux), Cocoa (macOS), Win32 (Windows).
  • Поддержка C/C++, Zig, Odin, Rust, Go, JS (WASM), C#, Swift, Pascal, Nim, Lua, Python, Ruby, OCaml, Fortran.

• Быстрый старт (C):

#define FENSTER_IMPL
#include "fenster.h"
int main() {
  struct fenster f = {.width = 320, .height = 240, .title = "demo"};
  uint32_t buf[320*240];
  for (fenster_open(&f); fenster_loop(&f) == 0; ) {
    // рисуем
    fenster_sync(&f, buf);
  }
  return 0;
}

• Сборка: cc demo.c -o demo (Linux: -lX11, macOS: -framework Cocoa, Windows: без флагов).

• API (C):

  • fenster_open, fenster_close, fenster_loop, fenster_sync.
  • Поля: width, height, title, keys[64], mouse.

• Лицензия: MIT.

• Fenster — это минимальная C-библиотека, создающая окно с пиксельным буфером, а не полноценный GUI с кнопками и меню.
• Участники отмечают отсутствие скриншотов и просят добавить их в README.
• Название «Fenster» переводится как «окно» на немецком, африкаанс, шведском и других языках.
• Некоторые считают polling-цикл ошибкой, другие считают его допустимым для такой простой задачи.
• В блог-посте нашли опечатку в sizeof и ограничение кода 8-битными цветами.
• Проект вызывает интерес для визуализации данных и как лёгкая альтернатива raylib.

agent-c — сверхлёгкий AI-агент от bravenewxyz.
Проект открыт, код на GitHub.

• 4 КБ-агент на Си вызывает OpenRouter через curl и исполняет команды, что вызывает шутки о «русской рулетке» и безопасности.
• Критика: сжатие UPX, отсутствие проверок ошибок, жёстко заданные константы, popen вместо libcurl.
• Лицензии обсуждают от «Copy me» до CC0, BSD, Apache, GPL и WTFPL.
• Некоторые предлагают запускать под отдельным пользователем или в Docker, локально через Ollama/LM Studio.
• Промпт заставляет агента говорить как Наполеон Динамит («Gosh!», «Sweet!»).
• Сравнивают с Rust-версией «alors» и оффлайн-Python-примером на 44 строки.

sping — терминальный мониторинг задержек HTTP/TCP с живыми графиками. Установка: pip install service-ping-sping.

Быстрый старт

sping google.com                 # HTTP
sping tcp://google.com:80        # TCP
sping https://api.example.com -i 0.5 -c 20
sping example.com --json -c 5

Возможности

• HTTP/HTTPS/TCP, разбивка по фазам (DNS, TLS, запрос, ответ).
• Авто-обнаружение выбросов по MAD (6× медиана).
• Пороги warning/critical, выбор IPv4/IPv6, кэш DNS.
• Процентили p50-p99, экспорт JSON, 8 цветовых тем.
• Bearer/Basic-аутентификация, кастомный User-Agent.

Примеры

sping api.example.com -X POST --body --auth "bearer:token"
sping tcp://localhost:5432 -i 0.1
sping example.com --warn 100 --crit 500 --percentiles

Ключи

-i интервал, -c число запросов, --timeout, --ipv4/--ipv6, --resolve-once, --body, --no-keepalive, --insecure, --warn/--crit, --percentiles, --palette <theme>.

• Пользователи хвалят визуальный ping-утилиту sping, но предлагают переписать её на Go/Rust для статического бинарника без зависимостей.
• Автор подтвердил, что проект полностью сделан с помощью ChatGPT и Claude, а README «украшен» эмодзи.
• Найдены мелкие баги: ошибка палитры цветов и сбой при выводе финального резюме.
• Некоторые сравнивают инструмент с mtr, tracepath и nping --tr, отмечая, что нужен более дружелюбный аналог.

Разрабатывая CLI-утилиту, я хотел избежать тормозов при тестах из-за fstat, как это было в Bundler. Решил попробовать in-memory FS, как в Go-библиотеке Afero.

В Rust аналогов нет: спросишь — получишь лекцию «в Rust это не нужно». Нашёл два кандидата:

• vfs — поддерживает swap-бэкендов, но без симлинков и прав, а главное — нельзя создавать исполняемые файлы.
• rsfs — старый, почти заброшенный; требует параметризовать весь код типом rsfs::FS, превращая сигнатуры в кашу.

Провёл бенчмарк: vfs, rsfs, ramdisk и обычный SSD — всё показывает ~45 мс. Современные SSD + кеш ОС настолько быстры, что экономия на syscalls незаметна.

Вывод: тестируй прямо на файловой системе — проще и не медленнее.

• Позикс-семантика сложна, поэтому самописная in-memory реализация почти всегда хуже по качеству, чем готовые tmpfs/ramfs.
• Для быстрых тестов достаточно /tmp (часто tmpfs) или /dev/shm — это дёшево и использует проверенный ядром код.
• SSD и кэши ОС настолько быстры, что даже обычное файловое I/O редко становится узким местом; CPU и syscalls чаще ограничивают.
• Несколько участников пожелали стандартным traits для файловой системы, как в Go (fs.FS, afero), но признают, что в std Rust это уже трудно.
• Основная цель обсуждаемого vfs-крейта — встраивать файлы в бинарь, а не мокать диск; об этом автор плохо сообщил в README.

Краткий итог тестов LLM для личных задач

• Цель: найти быструю и дешёвую модель для простых вопросов по Rust, Python, Linux и быту.
• Данные: 130 реальных запросов из bash-истории, разбитые на программирование, администрирование, объяснения, общие знания.
• Платформа: OpenRouter через собственный Rust-клиент ort.
• Тестовые модели: Claude-4 Sonnet, DeepSeek-chat-v3, DeepSeek-r1, Gemini 2.5 Flash/Pro, Kimi-k2, GPT-OSS-120B, Qwen3 235B (обычный и thinking), GLM-4.5, а также Mercury-Coder, Devstral, Qwen3-Coder для кода.

Выводы

• Почти все модели справляются; различия в качестве минимальны.
• Критерии победы: цена и скорость. Запросы стоят доли цента, но латентность варьируется в десятки раз.
• Закрытые модели не лидируют: Gemini Pro самый дорогой и многословный; Flash быстрее всех, но не всегда лучше.
• Режим «рассуждений» почти не нужен, кроме творческих заданий (стихи).
• Победители по категориям
  • Программирование: Mercury-Coder (сверхбыстрый диффузионный), DeepSeek-r1, GLM-4.5.
  • Сисадмин: Gemini 2.5 Flash.
  • Объяснения: Qwen3 235B.
  • Общие знания: GPT-OSS-120B.

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

• Google Gemini 2.5 Flash признан «рабочей лошадкой»: быстро, дёшево, мультимодален и способен пережёвывать 100 k запросов за €30.
• Большинство участников жалуются на «сговор» моделей: при творческих задачах 6 из 11 LLM выдают один и тот же ответ, что убивает креатив.
• Локальный запуск: на Mac Mini 64 ГБ уверенно работают модели < 32 B; фаворит — gpt-oss-20b (11 ГБ RAM) и семейство Qwen 3.
• Для выбора «одной на всё» многие выбирают deepseek-chat-v3-0324 как компромисс скорость/цена/качество.
• Трения с API: OpenAI требует KYC, Claude доступен не везде, поэтому кто-то использует Kagi, Perplexity или OpenRouter, чтобы «пощупать» все модели без лишних ключей.

Cloudflare запустил первый MoQ-CDN
Теперь можно тестировать Media over QUIC на их глобальной сети — это официальный продукт. MoQ — новый стандарт для live-медиа, призванный заменить WebRTC, HLS/DASH, RTMP и SRT.

Что уже работает

• Бесплатный технический превью: relay.cloudflare.mediaoverquic.com
• Поддерживаются клиенты draft-07: moq-rs, imquic, moxygen и др.
• Публикация/просмотр прямо в браузере через Web-компоненты <hang-publish> и <hang-watch>:

<hang-publish url="https://relay.cloudflare.mediaoverquic.com"
              name="unique-name-abc123" audio video controls captions>
  <video muted autoplay></video>
</hang-publish>

• Скрытые субтитры генерируются в браузере (Whisper + WebGPU) и передаются по MoQ.
• Есть Rust-библиотека: импорт MP4, ffmpeg, gstreamer.

Что пока не работает

• Нет аутентификации — используйте случайные имена стримов.
• Нет ANNOUNCE → конференции не стартуют.
• Safari не поддерживает WebTransport (в планах).
• Код не оптимизирован, баги гарантированы.

• Пользователи хвалят скорость и плавность демо MoQ, но жалуются на чёрные полосы на мобильных и проблемы с полноэкранным режимом.
• Вопросы к разработчикам: поддержка multicast, graceful degradation, fallback для Safari, балансировка нагрузки и сравнение с WebRTC после установки соединения.
• Разработчики объясняют: multicast не нужен — CDN решает это на L7; MoQ строится поверх WebTransport/WebCodecs и может работать с MSE для совместимости.
• QUIC/WebTransport пока работает в основном в Chrome; Firefox страдает от багов WebTransport и HTTP/3.
• MoQ позиционируется как более гибкая замена WebRTC для лайв-стриминга и может быть использована и для других данных, включая игровой трафик.

В 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 без нарушения обратной совместимости.

Rust — это язык с жёсткой внутренней связностью.
Он не сложен из-за плохой документации, а потому что его концепты переплетены: замыкания, трейты, заимствование, Send/Sync, итераторы и прочие вещи нужны сразу. Поняв их, вы получаете мощный и последовательный инструмент.

Мини-пример.
20 строк кода на Rust, отслеживающие изменения файлов:

use notify::{Watcher, RecursiveMode};
fn main() -> Result<(), notify::Error> {
    let mut w = notify::recommended_watcher(|r| {
        if let Ok(e) = r {
            println!("{:?} {:?}", e.kind, e.paths);
        }
    })?;
    ["pages", "templates", "static"].iter()
        .try_for_each(|p| w.watch(p.into(), RecursiveMode::Recursive))?;
    loop { std::thread::park(); }
}

Даже здесь нужно знать: Result, замыкания, итераторы, трейты Display, 'static, Send.
На JavaScript то же заняло бы 5 строк и не потребовало бы ни трейтов, ни заимствований.

Вывод.
Внутри Rust прячется «меньший, чище» язык с ясным видением: безопасность без сборщика мусора, абстракции без потерь, композиция через трейты. Этот язык появляется, когда все части складываются в единую картину.

• JS-пример из поста содержит несколько багов (null-файл, for-in вместо for-of), которые TypeScript не всегда ловит.
• Автору ставят в вину, что он «забыл» упомянуть async/await, Promise, модули и прочие скрытые концепции JS.
• Комментаторы спорят, можно ли выкинуть из Rust «половину» фич и остаться при этом «малым и чистым»; большинство считает, что нет.
• Многие советуют новичкам не начинать с Rust: компилятор будет целыми днями выдавать ошибки, прежде чем программа запустится.
• Несколько человек упоминают Gleam, Zig и Austral как «упрощённые» альтернативы, но подчёркивают, что это уже другие языки.

luminal — библиотека для глубокого обучения, работающая «со скоростью света».

Основное

• Язык: Rust
• Цель: максимально быстрое вычисление градиентов и обучение нейросетей.
• Подход: компиляция вычислительного графа в высокооптимизированный нативный код (LLVM).

Возможности

• Автоматическое дифференцирование.
• JIT-компиляция графов.
• Поддержка CPU и GPU (CUDA).
• Минимальные накладные расходы: нет Python-интерпретатора и лишних библиотек.

Примеры

let x = Cpu::tensor([1.0, 2.0, 3.0]);
let y = x.relu().sum();
let g = y.backward(); // градиент за наносекунды

Установка

cargo add luminal

Статус

Проект в активной разработке; API может меняться.

• Luminal — это ML-фреймворк, который вместо ручных правил формулирует оптимизацию как поиск по огромному пространству возможных ядер (tiling, потоки, инструкции и т.д.) с помощью e-graphs.
• Сейчас на M-серии MacBook Llama-3 8B Q8 выдаёт 15-25 ток/с; это ниже llama.cpp, но команда строит трекер производительности и продолжает улучшать поиск.
• Поиск ограничен 12 базовыми линейно-алгебраическими операциями, что делает задачу похожей на «superoptimisation» и позволяет добавлять аппаратно-специфичные инструкции (tensor cores, PTX/ASM) без роста frontend.
• Для оценки качества ядра используется реальное время выполнения на целевом железе; масштабировать планируют распараллеленным профилированием на кластерах GPU.
• Отличие от TVM/tinygrad — единое пространство поиска, включающее как параметры тайлинга, так и алгебраические преобразования (например, softmax → flash-attention).

Без 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, которые ядро автоматически разблокирует.

Программа должна оставаться валидной по мере набора.
Python-списковые включения плохи: пока вы не допишете for line in text.splitlines(), редактор не знает тип line, не может подсказать split() и даже не понимает, существует ли переменная.
В Rust text.lines().map(|line| line.split_whitespace()) строится слева-направо: сразу после line. доступны методы, и код всё время «жив».

Принцип progressive disclosure: сложность появляется ровно тогда, когда нужна. В C функции для FILE* начинаются на f; вводишь f и видишь сотни вариантов, не понимая, какой подходит. В идеале file. показал бы read, close и т. д. прямо во время набора.

Python и JS:

map(len, text.split())

— неясно, как называется длина (len, length, size?).

text.split(" ").map(w => w.length)

— length и map подсказываются сразу после точки.

С ростом логики читаемость падает:

len(list(filter(lambda line: all([abs(x) >= 1 and abs(x) <= 3 for x in line]) ...

• Обсуждение вращается вокруг идеи «слева-направо» синтаксиса: сначала контекст (объект, коллекция), потом действие, чтобы IDE могла мгновенно подсказывать.
• Критикуют Python- comprehensions и вложенные вызовы за «вправо-налево» порядок, мешающий автокомплиту и чтению.
• Многие хотят pipe-оператор (|>) или uniform call syntax, как в F#, Elixir, Nim, чтобы цепочки выглядели data |> filter(...) |> map(...).
• Противники считают, что язык не должен подстраиваться под автокомплит, а сложные цепочки лучше выносить в переменные или использовать методы.
• Примеры из SQL, JS/TS импортов, Rust for-loops и C# LINQ показывают ту же проблему: сначала надо указать, что ты хочешь получить, а потом — откуда.

Reality Defender API
Два вызова кода — и ваша система получает признанные наградами модели для обнаружения дипфейков. Бесплатный тариф: 50 проверок аудио/изображений в месяц.

Почему Reality Defender API

• Простота — загрузка файла и получение результата.
• Гибкость — SDK на Python, TypeScript, Java, Go, Rust.
• Прозрачность — исходники открыты.
• Доступность — 50 сканов/мес без карты.

Тарифы

План	Цена	Включено
Free	$0	50 сканов/мес, аудио+изображение, 1 пользователь
Growth	от $399/мес	50+ сканов, аудио+изображение+видео, чат
Enterprise	по запросу	неограниченный объём, мультисид, видео+текст, стриминг, интеграции Zoom/Teams/Webex, расширение Chrome, персональная поддержка

Где применять

• Верификация личности (KYC, безопасный доступ)
• Мошенничество (имперсонация, соц-инженерия)
• Модерация контента
• Анализ СМИ и факт-чекинг
• Исследования и тесты

Поддерживаемые форматы

Аудио (до 100 МБ, 12 с – 5 мин): wav, flac, mp3, m4a, aac, ogg, opus; 8 языков.
Изображения (до 10 МБ): jpg, jpeg, png, gif, webp.
Видео (до 250 МБ): mp4, mov; аудио как выше.

Начать бесплатно | Документация SDK

• Участники сомневаются в надёжности «детекторов ИИ» и предсказывают бесконечную «кошку-мышь» между генераторами и детекторами.
• Предлагают альтернативу: криптографическую подпись контента, но признают, что добровольные стандарты легко обходятся.
• Основатели Reality Defender отвечают: ансамбль моделей выдаёт лишь вероятность 1-99 %, API закрыт, таргетинг по паттернам и лимит 50 бесплатных сканов мешают злоупотреблениям.
• Уже используется крупными банками и корпорациями для проверки подлинности медиа и документов.

Почему в 2025 году мы всё ещё пишем на Ruby

Стартуя с Lago, мы выбрали Ruby on Rails — у команды был десятилетний опыт, и это был самый быстрый путь к рабочему API. Сегодня система обрабатывает миллионы вызовов в день, пережила множество обновлений Ruby/Rails, и, если бы начинали заново, выбор остался бы тем же.

Скорость как главное преимущество
Rails больше не «тренд» для стартапов, но его используют Shopify, GitHub, GitLab — зрелые компании, которым важна надёжность и скорость разработки. Мы взяли Rails в API-only режиме: без лишнего middleware и рендеринга, но с миграциями, валидациями, Active Record и фоновыми задачами. Это позволило тратить время на продукт, а не на костыли.

Масштабируемость
Rails не масштабируется? Это проблема архитектуры, а не фреймворка.

• Rails 8 упрощает деплой без PaaS.
• Redis + Sidekiq проверен временем.
• Ruby Fibers добавляют асинхронность.
• Puma, автомасштабирование и кеширование справляются с нагрузкой.

Недостатки, с которыми живём

• Производительность и память: ошибки дорого обходятся.
• GIL CRuby: один поток Ruby-кода за раз, поэтому тяжёлые задачи уходят в Go/Rust.
• «Магия» Rails: избегаем лишних гемов и пишем максимально явный код.

Все языки компромиссы; мы выбрали Rails, потому что знаем его настолько хорошо, что умеем обходить ограничения и получать максимум скорости разработки.

• Участники жалуются на рутину вокруг JS/TS-стека: тройное дублирование типов, самописная интеграция auth и прочие «reinventing wheels».
• Многие называют Rails «скучным, но рабочим» инструментом, который до сих пор быстро даёт полный вертикал функционала без бойлерплейта.
• Популярность Rails страдает из-за ассоциаций с «устаревшей» эпохой 10-летней давности и отсутствия хайпа, хотя кодовая база активно развивается (YJIT, ZJIT).
• На практике Rails используется для бизнес-логики и API, а Go/Rust — для I/O- или CPU-ёмких задач; Shopify и GitHub живут по такой же схеме.
• Некоторые мечтают о «Rails на другом языке» (Clojure, Gleam) или ждут, что AI сделает быстрые языки такими же удобными, как Ruby.

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

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

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

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

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

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

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

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

Оптимизация

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

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

• 3d hilbert curve
• shingles
• temple
• rusty maze
• spring
• fbm terrain
• torus knot
• dandelion
• power line
• woven WIP
• roots
• bumpy sphere
• abstract hourglass
• birdbath
• concrete tetrapod
• terraced floating island
• extruded clay bowl
• fancy shader props
• superellipse dominos
• dark souls tree

Автор всех работ: ameo
Geoscript и Geotoy — Casey Primozic, открытый код.

• GeoToy — это «Shadertoy для геометрии»: вместо цвета пикселя функция возвращает вершины, поэтому куб рисуется 36 вызовами, а не 921 600.
• Похож на DSL для 3D-моделей; пример «temple» помогает быстрее понять синтаксис.
• Материалы задаются не кодом, а через UI (три пиктограммы → «materials») и используют трипланарное отображение без UV.
• Анимации пока нет, но пользователи просят добавить переменную вроде iTime из Shadertoy.
• Проект вызывает ассоциации с Structure Synth и geometry-шейдерами, но последние считаются трудными для оптимизации.

doxx — утилита для просмотра содержимого .docx прямо в терминале.
Быстро, безопасно, без MS Office.

• Установка
  cargo install doxx

• Использование

  • Просмотр: doxx file.docx
  • Извлечение текста: doxx --text file.docx > out.txt
  • Показ метаданных: doxx --meta file.docx

• Особенности

  • Чистый Rust, нет внешних зависимостей.
  • Поддержка кириллицы, таблиц, списков.
  • Режим «только чтение» — файлы не изменяются.

• Пользователи высоко оценили скорость и полезность TUI-утилиты для просмотра docx, но почти все согласились: название «doxx» вызывает негативные ассоциации с doxxing и требует смены.
• Ключевое требование — любые «AI-фичи» должны быть полностью опциональными или вынесены в отдельный проект, иначе инструмент запретят в корпоративных и юридических средах.
• Популярные пожелания: Docker-образ, бинарники для Windows, поддержка Track Changes/метаданных, отображение картинок через kitty/sixel, а также возможность «cat+grep» без промежуточных конвертаций.
• Некоторые предложили использовать pandoc, LibreOffice или OOXML-Validator как дополнительные инструменты, а автор подтвердил, что скоро появятся релизы и улучшенная документация.

DOSDevelResources — подборка инструментов и ссылок для разработки под DOS.

Содержание

• Языки

  • C/C++: Watcom, DJGPP, OpenWatcom, SmallerC, SubC
  • Pascal: Free Pascal, Turbo Pascal 5.5
  • BASIC: FreeBASIC, QB64, QuickBASIC 4.5
  • Сборка: NASM, FASM, WASM, TASM, MASM 6.11
  • Прочее: Rust (rustc-dos), Go (gccgo), Lua, Python 2.4

• Библиотеки и API

  • Allegro, SDL, Raylib, GRX, pdcurses, OpenGL (Mesa3D), VESA, SoundBlaster, TCP/IP (Watt-32, mTCP)

• Утилиты

  • Редакторы: RHIDE, FTE, SETEdit, TDE, Vim, Emacs
  • Отладчики: GDB, WD, TD, SoftICE
  • Упаковка: UPX, LZEXE, PKLite, Diet
  • Эмуляция: DOSBox, DOSBox-X, 86Box, PCem, Bochs
  • Разное: Git, Make, Doxygen, Valgrind-like (Dr. Memory)

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

  • Ralf Brown’s Interrupt List, PCGPE, Intel/AMD manuals, OSDev Wiki

• Ссылки

  • FreeDOS, OSDev, Vogons, Scene.org

Как пользоваться

Клонируйте репозиторий:

git clone https://github.com/SuperIlu/DOSDevelResources.git

Все файлы/архивы лежат в каталогах по темам.

Лицензия

MIT.

• Участники вспомнили, что DOS-ретросцена жива: анонсирован 3-месячный DOSember game-jam.
• Перечислены доступные инструменты: HX DOS Extender, JWasm, Borland C++ 3.1, Free Pascal, DJGPP, GW-BASIC/PC-BASIC, а также MIT-лицензированный набор Microsoft 1988 года.
• Названы ключевые ресурсы: PC Games Programming Encyclopedia, эмулятор PCjs, книги «Black Book of Graphics Programming», «Programmer’s Guide to the EGA/VGA» и «PC-Intern».
• Отмечены удобные IDE: RHIDE и клон Turbo Vision от Free Pascal, а также ностальгия по быстрым Borland-IDE.
• Обсуждали, что современные ассемблеры (FASM/NASM) удобнее старых MASM/TASM, а DOS-цели можно собирать даже из Win32 PE.

• Участники жалеют, что выразительные языки с нативной компиляцией и автоматическим управлением памятью (Nim, D) не стали массовыми.
• Любители Nim хвалят его скорость, надёжность компилятора и эргономику, но жалуются на малую экосистему, устаревшую документацию и сложность кросс-компиляции.
• Скептики считают, что «выразительность» и макросы делают язык нишевым, требуют больше знаний и усложняют чтение чужого кода.
• Многие отметили, что успех языка определяют не фичи, а деньги, стандартная библиотека, тулинг и сообщество; Rust выиграл именно этим.
• Часть разработчиков ушла из Nim в Rust, Go или Zig из-за зрелости инструментов и богатой экосистемы, но продолжают следить за Nim и надеются на его рост.

lue — терминальный ридер ePub с TTS.

• Основное: читает ePub, воспроизводит речью, работает в консоли.
• Управление: клавиши Vim-стиля, навигация по главам, закладки.
• Настройка: темы, голоса, скорость, горячие клавиши.
• Установка: cargo install lue или brew install lue.
• Системы: Linux, macOS, Windows.
• Лицензия: MIT.

• Пользователи тестируют новый инструмент lue для чтения/озвучки epub в терминале: TTS-часть ценят за «просто закинул и слушай», но чтение в моноширинном шрифте вызывает сомнения.
• Основная боль — внешние зависимости (espeak, antiword) и требование Python ≥ 3.10; автор уже пообещал поднять минимальную версию.
• Прогресс и состояние озвучки сохраняются в системных логах; серверный запуск позволит синхронизировать закладки.
• Сноски, колонтитулы и служебные символы вырезаются, чтобы не мешать TTS; возможно появится опция оставлять их для обычного чтения.
• Автор собрал адаптеры для Kitten TTS, Gemini и др., но пока не опубликовал их, размышляя о выделении отдельного репозитория.
• Вопросы о запуске из Termux/Android и безопасности кода пока без ответа; автор приветствует аудит и обратную связь.

Проект «Zoo» — мини-реализации самых влиятельных статических систем типов последних 50 лет. Начнём с простых и дойдём до зависимых типов. Всё пишем на Rust — просто потому что удобно и забавно строить чисто функциональные языки на не-функциональном.

Это не учебник, а выходные развлечение. За теорией и доказательствами смотрите TAPL, ATTAPL, PFPL и оригинальные статьи (ссылки в приложении). Здесь же — грязные детали реализации: структуры данных, AST, логика, всё, что можно осилить за уик-энд.

Код — идиоматичный Rust с полноценным парсером и тестами (lalrpop, logos, ariadne). Примеры урезаны, но понятнее продакшен-реализаций. Парсинг и MLIR считаем решёнными задачами, поэтому не фокусируемся на них.

Четыре «зверька»:

• Algorithm W (775 строк) — классический Hindley–Milner, полиморфный λ-исчисление.
• System F (1090 строк) — второе λ-исчисление, параметрический полиморфизм, Mini-OCaml.
• System F-ω (3196 строк) — высшие рода, паттерн-матчинг, дататипы, Haskell-lite.
• Calculus of Constructions (6000 строк) — иерархия универсумов, индуктивные типы, крошечный Lean.

MIT-лицензия, хобби-проект. Нашли опечатку — присылайте pull-request.

• Пользователи хвалят Elaboration Zoo как полезный ресурс для изучения нормализации по вычислению и вывода неявных переменных.
• Просят аналогичный «зоопарк» для линейных типов и предлагают добавить быстрый вариант Hindley–Milner из OCaml.
• Автору советуют включить тёмную тему для блоков кода и рассмотреть простой однонаправленный type-checker в духе Featherweight Java.
• Уточняют, что присутствие индуктивных типов делает реализацию ближе к CIC, но Lean всё же сильнее за счёт аксиомы выбора.
• Картинки с животными вызывают путаницу; большинство считают их просто AI-орнаментом без смысловой нагрузки.

Citybound — симулятор города, где миллионы людей и бизнесов взаимодействуют, формируя живой организм мегаполиса.
Следи за жителями, транспортом, экономикой и принимай решения: чертить инфраструктуру, утверждать бюджеты, управлять ростом.
Проект с открытым исходным кодом, разрабатывается в основном одним человеком.
DevBlog • Reddit • GitHub • Экспериментальные сборки

---

Особенности

• Микро-экономика
  Каждая семья и компания имеет свой дом, ресурсы и потребности.
  Люди ищут выгодные сделки, учитывая цену, качество и транспорт.
  Из этих взаимодействий рождаются рынки, маршруты и районы.
  В планах: оценка привлекательности недвижимости и рост города до миллионов жителей.

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

• Citybound — проект симулятора города, но разработка прекращена ≈5 лет назад, последний коммит и активность на Patreon давно исчезли.
• Обсуждают, что большинство градостроителей (включая CB) игнорируют смешанное зонирование: квартиры над магазинами, бар на углу, пекарня в жилом доме и т.д.
• Критикуют упор на автомобили: «если единственный транспорт — машины, это уже не город».
• Пользователи советуют альтернативы: Egregoria, A/B Street, Workers & Resources.
• Кто-то вспоминает, что проект начинался как демонстрация мощи Rust для геймдева, но застрял в движке и не дошёл до геймплея.

Я написал 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, завари кофе».

Chromium
Войти

• Найдена критическая уязвимость escape из Chrome-песочницы, за которую Google заплатили $250 000.
• Некоторые считают, что на «чёрном» рынке она могла стоить дороже, но продажа чревата рисками и отмыванием денег.
• Mozilla платит за аналогичные баги лишь $20 000, что вызывает сравнение серьёзности подходов к безопасности.
• Ошибка логики/тайминга; Rust бы её не предотвратил.
• Участники обсуждают, как начать искать такие баги: читать write-ups, практиковать reverse engineering, пользоваться ресурсами вроде pwn.college.

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

Bezier-rs — интерактивная документация
Для работы необходим JavaScript

• Пользователи высоко оценили библиотеку Offsetting и её Rust-переписанный модуль булевых операций над кривыми.
• Обсуждаются возможности расширения: неравномерное обводное расширение, поддержка рациональных Безье для CAD, генерация равноудалённых точек, маршрутизация рёбер в диаграммах.
• Некоторые ищут обучающие ресурсы по математике для реализации подобных алгоритмов; рекомендованы видео Freya Holmér.
• Поднят вопрос о создании Python-биндингов и использовании WASM для работы в браузере.

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

Компании теряют время: 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 хорош для разовых скриптов.
• Нет единой метрики: из-за недетерминированности моделей и субъективных критериев «хорошего кода» каждый получает разные результаты.

HorizonDB — новая гео-БД на Rust, заменившая Elasticsearch и MongoDB.
Обрабатывает 1 млрд вызовов/день, 1 000 QPS на ядро, 50 мс прямого и <1 мс обратного геокодирования.

Проблемы старого стека

• Elasticsearch: шардирование, дорогие батчи, отсутствие отката.
• MongoDB: нет нормального bulk-импорта, переподбор ресурсов, сложный откат.

Архитектура HorizonDB

• Однопроцессный многопоточный бинарник.
• Данные Spark → S3 → RocksDB (версионные ассеты).
• Индексы: S2 (гео), Tantivy (поиск), FST (префиксы), LightGBM/FastText (ML-ранжирование).

Почему Rust

• Скомпилирован, без GC, предсказуемая латентность.
• Абстракции высокого уровня, pattern matching.
• Один процесс вместо Node.js-кластера → экономия памяти.

Ключевые компоненты

• RocksDB — быстрая запись/чтение с SSD.
• S2 — O(1) point-in-polygon через квадродерево.
• FST — компрессия префиксов, кэш «happy path» в МБ.
• Tantivy — встроенный инвертированный индекс, избегаем сетевого Elasticsearch.

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

• Пост вызывает много вопросов: детали шардирования, отказоустойчивость, latency и open-source-статус не раскрыты.
• Альтернативы: Typesense, DuckDB+spatial, Quickwit/Tantivy — всё open-source и уже показывает высокую производительность.
• RocksDB хвалят за надёжность и производительность, но кто-то вспоминает старые проблемы LevelDB.
• LMDB/OSM Express тоже предлагают более лёгкое решение для геопоиска.
• Многие считают, что 95 % задач решаются обычным Postgres/SQLite, а «заменить ES» сейчас модный лозунг.

flip-card
Проект Nicholas-L-Johnson на GitHub: публичный репозиторий, демонстрирующий карточку, переворачивающуюся при наведении.

• Технологии: HTML, CSS, возможно JavaScript.
• Функция: плавный 3D-переворот с лицевой стороны на обратную.
• Применение: карточки товаров, профили, интерактивные элементы UI.

Клонировать:

git clone https://github.com/Nicholas-L-Johnson/flip-card.git

• Проект — ультратонкая электронная визитка с симуляцией жидкости; вызывает восторг, но кажется дорогой для раздачи.
• Ключевые плюсы: реалистичное движение «воды», простая и дешевая конструкция, легко отлаживать.
• Минусы: можно намочить одежду, толщина USB-C + ПКБ выглядит «толстой» для визитки, шрифт на обороте раздражает многих.
• Отмечены изюминки: USB-C на краю платы без дополнительных деталей, прошивка на Rust с плавающей точкой, аккумулятор почти кредитной толщины.
• Люди хотят больше деталей о сборке, просят sans-serif шрифт и чуть более игривый дизайн.

Моя предыдущая статья о обобщённых структурах данных в C готовила почву к теме: структура, которая заменяет динамические массивы, даёт стабильные указатели и хорошо работает с аренными аллокаторами. Её переоткрывали много раз под разными именами: “levelwise-allocated pile” (2001), в Zig — Segmented List, частично похожая на C++ std::deque. Мне нравится название Per Vognsen — Segment Array.

Скачать мой однофайловый заголовок segment_array.h можно, подписавшись на рассылку.

Идея проста: фиксированный массив указателей на сегменты; каждый следующий сегмент вдвое больше предыдущего; новые сегменты выделяются по мере необходимости. Поскольку элементы не двигаются, указатели на них стабильны, не остаются “дыры” в арене, а доступ по индексу — за O(1).

Реализация

Структура на C:

typedef struct { u32 count; int used_segments; u8 *segments[26]; } SegmentArrayInternal;

Почему всего 26 сегментов? Из 64 бит указателя обычно реально используются 48, так что 49 сегментов уже перекрывают адресное пространство (~256 ТиБ). Я предпочитаю индекс u32 (до ~4 млрд элементов) — это даёт 32 сегмента. Ещё убираем 6 маленьких (1..32), начинаем с 64, остаётся 26 сегментов — хватает для 4 294 967 232 элементов (чуть меньше UINT32_MAX). Фиксированный массив рядом со структурой снижает риск промаха кэша.

Размеры сегментов — степени двойки: проще математика и быстрые сдвиги для индексов.

#define SMALL_SEGMENTS_TO_SKIP 6

#define log2i(X) ((u32) (8*sizeof(unsigned long long)
- __builtin_clzll((X)) - 1))

u32 capacity_for_segment_count(int segment_count) { return ((1 << SMALL_SEGMENTS_TO_SKIP) << segment_count) - (1 << SMALL_SEGMENTS_TO_SKIP); }

void *_sa_get(SegmentArrayInternal sa, u32 index, size_t item_size) { int segment = log2i((index >> SMALL_SEGMENTS_TO_SKIP) + 1); u32 slot = index - capacity_for_segment_count(segment); return sa->segments[segment] + item_sizeslot; }

log2i использует __builtin_clzll (подсчёт ведущих нулей) для быстрого вычисления номера сегмента.

Clang оптимизирует _sa_get до ~10 инструкций x86-64 (-O3), так что узким местом будет память, а не вычисления индекса. При последовательной итерации можно обходить сегменты напрямую; в segment_array.h есть макрос.

Выделение нового элемента:

u32 slots_in_segment(int segment_index) { return (1 << SMALL_SEGMENTS_TO_SKIP) << segment_index; }

void *_sa_alloc(SegmentArrayInternal *sa, size_t item_size) { if (sa->count >= capacity_for_segment_count(sa->used_segments)) { size_t segment_size = item_size * slots_in_segment(sa->used_segments); sa->segments[sa->used_segments++] = malloc(segment_size); } sa->count++; return _sa_get(sa, sa->count-1, item_size); }

Замечание: можно сделать ёмкость строго степенью двойки, если первые два сегмента одинакового размера. Код станет менее изящным, но это спасает от ~50% потерь памяти при использовании как массива бакетов в хеш-таблице со степенью двойки.

Дженерики

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

#define SegmentArray(type)
union {
SegmentArrayInternal internal;
type *payload;
}

Дальше макросы используют payload, чтобы передавать сведения о типе…

• Обсуждается структура «сегментированный массив» (экспоненциальные сегменты), её плюсы и минусы, и сравнение с существующими решениями: std::deque, ropes, Zig std.SegmentedList, rust-array-stump, plf::colony.
• Критика терминологии: это не «массив» в классическом смысле из‑за неконтигуозной памяти; многие API ожидают сплошной/страйдовый буфер и не подойдут.
• Производительность: при локальных L1-итерациях вычислительная часть индексации может быть ощутима; для больших объёмов память становится бутылочным горлышком. Предлагаются оптимизации итерации по сегментам и замечания про clz/bsr/lzcnt и опции компилятора.
• Виртуальная память как альтернатива: резервирование большого диапазона и по мере роста коммит страниц/guard pages; отмечены плюсы на Linux (MAP_POPULATE, mremap), но плохо для embedded/WASM.
• Сравнение с deque: фиксированные блоки vs экспоненциальные, поддержка prepend, рандом-доступ есть; реализация MSVC критикуется за малый размер блока, GNU/libc++ лучше.
• Недостатки сегментов: ухудшение предвыборки/кэш-локальности при линейной итерации, отсутствие стабильной непрерывности для API, сложность с хеш-таблицами при росте (rehash), потенциальный перерасход памяти при экспоненциальных размерах.
• Предложения: настраиваемый минимальный размер сегмента, функции «склейки» мелких сегментов, разбор условий, когда экспоненциальные сегменты оправданы, и замечания о чрезмерной макротрюковости в C/C23.

Это вторая часть серии о разработке Tyr — современного GPU‑драйвера на Rust для ядра Linux с поддержкой Arm Mali на CSF.

Разберем, как работают GPU‑драйверы, на примере VkCube — простого приложения на Vulkan, рисующего вращающийся куб. Простота сцены помогает понять путь данных и команд от приложения к GPU.

UMD и KMD

• UMD (usermode) реализует API вроде Vulkan/OpenGL/OpenCL и преобразует команды приложений в низкоуровневые команды для GPU. В нашем случае это panvk из Mesa.
• KMD (kernel mode) соединяет UMD с железом: инициализирует устройство, управляет памятью, очередями, планированием и уведомлениями. В нашем случае это Tyr, нацеленный попасть в основное дерево Linux.

Что делает UMD

• Подготавливает данные: геометрию, текстуры, машинный код шейдеров, матрицы трансформаций.
• Просит KMD разместить их в памяти GPU, создает VkCommandBuffer с командами отрисовки, настраивает состояние конвейера, указывает, куда писать результат, и как получать сигнал о завершении.

Про шейдеры

• Это полноценные программы на GPU. Для VkCube им нужны хотя бы геометрия, цвета и матрица вращения, чтобы расположить и раскрасить куб и крутить его.

Что делает KMD

• Выделяет и отображает память, изолируя процессы в отдельных контекстах/VM.
• Принимает работу от UMD, ставит в аппаратные очереди, отслеживает зависимости и завершение.
• Планирует выполнение на массово параллельном, асинхронном железе, соблюдая порядок и справедливое распределение ресурса между клиентами.
• Инициализирует устройство: тактирование, питание, стартовые процедуры; обеспечивает совместный и честный доступ приложений к GPU.

Ключевой вывод

• Основная сложность — в UMD, который переводит высокоуровневые API в команды GPU. Но KMD обязан предоставить надежные примитивы: память, очереди, синхронизацию, планирование и разделение ресурсов, чтобы UMD было реально реализовать.

Интерфейс драйвера

• На основе этих задач KMD экспонирует минимальный набор операций: запрос сведений об устройстве, создание/уничтожение VM, привязка/отвязка памяти к VM, получение состояния VM, отправка работ в очереди и механизмы уведомлений — тот же API, что у C‑драйвера Panthor для того же железа.

• Обсуждение статьи о драйвере GPU: часть читателей хвалит материал, но считает его слишком коротким и ждёт продолжения/второй части.
• Уточняют, что речь идёт о драйвере panthor для Mali CSF (на RK3588), а не panfrost; один из комментаторов отмечал баги в Firefox на RK3588, ему ответили про соответствующий драйвер.
• Спор о фокусе: одни подчёркивают важность того, что это один из первых GPU-драйверов Linux на Rust; другие критикуют кликбейт заголовок и считают, что нужно акцентировать Mali CSF, а не Rust.
• Техническая дискуссия: вопрос о целесообразности uring_cmd вместо ioctl; ответы поясняют, что из-за природы асинхронных очередей GPU дополнительная CPU-очередь мало что даст, а интерфейс драйвера следует ожиданиям Mesa.
• Отмечают, что текущая часть охватывает в основном границу пользователь/ядро и управление очередями/буферами; «основное действие» — выполнение команд GPU — ожидается в следующих частях.
• Дополнительно подчёркивают сложность современных GPU-драйверов и их объём в ядре Linux, что оправдывает выбранные подходы и терминологию.

Представьте, вы пишете проект и вам нужна библиотека — назовем ее 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 среди текстовых открытых моделей.

The reason you are not seeing crashes when allocating with Rust and freeing with C (or vice versa) is that by default Rust also uses the libc allocator.https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/src/std/s... Lots of detail, little substance, and misleading section headers