В эксперименте использовались Codex с GPT-5.6 Sol, Rust, 26 вариантов инструкций и 4 дополнительных набора правил. Вывод относится к этой постановке задачи, а не ко всем ИИ-моделям и методикам разработки.

Что проверял Дэн Лу

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

В новом сравнении для каждой комбинации инструкции и уровня вычислительных усилий модели, medium или xhigh, проведено 80 запусков. Основная метрика — доля запусков, прошедших 100% скрытых тестов. Вариант без специальных указаний оказался выше среднего; убедительного универсального победителя автор не выделяет.

Как тесты пропускали ошибки

При явном требовании использовать встроенные тесты Rust их число удваивалось на medium и увеличивалось на 25% на xhigh, но корректность не улучшалась. В отдельных тестах обработки четырёх битовых потоков встречались одинаковые входы: перестановка потоков оставалась незаметной. Фаззинг часто сводился к случайным байтам, которые проверяли преимущественно отказ на некорректном вводе.

Фаззинг — проверка программы на множестве автоматически сгенерированных входов. Если все они отбрасываются в начале, глубокая логика обработки может остаться нетронутой. В тестировании свойств задают правило для целого класса входов: например, после сжатия и распаковки должны восстановиться исходные данные. Библиотека Proptest также умеет уменьшать найденный сбойный пример, чтобы причину было проще разобрать.

Что это меняет для ревью

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

Результаты одного эксперимента не заменяют проверку на ваших задачах.

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

Producer-Consumer — это схема, в которой производители и потребители работают независимо, обмениваясь данными через общий буфер конечной ёмкости. Ёмкость здесь работает главным механизмом защиты: именно она не даёт быстрым производителям завалить медленных потребителей.

Ручная координация через wait() и notifyAll() в блоках синхронизации даёт гонки и ложные пробуждения, а активное ожидание в цикле впустую жжёт процессор.

Готовая блокирующая очередь решает задачу целиком: при переполнении она сама останавливает производителя, обеспечивая обратное давление вместо переполнения памяти.

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

Три гарантии прогресса различаются строго: obstruction-free требует отсутствия помех, lock-free гарантирует прогресс системы в целом, wait-free — завершение каждой операции за ограниченное число шагов.

Отсутствие блокировок и использование атомарных операций сами по себе не дают wait-free: цикл повторных попыток без верхней границы — это lock-free, как бы его ни называли в описании библиотеки.

Уровень первый: блокирующая очередь Producer-Consumer

С этого уровня начинают почти все, и здесь же делают три типовые ошибки:

• Писать собственную логику блокировок через wait() и notifyAll() внутри синхронизированных блоков. Это приносит тонкие гонки и баги ложного пробуждения, когда поток просыпается без всякого уведомления.
• Крутить активное ожидание в бесконечном цикле поверх коллекции, не рассчитанной на многопоточность. Процессор загружен постоянной проверкой размера очереди, а корректности всё равно нет.
• Не предусмотреть обратного давления. Когда производители быстрее потребителей, буфер растёт, пока приложение не упрётся в нехватку памяти.

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

В Java всё это уже реализовано в стандартной библиотеке:

Вся координация потоков спрятана внутри реализации очереди, и явных блокировок в коде не остаётся вовсе. Метод put останавливает производителя при переполнении, и это и есть обратное давление, ради которого затевалась ограниченная ёмкость.

Уровень второй: передача сообщений вместо общей памяти

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

Ключевое слово go перед вызовом запускает функцию конкурентно. Правда, у примера выше есть подвох: когда main завершается, программа выходит целиком, и горутина может не успеть отработать. Дожидаться её нужно явно:

Где здесь, собственно, очередь

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

Поведение совпадает с блокирующей очередью один в один: отправка встаёт при переполнении, приём встаёт на пустом канале. Разница в акценте. В Java вы защищаете общий буфер, в Go передаёте значение из одной горутины в другую, и владение данными переходит вместе с ним.

Почему это не просто потоки с коротким именем

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

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

Уровень третий: очередь без блокировок

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

Три гарантии прогресса

Obstruction-free. Операция завершится, если в какой-то момент ей дадут поработать без помех со стороны других потоков. При непрерывных помехах прогресс не гарантирован вообще. Самая слабая из трёх гарантий.

Lock-free. Гарантирует прогресс системы в целом: даже если один поток застрял, какой-то другой обязательно завершит свою операцию. Отдельный поток при этом может голодать сколь угодно долго, но система не встаёт целиком.

Wait-free. Каждая операция завершается за ограниченное число шагов независимо от того, что делают остальные потоки. Ключевая формулировка здесь именно «ограниченное число шагов», а не «обычно быстро», «не использует блокировок» или «работает на атомарных операциях». Это формальное свойство, а не характеристика скорости.

Два неравенства, которые стоит запомнить:
Отсутствие блокировок не равно wait-free. Использование атомарных операций тоже не равно wait-free.

Почему мьютекса недостаточно

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

Атомарность и упорядочивание — разные вещи

Процессор гарантирует, что атомарная операция неделима. Этого мало: нужно ещё, чтобы потребитель увидел записи, сделанные производителем до публикации флага. За это отвечает модель упорядочивания памяти.

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

Кольцевой буфер и номера последовательности

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

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

Тип UnsafeCell здесь означает ровно то, что написано на упаковке: обращаться к значению можно только из блока unsafe, компилятор проверку прекращает, и инвариант «в конкретный момент со слотом работает один поток» держится на номере последовательности, а не на системе типов.

Тип MaybeUninit здесь не для красоты: при ёмкости в 1024 элемента нужны 1024 места под значения, а не 1024 сконструированных объекта. Производитель получает уникальную позицию одним атомарным инкрементом, и никакого соревнования за неё не возникает:

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

Где заканчивается честность в названиях

Неприятная правда, которую стоит знать до выбора библиотеки: многое из того, что продаётся как wait-free очередь, на деле является lock-free. Причина в устройстве ядра алгоритма:

Операция обычно завершается быстро, но верхней границы на число неудачных попыток здесь нет, а именно она и определяет wait-free. И да, ровно такой цикл вы только что видели в нашей собственной очереди: строго говоря, на этом шаге она тоже lock-free, а не wait-free, и автор исходного разбора это прямо оговаривает. Строгая реализация требует ограниченной стратегии резервирования или механизма помощи: когда поток B встречает незавершённую операцию потока A, он не ждёт возвращения A, а доводит его операцию до конца сам. Так прогресс перестаёт зависеть от того, что планировщик сделал с конкретным потоком.

Какой уровень выбрать

Правило простое и почти всегда работает от обратного.

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

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

Что забрать с собой

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

Материалы разбора: задача о ресторанной кухне на Java, введение в горутины и модель конкурентности Go и построение wait-free очереди на Rust.

Если в вашем коде есть класс, где потоки координируются через ручные ожидания и уведомления, у вас уже есть кандидат на замену стандартной очередью. Начните с него.

Для тех, кто уже пользуется jj, это закрывает самую неприятную бытовую проблему инструмента, а два ломающих изменения в том же релизе стоит проверить сразу после обновления: команды jj config с флагом --user больше не спрашивают, какой файл править, а jj git import перестал подтягивать коммиты из отсоединённого HEAD в репозиториях без совмещения с Git. Предыдущая версия 0.44.0 выходила 6 августа, релизы у проекта идут примерно раз в месяц.

• jj converge заменяет две и больше видимых ревизии одного change ID одним коммитом; потомки перебазируются на решение, локальные закладки переезжают сами.
• Если эвристики не уверены, команда задаёт вопросы: слить описания, выбрать родителей, редко выбрать автора; в режиме --no-interactive операция прерывается, если нужен вопрос пользователю.
• Ломающее: jj config edit/set/unset --user теперь правит первый загруженный пользовательский конфиг, для точного выбора файла добавлен --file ПУТЬ.
• Ломающее: jj git import в неколоцированных репозиториях больше не импортирует коммиты с отсоединённого Git HEAD.
• Git HEAD теперь хранится отдельно для каждого worktree, существующие репозитории мигрируют автоматически; исправлен баг с duplicateEntries в git fsck после git add.

Откуда в jj берутся расходящиеся коммиты

В jj у каждого изменения есть постоянный change ID, который переживает перезапись коммита: можно поправить старый коммит в середине стека, и потомки перебазируются автоматически. Расхождение, или divergence, возникает, когда одно и то же изменение оказалось переписано дважды по разным веткам истории операций. Типичный сценарий: правка в двух рабочих пространствах, откат через jj undo после того, как часть работы уже ушла дальше, или неудачный конфликт при синхронизации с удалённым Git-репозиторием. В логе это выглядит как два коммита с одинаковым change ID, и до 0.45 их приходилось сводить руками через jj abandon, jj squash и jj rebase.

Что делает jj converge на самом деле

По описанию команды в исходниках, jj converge берёт ревизии из аргумента --revisions или из настройки revsets.converge, группирует их по change ID и считает расходящимися те группы, где ревизий больше одной. Если расходящихся изменений несколько, команда спросит, какое сводить. Дальше она применяет эвристики, чтобы собрать новую ревизию, а если те дали неоднозначный результат, задаёт вопросы: объединить ли описания, каких родителей выбрать и, в редких случаях, кого считать автором.

Когда решение найдено, новая ревизия заменяет расходящиеся, потомки перебазируются на неё, а локальные закладки, указывавшие на любую из старых версий, переезжают на новую. Два ограничения авторы оговаривают прямо. Во-первых, сводятся только ревизии, попавшие в revset: если у того же change ID есть видимые версии вне выборки, расхождение уменьшится, но не исчезнет. Во-вторых, в результате могут появиться файловые конфликты, даже если до этого их не было. Проверить, что именно сделала команда, можно через jj op show -p, посмотреть историю изменения через jj evolog, а откатить всё одним jj undo.

Режим --no-interactive нужен для скриптов и хуков: если без вопроса не обойтись, команда не зависнет в ожидании ввода, а прервётся с предупреждением.

Что сломается после обновления

Первое ломающее изменение касается конфигов. Раньше jj config edit --user, set --user и unset --user при нескольких пользовательских файлах, например ~/.config/jj/config.toml плюс каталог conf.d/, спрашивали, какой файл править. Теперь они молча берут первый загруженный. Если у вас конфиг разложен по нескольким файлам, нужный указывается явно:

Второе касается репозиториев, где jj живёт рядом с Git, но не в колоцированном режиме, то есть .jj и .git не делят один рабочий каталог. jj git import в них больше не импортирует коммиты с отсоединённого Git HEAD. Если рабочий процесс опирался на то, что jj подхватит коммит, сделанный в Git в состоянии detached HEAD, теперь такой коммит нужно закрепить веткой или тегом на стороне Git.

Внутреннее изменение, которое тоже стоит знать: состояние Git HEAD теперь хранится отдельно для каждого worktree. Это подготовка к поддержке нескольких Git worktree в колоцированных репозиториях, когда у каждого рабочего пространства jj свой HEAD. Существующие репозитории мигрируют автоматически при первом запуске новой версии.

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

• В колоцированных репозиториях git add после команды jj больше не оставляет в индексе устаревший cache-tree, из-за которого git fsck ругался на duplicateEntries. Уже испорченные репозитории исправление не лечит.
• Ctrl+C в пейджере less теперь выходит чисто: во флаги по умолчанию добавили -K, раньше терминал мог остаться в raw-режиме с мусором из escape-последовательностей.
• Сторона конфликта, оканчивающаяся на символ возврата каретки, больше не теряет этот байт при повторном разборе материализованного конфликта.
• jj run останавливается на первой ревизии, где процесс завершился с ненулевым кодом, вместо того чтобы идти дальше.
• Набор immutable_heads() по умолчанию теперь включает untracked_remote_tags(); jj bisect предупреждает, когда из-за пропусков не может однозначно назвать первую плохую ревизию; починен краш jj log на скрытых ревизиях с revset log-graph-prioritize.

Как обновиться

Готовые сборки для Windows, macOS и Linux лежат на странице релиза, вариант с musl должен работать на любом дистрибутиве. По документации установить последний релиз можно так:

Кому обновление ничего не изменит: тем, кто держит jj в одном файле конфига и работает только в колоцированных репозиториях. Им достанется jj converge и исправления, а ломающие изменения не затронут. Следующий сигнал, за которым стоит следить, это планируемая поддержка нескольких Git worktree, под которую в 0.45 подготовили хранение HEAD.

Источники: Релиз jj v0.45.0 на GitHub, Документация: установка и настройка jj 0.45, Исходник команды converge (описание в cli/src/commands/converge.rs)

Изображение на обложке: Логотип: J. Jennings, CC BY 4.0

Практический интерес здесь не в самом Plush, минималистичном динамическом языке на Rust, а в измеренном ответе на старый вопрос: сколько стоит стековая модель байткода. Вывод автора сформулирован жёстко: «вам, вероятно, не стоит писать стековые байткод-интерпретаторы в 2026 году» (перевод редакции). Для тех, кто пишет свои DSL, скриптовые движки или встраиваемые интерпретаторы, это готовый аргумент с цифрами и с честным списком того, что не ускорилось.

• Медианное ускорение 2,07 раза, максимальное 3,37; геометрическое среднее 1,94 раза, из них 1,55 дала сама регистровая модель без оптимизаций, ещё 25% добавили специализированные инструкции.
• Инструкция теперь 64-битное слово вместо enum на 24 байта; трёхадресная форма reg(a) = reg(b) + reg(c), до 64 000 локальных переменных, 76 опкодов.
• Замеры: MacBook Air M5 (10 ядер, arm64), rustc 1.96.0, 11 чередующихся запусков на тест, медиана; повторный прогон дал те же результаты.
• Против Lua 5.5.1: быстрее на 24% в fib и на 55% в binary_tree; сравнение с CPython 3.14.6 и CRuby 4.0.6 автор ограничивает оговорками о разной семантике и составе тестов.
• Тесты сборщика мусора почти не изменились: регистровая модель ускоряет диспетчеризацию, а не аллокацию.

Почему стековая машина медленнее

В стековой VM выражение a + b превращается в три инструкции: положить a, положить b, сложить. Каждая инструкция проходит через диспетчер: прочитать опкод, перейти на обработчик, сдвинуть указатель. В регистровой VM то же выражение записывается одной инструкцией с тремя операндами: куда положить и что сложить. Главный тезис статьи: в интерпретаторе самый большой рычаг производительности это число инструкций, которые нужно продиспетчеризовать, и регистровая модель сокращает его в разы. Автор цитирует это как основной вывод: «снова, в интерпретаторе главный рычаг это уменьшение числа инструкций» (перевод редакции).

Второй эффект: значения не гоняются между локальными переменными и временным стеком. Локальные переменные и есть регистры фрейма, поэтому x = y + z не требует ни загрузки, ни сохранения.

Как устроен новый байткод

Старая инструкция была Rust-перечислением Insn размером 24 байта. Новая упакована в 64-битное слово: опкод и операнды-регистры. Для сравнения автор приводит Lua: там 32-битное слово с 8-битными полями, отсюда лимит в 255 регистров на фрейм и 200 именованных локальных переменных. У Plush поля шире, до 64 000 локальных переменных, ценой вдвое большего размера инструкции. Всего опкодов 76. Сверху добавлены оптимизации, каждая из которых убирает инструкции: слитые сравнение-и-переход, сдвиги и маски с непосредственными операндами, свёртка констант, устранение лишних пересылок. Инлайн-кэши вынесены в отдельные таблицы, чтобы не раздувать слово инструкции.

Замену enum на 64-битное слово автор описывала неделей раньше, тогда это дало 17% на старой стековой модели; нынешняя статья седьмая в серии о Plush.

Что показали замеры и где их границы

Методика описана подробно: MacBook Air M5, rustc 1.96.0, для каждого сравнения 11 чередующихся запусков старой и новой версии, берётся медиана, весь набор прогнан дважды. Сравнивались конкретные коммиты репозитория. Неоптимизированная регистровая VM дала 1,55 раза по геометрическому среднему, оптимизации добавили ещё 25%, итого 1,94; медиана по отдельным тестам 2,07, максимум 3,37. Тесты, упирающиеся в сборщик мусора, остались на месте: диспетчеризация там не узкое место.

Сравнение с другими языками автор сопровождает оговорками: CPython 3.14.6, CRuby 4.0.6 и Lua 5.5.1 имеют другую семантику, а набор тестов синтетический. Заявлены только два прямых результата против Lua: fib на 24% быстрее, binary_tree на 55%. Отдельная демонстрация: программный рендеринг уровня Quake в 800 на 600 в один поток, около 47 кадров в секунду, с живой кучей до 1 ГБ без заметных пауз GC по оценке автора.

Что из этого забрать в свой интерпретатор

• Если вы проектируете байткод с нуля, начинайте с регистровой модели: выигрыш от неё больше, чем от любой микрооптимизации диспетчера.
• Считайте инструкции, а не такты: слитые инструкции (сравнение плюс переход) и непосредственные операнды окупаются именно сокращением диспетчеризации.
• Не ждите ускорения там, где узкое место в аллокации: GC-тесты Plush не изменились.
• Готовые бинарники Plush есть для Linux и macOS (x86-64 и arm64) и через PowerShell-установщик для Windows x86-64; код под Apache-2.0, примеры под CC0, всё в репозитории.

Кому это не пригодится: тем, кто использует готовые рантаймы и не пишет свои. CPython, к слову, остаётся стековой машиной, и разница подходов хорошо видна на его фоне; о цене операций в самом Python мы недавно писали в связи с новой 3.15.0rc2. Другой свежий пример переписанного интерпретатора с подробным разбором каждой оптимизации: Wasmi 2.0, где тоже сменили промежуточное представление и получили 2,2 раза.

Источники: Pointers Gone Wild: Plush's New Register-Based Interpreter, Репозиторий Plush, Предыдущая статья серии: Replacing a Rust enum with a 64-bit word

Ошибка проявляется только там, где FMA эмулируется программно: на x86 это дешёвые или старые Intel без AVX2 и процессоры Hygon без аппаратного FMA, а также 32-битный ARM и старые встраиваемые тулчейны. 64-битный ARM, по словам автора, не затронут. На практике это касается детерминированных симуляций и численных библиотек, где одинаковый код обязан давать одинаковые биты на разных машинах: сетевые игры с lockstep, физические движки, воспроизводимые вычисления. Автор честно пишет, что не знает, насколько ошибка важна в реальных программах.

• Ошибка: неправильное округление fmaf на субнормальных входах, отличие на один младший бит.
• Затронуты f32::mul_add и std::simd в Rust, fmaf() в musl; проверка одна и та же: a = 0x97000800, b = 0x1cfff001, c = 0x00010002, верный ответ 0x00010001, ошибочный 0x00010002.
• Исправлены fearless_simd и ABI f128 в компиляторе Rust на 32-битном ARM; патч в стандартную библиотеку Rust на момент публикации ждал ревью, исправления musl не влиты.
• Аппаратный FMA (x86 с AVX2/FMA3, 64-битный ARM) не затронут: ошибка живёт в программной эмуляции.
• Контрпример к первой версии исправления в Rust нашла языковая модель, которую автор попросил искать ошибки.

Что такое FMA и откуда берётся лишний бит

Fused multiply-add вычисляет a*b+c с одним округлением в конце вместо двух: после умножения и после сложения. Так требует IEEE 754, и именно на это рассчитывают численные алгоритмы: одно округление даёт предсказуемую ошибку. Когда у процессора нет аппаратной инструкции, библиотека эмулирует FMA через операции с расширенной точностью и ручную коррекцию округления. Ошибка, которую нашёл автор, живёт в этой коррекции на субнормальных числах, то есть очень маленьких значениях, у которых часть мантиссы уже ушла в ноль. В таких случаях программная реализация округляла не в ту сторону.

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

Как проверить свою платформу

Достаточно трёх чисел. Ниже проверка на C для fmaf из системной libc; в Rust то же самое делается через f32::from_bits и mul_add:

Если вывод 00010002, ваша libc или тулчейн эмулируют FMA с ошибкой. На машине с аппаратным FMA (любой современный x86 с AVX2, 64-битный ARM) результат будет верным независимо от библиотеки, поэтому проверять имеет смысл именно сборки под старое или встраиваемое железо и контейнеры на musl (Alpine) на таких хостах.

Состояние исправлений

• fearless_simd: исправлено, можно использовать как реализацию FMA без этой ошибки.
• Rust, тип f128 на 32-битном ARM: ошибка ABI исправлена в компиляторе (тип доступен только в nightly).
• Стандартная библиотека Rust (f32::mul_add, std::simd): патч на момент публикации ожидал ревью; номер версии с исправлением не назван.
• musl: предложены минимальное исправление и полная переработка fmaf(), ни то ни другое не влито. Автор отмечает, что код FreeBSD, откуда растёт реализация, мог копироваться и в другие тулчейны.

Кому это ничего не меняет: сервисам на современных x86 и ARM64, где FMA аппаратный, и коду, не зависящему от битовой точности. Кому стоит проверить: авторам физических движков и симуляций с детерминизмом между машинами, разработчикам под 32-битный ARM и тем, кто собирает статические бинарники под musl для старых серверов. Про то, как выбор libc влияет на скорость тех же бинарников, мы писали на примере Rust Coreutils; смежная тема из этой же недели: переписывание линкера mold на Rust. Что мы проверим дальше: когда патч попадёт в стабильный Rust и появится ли исправление в релизе musl.

Источники: Shnatsel: Implementing FMA and finding bugs in C and Rust standard libraries, Обсуждение на Lobsters

Для тех, кто гоняет Polars в пайплайнах, это значит два дела на сегодня. Во-первых, после обновления часть запросов может вернуть строки в другом порядке: потоковый движок не гарантирует порядок для join, group_by и unpivot, если явно не попросить. Во-вторых, код, который годами «работал» на неявных приведениях типов и молчаливом заполнении пропусков, начнёт падать с ошибкой. Разработчики называют это осознанной политикой: ошибка сразу лучше неверного результата через двадцать минут работы пайплайна.

• RC ставится командой pip install polars==2.0rc1; финальный 2.0 выйдет в ближайшие недели, точной даты нет.
• LazyFrame.collect() по умолчанию идёт через streaming-движок; по ожиданиям авторов, в совокупности он «легко в 5 раз быстрее» старого in-memory и заметно экономит память; независимых замеров RC нет.
• Порядок строк после join, group_by и unpivot больше не гарантирован; для join и group_by порядок возвращает параметр maintain_order, для unpivot нужен явный sort; старый движок включается через pl.Config.set_engine_affinity("in-memory") или collect(engine="in-memory").
• is_in с разными типами, горизонтальный concat с разной высотой, касты строк в даты и целых в Enum теперь бросают исключение вместо тихого приведения.
• Большинство удалённых методов и параметров отвечают типизированными ошибками AttributeRemovedError и ArgumentRemovedError с подсказкой, чем заменить.

Почему потоковый движок потребовал мажорной версии

Polars давно развивает два движка. Классический in-memory собирает результат каждой операции целиком в памяти. Потоковый разбивает данные на куски и прогоняет их через план запроса конвейером, поэтому промежуточные результаты не раздуваются. До 2.0 потоковый движок нужно было включать явно; теперь режим engine="auto" выбирает именно его.

Цена такого дефолта в порядке строк: потоковый движок для ряда операций его не гарантирует. Старый движок порядок сохранял, и на это молча полагалось много кода: например, брали первую строку после группировки и считали её «самой ранней». В 2.0 такие места нужно найти и явно попросить порядок (у join и group_by есть параметр maintain_order, после unpivot остаётся явный sort):

Заявление о скорости стоит читать как оценку вендора: «в сумме мы ожидаем, что потоковый движок будет легко в 5 раз быстрее», со ссылкой на собственные бенчмарки Polars. Независимых замеров на RC пока нет, и выигрыш зависит от запроса: на маленьких таблицах, которые целиком помещаются в кеш, разница будет меньше, чем на группировках по десяткам гигабайт.

Где код перестанет молчать об ошибках

Вторая тема релиза сформулирована в посте так: ошибки должны подниматься заранее, а не через 20 минут работы пайплайна, и неявное поведение при несовпадении данных должно включаться явно, а не быть дефолтом. Авторы отдельно отмечают, что строгость стала ценнее с приходом ИИ-агентов: агент может вызвать collect_schema(), проверить типы без чтения данных и быстро получить обратную связь. Примеры из поста и руководства по миграции:

• is_in с разными типами. Раньше Int64 и Float64 приводились к общему супертипу, даже если это теряло точность. В примере из поста идентификатор 9007199254740993 при касте в float64 округлялся до 9007199254740992 (граница, до которой float64 представляет все целые точно), и проверка по списку «помеченных» аккаунтов давала ложное совпадение. В 2.0 это InvalidOperationError: кастовать нужно самому и осознанно.
• Горизонтальный concat. Таблицы высотой 5 и 4 раньше склеивались, а недостающая ячейка молча становилась null; типичный сценарий из поста: тихо упавшая задача за один из дней. Теперь ShapeError, а старое поведение включается через how="horizontal_extend".
• Касты заменены специализированными методами. Целые в Enum или Categorical и обратно: вместо cast() нужны .cat.to() и .cat.physical(). Строка в дату: вместо cast(pl.Date) методы .str.to_date() и .str.to_datetime(), которым можно явно задать формат. Кастовать плоскую колонку в List через cast(pl.List(...)) тоже нельзя, для этого есть pl.list().
• Булевы операторы между Boolean и целыми числами теперь ошибка; std() и var() для Duration удалены, сначала переводите в микросекунды через .dt.total_microseconds().
• Каст между Struct с разным числом полей при strict=True (дефолт) падает, а не обрезает лишние поля; руководство помечает это отдельным предупреждением, потому что раньше данные терялись молча.

Отдельный набор изменений касается чтения CSV. При сканировании набора файлов схема теперь выводится по первым 10 файлам, а не по всем (параметр infer_schema_files). Автоматические имена колонок для файлов без заголовка начинаются с column_0, а не column_1; это же касается read_excel и read_ods. Пользовательская схема в scan_csv сопоставляется с файлом по именам колонок, а не по позиции: раньше первая запись схемы молча получала данные первой колонки файла, даже если имена не совпадали. Для лишних и недостающих колонок появились параметры extra_columns и missing_columns, по умолчанию оба бросают ошибку.

Что будет со старым кодом

Для большинства удалений библиотека получила два типизированных исключения (документация предупреждает, что часть удалённого по-прежнему даёт обычные AttributeError и TypeError): polars.exceptions.AttributeRemovedError для удалённых методов и атрибутов и polars.exceptions.ArgumentRemovedError для удалённых параметров. Оба сообщения указывают на замену:

По словам Винка, большая часть удалённого давно помечена как deprecated, и у тех, кто обновлялся регулярно, пайплайны пострадать не должны. Команда просит сообщать, если из библиотеки убрали что-то, на что реально полагались. Смена движка не затрагивает eager-API DataFrame: выигрыша в скорости там не будет, потому что дефолт меняется только у LazyFrame. Остальные несовместимости на eager распространяются полностью: строгий concat, новые правила read_csv, убранные касты и удалённые методы.

Как проверить свой проект до финального релиза

1. Поставьте RC в отдельное окружение: pip install polars==2.0rc1. В прод его тащить рано, это кандидат в релиз.
2. Прогоните тесты и посмотрите на исключения AttributeRemovedError, ArgumentRemovedError, InvalidOperationError и ShapeError: каждое сообщение содержит подсказку с заменой.
3. Найдите места, где код полагается на порядок строк после join, group_by или unpivot: сортировки «по умолчанию», head(1) после группировки, сравнение с эталоном по позициям. Добавьте maintain_order (join, group_by) или явный sort (unpivot).
4. Если результат обязан совпадать со старым до байта, зафиксируйте старый движок на время миграции: pl.Config.set_engine_affinity("in-memory").
5. Проверьте чтение CSV без заголовка (сдвиг нумерации колонок на единицу) и scan_csv с явной схемой (сопоставление по именам).

В планах ветки 2.x, о которых команда, по её словам, «недостаточно говорила публично»: полноценная out-of-core обработка для потокового движка, новая архитектура IO-плагинов, собственный читатель S3, расширенное покрытие SQL, планировщик на основе оценки стоимости с переупорядочиванием join и отказ от mmap, после которого конвейер станет асинхронным от начала до конца. Сроков по этим пунктам нет. Замечания по RC команда принимает в issues на GitHub.

Источники: Pre-release of Polars 2.0 (блог Polars, Ritchie Vink), Руководство по переходу на Polars 2.0, Бенчмарки Polars

Изображение на обложке: Логотип: Polars

Для тех, кто пользуется обычными GNU Coreutils, ничего не меняется, пока дистрибутив не переключится сам. Но тенденция понятна: Ubuntu уже ставит Rust-реализацию по умолчанию, и вопрос «а чем это отличается» становится практическим. Ответ версии 0.11: сообщениями об ошибках, скоростью и очередным шагом к полной совместимости с GNU.

• Новый диагностический движок на библиотеке ariadne: подсказки с указателем в 28 утилитах.
• Переменная UUTILS_DIAG принимает always, never и auto; в скриптах и пайпах по умолчанию сохраняется однострочное сообщение.
• PGO-сборки для Linux, macOS и Windows дают до 31% прироста; cp ускорен на 32,93%, join в одном сценарии в 2,5 раза быстрее GNU.
• Совместимость с тестами GNU: 653 успешных, 22 неудачных, 10 пропущенных из 685; было 645 и 28.
• Исправлены TOCTOU-проблемы в mv, cp, rm и chmod; 358 pull request от 26 новых участников.

Как выглядит новая ошибка

Идея, описанная Сильвестром Ледрю в блоге проекта, проста: GNU-утилиты десятилетиями отвечали на опечатку сухой строкой вроде «invalid field specification», и пользователь сам искал, где именно ошибся. Теперь под командой печатается сама команда, а под ней каретка, указывающая на неверный символ, и короткое объяснение. Реализовано это на библиотеке ariadne, той же, что используют некоторые парсеры на Rust.

Важная деталь для тех, кто пишет скрипты: многострочная диагностика включается только в интерактивном терминале. В пайпах и при перенаправлении вывода по умолчанию остаётся привычное однострочное сообщение, поэтому парсеры stderr не сломаются. Управляет этим переменная окружения UUTILS_DIAG со значениями always, never и auto. Попробовать без установки можно в браузерной песочнице проекта.

Скорость: «медленнее GNU теперь считается багом»

Команда прямо формулирует новую политику: «утилита, которая значительно медленнее GNU, теперь считается багом» (перевод редакции). В релизе это подкреплено PGO-сборками для Linux, macOS и Windows, которые, по замерам проекта, дают до 31% прироста. Отдельно названы cp, ускоренный на 32,93%, и join, который в одном из сценариев работает в 2,5 раза быстрее GNU-версии. Это замеры самого проекта на его наборах; на других данных разница будет иной.

Совместимость с GNU

Таблица в релизе сравнивает результаты на тестовом наборе GNU Coreutils: в 0.10.0 было 645 успешных и 28 неудачных тестов из 683, в 0.11.0 стало 653 успешных, 22 неудачных и 10 пропущенных из 685. Оставшиеся расхождения касаются редких флагов и краевых случаев, но именно они всплывают в старых скриптах, поэтому перед заменой системных утилит стоит прогнать свои сценарии.

Из исправлений безопасности названы TOCTOU-проблемы, то есть гонки между проверкой и использованием файла, в mv, cp, rm и chmod; также закрыты зависания и переполнения. Реализации kill и uptime доработаны для Windows.

Как попробовать

Проект распространяется под лицензией MIT и рассчитан на Linux, Windows, Redox и Fuchsia. Самый безопасный способ познакомиться: поставить uutils рядом с системными утилитами, а не вместо них. По README проекта, сборка из исходников выполняется через cargo, а в ряде дистрибутивов пакет называется uutils-coreutils или rust-coreutils и ставит бинарники в отдельный каталог. Точные имена пакетов зависят от дистрибутива, поэтому проверять их стоит в его репозитории.

Если ваши скрипты парсят stderr утилит, оставьте UUTILS_DIAG в значении auto: тогда в неинтерактивном режиме формат ошибок не изменится.

В релиз вошли 358 pull request от 26 новых участников; всего в проекте отметились более 1000 контрибьюторов. Редакция проверит, как изменится таблица совместимости в 0.12.

Источники: Релиз 0.11.0 на GitHub, Блог uutils: новая диагностика ошибок

Изображение на обложке: uutils

Wasmi написан на Rust и рассчитан на сценарии, где нужен именно интерпретатор: плагины в приложениях, встраиваемые устройства, песочницы, смарт-контракты. Релиз опубликован на GitHub и crates.io; работа над ним заняла восемь месяцев.

• Wasmi 2.0 примерно в 2,2 раза быстрее Wasmi 1.0 по геометрическому среднему; замеры вендора на Apple M2 Pro, AMD EPYC 7763 и Intel Xeon Platinum 8370C.
• Появились четыре режима dispatch; indirect-threaded на 10–15% медленнее direct-threaded, но экономит память под IR.
• Новое промежуточное представление с аккумуляторными регистрами ireg, freg32 и freg64 и 64-битными ячейками стека.
• Fuel metering стал стабильным и привязан к входному Wasm-коду; появился deterministic profile и новый CLI.
• Включение SIMD больше не замедляет обычный код: в 1.0 это стоило около 8%, в 2.0 разница в пределах шума.

Откуда взялись 2,2 раза

Автор подробно разбирает три источника ускорения. Первый: режимы диспетчеризации инструкций. В 1.0 был один switch-loop, теперь их четыре: direct-threaded, indirect-threaded, switch-loop и call-loop. Режим auto-dispatch включён по умолчанию и выбирает threaded-код там, где компилятор и платформа это позволяют. Indirect-threaded вариант примерно на 10–15% медленнее direct-threaded, зато требует меньше памяти на промежуточное представление, что важно для микроконтроллеров.

Второй источник: новое промежуточное представление. В 1.0 операнды адресовались смещениями в стеке; в 2.0 появились аккумуляторные регистры ireg, freg32 и freg64, через которые проходит большая часть значений. Ячейки стека стали всегда 64-битными, а SIMD-значения занимают две соседние ячейки, поэтому поддержка SIMD больше не стоит производительности обычного кода.

Третий: структура CodeMap, в которой хранятся скомпилированные функции. Она стала append-only с раздельными buckets, поэтому вызов внутренней функции на горячем пути не требует ни одного lookup и не берёт блокировок. Доступ к данным экземпляра модуля, по бенчмарку count/globals, улучшился примерно на 35%; таблицы Wasm уменьшились в 2–4 раза за счёт 32-битных ссылок.

Как измеряли и с кем сравнивали

Замеры сделаны на проекте wasmi-benchmarks, который можно запустить самостоятельно, на трёх машинах: Apple M2 Pro, AMD EPYC 7763 и Intel Xeon Platinum 8370C. Кроме Wasmi 1.0 в сравнении участвовали интерпретаторы Wasm3, WAMR в режиме fast-interpreter, Wasmtime Pulley и Stitch. Это замер вендора: набор тестов, машины и конфигурации выбирал сам проект, и автор оговаривает, что цифры зависят от нагрузки.

В посте есть поучительный эпизод про компилятор. Rust 1.92 включил оптимизацию DestinationPropagation, из-за чего CoreMark у интерпретатора Stitch упал с более чем 3000 до примерно 2200 баллов; после исправления результат вернулся выше 3000. Похожая проблема нашлась и в Wasmi: её устранение подняло CoreMark примерно с 2800 до более чем 4200 баллов, то есть примерно на 50%. Вывод для практики: производительность интерпретатора на Rust заметно зависит от версии компилятора, и после обновления toolchain бенчмарки стоит перепрогонять.

Что изменилось кроме скорости

• Fuel metering, то есть учёт «топлива» на выполнение, стал стабильным и считается по входному Wasm-коду, а не по внутренним инструкциям; это важно для смарт-контрактов и лимитов на плагины.
• Deterministic profile гарантирует одинаковый результат на разных платформах.
• Поддержка memory64 стала опциональной; отключение валидации через feature validate уменьшает бинарник примерно на 200–300 КБ.
• Обновлённый CLI и C-API.

Кому обновление ничего не даст: тем, кто запускает Wasm через JIT-рантаймы вроде Wasmtime или V8 на сервере и в браузере. Интерпретатор нужен там, где JIT запрещён (iOS, некоторые блокчейн-среды), где нет памяти под скомпилированный код или где важна предсказуемость времени запуска.

Как попробовать

Wasmi ставится как обычный crate из crates.io; для Rust-проекта достаточно обновить зависимость wasmi до версии 2.0 и прогнать тесты: автор предупреждает о смене внутреннего представления, а значит, поведение при ошибках и лимитах стоит перепроверить. Проект открыт, спонсируется Stellar Development Foundation с октября 2024 года.

В планах на Wasmi 3.0 названы оставшиеся части WebAssembly 3.0: function-references, exception-handling и gc. Сроков автор не называет.

Источники: Блог Wasmi Labs: Wasmi v2.0, Релиз v2.0.0 на GitHub

Изображение на обложке: Wasmi Labs

Линкер склеивает скомпилированные объектные файлы в исполняемый файл, и на больших проектах это минуты ожидания при каждой пересборке. mold появился в 2021 году именно как ответ на это: по свежему бенчмарку автора он в 4,9 раза быстрее lld по медиане. Но проекты, которые собираются через сложные линкер-скрипты GNU ld, вроде ядра Linux, до сих пор были для него закрыты; 3.0 должна это изменить.

• mold переписывают на Rust; новая версия выйдет как mold 3.0, дата не названа.
• Цель: поддержка линкер-скриптов, чтобы mold собирал всё, что умеет GNU ld, включая ядра и прошивки.
• Текущий mold написан на C++20; по бенчмарку августа 2026 года он быстрее lld в 4,9 раза, а wild в 1,9 раза по медиане.
• Debug-сборка Chromium 145 на Threadripper 7980X: lld 16,64 с, wild 3,98 с, mold 1,65 с; TensorFlow 2.21: lld 50,73 с, mold 3,15 с.
• Текущий mold продолжает работать как замена ld и lld; включается флагом -fuse-ld=mold или через .cargo/config.toml.

Зачем линкеру скрипты

Линкер-скрипт описывает, как раскладывать секции кода и данных по адресам памяти. Обычному приложению это не нужно: там всё решает стандартная раскладка. Ядру, загрузчику или прошивке микроконтроллера критично, чтобы таблица прерываний лежала по конкретному адресу, а код инициализации попал в нужную область флеш-памяти. Всё это описывается на языке скриптов GNU ld, и до сих пор mold понимал лишь их малую часть: в собственной документации проект называет этот язык переусложнённым и ещё недавно прямо писал, что расширять поддержку не планирует.

Уэяма пишет, что цель новой версии — совместимость со всем, что умеет собирать GNU ld. Именно это открывает дорогу к тому, чтобы дистрибутивы Linux сделали mold линкером по умолчанию: пока хоть один важный пакет не собирается, менять умолчание никто не будет. Конкретных дистрибутивов с такими планами в README пока не названо.

We are rewriting the mold linker in Rust. This will be mold 3.0.

Насколько mold быстрее сегодня

Автор обновил бенчмарки в README репозитория в августе: девять крупных программ, медиана трёх запусков после прогрева, два стенда — Threadripper 7980X с 64 ядрами и Apple M1 Ultra, у которого использовались 16 производительных ядер. Сравнивались lld, wild (ещё один линкер на Rust) и mold. Результаты на Threadripper выглядят так.

На Chromium 145 lld тратит 16,64 секунды, wild 3,98, mold 1,65. На TensorFlow 2.21 разрыв ещё больше: 50,73 секунды у lld против 3,15 у mold. На Apple M1 Ultra картина ровнее: debug-сборка Clang 21 линкуется за 2,96 секунды у mold, 4,40 у lld и 2,78 у wild, то есть в этом тесте конкурент на Rust слегка впереди, хотя на большинстве остальных задач M1-стенда mold быстрее. Артефакты бенчмарка опубликованы на Zenodo, их можно повторить.

Почему Rust, если и так быстро

В сообщении Уэямы причин не названо. Из README видно другое: текущий mold требует GCC 10.2 или Clang 16 и написан на C++20, а конкурент wild с самого начала на Rust и на части задач уже догоняет. Переписывание с добавлением линкер-скриптов означает во многом новую кодовую базу, и выбор языка для неё делается один раз. Всё остальное — предположения, и мы их не делаем.

Как включить mold сегодня

Для C и C++ с GCC или Clang достаточно флага компоновки -fuse-ld=mold. Для Rust README предлагает настройку в .cargo/config.toml:

• Проекты с собственными линкер-скриптами (ядра, прошивки, загрузчики) пока остаются на GNU ld; ждите mold 3.0.
• Если пользуетесь wild, сравните на своём проекте: на M1 Ultra он выигрывает лишь в части тестов, по общей медиане бенчмарка mold быстрее в 1,9 раза.
• mold распространяется под лицензией MIT через GitHub и пакеты дистрибутивов; наличие пакета в репозиториях Astra Linux и РЕД ОС проверяйте отдельно, в README они не перечислены.

Что дальше

mold используется в проде с 2021 года, и текущая C++-версия никуда не денется до выхода 3.0. Следить стоит за двумя сигналами: появится ли в репозитории ветка на Rust с первыми тестами линкер-скриптов и объявит ли какой-нибудь дистрибутив о планах сделать mold линкером по умолчанию. Второе и будет настоящей новостью.

Источники: Сообщение Руи Уэямы в X, Репозиторий mold с бенчмарками

Изображение на обложке: Tproger по данным README mold

На конференции Open Source Summit India 2026 в Мумбаи Кроах-Хартман выступил с докладом «Rust and Linux: How the Rust Language is Going to Help Linux Succeed». В нём он признался, что поначалу относился к языку скептически и считал, что всё необходимое уже есть в C. Сейчас он считает иначе: Rust действительно делает программирование интереснее и безопаснее.

• Грег Кроах-Хартман назвал Rust постоянной частью Linux, а не временным экспериментом.
• По его оценке, около 80% уязвимостей ядра за последние 25 лет можно было бы поймать на этапе компиляции Rust.
• Linux получает около 13 CVE в день и почти 9 изменений в час на протяжении десяти лет и более.
• Binder — ключевой механизм IPC Android — уже имеет параллельную реализацию на Rust, а C-версия скоро уйдёт.
• Git и ряд других крупных проектов также движутся в сторону Rust.

От скептицизма к поддержке

Кроах-Хартман рассказал, что несколько лет назад друг советовал ему попробовать Rust, но он отмахнулся: C казался достаточным. Со временем он изменил мнение. «Он был прав. Я должен был сделать это тогда. Rust на самом деле весёлый. Он заставляет программирование быть весёлым», — сказал мейнтейнер.

Главное преимущество языка в ядерной разработке — владение и типизация, которые убирают массу мелких ошибок: непроверенные указатели, забытые разблокировки, неправильная очистка ресурсов. Именно такие баги, по словам Кроах-Хартмана, составляют большинство ежедневных CVE.

Масштаб проблемы

Linux развивается с огромной скоростью. Кроах-Хартман привёл цифры: ядро набирает примерно девять изменений в час уже больше десяти лет, а количество публично раскрываемых уязвимостей держится на уровне около 13 CVE в день. Большая часть из них — не сложные атаки, а простые ошибки в C-коде.

Я видел каждую CVE ядра за последние 25 лет. Думаю, 80% исчезли бы просто потому, что Rust поймал бы их.

Что уже меняется в ядре

Rust постепенно становится обязательным выбором для отдельных подсистем. Кроах-Хартман отметил, что новые драйверы некоторых подсистем будут приниматься только на Rust. Яркий пример — Binder, межпроцессный механизм Android, от которого зависят миллиарды устройств. В ядре уже существуют параллельные реализации Binder на C и Rust, и C-версия «скоро исчезнет».

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

Контекст:
Binder — это механизм межпроцессного взаимодействия (IPC) в Android. Он позволяет приложениям и системным сервисам безопасно обмениваться данными. Переписывание Binder на Rust напрямую влияет на безопасность и стабильность почти всех Android-устройств.

Выводы

Позиция Кроах-Хартмана — ещё один сигнал того, что Rust перешёл из разряда «перспективного языка» в разряд инфраструктурного инструмента. Если оценка в 80% CVE верна, массовый переход на Rust в ядре может существенно снизить количество исправлений безопасности и освободить время мейнтейнеров для сложных логических задач.

Источник: Slashdot.

Речь пойдёт не о сравнении синтаксиса в вакууме, а о бэкенд-сервисах: API, шлюзах, обработке событий, парсинге данных и всём, что работает под нагрузкой. В статье — авторский взгляд на материал блога инженера Pooya Golchian, дополненный российским контекстом и поправками на реальное состояние экосистем.

Go остаётся стандартным выбором для большинства микросервисов: быстрая компиляция, простота найма, огромная экосистема.

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

Zig подходит для узких, критичных к производительности участков и для интеграции с существующим C-кодом, но экосистема пока незрелая.

В больших системах работает гибридный подход: Go для скорости разработки, Rust/Zig для горячих путей.

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

Почему именно эти три языка

В 2026 году для нового backend-проекта по-прежнему можно взять Java, C#, Python или Node.js. Но если речь заходит о высоких нагрузках, низкой задержке и контроле над ресурсами, внимание смещается к трём игрокам.

• Rust — язык с владением и заимствованием, дающий безопасность памяти без сборщика мусора.
• Go — язык с простой моделью конкурентности, статической линковкой и минималистичной философией.
• Zig — язык в духе C, но с современной системой сборки, comptime и явным управлением памятью.

Все трое компилируются в нативный код, дают один бинарник на выходе и не требуют виртуальной машины. Именно это отличает их от Java, C# и Python на старте.

Rust: максимум производительности, максимум сложности

Сильные стороны

• Безопасность памяти на этапе компиляции — нет use-after-free, data races и большинства утечек.
• Нулевая стоимость абстракций: высокоуровневый код часто компилируется так же эффективно, как ручной C.
• Мощная модель конкурентности поверх tokio или async-std.
• Зрелая экосистема: axum, actix-web, serde, sqlx.

Слабые стороны

• Крутая кривая обучения: borrow checker требует перестройки мышления.
• Долгая компиляция: полная пересборка крупного проекта занимает десятки секунд и минуты.
• Меньше кадров на рынке, чем у Go или Java.
• Итерации медленнее: каждая ошибка компилятора — это время на переделку.

Когда выбирать Rust

Rust логичен, если вы строите инфраструктуру — прокси, базы данных, очереди, edge-сервисы — или если профилирование показывает, что горячий путь съедает CPU и память. Примеры из продакшена: Cloudflare использует Rust на edge, Discord переписал на Rust часть read-path сервисов.

Go: скорость разработки в масштабе

Сильные стороны

• Компиляция за секунды и один статический бинарник для деплоя.
• Встроенные горутины и каналы — простая, но мощная конкурентность.
• Отличная стандартная библиотека и быстрое тестирование через go test.
• Большая база инженеров и проверенные практики в крупных компаниях.

Слабые стороны

• Сборщик мусора может давать всплески задержек, хотя в последних версиях паузы сокращаются.
• Меньше контроля над расположением памяти и размером структур.
• Пиковая пропускная способность ниже, чем у Rust и Zig, на CPU-bound задачах.
• Система типов и обработка ошибок минималистичны — кому-то этого достаточно, кому-то не хватает.

Когда выбирать Go

Go — выбор по умолчанию для команд из 5–50 человек, которым нужно быстро запускать CRUD-сервисы, API-шлюзы и data pipeline. Uber, Google и Яндекс активно используют Go в микросервисах. Если главная метрика — time to market, а не последний процент производительности, Go обычно выигрывает.

Zig: новый игрок с C-душой

Сильные стороны

• Производительность уровня C с более современным синтаксисом и системой сборки.
• comptime — выполнение кода на этапе компиляции для генерации оптимизированных структур.
• Прямое взаимодействие с C без FFI-слоёв.
• Маленькие быстрые бинарники и явное управление памятью.

Слабые стороны

• Экосистема backend-фреймворков и библиотек пока существенно меньше, чем у Rust и Go.
• Сообщество и количество инженеров на рынке ограничены.
• Ручное управление памятью перекладывает ответственность на разработчика.
• Некоторые части языка и стандартной библиотеки всё ещё эволюционируют.

Когда выбирать Zig

Zig хорош, когда нужна C-производительность, но с более удобным инструментарием, или когда приходится интегрироваться с существующим C-кодом. Пример из продакшена: финансовая база данных TigerBeetle написана на Zig. Для универсального backend в 2026 году Zig ещё рано называть mainstream-выбором.

Сравнение в цифрах

Ниже — иллюстративные цифры из оригинального материала, полученные на AWS c7g.2xlarge (Graviton3). Относитесь к ним как к точке отсчёта, а не как к гарантии для вашего сервиса: в реальности большее значение имеют I/O, запросы к базе данных и сетевая задержка.

Бенчмарки:
HTTP throughput — Rust 892K req/s, Go 734K req/s, Zig 812K req/s.
JSON-сериализация — Rust 1,2M/s, Go 890K/s, Zig 1,1M/s.
Память на 10K соединений — Rust 45MB, Go 78MB, Zig 38MB.
Размер бинарника — Rust 8,2MB, Go 12,4MB, Zig 6,1MB.
Время компиляции с нуля — Rust 42s, Go 3,2s, Zig 18s.
P99 latency — Rust 2,1ms, Go 3,8ms, Zig 2,4ms.

Реальные истории миграции

Discord: Go → Rust

Discord переводил read-path сервисы с Go на Rust из-за пауз сборщика мусора, которые проявлялись в хвостовых задержках. По данным компании, throughput вырос в несколько раз, а tail latency снизилась. Ключевой вывод: мигрировать стоит только горячие пути, а не весь сервис целиком.

Uber: Python → Go

Uber мигрировал часть микросервисов с Python на Go, чтобы обойти ограничения GIL и упростить масштабирование. Переход занял годы, но зато проходил постепенно: Go-совместимость и простота языка позволяли быстро обучать команду.

TigerBeetle: C++ → Zig

TigerBeetle — финансовая база данных, ориентированная на корректность и производительность. Команда выбрала Zig, отказавшись от сложности C++ и сборщика мусора. comptime позволил генерировать специализированные структуры данных под задачу.

Гибридная архитектура

На практике редко выбирают один язык на весь проект. Гораздо чаще используют гибрид:

• API Gateway и CRUD — Go: быстро писать, просто деплоить, легко искать людей.
• Горячие пути — Rust: низкая задержка и контроль над памятью.
• Специализированные компоненты — Zig: парсинг бинарных форматов, криптография, интеграция с C.

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

Что выбрать в 2026 году

Выбор зависит от приоритетов команды и задачи:

• Нужна скорость разработки и лёгкий найм — Go.
• Нужна максимальная производительность и безопасность памяти — Rust.
• Нужна C-производительность с современной сборкой и интеграцией с legacy на C — Zig.
• Команда маленькая и сроки горят — начинайте с Go, профилируйте, мигрируйте горячие пути при необходимости.
• Строите базу данных, прокси или edge — Rust становится очень сильным кандидатом.

FAQ

Выводы

Rust, Go и Zig — не конкуренты в прямом смысле, а инструменты для разных условий. Go задаёт темп разработки, Rust отвечает за надёжность и производительность, Zig покрывает специализированные ниши. Лучшая стратегия для 2026 года — начать с Go, измерять, а затем точечно внедрять Rust или Zig там, где данные это оправдывают.

Нет универсального лучшего языка — есть лучший язык для конкретной команды, задачи и бюджета на обучение.

Источник: Pooya Golchian — Rust vs Go vs Zig: High-Performance Backend Services in 2026.

Тема получила новый импульс после серии публикаций Диона Доктера (Dion Dokter) из голландской компании Tweede golf. Во второй части он заглядывает внутрь rustc и утверждает: async Rust так и не вышел из состояния MVP. Я не буду дословно переводить его рассуждения, а переосмыслю их с упором на практику: как понять, платите ли вы за async-удобство лишними байтами, и как снизить налог, пока компилятор не научился делать это сам.

• Асинхронный Rust компилируется в state machine: на каждую await-точку приходится отдельное состояние плюс служебные Unresumed, Returned и Panicked.
• Простая функция с двумя await-точками даёт 360 строк MIR против 23 у синхронного кода. Часть излишков LLVM убирает, но не все, особенно при оптимизации по размеру.
• Компилятор не схлопывает идентичные состояния, не инлайнит futures через await, генерирует state machine даже для async-блоков без await и оставляет panic-путь в состоянии Returned.
• В release-сборках замена panic в Returned на возврат Pending может сократить прошивку на 2–5%. Убирание state machine у пустых async-блоков — ещё около 0,2%.
• Пока rustc не исправлен, можно вручную: возвращать impl Future из «прозрачных» функций, использовать std::future::ready, схлопывать await-точки через match и передавать большие данные по ссылке.

Почему async-функция — это всегда state machine

Когда вы пишете async fn, компилятор не просто оборачивает тело в callback. Он строит конечный автомат: enum, где каждый вариант — состояние между await-точками. Это называется coroutine desugaring и происходит на уровне MIR (Mid-level IR) — до того, как код попадает в LLVM.

Рассмотрим минимальный пример. Есть две функции, каждая из которых просто возвращает число, и третья складывает результаты:

У bar две await-точки, поэтому минимум два пользовательских состояния. Но если сдампить MIR после прохода coroutine_resume, картина шире:

Три служебных состояния добавляются всегда. Они нужны, чтобы соблюсти контракт Future::poll: опрос завершённой future не должен приводить к неопределённому поведению. Поэтому после первого Ready future переходит в Returned, а повторный poll паникует. Аналогично Panicked блокирует future после пойманного panic — похоже на poisoning мьютекса.

Логика корректная, но цена высокая: bar порождает 360 строк MIR, а эквивалентный синхронный код — 23. В 15 с лишним раз больше. LLVM часть этого выбросит, но на opt-level = "z" или в толстых async-графах вызовов он быстро сдаётся.

Четыре места, где компилятор работает вхолостую

1. Panic в состоянии Returned

Контракт future требует только отсутствия UB. Паниковать при повторном poll — не обязательно. Можно просто вернуть Pending снова: ничего опасного не произойдёт, а ветка panic — это лишний побочный эффект, который плохо оптимизируется.

Дион сделал экспериментальный патч rustc: в release-режиме Returned больше не паникует. На embedded-прошивках это дало 2–5% экономии бинарного размера. В debug-сборках панику можно оставить, чтобы быстро ловить ошибочный повторный poll, — по аналогии с overflow-checks.

2. State machine без await

Взгляните на функцию без единой await-точки:

Идеальная реализация — всегда возвращать Poll::Ready(5) безо всякого enum. А rustc генерирует полноценный CoroutineLayout с тремя служебными состояниями и switch по дискриминанту. Такие функции часто появляются в трейтах, где один интерфейс должен быть async, но конкретная реализация ничего не ждёт. Патч, убирающий state machine у async-блоков без await, даёт ещё 0,2% размера — мало, но правка тривиальная.

3. Futures не инлайнятся через await

Классический шаблон: адаптер просто пересылает вызов вниз.

Сейчас bar получает собственный state machine, который вызывает state machine foo. Вручную мы бы написали fn bar(blah) -> impl Future { foo(blah) } и избавились бы от лишнего enum. Аналогично с преамбулой и постамбулой: их можно перенести на FutureExt::map из крейта futures.

4. Одинаковые состояния не схлопываются

Если в async-функции несколько веток match ведут к одинаковому await, компилятор создаёт отдельное состояние на каждую ветку:

Здесь send_response вызывается с разными аргументами, но структура состояний дублируется. Если вынести выбор аргумента за await, получится одно состояние вместо двух:

В одном примере из статьи MIR сокращается с 456 до 302 строк, а ассемблер — примерно на 11%. Оптимизации stack, поэтому выигрыш в реальном коде может быть заметнее.

Что делать сегодня, не дожидаясь rustc

Всё перечисленное выше — это работа для команды компилятора. Но релиз с этими патчами может занять месяцы, а то и годы. Пока он не вышел, можно снизить async-bloat в своём коде.

Главный принцип: каждый лишний async fn — это лишний state machine. Если функция не содержит await, не делайте её async.

Заменяйте async-пустышки на impl Future

Типичный случай — трейт, где одна реализация реально ждёт ввода-вывода, а другая просто возвращает значение.

Вместо полноценного state machine получается готовая future, которая сразу возвращает Ready. Это особенно полезно в embedded-HAL, где трейты часто async, но конкретный драйвер может делать только прямой доступ к регистрам.

Прозрачные обёртки без await

Если функция только пересылает await вниз, уберите await:

Схлопывайте await-точки

Если несколько веток match заканчиваются одним и тем же await, вынесите выбор аргументов наружу. Это уменьшает число состояний state machine и облегчает жизнь LLVM.

Передавайте большие данные по ссылке

Async-функция захватывает в state machine всё, что живёт через await. Если передать массив по значению, он окажется внутри future целиком:

Разница в 52 раза по размеру future — и это без учёта memcpy, который компилятор вынужден вставлять при перемещении больших значений.

Перспективы: Project Goal и финансирование

Дион оформил эти идеи как Rust Project Goal — формальный механизм, через который команды заявляют цели на полугодие. По его оценке, работа требует порядка €30 000 финансирования. Для компиляторного проекта это скромная сумма: речь идёт о 2–5% размера прошивки практически в любом async-проекте.

Есть и другой подход к той же проблеме: не убирать state machine на входе, а научить LLVM лучше их оптимизировать на выходе. Дион считает, что оба направления дополняют друг друга. Чем проще state machine попадает в LLVM, тем эффективнее её можно проинлайнить и упростить на поздних проходах.

Выводы

Async Rust never left the MVP state. The compiler generates state machines with a lot of unnecessary baggage. With a few targeted optimizations in rustc we can get smaller binaries and better performance for everyone.

Утверждение «async Rust так и не вышел из MVP» звучит резко, но поясняет, почему наши «zero-cost» абстракции иногда всё-таки стоят дорого. Компилятор делает корректный, но не оптимальный код: лишние panic-ветки, неинлайненные futures, дублирующиеся состояния и state machine там, где они не нужны.

Для embedded и WASM это не абстрактная проблема, а конкретные килобайты прошивки. Пока rustc учится, разработчик может снизить налог вручную: убирать async у функций без await, возвращать impl Future из прозрачных обёрток, схлопывать await-точки и не передавать большие структуры по значению.

Если ваш проект на Rust бьётся о лимит flash, имеет смысл посмотреть на async-граф вызовов свежим взглядом. Часто проще убрать одну лишнюю async-обёртку, чем месяцами ждать патч в компиляторе.

Источники:
— Dion Dokter, «Async Rust never left the MVP state»;
— Dion Dokter, «Debloat your async Rust»;
— Rust Project Goal: Async state machine optimisation.

Сервис Images, написанный на Rust и работающий в Workers, запущен на каждой машине в edge-сети Cloudflare. Чтобы обрабатывать клиентские соединения, мы используем hyper — открытую HTTP-библиотеку для Rust.

В прошлом году мы представили Images binding — он позволяет создавать кастомные программные сценарии обработки удалённых изображений в Workers. В конце 2025 года мы перестроили binding, чтобы сделать связь между Workers runtime и сервисом Images более прямой и локальной.

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

Мы потратили шесть недель на охоту за почти невидимым багом — состоянием гонки, которое проявлялось только при определённых условиях, — в библиотеке hyper, который влиял на то, как Images binding возвращает обработанные изображения клиенту. В итоге исправление заняло четыре строки кода.

Cloudflare Images binding перешёл на прямое локальное соединение через Unix-сокеты в декабре 2025 года.

После выкатки большие изображения стали иногда возвращаться обрезанными: HTTP 200, но тело ответа короче Content-Length.

Причина — состояние гонки в hyper: цикл poll_loop отбрасывал результат poll_flush, даже если тот возвращал Poll::Pending.

Баг существовал в hyper 0.14.x, 1.7 и 1.8; прежний посредник FL читал данные достаточно быстро, чтобы он не проявлялся.

Исправление заняло четыре строки кода: flush теперь выполняется перед shutdown.

Прыжки, передачи и hyper

Когда разработчики создают приложения на Cloudflare, они собирают full-stack приложения из набора платформенных сервисов, доступных Workers через bindings. Bindings предоставляют прямые API к ресурсам Developer Platform: вычислениям, хранилищам, ИИ-инференсу и обработке медиа.

Images binding отделяет оптимизацию изображений от доставки: вы можете транскодировать, компоновать или изменять изображения, не возвращая результат в виде HTTP-ответа. Также он позволяет применять параметры оптимизации в любом порядке, а не в фиксированной последовательности, которую навязывает URL-интерфейс. Вот пример: воркер передаёт данные изображения напрямую в Images API, объединяет операции в цепочку и получает обработанный результат в виде потока:

На высоком уровне так выглядит движение данных через наши сервисы:

Труба на схеме обозначает сокетное соединение между посредником и Images, через которое данные передаются от одного процесса к другому через буфер ядра.

Binding взаимодействует с Images через сокетное соединение, управляемое Workers runtime. Сокет — это канал связи между двумя процессами. У каждого конца сокета есть буферы, управляемые ядром операционной системы; эти буферы — временные области, где данные остаются после записи одной стороной, но до чтения другой.

Hyper управляет соединением на стороне сервиса Images: читает входящие запросы из сокета и пишет ответы обратно в него.

Когда запрос использует Images binding, сервис Images читает входные данные, выполняет запрошенные операции оптимизации и кодирует результат. Затем он передаёт всё закодированное изображение hyper как один непрерывный блок в памяти.

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

Если читатель на другом конце быстрый, hyper может сбросить всё за один проход — в исходящем буфере будет место, потому что читатель потребляет данные по мере поступления. Как только все данные отправлены, hyper вызывает shutdown на сокете, сигнализируя, что соединение завершено и больше данных записано не будет. Но если читатель медленнее (хотя бы на несколько миллисекунд), исходящий буфер заполняется, и hyper должен ждать, пока появится место, чтобы продолжить запись.

Локальное соединение

Весь входящий трафик в сети Cloudflare проходит через FL — внутренний сервис-посредник, который включает функции безопасности и производительности и маршрутизирует запросы к нужному бэкенду. Когда мы только запустили binding, данные изображений шли из Workers runtime через FL в сервис Images.

Этот путь хорошо подходил для первого релиза и повторял архитектуру URL-интерфейса. Но со временем связь с FL стала ограничением: любое изменение binding приходилось согласовывать с циклом релизов FL.

В декабре 2025 года команда Images заменила FL новым посредником — внутренним worker binding, который работает на той же машине. В исходной архитектуре данные шли через FL по сетевым сокетам; этот путь нёс накладные расходы полного конвейера обработки FL, такие как DNS-lookup'ы и маршрутизация.

Внутренний binding заменил их на Unix-сокеты, чтобы напрямую соединить сервисы на одной машине, минуя FL и накладные расходы сетевого стека. Это ускорило путь запроса к Images и дало команде независимый контроль над релизами binding.

В течение нескольких дней после выкатки мы получили первый отчёт от клиента.

200 OK (не OK)

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

Сначала их воркер с помощью Images binding компоновал несколько больших исходных изображений из R2 — JPEG-фон и PNG-оверлеи — в один объединённый JPEG. Затем результат дополнительно сжимался, транскодировался и изменялся размер через URL-интерфейс.

Баг возникал на обратном пути внутреннего pipeline, где ответ обрезался до того, как достигал внешнего.

Внутренний pipeline (transformation binding) отвечал за компоновку. Внешний pipeline (transformation URL) отвечал за оптимизации доставки: масштабирование и конвертацию формата. Такая многоуровневая схема означала, что когда внутренний pipeline молча возвращал обрезанный ответ, видимая ошибка появлялась на уровень выше:

Внешний pipeline получал от внутреннего HTTP 200 с заголовком Content-Length, который обещал несколько мегабайт. Фактическое тело было лишь частью от этого: в одном запросе из ожидаемых 3,3 МБ пришло всего около 200 КБ. Ошибка всплывала во внешнем pipeline, но обрезка могла произойти в binding, посреднике, сервисе Images или где-то между ними.

Когда браузер получает обрезанное изображение, результат виден невооружённым глазом. В зависимости от формата изображение либо отрисовывается частично (например, с отсутствующей или серой нижней частью), либо полностью не декодируется и отображается как битое.

Отладка вслепую

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

• Сборка репродукции. Мы собрали воркер, повторяющий вложенную схему клиента, и постепенно убирали уровни, пока не смогли воспроизвести баг только с binding. Небольшой скрипт отправлял запросы пачками. На одном из первых прогонов 19 из 25 запросов упали. Объём данных, которые всё-таки приходили, — примерно 200 КБ — настораживающе близко к размеру сокетного буфера в продакшене. Это подтвердило, что проблема не связана с конфигурацией клиента, и дало надёжный способ воспроизводить баг по запросу.
• Проверка таймаутов. Сначала мы подозревали, что обрезка связана с поведением таймаутов (то есть соединение закрывалось по истечении лимита времени). Эта теория не подтвердилась: обрезка не коррелировала с длительностью запроса.
• Обновление версии hyper. Когда баг впервые зарепортили, мы использовали 0.14.x, а последняя версия hyper была около 1.8.x. Мы протестировали версии 0.14, 1.7 и 1.8 — на случай, если самый очевидный ответ окажется правильным (и самым простым). Но баг проявлялся в каждой версии, значит, upstream-исправления не было.
• Локальное воспроизведение. Мы запускали интеграционные тесты на macOS и Debian-виртуалке. Даже под значительной нагрузкой локальные запросы никогда не падали. Прямые curl-запросы к сокету binding и повтор отловленных запросов всегда работали. Баг проявлялся только на полном продакшен-пути при реальной конкурентности и реальном клиенте Workers runtime на другом конце сокета. Это натолкнуло нас на подозрение, что виноват сам runtime.
• Исключение Workers runtime. Мы изучили HTTP-клиент, который Workers runtime использует для связи с Images через сокет binding. Ни на одной из сторон соединения в трассировках не было системных вызовов, указывающих на неожиданное закрытие или преждевременное завершение. Клиент вёл себя корректно, и несколько других сервисов использовали того же клиента без проблем.
• Распределённая трассировка. Изучив сквозные трассировки запросов, мы подтвердили, что обрезанное тело уже присутствовало до того, как достигало внешнего уровня трансформации в схеме клиента. Это сузило проблему до внутреннего pipeline — пути binding через сервис Images.
• Инструментирование посредника. Мы добавили инструментирование в посредник, чтобы измерять размеры тел перед пересылкой ответа. Тела уже были обрезаны к моменту выхода из сервиса Images, так что посредник был исключён.
• Углублённая трассировка внутри Images. На уровне сервиса запрос обрабатывался, изображение корректно кодировалось, и ответ отправлялся с HTTP 200.

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

Зерно истины

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

Чтобы увидеть, что система делала на самом деле, мы подключили strace к сервису Images. strace записывает системные вызовы, которые процесс делает ядру; это позволило показать, какие именно байты были записаны, когда вызывался shutdown и посылал ли клиент сигнал завершения.

Настройка трассировки была деликатной. strace работает, перехватывая системные вызовы по мере их выполнения, что добавляет небольшие накладные расходы по времени к каждому вызову. Фильтрация узкого набора системных вызовов держала эти накладные расходы минимальными. Однако расширение фильтра замедляло процесс ровно настолько, чтобы сдвинуть тайминг между flush и проверкой shutdown — и баг полностью исчезал. Одно это уже подкрепляло теорию о тайминг-зависимости проблемы.

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

При успешном запросе ответ пишется кусками по мере освобождения сокетного буфера, а shutdown вызывается только после отправки всех данных. Например, это может выглядеть так:

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

Здесь есть только одна запись — лишь заголовки и крошечная часть тела — перед немедленным вызовом shutdown. Из ответа в 14,9 МБ было отправлено около 219 КБ. Оставшиеся ~14,8 МБ данных изображения никогда не покидали внутренний буфер hyper, и не было никакого сигнала завершения от клиента между записью и shutdown. Вместо этого сервис Images преждевременно закрывал соединение самостоятельно, искренне полагая, что работа завершена.

Упавшие запросы подтвердили, что баг — состояние гонки, которое срабатывало непостоянно. Успех или провал зависели от того, перекрывались ли операции flush и shutdown, и это менялось от запроса к запросу. Когда буфер был полон в тот самый момент, когда hyper решил, что соединение завершено, данные терялись.

Когда читатель потребляет медленнее, чем hyper пишет, исходящий буфер заполняется. Если hyper закрывает соединение до того, как буфер опустеет, то лишь часть ответа попадает к посреднику; эти неполные данные пересылаются обратно в Workers runtime и клиенту.

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

Этих нескольких миллисекунд обратного давления, внесённых улучшением, которое ускорило всё остальное, хватило, чтобы выявить изъян, который скрывался на виду.

Внутри цикла dispatch

Жизненный цикл HTTP/1-соединения в hyper управляется конечным автоматом в файле под названием dispatch.rs. Он выполняет цикл, который читает запросы, пишет ответы, сбрасывает буфер записи в сокет и решает, когда закрываться. В упрощённом виде:

Точнее, именно let _ перед poll_flush — это место, где живёт баг.

В Rust let _ = expr отбрасывает результат выражения, включая Poll::Pending — сигнал о том, что flush ещё не завершён. В буфере flush может остаться несколько мегабайт, но цикл об этом никогда не узнаёт.

Когда запрос падает, последовательность событий выглядит так:

1. Сервис Images завершает кодирование изображения и передаёт весь ответ hyper как один блок в памяти.
2. Hyper записывает блок во внутренний буфер и помечает состояние записи как Writing::Closed. С точки зрения кодирования работа сделана — кодировать больше нечего.
3. Hyper вызывает poll_flush, чтобы перенести буферизованные данные в сокет. В нашем примере сокет принял около 219 КБ. Оставшиеся ~14,8 МБ остаются в буфере hyper. Сокет полон, поэтому ядро возвращает Poll::Pending.
4. poll_loop отбрасывает Poll::Pending с помощью let _.
5. Он проверяет wants_read_again(). Полный запрос уже получен, поэтому возвращается false.
6. poll_loop возвращает Poll::Ready(Ok(())), сигнализируя, что цикл завершён, хотя flush ещё не сделан.
7. Срабатывает poll_shutdown(). Выполняется системный вызов SHUT_WR.
8. Клиент получает 219 КБ и EOF (end-of-file), указывающий, что соединение закрыто, хотя он ожидает 14,9 МБ.

На втором шаге hyper помечает операцию записи как завершённую, как только тело ответа оказывается в буфере (то есть когда кодирование закончено), а не когда данные фактически сброшены. В большинстве случаев flush завершается за один проход, и это различие незаметно. В редких случаях, когда сокетный буфер полон, flush приходится ждать — но hyper не ждёт. Байты всё ещё сидят в буфере hyper, ожидая сброса в сокет. Hyper при этом закрывает соединение с этими данными всё ещё в буфере.

Это также объясняет, почему curl никогда не воспроизводил баг. Curl читает данные так быстро, как они приходят: сокетный буфер никогда не заполняется, flush всегда завершается мгновенно, и отброшенное возвращаемое значение безобидно. Продакшен-путь с читателем, который иногда паузил на несколько миллисекунд, был единственной конфигурацией, где буфер заполнялся в нужный момент.

Не забывайте сбрасывать буфер

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

Наш reproduction-воркер подтвердил, что баг существует, но не мог объяснить, почему падает конкретный запрос. Прежде чем писать исправление, нам нужен был тест, который мог бы спровоцировать точные сокетные условия внутри hyper.

Мы знали условия, вызывающие баг: сокет, который принимает один кусок данных, а затем блокируется. Для контролируемого сценария мы построили обёртку вокруг TCP-потока, имитирующую полный сокетный буфер. Обёртка принимала 8 КБ при первой записи, а затем возвращала Poll::Pending на каждой последующей записи, имитируя читателя, который перестал опустошать буфер.

Тест отправлял 500 КБ ответа через этот ограниченный сокет и проверял, вызывает ли hyper shutdown, пока в буфере остаётся 492 КБ. Без исправления — вызывал. С исправлением — ждал.

Сначала мы применили исправление в цикле dispatch hyper. Вместо отбрасывания результата poll_flush мы проверяли, завершён ли flush на самом деле:

Если flush не завершён, цикл возвращает Poll::Pending асинхронному runtime. Runtime ждёт, пока сокет не станет доступен для записи, а затем будит задачу, чтобы продолжить flush. Соединение закрывается только после того, как все данные отправлены.

Когда мы выкатили это исправление, мы увидели, что записан каждый байт, а shutdown вызывался только после того, как буфер действительно опустел. Клиент, который сделал первый репорт, тоже подтвердил, что проблема исчезла.

Хотя первоначальное решение работало, цикл dispatch был неправильным местом для исправления. Ранний возврат Poll::Pending мог замедлять другие операции на том же соединении, уменьшая частоту опроса чтения и вызывая нежелательное обратное давление. Также это корректно не обрабатывает keepalive-соединения, где одно соединение обрабатывает несколько запросов подряд — они должны оставаться пригодными к использованию, даже пока предыдущий ответ всё ещё сбрасывается. Ни одна из этих проблем не затрагивала наш сервис (где keepalive отключён), но обе могли повлиять на других пользователей hyper, если бы исправление было предложено upstream.

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

Это оставляет цикл dispatch без изменений. Flush добавляется только в тот точный момент, где иначе произошла бы потеря данных — непосредственно перед shutdown.

Что осталось с нами

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

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

Прорыв случился благодаря инструментарию уровня ядра — strace, единственному слою, который фиксирует, что на самом деле происходило на сокете. Базовый баг жил в нескольких миллисекундах между частичным flush и преждевременным shutdown — окне, которое открылось только после того, как мы ускорили систему.

Мы влили исправление и детерминированный тест в hyperium/hyper через PR #4018. Оно появится в будущем релизе hyper, гарантируя, что любой сервис, использующий HTTP/1-реализацию hyper, не потеряет данные ответа из-за того же состояния гонки.

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

Изначально Images binding покрывал только трансформации удалённых изображений. В начале этого месяца мы объявили, что Images binding теперь поддерживает операции для hosted-изображений, давая разработчикам единый способ строить медиа-насыщенные приложения на Cloudflare.

Подробнее о том, как работает binding, — в нашей документации.

EchoBird — это open-source настольный лаунчер для ИИ-агентов и локальных больших языковых моделей (LLM). Написан на Rust + Tauri, работает на Windows, macOS и Linux. Автор, разработчик с ником edison7009, собрал его после того, как друзья не раз просили помочь «поставить этот ваш ИИ» на новой машине. Сейчас проект насчитывает 2200 звёзд на GitHub, 162 ответвления и 112 релизов; актуальная версия — v5.2.7.

Идея простая: вместо того чтобы запускать терминал для каждого инструмента, вбивать команды установки и копаться в переменных окружения, вы открываете одно окно. Там устанавливаются агенты, подключаются API-ключи, запускаются локальные модели и управляются собственные ИИ-проекты. В российских условиях локальные LLM и альтернативные поставщики часто воспринимаются не как эксперимент, а как рабочая необходимость: ограничения на доступ к западным сервисам и требования к данным делают собственное железо привлекательнее облака.

• EchoBird — это open-source менеджер ИИ-инструментов на Rust + Tauri для Windows, macOS и Linux.
• Четыре сценария: установка и починка агентов, локальные LLM, личные ИИ-проекты и единое средство запуска приложений.
• Model Nexus объединяет API-ключи, модели и протоколы OpenAI / Anthropic в одном центре конфигурации.
• Локальные модели запускаются через llama.cpp, vLLM или SGLang с автоподбором под железо.
• Расширяется через plugin.json: новый инструмент можно добавить без изменения кода приложения.

Четыре сценария, которые покрывает EchoBird

Приложение не претендует на роль универсального рабочего стола, а решает конкретные задачи вокруг «поставил — настроил — запустил». Все четыре сценария используют общий Model Nexus — о нём ниже.

Установка и починка агентов

EchoBird сканирует систему, находит уже установленные инструменты и проверяет зависимости. Если чего-то не хватает, ведёт установку в режиме диалога. Если что-то сломалось — запускает починку. Поддерживаются Claude Code, Codex CLI, OpenCode, Aider, Hermes Agent, MiMo Code от Xiaomi и собственная линейка агентов автора — OpenClaw, ZeroClaw, NanoBot и PicoClaw. Новый инструмент добавляется через файл plugin.json, поэтому сообщество может расширять список без запросов на слияние в основной репозиторий.

Локальные LLM в один клик

Встроены три runtime'а под разное железо: llama.cpp для CPU и слабых машин, vLLM для серверных GPU NVIDIA на Linux и SGLang для агентских сценариев с жёстко заданным выводом — например, когда модель должна вернуть JSON строго по схеме. EchoBird сам определяет наличие видеокарты NVIDIA и предлагает runtime с подходящими параметрами — например, размер батча и offloading слоёв на GPU. После запуска модель отдаёт совместимые с OpenAI и Anthropic endpoints — остальные инструменты не замечают подмены. Про локальный запуск LLM через Ollama у нас есть пошаговый гайд.

Мои ИИ-проекты

Раздел для утилит, демок, игр и скриптов, созданных в режиме vibe coding (импровизационной разработки с ИИ), которые рождаются за один вечер с ИИ-помощником. Вместо того чтобы искать директорию и вспоминать команду запуска, проект живёт в едином списке с кнопкой «старт».

Менеджер приложений

Центральная панель запуска для всего, что уже установлено. Можно запустить Claude Code, Codex CLI или локальную модель из одного списка, не открывая отдельные терминалы и окна.

Model Nexus: единая точка входа для моделей

Главная архитектурная идея — Model Nexus. Это прослойка между приложением и поставщиками моделей, которая хранит API-ключи, проверяет задержки, транслирует OpenAI- и Anthropic-совместимые протоколы.

Без него каждый инструмент требует своей конфигурации: Claude Code требует свой API-ключ, Codex CLI — свой .env, Hermes Agent — свой config.toml, а локальный vLLM — свой путь к модели. Model Nexus заменяет это на «ввёл один раз, используешь везде».

Поддерживаются 14+ поставщиков: Anthropic, OpenAI, Gemini, xAI Grok, Mistral, Together AI, DeepSeek, MiniMax, GLM, SiliconFlow, а также Ollama, llama.cpp, vLLM, SGLang, OpenRouter и любой OpenAI-совместимый endpoint. Каждому агенту можно назначить свой протокол независимо от остальных.

Почему Tauri + Rust, а не Electron

Выбор стека для менеджера, который управляет чужими тяжёлыми моделями, логичен. Tauri даёт бинарник менее 10 МБ против типичных 100+ МБ у Electron. Rust напрямую дёргает системные API, работает с файловой системой, процессами и детекцией GPU без лишних мостов. Для инструмента, который постоянно запускает подпроцессы и читает конфигурации, это надёжнее и предсказуемее.

Сравнение: классическая установка Claude Code и EchoBird

Традиционный путь — пять шагов, каждый из которых может обломаться:

1. Проверить версию Node.js (нужен 18+).
2. Убедиться, что права npm настроены правильно.
3. Выполнить npm install -g @anthropic-ai/claude-code.
4. Прописать переменную окружения ANTHROPIC_API_KEY.
5. Проверить: claude --version. При смене машины — повторить.

Путь через EchoBird — короче в разы:

1. Открыть EchoBird.
2. Install & Repair → Claude Code → установить в один клик.
3. Model Nexus → ввести API-ключ один раз для всех инструментов.

Расширение через plugin.json

Новый инструмент описывается JSON-файлом с командами установки, проверки, починки и запуска. Пример минимального плагина:

Такой подход отделяет ядро приложения от рецептов установки. Теоретически сообщество может добавить плагины для российских моделей — например, GigaChat, YandexGPT или локальных сборок на базе Saiga — без необходимости ждать официальных обновлений.

Что нового в ветке v5.x

Релизы выходят активно. Несколько примечательных изменений последних недель:

• v5.2.4 — зеркала для установки из Китая (Tsinghua, Alibaba, Huawei), чтобы зависимости качались без VPN.
• v5.2.0 — переключатель Responses-протокола OpenAI для моделей, которые говорят на нём нативно, например MiniMax-M3 и Qwen3.7.
• v5.2.6 — поддержка MiMo Code от Xiaomi и починка автоуплотнения контекста в Codex V2, из-за которого разговоры обрывались.
• v5.2.4 — нативные элементы управления окном и стандартные горячие клавиши macOS (⌘W, ⌘M, ⌘,).

Как попробовать

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

После установки: открываете Model Nexus, добавляете ключи; переходите в Install & Repair, выбираете инструменты; запускаете их из App Manager. Для локальных моделей — Local LLM → runtime → модель.

Кому пригодится

• Тимлидам и DevRel'ам, которым часто нужно «поднять окружение» на новой машине коллеги.
• Разработчикам, кто переключается между рабочими и личными ПК и устал от повторяющегося адаптации.
• Энтузиастам локальных LLM, которым надоело вручную ставить CUDA, vLLM и искать пути к моделям.
• Авторам плагинов, которые хотят добавить поддержку отечественных или нишевых ИИ-сервисов.

Выводы

EchoBird не изобретает ИИ-инструменты заново — он убирает трение на границе между «хочу попробовать» и «уже работает». Model Nexus решает проблему разрозненных конфигураций, встроенные runtime'ы — проблему локальных моделей, а плагины — проблему поддержки новых сервисов. Выбор Rust + Tauri выглядит обоснованным: приложение остаётся лёгким, хотя самые тяжёлые модели грузятся вне его.

EchoBird родился из собственной боли: друзья постоянно просили меня установить Claude Code на их машины. Я хотел, чтобы любой мог нажать одну кнопку и получить рабочее окружение, не разбираясь в Node.js, npm и переменных окружения.

Если в вашем рабочем процессе регулярно фигурируют Claude Code, Codex CLI, Aider или локальные LLM, стоит потратить несколько минут на установку и посмотреть, сколько ручных шагов отпадёт.

Источники

Оригинальный материал: Open Source Project of the Day (#97): EchoBird — DEV Community. Дополнительно: репозиторий EchoBird на GitHub, официальный сайт.

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

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

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

Ранее у нас был опыт использования Nextcloud, однако его функционал, подобный швейцарскому ножу (встроенные календарь, конференции, таск-трекер и т. д.), оказался слишком объемен для нашей, по сути, скромной задачи – удобного и стабильного хранения файлов.

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

В этой статье я расскажу, какие возможности есть у ownCloud, почему это ПО может быть полезно и как настроить связку ownCloud и S3. Если вы хотите организовать безопасное, контролируемое хранение и обмен данными на работе или дома, то этот материал будет для вас полезен.

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

Это программное обеспечение с открытым исходным кодом для хранения, синхронизации и обмена файлами появилось в 2010 году благодаря усилиям разработчика KDE Франка Карличека, который стремился создать бесплатную альтернативу коммерческим облачным сервисам хранения данных.

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

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

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

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

С ownCloud мне не нужно слепо доверять какой-то неопределенной организации. Я контролирую, как происходит обмен файлами, и ownCloud помогает мне на каждом этапе.

OwnCloud позволяет решать самые разные задачи, связанные с работой с файлами, – расскажем на примере трех кейсов, как это облачное хранилище помогает нам в отделе маркетинга.

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

Мы часто работаем с текстами, изображениями и презентациями. Дизайнеры и авторы загружают эти материалы в ownCloud, файлы автоматически сохраняются в S3, а для удобства поиска у нас настроены теги.

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

Связка ownCloud и S3 позволяет выгружать внешним специалистам материалы и получать результаты работ без прямого доступа к внутренней сети компании. Мы создали папку с публичной ссылкой, но жесткими ограничениями – паролем, сроком жизни ссылки в течение нескольких дней и разрешением на загрузку файлов без права просмотра папки.

На практике это работает так: менеджер создает ссылку и отправляет подрядчику, подрядчик переходит по ссылке и загружает архив с готовыми материалами, файл попадает в ownCloud, а его содержимое сохраняется в S3. Таким образом, подрядчик не видит, какие еще файлы лежат в папке, а мы контролируем, кто, что и когда загрузил.

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

Разработчики ownCloud предлагают два варианта установки. Можно скачать ownCloud и установить его вручную или использовать Docker-контейнеры. Мы выберем второй вариант.

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

Создайте директорию для размещения конфигурационных файлов проекта и перейдите в нее:

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

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

Теперь необходимо отредактировать эти строки:

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

Все запросы к домену будут проксироваться в контейнер ownCloud_server.

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

Потребуется несколько минут, чтобы docker загрузил образ и развернул контейнеры.

После запуска перейдите по домену, чтобы проверить работу хранилища:

Выполните вход со стандартными доступами.

Обратите внимание! Если ownCloud недоступен или вы получаете ошибку при входе со стандартными доступами, проверьте корректность конфигурационных файлов. После внесения изменений перезапустите контейнеры.

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

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

Если вы ловите себя на мысли, что данных стало настолько много, что поиск нужного файла порой происходит дольше, чем работа с ним (особенно если одни файлы хранятся на почте или в мессенджере, а другие – на ноутбуке или флешке), облачное хранилище может вам помочь.

Подобное ПО пригодится как для личных целей, так и для бизнеса – недаром в 2025 году в нашей стране был зафиксирован рост интереса крупного и среднего бизнеса к технологии облачного хранилища.

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

Это вторая часть серии. В первой — обходные приёмы для async-кода прямо в пользовательском коде. Во второй — автор копает в MIR (Mid-level Intermediate Representation — внутреннее представление rustc между исходником и LLVM IR) и формулирует, что должен научиться делать сам компилятор. Цель — не лечить симптомы, а добраться до корня и улучшить генерацию futures.

• Async-функция в Rust разворачивается в state machine: компилятор генерирует enum с одним состоянием на каждую точку await плюс три служебных — Unresumed (старт), Returned (после завершения) и Panicked (после пойманного catch_unwind).
• Функция с двумя await-точками у автора разворачивается в 360 строк MIR против 23 у синхронного аналога — больше чем в 15 раз. Часть этого LLVM срежет, но не всё.
• Замена panic! в состоянии Returned на возврат Pending в release-сборках даёт 2–5% экономии размера прошивки на embedded.
• Ещё четыре оптимизации: убрать state machine у async-блоков без await-точек, заинлайнить futures с одним await, схлопнуть одинаковые состояния из ветвей match, под panic=abort вообще убрать состояние Panicked.
• Автор подал Rust Project Goal и оценил работу примерно в €30 000 финансирования.

Что компилятор делает с async-блоком

Возьмём простой пример из статьи:

У bar два await-points — значит, в state machine минимум два состояния. Просим компилятор сдампить MIR на этапе coroutine_resume (последний async-специфичный pass) и видим:

Returned и Panicked — служебные. Future::poll — безопасная функция, и опросить уже завершённую future нельзя так, чтобы получить undefined behaviour. Поэтому компилятор после первого Ready переключает future в Returned, и при повторном poll она паникует. Похожая логика для Panicked: после пойманного unwind future блокируется от повторного poll, иначе можно дёрнуть её в неконсистентном состоянии — автор сам отмечает, что точная документация по этому состоянию ему не нашлась, и сравнивает механизм с mutex poisoning.

Логично, но автор замечает: bar генерирует 360 строк MIR, а синхронный аналог — 23 строки. То есть в 15+ раз больше. Часть этого добавления LLVM оптимизирует позже, но не всё — и на embedded остаток ощутимо влияет на размер прошивки.

Оптимизация 1: вместо panic — снова Pending

Future в состоянии Returned обязана не вызывать UB. А не обязана паниковать. Можно вместо panic! просто возвращать Pending: контракт Future не нарушается, ничего опасного не происходит.

Panic — относительно дорого: добавляется ветка с побочным эффектом, которая плохо оптимизируется. Автор пропатчил компилятор и измерил: 2–5% сокращение размера бинарника для async-прошивок на embedded.

Идеальное место — флаг по аналогии с overflow-checks = false: в debug-сборке оставляем panic, чтобы быстро ловить ошибочный повторный poll, в release — экономим. Аналогично, при panic = abort состояние Panicked потенциально можно убрать целиком — автор хочет это отдельно исследовать.

Оптимизация 2: лишняя state machine у пустого async-блока

Возвращаемся к foo: там нет ни одного await-point, future просто возвращает число. Логично было бы реализовать вручную как:

Никакого состояния не нужно — просто вернуть 5. На деле компилятор генерирует CoroutineLayout с тремя вариантами (Unresumed, Returned, Panicked) и честный switch по дискриминанту перед каждым возвратом — даже там, где без него можно было обойтись. Когда await-точек ноль, state machine можно убирать целиком — это около 0,2% размера бинарника. Поведение чуть меняется только для неконформных executor-ов: future всегда возвращает Ready без переходов между состояниями.

Ещё две оптимизации в плане работ

• Inlining futures с одним await-point. В таких future внутреннее состояние сводится к Suspend0 + Returned + Panicked, а ветка управления при правильной работе компилятора схлопывается в обычный вызов с одним переключением.
• Схлопывание идентичных состояний из ветвей match. Если в функции несколько await-точек попадают в одинаковые по смыслу варианты (одни и те же сохранённые поля), их можно объединить в одно состояние state machine — без потери семантики.

Каждый из этих кейсов даёт меньше, чем замена panic на Pending, но вместе с ней образуют связный набор патчей в компилятор. Автор формулирует план так: вынести проблему из «каждая embedded-команда со своими обходными приёмами» в «исправление в rustc раз и навсегда».

Project Goal и финансирование

Изменения требуют времени на проектирование, обсуждение в Rust-проекте и собственно правки. Автор оформил это как Project Goal по async state machine optimisation и оценил необходимое финансирование примерно в €30 000 — в основном на работу embedded-инженера над патчами компилятора. Платит обычно либо сам Tweede golf, либо Rust Foundation через программу грантов, либо отдельный спонсор; Project Goal — публичный механизм, чтобы заявить цель и собрать поддержку, в том числе финансовую. По меркам компиляторных проектов это недорого: типичная цена «уберём 2–5% размера прошивки в любом async-проекте» — десятки тысяч евро.

Это вторая часть серии. В первой я показывал, что вы можете сделать в своём async-коде, чтобы избежать части bloat. Во второй мы лезем во внутренности и переводим методы из первой части в оптимизации для компилятора.

Выводы

Async в Rust — давно главный болевой пункт у embedded-сообщества: обещания zero cost не подтверждаются, а обходные приёмы на уровне пользовательского кода сильно ограничены. Tweede golf формулирует разговор иначе: показывает, какие именно паттерны генерации виноваты, и предлагает их закрывать в компиляторе.

Для практика это значит две вещи. Первое — писать async-код можно не оглядываясь на «не сделать ли я ещё одно состояние»; bloat лежит в компиляторе, и просьба к нему — править генерацию, а не ваши async fn. Второе — следить за статусом Project Goal: если его подхватят, размер async-кода в release-сборках уменьшится у всех пользователей сразу, без правок в их репозиториях.

Оригинал — на tweedegolf.nl/en/blog/237/async-rust-never-left-the-mvp-state. Первая часть серии — «Debloat your async Rust». Project Goal лежит на rust-project-goals/2026/async-statemachine-optimisation.

Главная идея: в Rust поле типа Option<BigStruct> занимает столько же, сколько BigStruct — даже когда оно None. Чтобы пустое поле «весило одно слово», нужно обернуть значение в Box. Компилятор тогда применяет niche-оптимизацию (использует нулевой указатель как маркер None) — Option<Box<T>> весит ровно как один указатель. На задачах с массой опциональных полей это даёт двукратное сокращение памяти.

• Кейс: десериализация всех JSON-моделей AWS SDK (Smithy Shapes) через serde в Rust
• Было: 895 МБ. Стало: 420 МБ. Экономия 475 МБ (-53%)
• Изменения: только layout структур + кастомный Deserializer для пустых полей
• Ключевая мысль: Option<Big> ≠ Option<Box<Big>> по памяти
• Niche-оптимизация компилятора: Option<Box<T>> весит как один указатель
• Verification: jemalloc через feature-флаг profile, замер до/после загрузки
• Цена: десериализация чуть дороже по CPU (значение всё равно создаётся, потом отбрасывается)

Реальный кейс

Программа автора десериализует все JSON-файлы из репозитория awslabs/aws-sdk-rust/aws-models в структуры «Smithy Shape». Эти файлы содержат тысячи объявлений вроде такого:

Как принято в Rust-коде, для разбора используется serde. Соответствующие структуры выглядят естественно — это обычная вложенность структур со множеством опциональных полей и serde-атрибутов. Не нужно вчитываться в код: обратите внимание только на сами имена полей и на россыпь Option<...>:

Это типичный для Rust код. Но именно такой layout приводит к тому, что после десериализации структуры занимают 895 МБ. При этом анализ показывает: большинство опциональных строк отсутствуют — это и стало рычагом для радикального сокращения объёма. Чтобы понять механизм, нужен короткий теоретический отступ.

Как устроены структуры в памяти Rust

На 64-битной платформе одно «слово» — это 8 байт. Например, столько занимает usize.

Тип String занимает 3 слова: указатель на буфер, длину и ёмкость (capacity). Это 24 байта на сам тип String (проверить можно через dbg!(std::mem::size_of::<String>())) — не считая место под содержимое строки на heap. Подробности в документации Rust.

Существует niche-оптимизация компилятора: Option<String> весит столько же, сколько String. Дополнительный байт под пометку «это None» не нужен — пустое значение определяется по нулевому указателю.

Поэтому такая структура, когда все строки None, занимает ровно 120 байт (5 × 24):

Композиция структур

Дальше — самое важное. Что будет, если такая структура встроена в другую? Пусть это будет Container1, у которой одно поле Option<String> и одно — SmithyServiceTrait:

Размер Container1 — 24 + 120 = 144 байта: 24 под Option<String> и 120 под SmithyServiceTrait. А что, если поле trait сделать опциональным — на случай, когда trait отсутствует?

Сколько занимает Container2, когда оба поля None? Те же 144 байта. Опциональность ничего не сэкономила: место под структуру уже зарезервировано в layout родителя, и компилятор всё равно держит его готовым. Везёт ещё, что внутри SmithyServiceTrait только поля Option<String> — это позволяет компилятору не добавлять дополнительный байт-discriminant для внешнего Option.

Применив эту арифметику к SmithyTraits, видно, почему наивная реализация так разбухает в памяти.

Почему в Java и других языках с GC такой проблемы нет

В языках с reference-семантикой полей композиция работает иначе. Когда у класса Container есть поле-объект, это поле — указатель на heap. Если поле null, оно занимает только одно слово.

Чтобы добиться того же поведения в Rust — то есть чтобы пустое поле занимало одно слово, — нужно явно вынести содержимое на heap, обернув в Box:

Теперь, когда оба поля None, Container3 занимает всего 32 байта: 3 слова под Option<String> и одно слово под Option<Box<...>>. Та же niche-оптимизация работает и здесь: Option<Box<...>> весит столько же, сколько голый Box<...>.

Что именно поменялось

Изменение свелось к трём шагам:

1. Найти структуры, которые часто оказываются «пустыми» (все поля — None).
2. Сделать их опциональными в родительской структуре, переместив на heap через Box.
3. Написать кастомный Deserializer, чтобы пустые структуры вообще не попадали в результат.

Было:

Стало:

Аналогично, в SmithyShape все поля Option<SmithyReference> заменены на Option<Box<SmithyReference>>. Местами пришлось поправить акцессоры, потому что путь к данным удлинился на одну разыменовку. И всё — память на хранение десериализованных AWS-shape снизилась вдвое, экономия 475 МБ.

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

• CPU чуть дороже. Десериализация полного объекта всё равно происходит — а потом он отбрасывается, если оказался пустым. Парадокс: суммарно задача стала быстрее, потому что меньше памяти = меньше работы аллокатора, меньше TLB-промахов, лучше попадания в L2/L3-кеш. На больших объёмах эти эффекты перевешивают накладные расходы на лишний разбор.
• Фрагментация heap. Много мелких Box ведёт к фрагментированной куче. В авторском случае это не было проблемой, но в долгоживущих сервисах — стоит держать в уме.

Как проверить, что экономия реальная

Чутьё подсказывает, где можно сэкономить и сколько примерно. Но без замеров — не работа. В Rust нет простого способа узнать, сколько весит композитный объект со всеми полями и аллокациями за указателями. Решение автора — использовать аллокатор, умеющий отдавать статистику. В стандартной поставке такие данные ограничены, поэтому подключается jemalloc:

В Cargo.toml объявляется feature-флаг profile, чтобы не таскать jemalloc в обычные сборки:

В main.rs аллокатор подключается под этим же флагом:

И в самой функции загрузки структур делается замер: до и после.

Совет автора: tikv_jemalloc_ctl отдаёт ещё кучу деталей, которые полезно мониторить в серверных приложениях.

Что запомнить из статьи

• Применяйте Option<Box<T>> только там, где поле пусто в большинстве случаев — иначе heap-fragmentation и разыменовка перевесят выигрыш.
• Размер типа узнать просто: std::mem::size_of::<T>(). Реальное потребление с heap — только через jemalloc-ctl, dhat-rs или heaptrack.
• Niche-оптимизация работает не для всего: String, Box, Vec, &T — да; кастомный enum без явных #[repr] — обычно нет.
• При desered-через-serde: голая замена типа на Option<Box> не даёт выигрыша — нужен кастомный Deserializer, который вернёт None для «пустых» структур.
• Перед оптимизацией — всегда замер. После оптимизации — снова замер. Без цифр это карго-культ.

От редакции

Один практический совет от редакции: чтобы быстро найти кандидатов на оптимизацию в большом проекте, прогоните код через dhat-rs — это профайлер аллокаций от автора «Rust Performance Book». Он покажет, какие типы съедают больше всего heap. Альтернатива Option<Box<T>> — arena-аллокаторы вроде bumpalo: если вся группа объектов живёт один пакетный жизненный цикл, разовый bump-аллокатор может оказаться эффективнее множества мелких Box.

Если интересна тема Rust в крупных продакшенах, у Tproger есть свежий материал про то, как WhatsApp переписал медиадвижок на Rust и выкинул 160 тысяч строк C++ — там тоже про экономию памяти и скорость, только в другом масштабе.

Источник: «Box to save memory» — dystroy.org/blog. Автор оригинала — Дени «Canop» де Майе, разработчик файлового менеджера broot и других open-source утилит на Rust.

Релиз замыкает двухлетний LTS-цикл: между Ubuntu 24.04 LTS «Noble Numbat» и 26.04 LTS вышли три промежуточных релиза (24.10, 25.04, 25.10), и именно в них Canonical обкатал большую часть изменений — от замены классических GNOME-приложений на Rust-варианты до Wayland-only сессии и NTSYNC-драйвера для Windows-игр в Proton. К моменту LTS эти переходы уже прошли стадию «сыро» — в 26.04 они приходят готовыми.

Ядро и безопасность: Linux 7.0 как дефолтное ядро, post-quantum подписи модулей (ML-DSA), OpenSSH 10.2p1 с гибридным обменом ключами mlkem768x25519-sha256.

Десктоп: GNOME 50 на Wayland-only сессии, GIMP 3.0, LibreOffice 25.8, Firefox 149, Thunderbird 140 «Eclipse».

Rust в ядре системы: новый монитор ресурсов Resources (с трекингом NPU), PDF-вьюер Papers, просмотрщик картинок Loupe, терминал Ptyxis с интеграцией podman и distrobox — все переписаны на Rust.

Железо: официальный ARM64 desktop ISO с поддержкой Snapdragon X Elite, полноценный Wayland на NVIDIA, apt install rocm для AMD GPU из коробки.

Поддержка: security-обновления до 2031 года, до 2036 года — с Ubuntu Pro ESM.

Rust въехал в базовые утилиты — и это главное изменение

Главный технический сдвиг 26.04 — системные утилиты GNOME переписываются на Rust. Это не эксперимент энтузиастов, а дефолт новой LTS. Вот что поменялось на вашем рабочем столе:

• Resources заменяет System Monitor и Power Statistics. Группирует процессы в приложения, трекает использование GPU (включая видеокодеры), NPU, частоты CPU/GPU/памяти. Написан на Rust с GTK 4.
• Papers пришёл на смену Evince как дефолтный PDF-вьюер. Перенесён на GTK4 и частично переписан на Rust.
• Loupe вместо Eye of GNOME для картинок — чистый Rust поверх библиотеки Glycin.
• Ptyxis заменяет GNOME Terminal. Из интересного — прямая интеграция с podman, toolbox и distrobox (вкладка сразу в контейнере), session-save для восстановления вкладок после перезапуска.
• gst-thumbnailers генерирует превью для видео и аудио — через Rust-биндинги к GStreamer. Лучше находит «интересные» кадры, чем Totem.

Параллельно ядро Linux 7.0 окончательно признало Rust-драйверы как часть основного дерева ядра — они собираются вместе с остальными модулями без отдельных галок в конфиге. Это тот момент, когда «Rust в Linux» перестаёт быть новостью и становится инфраструктурой.

Wayland-only, ARM64 desktop и NVIDIA

Ubuntu 26.04 окончательно выкидывает X.org-сессию из GDM — десктоп GNOME запускается только под Wayland. Приложения под X.org продолжат работать через XWayland-слой совместимости, а если нужен именно X11 — остаются сессии KDE on X11, Xfce, MATE, i3 и другие.

Для NVIDIA это первый LTS с полной поддержкой Wayland — включая то, что раньше ломало композитор: XID-ошибки GPU, suspend/resume, Secure Boot-модули. Работает без возни.

Отдельный пункт — первый в истории Ubuntu официальный ARM64 Desktop ISO. Прицел на виртуальные машины, ACPI+EFI-платформы и устройства на Snapdragon (включая Snapdragon X Elite). Это запуск Ubuntu Desktop как гражданина первого класса на ARM-ноутбуках с UEFI.

Для AMD ROCm теперь ставится прямо из репозиториев Ubuntu — одной командой sudo apt install rocm. До 26.04 нужно было подключать сторонний репо от AMD и следить за версией — теперь это стандартный deb-пакет.

Серверная часть: OpenSSH, post-quantum и разблокировка DSA

OpenSSH прыгнул с 9.6p1 в 24.04 LTS до 10.2p1. Главные изменения — про криптографию следующих десяти лет:

• Поддержка гибридного post-quantum обмена ключами mlkem768x25519-sha256 — по умолчанию. Это та самая защита от «harvest now, decrypt later».
• Предупреждение при подключении без post-quantum-алгоритмов — чтобы администраторы видели устаревающие SSH-конфиги.
• Слабый DSA-алгоритм подписи удалён. Если у вас где-то остались DSA-ключи — не обновляйте хосты без миграции на ed25519 или RSA.
• PerSourcePenalties штрафует IP, которые не дожимают аутентификацию — мягкий встроенный fail2ban.
• Хост-ключи DSA больше не генерируются при установке.

На уровне ядра появились post-quantum подписи модулей через ML-DSA — CA для kernel modules защищён от будущих квантовых атак. Не ваша ежедневная боль, но LTS со сроком до 2036 обязана это учитывать.

Игры под Windows и ускорение видео

Для пользователей Steam Play и Wine в Ubuntu 26.04 — новый драйвер NTSYNC, эмулирующий примитивы синхронизации Windows NT. На синтетических тестах даёт заметный прирост FPS в играх, использующих многопоточность через WaitForSingleObject и подобные API.

Hardware-accelerated video encoding и decoding теперь включены по умолчанию для AMD и Intel через VA-API — никаких дополнительных пакетов. JPEG XL поддерживается из коробки.

Для Windows-пользователей, которые ставят Ubuntu рядом — улучшен dual boot с BitLocker. Установщик теперь видит зашифрованные разделы и корректно рядом с ними размещается.

Как обновиться и что проверить до апдейта

Путь обновления с точки зрения Canonical:

1. С Ubuntu 24.04 LTS (Noble Numbat) — прямое обновление через do-release-upgrade, Canonical запустит автоматическое предложение через пару недель после релиза.
2. С Ubuntu 25.10 (Questing Quokka) — тоже прямое обновление.
3. С Ubuntu 22.04 LTS (Jammy Jellyfish) — только через промежуточный апгрейд до 24.04 LTS, и уже потом на 26.04 LTS.
4. С Ubuntu 25.04 (EOL с января 2026) — сначала на 25.10, затем на 26.04 LTS. Либо — чистая переустановка.
5. Требования: для десктопа нужен двухъядерный 2 GHz, минимум 4 ГБ RAM и 25 ГБ свободного места. Если меньше — смотрите в сторону Xubuntu или Lubuntu.

Что стоит проверить до нажатия кнопки:

• Кастомные X11-утилиты, которые вы использовали годами, — под Wayland не все работают. Если зависите от autokey, xbindkeys или специфичных скриншотилок — протестируйте в live-сессии сначала.
• Кастомные сборки ядра или out-of-tree модули — Linux 7.0 требует обновления драйверов.
• DSA-ключи в SSH — мигрируйте на ed25519 до апдейта.
• NVIDIA-сетапы с проприетарным драйвером — Canonical обещает полный Wayland, но протестировать на своём железе безопаснее отдельно.

Выводы

Ubuntu 26.04 LTS — это не «ещё один LTS с обновлёнными пакетами». Это точка, в которой Canonical одновременно закрывает три длинных перехода: Wayland-only на десктопе, Rust в системных утилитах и официальная ARM64-платформа для десктопа. Плюс криптография нового поколения в SSH и ядре, которая закладывает основу на десятилетие вперёд — как раз под срок поддержки LTS.

Если вы в продакшне на 22.04 LTS — теперь двигаться через 24.04 LTS к 26.04 LTS без спешки, но планово: 22.04 LTS теряет стандартную поддержку в апреле 2027. Если на 24.04 LTS — обновление посимпатичнее, потому что промежуточные релизы пропустили большую часть «переходных болей».

Источники: Ubuntu 26.04 LTS release notes, Summary for LTS users, The Linux Kernel Archives.

Xilem вдохновлён архитектурами React, SwiftUI и Elm — но реализован на чистом Rust с GPU-рендерингом через Vello и wgpu. Никаких биндингов к Qt или GTK.

• Xilem — реактивный GUI-фреймворк на чистом Rust, вдохновлённый React/SwiftUI/Elm
• GPU-рендеринг через Vello (2D) + wgpu — нативная производительность без C++ зависимостей
• Два уровня: Xilem (высокоуровневый, для приложений) и Masonry (низкоуровневый, для фреймворков)
• Веб-бэкенд через xilem_web — те же компоненты работают и в браузере
• 5 000 звёзд на GitHub, активная разработка командой Linebender (Raph Levien)

Зачем ещё один GUI-фреймворк для Rust

GUI на Rust — давняя боль сообщества. Существующие решения делятся на две категории:

• Обёртки над C/C++ библиотеками (gtk-rs, Qt bindings) — работают, но тянут за собой чужую экосистему, сборочные зависимости и не-Rust-идиоматичный API
• Чисто Rust-решения (Iced, Druid, egui) — каждое с компромиссами: Iced ближе к Elm но ограничен, Druid заброшен, egui — immediate mode без retained state

Xilem занимает нишу retained-mode реактивного фреймворка: как React, но для десктопа, с типобезопасностью Rust и без virtual DOM overhead.

Архитектура: Xilem + Masonry

Проект состоит из двух слоёв:

• Masonry — низкоуровневый тулкит. Retained widget tree, event handling, layout passes. Можно использовать отдельно, если нужен полный контроль. Аналог: Flutter's rendering layer
• Xilem — высокоуровневый реактивный слой поверх Masonry. Лёгкое view tree, автоматическое обновление UI при изменении данных. Аналог: SwiftUI или React

Стек технологий под капотом:

• winit — кроссплатформенное создание окон (Windows, macOS, Linux, Web)
• Vello + wgpu — GPU-ускоренный 2D-рендеринг
• Parley + Fontique — текстовый стек (шрифты, layout, шейпинг)
• AccessKit — accessibility API (screen readers, навигация с клавиатуры)

Как выглядит код

Простой счётчик на Xilem:

Если вы знакомы с React или SwiftUI — паттерн узнаваем: состояние (&mut i32) передаётся в функцию, которая возвращает описание UI. Фреймворк сам определяет, что изменилось, и обновляет только нужные виджеты.

Веб-бэкенд

Через xilem_web те же компоненты работают в браузере. Xilem компилируется в WebAssembly и рендерит через DOM — подход, аналогичный Yew или Leptos, но с единой кодовой базой для десктопа и веба.

Текущий статус и ограничения

Xilem — экспериментальный проект. Команда прямо об этом говорит: API нестабилен и будет меняться. Вот что важно учитывать:

• Нет готовых виджетов для сложных сценариев (таблицы, rich text editor, drag-and-drop)
• Документация минимальна — основной источник знаний: примеры в репозитории
• Masonry (нижний слой) стабильнее Xilem — если нужна предсказуемость, начинайте с него
• Linux-зависимости: нужны пакеты wayland, libxkbcommon, vulkan-loader

Но для тех, кто следит за экосистемой Rust GUI, — это самый перспективный проект: активная разработка, сильная команда и продуманная архитектура.

Как попробовать

Выводы

Нативный GUI на Rust без обёрток над C++ — больше не фантазия. Xilem предлагает знакомую реактивную модель (React/SwiftUI), GPU-ускоренный рендеринг и кроссплатформенность из коробки. Проект экспериментальный, но архитектура и команда внушают доверие.

Если вы Rust-разработчик и давно ждали нормальный GUI-фреймворк — попробуйте Xilem и оцените, насколько он подходит под ваши задачи.

Нет. WebAssembly победил — просто не так, как все ожидали.

Главное: WebAssembly не заменил JavaScript в браузере — и не должен был. Его главная роль — мост между языками. Figma, Godot, Squoosh, Cloudflare Workers, Zellij — все они используют Wasm, но вы этого не замечаете — и это нормально.

Где Wasm уже работает

• Figma — конвертирует C++ кодовую базу в браузерное приложение + запускает пользовательские плагины в песочнице через QuickJS+Wasm
• Godot — сборка игр для веба
• Squoosh.app — использует C/C++ библиотеки сжатия изображений прямо в браузере
• Stackblitz — веб-контейнеры на Wasm
• Ruffle — эмулятор Flash в браузере
• Cloudflare Workers — запуск недоверенного кода через V8 isolates
• Zellij, Envoy, Lapce — экосистема плагинов на Wasm

Что такое WebAssembly на самом деле

WebAssembly — это язык. Более точно — байткод, похожий на JVM bytecode, но с меньшим API, более строгими гарантиями безопасности и без мнений о том, как управлять памятью.

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

Цель компиляции, не язык разработки

В Wasm компилируются десятки языков: Rust, C, Zig, Go, Kotlin, Java, C#. Даже интерпретируемые языки работают — их рантаймы компилируются в Wasm (Python через Pyodide, PHP, Ruby). Есть и языки, которые компилируются исключительно в Wasm: AssemblyScript, Grain, MoonBit.

Ваш браузер уже умеет запускать Wasm. Но есть и автономные рантаймы: Wasmtime, WasmEdge, Wasmer — аналоги JVM, но для Wasm.

Безопасность — главное преимущество

Всё внешнее взаимодействие — явные импорты от хоста. Это даёт изоляцию на уровне процесса внутри одного процесса. Cloudflare запускает недоверенный код через V8 isolates — старт в 100 раз быстрее, чем отдельный процесс. Fermyon заявляет о старте менее чем за миллисекунду.

Мост между языками — главная роль

Самое распространённое применение — мост между языками. В большинстве случаев Wasm прозрачен для вас — какая-то библиотека просто использует его в дереве зависимостей. Это обработка изображений, OCR, физические движки, рендеринг, базы данных, парсеры.

Ограничения

• В браузере Wasm работает через тот же пайплайн, что и JS — потолок на производительность
• Пересечение границы хост-программы стоит дорого — пост-мортем Zaplib показал, что постепенная миграция может не дать выигрыша
• Нет нативного строкового типа — системные API приходится пересоздавать, WASI помогает частично
• Самые компактные бинарники даёт Zig, самые тяжёлые без оптимизации — Rust

Почему кажется, что ничего не произошло

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

Фреймворки Blazor (.NET) и Leptos (Rust) позволяют писать веб-приложения без прямого контакта с JS. Стандартизация идёт: WasmGC уже в Chrome, Firefox и Safari; Component Model развивается в Bytecode Alliance.

FAQ

WebAssembly быстрее JavaScript?

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

Wasm заменит JavaScript?

Крайне маловероятно. JS остаётся языком браузера, Wasm дополняет его там, где нужны вычисления, безопасность или доступ к библиотекам из других языков.

С чего начать?

Попробуйте watlings — упражнения по ручному написанию WAT в стиле rustlings. А для практического применения — wasm-pack для Rust.

Источник: What Happened To WebAssembly — EmNudge

Как это работает

Момо нажимает клавиши на Bluetooth-клавиатуре. Сигнал проходит через Raspberry Pi 5 в небольшое Rust-приложение DogKeyboard, которое фильтрует спецклавиши и передает ввод ИИ Claude.

После определенного количества символов система:

• отправляет текст в Claude Code,
• запускает сборку игры (на Godot 4.6, логика — на C#),
• выдает собаке лакомство через автоматическую кормушку,
• звуковым сигналом сообщает, что ИИ готов к следующему «брифингу».

Один цикл — и еще один уровень готов. На создание играбельной сборки уходит 1–2 часа.

Главный трюк — не в собаке

Самое сложное, по словам Лика, было не научить собаку «долбить» клавиши, а убедить Claude воспринимать бессмысленный ввод как осмысленные команды.

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

Это глупость или в этом все же что-то есть?

Формально Момо не «кодит». Но эксперимент показывает, насколько гибко современные агенты могут интерпретировать даже абсурдный ввод.

Да и в целом, как фановый проект, ставший популярным мемом — отличное отражение времени.

Об этом Миллер написал на своем личном сайте, отметив, что уже более 30 лет остается фактически единственным мейнтейнером одного из ключевых инструментов Unix- и Linux-систем.

Что произошло

До февраля 2024 года разработку sudo спонсировала компания Quest Software (позже — One Identity). После завершения сотрудничества и ухода Миллера из компании, финансирование прекратилось. С тех пор поддержка проекта ведется без стабильного источника дохода.

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

Почему это проблема

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

За последние годы в ней неоднократно находили серьезные уязвимости, включая баги, позволявшие локальным пользователям получать root-доступ. Некоторые из них существовали в коде более 10 лет.

Именно из-за регулярных проблем с безопасностью в экосистеме появился sudo-rs — новая реализация утилиты на Rust, ориентированная на безопасную память. В Ubuntu 25.10 она уже используется по умолчанию.

Что будет дальше

Миллер подчеркивает, что не планирует бросать sudo, но и не видит очевидного преемника. После истории с закладкой в xz-utils, он с осторожностью относится к передаче проекта сторонним разработчикам.

При этом он считает, что в долгосрочной перспективе именно sudo-rs станет основной версией инструмента. Он уже даже сотрудничает с командой этого проекта.

Меня зовут Максим, я не совсем разработчик, хотя и работаю в IT.

Это история о том, как я впервые сделал настоящее (наверное, если его вообще можно таковым считать с учётом использования Tauri) приложение под macOS и Windows и о боги даже скомпилировал его под RedOS

Честно, я пытался собрать его и под АльтЛинукс, но не осилил корректную работу с глобальными хоткеями.

Возможно, соберусь силами, мыслями и помощью ИИ и всё-таки это поправлю 🙂

Было больно, интересно и очень познавательно.

По воле случая(работы) мне часто приходится использовать однотипные ответы для коллег на базовые вопросы и типовые вещи. Думаю, многие с таким сталкиваются, ну или не многие(везет же вам!)

И каждый раз это выливается в:

• копипаст,
• переключение окон,
• поиск нужного файла, как в посте так и на компе

Да, есть готовые решения, но они меня не устроили: где-то оверхед по функционалу, где-то я просто забивал болт (будем честны)

Плюс был ещё один минус — отсутствие нормальной мультиплатформы.

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

Ну и, конечно, чтобы это было мультиплатформенно.

Изначально проект писался на C# под Windows. Он даже работал, и в целом всё было неплохо — кроме внешнего вида (привет дефолтным формам Visual Studio).

А потом у меня появился Mac, и стало понятно: нужно одно приложение, один внешний вид, привычные команды и одинаковый функционал на всех платформах.

Начались изыскания.

В теории можно было использовать .NET и Avalonia, но не срослось.

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

Я не осилил это зло и… просто забил.

Вообще забил на приложение и идею его делать.

Спустя время мне на глаза попался Tauri.

Я немного потыкался в него и мне понравилось:

• размеры билдов небольшие
• не тащим за собой целый браузер ради маленького desktop-приложения (в отличие от Electron)
• UI на обычном HTML/CSS
• ну и как тут не залететь в хайп-поезд под названием Rust 🙂

Так, собственно, за месяц неспешной работы на свет появился EasyPaste.

Что было самым сложным

Честно не UI и даже не логика(ведь приложение простое).

Самое сложное:

• сборки под разные платформы(первый раз таким занимался, да еще и через воркфлоу)
• системные зависимости
• tray и hotkeys
• и просто понять, как правильно делать вещи в Tauri

Что же такое EasyPaste

По факту это библиотека шаблонов со следующим функционалом:

• хранение шаблонов в виде дерева (разделы и файлы)
• открытие через быстрое окно шаблонов
• поиск по названию, тексту и тегам
• избранные шаблоны
• работа с форматированным текстом (жирный, курсив, таблицы)
• вложения файлов к шаблонам
• перетаскивание текста или файлов прямо в любое приложение

Для кого это

Изначально я делал это для себя, но довольно быстро понял, что инструмент полезный и подойдет для:

• служб поддержки
• sales-менеджеров
• HR и рекрутеров
• людей, которые часто отвечают на типовые вопросы

Почему вообще я написал весь этот текст

Сейчас EasyPaste уже работает и используется, но я не хочу превращать его в продукт в вакууме.

Мне очень нужен живой фидбек:

• удобно ли
• чего не хватает
• что лишнее
• где больно.

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

Я не обещаю «революцию», но, возможно вы поможете сделать продукт более полезным и функциональным.

Скачать приложение и получить свежий триальный ключ можно на сайте:

Буду очень благодарен за любой фидбек 🙏

PS ах да тк я зажопил(будем честны) деньги на сертификаты, то будут алерты, но настанут светлые дни и Майкрософт мне подтвердить уз, чтобы я через Azure мог подписывать приложения за 9.99$ в месяц и оплачу Apple Developer Account(как большие разработчики), то все проблемы исчезнут а пока вот вам лайфхаки:

Windows: можно нажать «Доверяю / Установить», проверив любым понравившимся антивирусом Если будет спрос то выложу портабл версию без инсталятора

macOS (Intel и ARM): выполните в терминале после того как перенесете приложение в Applications

*WhatsApp заменил более 160 000 строк C++-кода на Rust в критически важной части приложения — обработке медиафайлов. Новый код уже развернут на миллиардах устройств: от Android и iOS до веба, десктопа и носимых гаджетов.

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

Откуда вообще взялась проблема

История тянется с 2015 года и уязвимости Stagefright в Android. Тогда выяснилось неприятное: достаточно отправить специально собранный видеофайл и он выполнит код на устройстве жертвы еще до того, как пользователь что-то нажмет.

Проблема была в системных медиабиблиотеках операционной системы. Именно поэтому приложения вроде *WhatsApp не могли решить ее самостоятельно.

После этого в *WhatsApp появился собственный C++-модуль wamedia, который проверял медиафайлы на соответствие стандартам, чтобы не скормить ОС заведомо опасный контент.

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

Почему именно Rust

В *WhatsApp довольно рано сделали неприятный, но честный вывод: значительная часть критических багов связаны с банальными ошибками работы с памятью в C и C++. Rust эту категорию проблем убирает на уровне языка.

Вместо аккуратного «подкручивания гаек», разработчики пошли чуть более радикальным путем: переписали медиабиблиотеку целиком, параллельно поддерживая две реализации — на C++ и на Rust.

Их прогоняли через дифференциальный фаззинг, тесты и сравнение поведения, пока результаты не совпали.

Что получилось на выходе

Итог оказался даже лучше ожидаемого. 160 000 строк на C++ превратились примерно в 90 000 строк на Rust. И это уже с тестами.

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

Тем не менее, библиотеку полностью выкатили в прод. Сейчас этот Rust-код ежемесячно доставляется на миллиарды устройств, включая *WhatsApp, *Messenger и *Instagram.

В *Meta прямо называют это крупнейшим клиентским деплоем Rust, о котором им известно.

Зачем это пользователю, который «просто шлет мемы»

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

Она отсекает битые и нестандартные структуры, ловит подмену типов (когда «картинка» на деле исполняемый файл), отдельно помечает рискованные форматы вроде PDF со скриптами и вложениями.

По сути, это еще один слой защиты. Пользователь его не видит, но это и не нужно.

Его формулировка предельно прямолинейна: цель — убрать каждую строку C и C++ к 2030 году и заменить их кодом на Rust.

Microsoft собирается переписать крупнейшие и самые критичные системы. В том числе компоненты Windows и прочие низкоуровневые продукты.

Ставка на ИИ и автоматическую переработку кода

Ключевым инструментом в этом процессе станет ИИ. По словам Ханта, Microsoft уже выстроила инфраструктуру, которая объединяет алгоритмы анализа кода и ИИ-агентов.

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

Внутренняя цель проекта звучит амбициозно: «1 инженер, 1 месяц, 1 миллион строк кода». По утверждению Microsoft, базовая часть этой инфраструктуры уже работает — как минимум для задач на понимание и анализа кода.

Почему именно Rust

Переход на Rust не стал сюрпризом. Еще в 2023 году Microsoft объявила, что новые компоненты ядра Windows больше нельзя писать на C и C++. Тогда же Марк Русинович, CTO Azure, прямо заявил: компания «полностью делает ставку на Rust».

Причина банальна — Rust обеспечивает безопасность памяти по умолчанию. Для Microsoft, которая десятилетиями сталкивается с уязвимостями классов use-after-free и buffer overflow, это банально стратегический выбор.

Кто будет переписывать код Microsoft

Хант уже ищет Principal Software Engineer, который поможет развивать инфраструктуру автоматического перевода C и C++ в Rust.

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

Команда входит в группу Future of Scalable Software Engineering внутри Microsoft CoreAI. Ее задача — не только переписать код компании, но и создать инструменты, которые позволят устранять технический долг «в промышленных масштабах».

Баг находился в Rust-реализации Binder — ключевого механизма межпроцессного взаимодействия в Android. Ошибка могла приводить к повреждению памяти и, как следствие, к kernel panic.

Исправление уже принято в стабильное дерево Linux и распространяется через обновления.

Что пошло не так

Проблема возникла в логике работы со списком death_list, который используется для отслеживания завершенных объектов Binder.

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

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

Это создавало гонку данных и приводило к повреждению указателей prev/next в связанном списке.

В результате происходило обращение к невалидным адресам памяти внутри ядра. В логах такие ситуации проявлялись как ошибки обработки страничных запросов и завершались kernel panic.

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

Binder — один из базовых компонентов Android. Любые ошибки в его реализации потенциально затрагивают миллионы устройств.

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

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

Как баг исправили

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

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

Таким образом, опасный сценарий с одновременной модификацией списка стал невозможен.

Что это значит для Rust в ядре

Этот инцидент не отменяет преимуществ Rust, но служит напоминанием: безопасность — это не только язык, но и архитектура кода.

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

Для ядра Linux это еще один аргумент в пользу осторожного и постепенного расширения Rust-кода — с тщательным аудитом, ревью и минимизацией unsafe-участков.

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

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

Этот вопрос важен для меня, потому что я не хочу выбирать язык по чек-листу, будто покупаю увлажнитель воздуха. Меня волнует создание софта и мои инструменты. Делая свои компромиссы, языки выражают набор ценностей. Я хочу понять, какие ценности резонируют со мной.

Этот вопрос также помогает прояснить разницу между языками, которые на первый взгляд сильно пересекаются по возможностям. Судя по количеству вопросов статей вроде “Go или Rust” и “Rust или Zig”, люди тоже не понимают, что происходит. Сложно запомнить, что язык X лучше для веб-сервисов, потому что у него есть фичи a, b и c, а у языка Y только a и b. Гораздо проще запомнить, что язык X лучше для веб-сервисов, потому что язык Y создан человеком, который ненавидит интернет (условно) и считает, что нужно вырубить всю сеть.

Я собрал здесь мнение о трёх языках, с которыми недавно экспериментировал: Go, Rust и Zig. Я попытался превратить свой опыт с каждым языком в общий вывод о том, что этот язык представляет из себя и насколько хорошо реализует свои ценности. Да, это упрощение, но кристаллизация упрощённых предубеждений — именно то, что я здесь и делаю.

Go: минимализм для корпораций

Go выделяется своим минимализмом. Его называют “современным C”. Go не похож на C, потому что у него есть сборщик мусора и полноценная среда выполнения, но он похож на C тем, что весь язык помещается в голове.

Весь язык помещается в голове, потому что в Go очень мало возможностей. Долгое время Go был известен отсутствием дженериков. Их наконец добавили в Go 1.18, но только после 12 лет, в течение которых люди умоляли это сделать. Другие возможности, обычные для современных языков — например, размеченные объединения (tagged unions) или синтаксический сахар для обработки ошибок — в Go так и не появились.

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

Ещё один пример минимализма Go — тип slice. И в Rust, и в Zig есть slice, но это толстые указатели (fat pointers) и только они. В Go slice — это толстый указатель на непрерывную последовательность в памяти, но slice также может расти. То есть он объединяет функциональность типа Vec<T> из Rust и ArrayList из Zig. Кроме того, поскольку Go управляет памятью за вас, он сам решает, где будет жить память вашего slice — в стеке или куче. В Rust или Zig вам придётся сильно задуматься, где живёт ваша память.

История происхождения Go, насколько я понимаю, примерно такая: Роб Пайк устал ждать компиляции проектов на C++ и устал от ошибок, которые другие программисты Google делали в тех же проектах на C++. Поэтому Go прост там, где C++ перегружен. Это язык для рядовых программистов, спроектированный быть достаточным для 90% задач и при этом простым для понимания, даже (или особенно) при написании конкурентного кода.

Я не использую Go на работе, но думаю, что должен бы. Go минималистичен ради корпоративного сотрудничества. Я не считаю это недостатком — создание софта в корпоративной среде имеет свои вызовы, которые Go решает.

Rust: максимализм ради безопасности

Если Go минималистичен, то Rust максималистичен. Популярный слоган Rust — “абстракции с нулевой стоимостью” (zero-cost abstractions). Я бы дополнил: “абстракции с нулевой стоимостью, и их очень много!”

У Rust репутация сложного для изучения языка. Я согласен с Джейми Брэндоном, который пишет, что Rust делает сложным не система времён жизни (lifetimes), а количество концепций, запиханных в язык. Я не первый, кто приводит в пример этот конкретный комментарий на GitHub, но он идеально показывает концептуальную плотность Rust:

Тип Pin<&LocalType> реализует Deref, но не реализует DerefMut. Типы Pin и & помечены #[fundamental], так что возможна реализация DerefMut для Pin<&LocalType>>. Вы можете использовать LocalType == SomeLocalStruct или LocalType == dyn LocalTrait, и можете привести Pin> к Pin>. (Действительно, два слоя Pin!!) Это позволяет создать пару “умных указателей, реализующих CoerceUnsized, но имеющих странное поведение” на стабильной версии (Pin<&SomeLocalStruct> и Pin<&dyn LocalTrait> становятся умными указателями со «странным поведением», и они уже реализуют CoerceUnsized).

Конечно, Rust не пытается быть максималистичным просто так, как Go пытается быть минималистичным. Rust сложный, потому что пытается достичь двух целей — безопасности и производительности — которые частично противоречат друг другу.

Цель производительности понятна сама по себе. Что означает “безопасность” — менее очевидно, по крайней мере для меня (хотя, может быть, я просто слишком долго писал на Python). “Безопасность” означает “безопасность памяти” — идею, что вы не должны иметь возможность разыменовать невалидный указатель или сделать двойное освобождение памяти. Но это также означает больше. “Безопасная” программа избегает всего неопределённого поведения (undefined behavior, или UB).

Что такое ужасное UB? Лучший способ понять это — вспомнить, что для любой работающей программы ЕСТЬ СУДЬБЫ ХУЖЕ СМЕРТИ. Если в программе что-то идёт не так, немедленное завершение — это прекрасно! Потому что альтернатива, если ошибка не поймана — ваша программа переходит в сумеречную зону непредсказуемости, где её поведение может определяться тем, какой поток выиграет следующую гонку данных, или тем, какой мусор оказался по конкретному адресу памяти. Теперь у вас хайзенбаги и дыры в безопасности. Очень плохо.

Rust пытается предотвратить UB без потери производительности во время выполнения, проверяя всё во время компиляции. Компилятор Rust умный, но не всеведущий. Чтобы проверить ваш код, ему нужно понимать, что код будет делать во время выполнения. Поэтому в Rust есть выразительная система типов и множество трейтов, которые позволяют объяснить компилятору то, что в другом языке было бы просто видимым поведением кода во время работы.

Это делает Rust сложным, потому что вы не можете просто взять и сделать что-то! Вы должны узнать, как Rust это называет — найти нужный трейт или что-то ещё — и реализовать это так, как Rust ожидает. Но если вы это делаете, Rust может дать гарантии о поведении вашего кода, которые другие языки не дают, а это в зависимости от приложения может быть критично. Он также может давать гарантии о чужом коде, что делает использование библиотек в Rust простым и объясняет, почему проекты на Rust имеют почти столько же зависимостей, сколько проекты в экосистеме JavaScript.

Zig: свобода и контроль

Из трёх языков Zig самый новый и наименее зрелый. На момент написания статьи Zig на версии 0.14. У его стандартной библиотеки почти нет документации, и лучший способ научиться её использовать — читать исходный код напрямую.

Не знаю, правда ли это, но мне нравится думать о Zig как о реакции одновременно на Go и Rust. Go прост, потому что скрывает детали того, как работает компьютер. Rust безопасен, потому что заставляет прыгать через свои обручи. Zig освободит вас! В Zig вы контролируете вселенную, и никто не может указывать, что делать.

И в Go, и в Rust выделить объект в куче просто — достаточно вернуть указатель на структуру из функции. Выделение памяти неявное. В Zig вы выделяете каждый байт сами, явно. (В Zig ручное управление памятью.) У вас больше контроля, чем даже в C: чтобы выделить байты, нужно вызвать alloc() на конкретном виде аллокатора, то есть вы должны выбрать лучшую реализацию аллокатора для вашего случая.

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

Неопределённое поведение всё ещё важно в Zig

Zig называет его “нелегальным поведением” (illegal behavior). Он пытается обнаружить его во время выполнения и обрушить программу, когда это происходит. Для тех, кого беспокоит стоимость таких проверок по производительности, Zig предлагает четыре разных “режима релиза” на выбор при сборке программы. В некоторых проверки отключены. Идея в том, что вы можете запустить программу достаточно раз в проверяемых режимах, чтобы иметь разумную уверенность: в непроверяемой сборке нелегального поведения не будет. Это кажется мне очень прагматичным дизайном.

Ещё одно различие между Zig и двумя другими языками — отношение Zig к объектно-ориентированному программированию. ООП давно не в моде, и Go, и Rust избегают наследования классов. Но в Go и Rust достаточно поддержки других идиом ООП, чтобы вы могли построить программу как граф взаимодействующих объектов, если захотите. В Zig есть методы, но нет приватных полей структур и нет языковой возможности для полиморфизма во время выполнения (динамической диспетчеризации), хотя std.mem.Allocator просто умирает стать интерфейсом. Насколько я могу судить, эти исключения намеренны; Zig — язык для дата-ориентированного дизайна (data-oriented design).

Ещё одна вещь, которую я хочу сказать, потому что она открыла мне глаза: может показаться безумием создавать язык программирования с ручным управлением памятью в 2025 году, особенно когда Rust показал, что сборка мусора не нужна и компилятор может всё сделать за вас. Но это дизайнерский выбор, тесно связанный с выбором исключить возможности ООП. В Go, Rust и множестве других языков вы обычно выделяете маленькие кусочки памяти за раз для каждого объекта в графе объектов. У вашей программы тысячи маленьких скрытых malloc() и free(), и, следовательно, тысячи разных времён жизни. Это RAII. В Zig может показаться, что ручное управление памятью потребует много утомительной, подверженной ошибкам работы, но это так только если вы настаиваете на привязке выделений памяти к каждому маленькому объекту. Вместо этого вы можете просто выделять и освобождать большие куски памяти в определённых разумных точках программы (например, в начале каждой итерации цикла событий) и использовать эту память для данных, с которыми работаете. Именно этот подход и поощряет Zig.

Многие люди не понимают, зачем нужен Zig, если уже есть Rust. Дело не только в том, что Zig пытается быть проще. Думаю, разница более важная. Zig хочет, чтобы вы вырезали ещё больше объектно-ориентированного мышления из своего кода.

У Zig весёлая, подрывная атмосфера. Это язык для разрушения корпоративной классовой иерархии (объектов). Это язык для мегаломанов и анархистов. Мне он нравится. Надеюсь, он скоро выйдет в стабильный релиз, хотя текущий приоритет команды Zig — переписать все свои зависимости. Не исключено, что они попытаются переписать ядро Linux, прежде чем мы увидим Zig 1.0.

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

Решение было принято на конференции Kernel Maintainers Summit, где мейнтейнеры обсудили итоги внедрения языка. Там же они пришли к выводу, что Rust доказал свою практическую пригодность.

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

Теперь же разработка компонентов ядра на Rust официально считается поддерживаемым направлением, наравне с кодом на Cи.

Три года активного внедрения

Наиболее активная фаза внедрения Rust началась в 2022 году, когда в ядре Linux версии 6.1 появилась возможность писать драйверы и модули на этом языке.

За последующие три года количество Rust-кода в ядре заметно выросло. За это время были реализованы:

• абстракции для написания драйверов видеокарт, сетевых и USB-устройств;
• экспериментальные драйверы Nova для видеокарт NVIDIA и Tyr для ARM Mali;
• драйвер rust_ext2 для поддержки файловой системы Ext2.

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

Сопротивление и смена позиции Торвальдса

Продвижение Rust сопровождалось жесткими спорами внутри сообщества.

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

Создатель Linux Линус Торвальдс долгое время публично поддерживал скептиков и резко критиковал сторонников Rust.

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

Почему выбор пал на Rust

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

При этом Rust остается нишевым языком: в рейтинге TIOBE за декабрь 2025 года он занимает 17-е место, тогда как Cи и C++ по-прежнему входят в мировую тройку лидеров.

Что это значит для будущего ядра

Rust не заменит Cи в Linux и не станет «языком ядра».

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

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

Но теперь эта «шутка» стала наглядной — проект Stacktower превращает рисунок в настоящую визуализацию зависимостей.

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

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

Как работает Stacktower

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

Пользователь может загрузить зависимости своих приложений — например, на Python или JavaScript — и увидеть, что будет, если убрать даже один элемент.

На странице приводится пример для Node.js:

приложение зависит от Express → Express зависит от body-parser → body-parser зависит от qs → и так далее

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

Есть и Python-вариант:

импорт Flask тянет Werkzeug, Jinja2, MarkupSafe, Click и еще несколько пакетов. А те, в свою очередь, имеют собственные зависимости.

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

Автор подчеркивает: цель проекта — не критиковать экосистемы, а показать их реальное устройство.

Стек современных приложений неизбежно сложен и даже крошечный модуль может стать критически важным. Именно так в 2022 году случайное удаление библиотеки left-pad временно «сломало» огромный кусок JavaScript-мира.

Stacktower превращает эту абстрактную проблему в понятный визуальный эффект: убираешь одну зависимость — рушится вся конструкция.

Комьюнити уже подхватило идею

Проект быстро разошелся по Reddit, Hacker News и X: разработчики делятся скриншотами своих «башен», спорят о хрупкости экосистем и обсуждают, стоит ли пересматривать подход к зависимости.

Кто-то предлагает добавить поддержку Rust и Go, другие мечтают о корпоративной версии инструмента для визуального аудита безопасности.

Изучить проект подробнее можно на его странице на GitHub.

Из-за накопившихся уязвимостей проект переходит на новый алгоритм — Counter Galois Onion (CGO). Он уже внедрен в Arti (реализацию Tor на Rust) и в классическую C-реализацию.

Почему tor1 небезопасен

Tor1 использует режим AES-CTR. Он достаточно быстрый, но одновременно с этим и уязвимый к ряду атак. Авторы выделяют три ключевые проблемы:

• Тегирование трафика (tagging attacks). Отсутствие hop-by-hop аутентификации делает поток ячеек изменяемым. Вмешавшись, атакующий может деанонимизировать пользователя.
• Нет мгновенной прямой секретности. Одни и те же ключи живут весь срок цепочки. Получив ключ, злоумышленник способен расшифровать все предыдущие данные.
• Слабая аутентификация. Подпись была всего 4 байта на SHA-1 — это 1 шанс из 4 млрд пройти незамеченным. Для криптографии — ничтожно мало.

Что меняет новый CGO

CGO решает проблемы комплексно. Алгоритм вводит две ключевых идеи:

1. Irreversible Update. Ключи обновляются при каждом новом сообщении и старые версии невозможно восстановить. Это дает мгновенную «совершенную прямую секретность».
2. Wide-block шифрование. Любая попытка изменить хотя бы байт приводит к полной порче расшифровки — атаки тегирования становятся бессмысленны.

Также MD4 заменен на полноценный 16-байтный аутентификатор.

Когда изменения доберутся до пользователей

Tor уже применил CGO в Arti и в реализации на C. Tor Browser, Tails и Orbot постепенно перейдут на новый метод автоматически — пользователю не надо ничего настраивать вручную.

Для большинства это будет тихое, но крайне важное обновление: впервые за долгие годы Tor получает серьезное усиление защиты на уровне базовой криптографии.

Об этом он рассказал в интервью на Open Source Summit в Сеуле.

«Я уже 20 лет не программист»

Торвальдс признался, что своей основной задачей давно не считает написание кода:

«Около 20 последних лет я не программист. Я смотрю на Git со стороны, а в ядре моя роль — соглашаться или отказывать».

Он отметил, что все чаще приходится «говорить да» новым идеям, несмотря на сопротивление старых мейнтейнеров. Это можно заметить, например, в вопросе интеграции Rust в ядро Linux.

Что он думает об ИИ и разработке

Несмотря на то, что сам Линус не пользуется ИИ-ассистентами, он не исключает, что такие инструменты могут пригодиться в ядре. Основная проблема ИИ сейчас, по его словам — не код, а инфраструктура:

«ИИ-краулеры сильно захламляют наши ресурсы, притаскивают баги и репорты, которых не существует».

При этом Торвальдс позитивно оценивает влияние ИИ-бума на индустрию: из-за него NVIDIA стала «значительно более хорошим игроком» в Linux-сообществе.

А что с вайб-кодингом?

Именно здесь Линус удивил больше всего. Он сказал, что относится к вайб-кодингу «довольно позитивно», потому что он:

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

Но использовать это в реальных проектах — гиблая идея:

«Это может быть ужасным решением с точки зрения поддержки».

По мнению Торвальдса, вайб-кодинг — отличная «точка входа», но плохой фундамент для сложных систем вроде ядра Linux.

Вердикт Линуса

Он видит ИИ как обычный инструмент — как когда-то компиляторы, которые избавили разработчиков от необходимости писать код ассемблера вручную:

«ИИ не убьет профессию. Как и компиляторы, он просто повысит продуктивность».

Если PEP примут, Python впервые за историю станет «двуязычным» проектом — частично на C, частично на Rust.

Зачем Python нужен Rust

Разработчики приводят несколько причин:

• Безопасность памяти. Rust устраняет категории ошибок, привычные для C: use-after-free, гонки, переполнения.
• Подготовка к free-threaded Python. Переход к работе без GIL требует безопасных примитивов — Rust подходит идеально.
• Производительность. Rust позволяет создавать быстрые структуры данных без ручного менеджмента памяти.
• Современный стек. Linux, Android и Firefox уже используют Rust в системных компонентах — Python догоняет тренд.
• Поддержка долгосрочного развития CPython. Сложность кода растет, а Rust упрощает сопровождение.

Что именно планируют делать

Стоит отметить, что Rust не планируют использовать в качестве полной замены C — появится возможность использовать оба языка. В идеале, должен получиться симбиоз:

• Crate cpython-sys. Это набор автоматически сгенерированных привязок (FFI-слоя), которые позволяют Rust-коду безопасно «общаться» с внутренним API CPython.
• Поддержка модулей на Rust. Некоторые части стандартной библиотеки можно будет писать и подключать так же, как C-модули — только на Rust.
• Прозрачное разделение зон безопасности. «Безопасный» Rust будет использоваться по максимуму, а unsafe — только там, где нужно напрямую взаимодействовать с C-частями интерпретатора.

Уже есть рабочий пример — модуль _base64 на Rust, который оказался быстрее варианта на C.

Переходный план

Если PEP утвердят, переход займет три релиза:

• Python 3.15 — предупреждение при сборке без Rust.
• Python 3.16 — Rust остается опциональным, но его отключение потребует отдельного флага.
• Python 3.17 — Rust становится обязательной частью сборки CPython.

То есть через два релиза Python не соберется там, где нет Rust.

Какие есть проблемы

В обсуждении упоминают несколько рисков. Например, циклическая зависимость при сборке — Rust требует Python, Python требует Rust.

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

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

Что это значит для сообщества

Для пользователей Python почти ничего не изменится. А вот для разработчиков интерпретатора это станет одним из самых крупных сдвигов в истории проекта.

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

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

Что произошло

По данным Phoronix, баг впервые был зафиксирован в приватном отчете разработчиков Ubuntu и получил идентификатор CVE-2025-64170. Позже отчет стал публичным — вместе с фиксом от авторов проекта sudo-rs.

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

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

Как исправили

В обновлении sudo-rs 0.2.10, которое уже доступно пользователям Ubuntu 25.10, исправлено несколько ошибок:

• добавлено очищение памяти с паролем при выходе или тайм-ауте;
• переработан механизм обратной связи с пользователем (feedback) — теперь он реализован через enum;
• исправлено поведение клавиши Backspace при пустом вводе;
• улучшено удаление содержимого буфера перед завершением чтения.

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

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

Проблема стала очередным эпизодом в череде трудностей Ubuntu 25.10, связанных с переходом системных инструментов на Rust. Ранее пользователи сталкивались с ошибками в rust-coreutils, которые ломали автообновления и некоторые базовые команды.

Что делать пользователям

Ubuntu уже распространила обновление безопасности (SRU), которое устраняет уязвимость.

Пользователям рекомендуется как можно скорее выполнить обновление пакета sudo-rs до версии 0.2.10:

Переход на Rust-инструменты должен повысить безопасность и устойчивость системы, но инцидент с sudo-rs показывает, что новая архитектура еще проходит этап «обкатки». Как итог — ошибки все еще возможны.

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

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

Кем должен быть ML‑специалист — математиком или программистом

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

Сколько математики нужно в ML

Без линейной алгебры, матриц, теории вероятностей и дифференцирования не получится даже понимать, что именно делает модель. Эти базовые знания можно освоить за полгода‑год, но важно не просто формулы выучить, а развить интуицию.

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

Как развиваться в ML и не застрять на старте

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

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

Развитие начинается, когда ты сам задаёшь вопросы вроде «почему слой ведёт себя так», «как меняются веса», «что даёт нормализация». Именно через эти вопросы начинается путь к инженеру, а не к пользователю фреймворков и вайбкодингу.

Что с большими языковыми моделями

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

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

LLM полезны там, где есть конкретный сценарий и метрики: если видно, что саммари экономит время менеджера или классификатор улучшает отклик в CRM, тогда инструмент оправдан.

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

Какие методы сейчас реально работают

По данным Александра, для бизнес‑задач нет универсального решения, но есть набор проверенных инструментов. Если данные категориальные — лучше использовать градиентный бустинг, например CatBoost или XGBoost. Эти методы часто точнее нейросетей и требуют меньше подгонки.

Хороший результат даёт комбинация моделей. Например, можно взять LLM для генерации эмбеддингов, а дальше подать их в логистическую регрессию или тот же бустинг. Такой гибрид работает быстрее и требует меньше ресурсов, но при этом сохраняет качество.

Если данных мало или вычислительных мощностей не хватает, помогает байесовский подход. Он хорошо ведёт себя на шумных и несбалансированных выборках, где другие методы не подходят или не работают. Отдельное направление — оптимизация моделей. Уменьшение моделей через compression позволяет запускать их на обычных серверах без потери точности — актуально для компаний без GPU‑кластеров.

Когда ML действительно нужен

Не любую задачу стоит решать через машинное обучение. Александр объясняет: если алгоритм можно описать правилами, лучше начинать с классики. Но когда формулы не работают — например, при обработке изображений или машинном переводе — подходит ML. Главное, чтобы были данные: сотни или тысячи пар примеров «правильно» и «неправильно». Без них обучение просто не из чего строить.

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

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

Что делать, если данных мало

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

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

Где ML приносит реальную пользу бизнесу

Александр приводит примеры из практики Bitrix24. Один из самых ощутимых по эффекту — скоринг лидов и сделок. Там используется логистическая регрессия и градиентный бустинг. Метод простой, но позволяет заметно повысить точность прогнозов и напрямую влияет на выручку.

Вторая история — классификация запросов техподдержки. Решение построено на основе алгоритма шинглов и простой модели, оно работает стабильно и подходит для разных языков.

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

Пример: текст "машина" при длине шингла 3 даёт набор шинглов: "маш", "аши", "шин", "ина".

Дальше можно сравнивать эти множества и вычислять похожесть, например через коэффициент Жаккара.

В Bitrix24 метод шинглов помогает системе одинаково понимать обращения пользователей на разных языках или с разными формулировками.

Как проверить, что модель действительно работает

Без тестирования и валидации никакая модель не считается готовой. Первое, с чего нужно начинать, — сравнение с базовой линией. Самый простой пример — случайный классификатор. Если ваша модель даёт результат не лучше рандома, значит, смысла в ней нет.

Дальше важно понимать метрики: precision, recall, F1 и другие. Они показывают, на сколько точно модель попадает в нужные ответы и сколько ложных срабатываний допускает. Не стоит воспринимать метрики как формальности — от них зависит, будет ли решение полезно для бизнеса.

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

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

Какие инструменты и ресурсы использовать

Основная экосистема машинного обучения сегодня крутится вокруг Python, и начинать логично с него. Хороший старт — realpython.com, где подробно объясняются основы языка и приёмы написания читаемого кода.

Но нужно развивать инженерные привычки. Александр рекомендует читать книги вроде Effective Java Джошуа Блоха, чтобы прокачивать культуру разработки и понимать многопоточность. Даже если вы работаете с Python, знания из других языков помогают писать лучше и думать о производительности.

Из библиотек стоит освоить PyTorch или TensorFlow для нейросетей и scikit‑learn для классического ML. При росте нагрузки полезно переписывать критичные части на Java или Rust — это уменьшает задержки и делает систему устойчивее.

Как набраться практики и выбрать правильную команду

Лучший способ вырасти в ML — попасть туда, где есть реальные данные и сильная инженерная культура.

Идите в крупные компании вроде Яндекса, ВК, Сбера или X5 — там есть инфраструктура, процессы и опытные коллеги. Просто читать статьи и собирать pet‑проекты недостаточно, если не сталкиваешься с настоящими продуктами и их ограничениями.

Главный признак хорошей команды — наличие тестов, QA и понятного кода. Если в отделе этого нет, нужно уходить, иначе быстро потеряешь профессиональный уровень. ML уже давно не чудо‑технология, а инструмент. И успех зависит не от того, кто первым применил нейросеть, а от того, чья команда умеет держать систему в рабочем состоянии и проверять результаты каждый день.

В конце хочется спросить: как вы сами учились или учитесь ML — через курсы, проекты или книги? Делитесь своим опытом и мыслями в комментариях — обсудим, какие подходы к обучению и работе в ML работают сегодня.

ZDNET выбрал пять самых красивых дистрибутивов, которые и без «допиливания» выглядят впечатляюще.

KDE Neon

Флагман для поклонников Plasma. Никаких излишеств — только чистый, минималистичный интерфейс KDE, таким, каким его задумали.

Neon показывает, что иногда красота — в сдержанности.

EndeavourOS

Arch-база и слегка «космическая» тема оформления. Темная цветовая схема, аккуратные акценты, лаконичные панели.

По мнению автора, это один из немногих дистрибутивов, где «Темную тему» не хочется менять сразу после установки.

Pop!_OS с окружением COSMIC

System76 переписала интерфейс на Rust и добавила гибкости. В итоге новый COSMIC — это GNOME-подобная оболочка, которую легко подстроить под себя.

Но что важнее — ее можно можно и не менять. По умолчанию Pop!_OS уже выглядит стильно и современно.

ElysiaOS

Arch + Hyperland + аниме. Да, именно так: дистрибутив с милым, ярким, кавайным дизайном.

По словам автора, хоть в дистрибутиве и куча визуальных деталей, это не минус, а скорее даже плюс. Экзотика? Да. Зато запоминается.

BigLinux

Базируется на Manjaro и использует KDE Plasma. Простая, сбалансированная эстетика без визуальной перегрузки.

Во время установки можно выбрать оформление под macOS, GNOME или Ubuntu. Красивый, удобный и дружелюбный дистрибутив.

Интересный факт. Почти все дистрибутивы в списке — с KDE Plasma. Похоже, именно Plasma сегодня задает стандарт красоты в Linux-мире.

Редакция Tproger сделала и адаптировала перевод подборки программ для Windows и macOS. Здесь вы найдёте проверенные временем решения для работы, развлечений и повседневных задач. Мы сосредоточились на бесплатных и условно-бесплатных приложениях с отличной репутацией, которые решают реальные задачи без навязывания ненужных функций.

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

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

Chrome остаётся самым популярным браузером в мире — и не просто так. Он быстрый, стабильный и отлично интегрируется с экосистемой Google. Огромная библиотека расширений из Chrome Web Store позволяет настроить браузер под любые задачи. Синхронизация между устройствами работает безупречно: вкладки, пароли, закладки и история всегда под рукой.

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

Firefox — это выбор тех, кто ценит приватность и открытость. Mozilla не зарабатывает на продаже ваших данных, а сам браузер активно развивается сообществом. Встроенные инструменты защиты от трекинга работают из коробки, блокируя рекламные сети и скрипты слежения.

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

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

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

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

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

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

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

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

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

Пропустите LastPass — когда-то фаворит, он упал в немилость после повторных утечек безопасности. Для душевного спокойствия лучше поискать в другом месте.

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

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

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

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

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

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

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

Если не хочется ставить традиционный антивирус, есть достойные альтернативы. Emsisoft Emergency Kit — мощный портативный сканер, который можно запускать с флешки: идеально для редких глубоких сканов или лечения заражённых систем без установки чего-либо. Просто подключаете, когда нужно.

Ещё один отличный инструмент — VirusTotal: бесплатный веб-сервис, который проверяет файлы и URL через десятки антивирусных движков. Прежде чем открывать подозрительную загрузку, можно залить файл на VirusTotal.com или использовать их расширение для браузера, чтобы проверять ссылки в реальном времени. Быстро, просто и удобно для осторожных пользователей.

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

Тем, кому нужны более устоявшиеся коммерческие решения, подойдёт AnyDesk, который остаётся лёгким и надёжным вариантом для личного и командного использования.

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

Remote Mouse — простой и эффективный способ эмулировать мышь и клавиатуру с телефона. Для более продвинутых сценариев можно использовать приложения вроде Unified Remote.

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

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

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

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

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

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

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

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

Когда приватность критична, Signal — один из лучших вариантов. Разработан некоммерческой организацией, бесплатен, open-source, без рекламы, использует надёжное сквозное шифрование для сообщений и звонков.

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

Если вы работаете с креативными командами, сообществами или геймерами, Discord стал явным лидером. Изначально созданный для игр, он превратился в полноценную коллаборативную платформу с текстом, голосом и видео, стримингом экрана и ботами для автоматизации. Многие комьюнити — и даже IT-компании — используют Discord как основной рабочий инструмент.

Для внутриигрового голосового чата TeamSpeak остаётся олдскульным достойным вариантом: можно использовать анонимно и получать полный контроль над сервером. Встроенный чат Steam лучше, чем раньше, и помогает в игровой координации, но большинство всё же выбирает Discord.

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

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

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

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

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

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

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

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

Чтобы грамотно управлять файлами и освобождать место, нужно понимать, что именно занимает пространство. На Windows популярны WinDirStat и WizTree — быстрые бесплатные инструменты для визуализации диска. SpaceSniffer предоставляет динамическую схему.

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

На macOS приложение Photos автоматически создаёт альбомы по людям и локациям, синхронизирует всё через iCloud.

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

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

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

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

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

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

Как сообщили разработчики, причиной стал баг в Rust-версии утилиты date, входящей в состав пакета rust-coreutils.

Ошибка затронула все варианты дистрибутива — от облачных инстансов и контейнерных образов до настольных и серверных установок.

Подробности инцидента

В Ubuntu 25.10 разработчики Canonical начали эксперимент по «оксидированию» системы — постепенному замещению классических инструментов GNU Coreutils на переписанные на Rust версии из проекта uutils.

Среди них оказалась и утилита date, которая используется в механизме проверки обновлений.

В релизе rust-coreutils 0.2.2-0ubuntu2 в date закралась ошибка, нарушающая корректную обработку времени при выполнении системных скриптов, отвечающих за автообновления. В результате службы обновления не могли определить дату последней проверки и прекращали работу.

Баг не влияет на ручные обновления через apt или другие менеджеры пакетов — только на автоматические проверки.

Как исправить

Canonical уже выпустила исправление в пакете rust-coreutils 0.2.2-0ubuntu2.1. Проверить, затронута ли система, можно командой:

Если версия ≤ 0.2.2-0ubuntu2, нужно вручную обновить пакет:

Системы, обновлявшиеся вручную или через apt upgrade, скорее всего, не пострадали.

Контекст

Переход Ubuntu на Rust-инструменты — часть более масштабного проекта Canonical по повышению безопасности и надежности базовых утилит. Помимо coreutils, компания тестирует и sudo-rs — переписанную на Rust версию sudo.

Однако текущий инцидент показывает, что полная замена проверенных C-реализаций на новые Rust-проекты пока сопряжена с рисками.

Canonical заявляет, что перед выходом LTS-версии в апреле 2026 года проведет дополнительное тестирование Rust-утилит.

По словам Карпати, NanoChat — это полный стек LLM-платформы, включающий токенизацию, обучение, дообучение, оценку, инференс и веб-интерфейс, позволяющий общаться с моделью прямо из браузера. Все работает на одном узле с 8 GPU H100 и запускается одной командой:

Обучение занимает около четырех часов и стоит примерно $100 при аренде облачного сервера Lambda Labs. После этого можно открыть локальный веб-интерфейс и «болтать» с собственной моделью как с ChatGPT.

Собери сам

Карпати описывает NanoChat как «чистый, минималистичный и хакабельный код», который подойдет тем, кто хочет понять, как устроен ChatGPT изнутри.

Репозиторий включает всего около 8000 строк кода и написан в основном на Python (89%), с минимальными вставками на Rust и HTML.

NanoChat — это не гигантская инфраструктура, а сильная и прозрачная база, на которой можно построить свой LLM с нуля.

Он также подтвердил, что проект станет частью нового курса LLM101n, который готовит его команда Eureka Labs.

Что под капотом

NanoChat использует простую пайплайн-архитектуру с поддержкой этапов pretraining, fine-tuning, evaluation и serving, а также встроенный сервер чата на Python (python -m scripts.chat_web).

Результаты обучения сохраняются в виде «отчетной таблицы» с ключевыми метриками (ARC, GSM8K, MMLU).

Open source и вдохновение

NanoChat распространяется под лицензией MIT и вдохновлен предыдущими проектами Карпати — nanoGPT и сообществом разработчиков на Hugging Face.

Как подчеркивает автор, цель NanoChat — демократизировать ИИ, сделав разработку больших языковых моделей понятной и доступной «для всех, у кого есть $100 и немного любопытства».

🔥 Помогал с публикацией Игорь Панасюк — Software Engineer и автор канала Igor Panasyuk | IGORoutine Programming.

Регистрация бота в Телеграм

Откройте Телеграм и найдите @BotFather — это официальный бот, он создаёт других ботов. Отправьте ему команду /newbot.

BotFather сначала спросит имя бота, оно может быть любым. Далее придумайте username, чтобы он заканчивался на «bot», например hello_chat_bot. Если юзернейм свободен, BotFather пришлёт токен для управления. Выглядит токен как длинная строка: 8201115114:AAGNII8UA3kjcz9qvV8znl77pK-YldkWMmQ.

В BotFather есть несколько команд для настройки оформления:

• /setname — меняет имя бота (то, что видят пользователи);
• /setdescription — добавляет описание, которое отображается при первом запуске;
• /setabouttext — добавляет короткий текст для страницы бота;
• /setuserpic — загружает аватарку (квадратное изображение от 512×512 px).

Имя можно менять сколько угодно раз. Username (тот, что заканчивается на _bot) изменить нельзя.

Создаём Телеграм-бота на Rust

В качестве примера напишем эхо-бота. Он будет получать строку текста и её же присылать в ответ.

Создайте новый проект:

Откройте Cargo.toml и добавьте зависимости:

Создайте файл .env в корне проекта:

Откройте src/main.rs и вставьте код:

teloxide::repl() запускает цикл обработки сообщений. Функция внутри получает сообщение и отправляет текст обратно пользователю.

msg.text() извлекает текст из сообщения. Если пользователь отправил стикер или фото, бот их проигнорирует. Как читать разные типы сообщений — разберём далее.

bot.send_message() отправляет ответ. Первый параметр — ID чата, второй — текст. Методы отправки с форматированием, кнопками и файлами рассмотрим в следующих разделах.

Скомпилируйте проект:

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

Перенос бота на хостинг

Сейчас бот работает локально на вашем компьютере. Чтобы он отвечал круглосуточно, нужен сервер. Есть три варианта:

• Виртуальный сервер (VPS).
• Облачные платформы.
• Домашний сервер.

Проще и дешевле взять VPS, подойдёт любой Linux-сервер за 200-300 рублей/месяц.

После оплаты хостинга вы получите IP-адрес сервера, логин и пароль. Откройте терминал и подключитесь: ssh root@123.45.67.89, введите пароль.

Установите Rust:

Клонируйте проект с GitHub или создайте новый:

Создайте на сервере файл .env с токеном:

Соберите релизную версию:

Если закроете терминал, бот остановится. Чтобы он работал постоянно, используйте утилиту screen:

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

Чтение сообщений

Телеграм отправляет боту данные через API. Каждое сообщение приходит в виде объекта:

• текст,
• ID чата,
• информация о пользователе,
• время отправки.

Библиотека teloxide распарсила JSON от Телеграм и превратила его в удобные структуры. Нужен лишь обработчик, который срабатывает на новое сообщение:

Бот как-то должен узнавать о новых сообщениях от пользователей. Самый простой способ — метод getUpdates. Бот каждые несколько секунд спрашивает: «Есть что-то новое?». Получает ответ, обрабатывает сообщения и снова спрашивает.

Под капотом teloxide делает примерно следующее:

Есть другой вариант — вебхуки. Вы один раз говорите Телеграму: «Вот адрес моего сервера, присылай сюда все обновления».

Telegram сам шлёт обновления на ваш HTTPS-эндпоинт, вместо того чтобы бот опрашивал API (getUpdates). Преимущества в меньшей нагрузке и задержке, можно масштабировать через балансировщик и легко интегрировать в микросервисную архитектуру.

С getUpdates сами решаете, когда проверять новые сообщения. С вебхуками Телеграм решает за вас — он шлёт данные сразу, как только что-то происходит. Если вы пишете бота для себя или учитесь, начните с getUpdates.

Отправка сообщений

Базовая отправка текста выглядит так:

chat_id — это идентификатор чата, откуда пришло сообщение. Бот отправит ответ туда же.

Телеграм ограничивает длину одного сообщения 4096 символами. Если попытаетесь отправить больше, API вернёт ошибку. Проблему решает функция, которая разбивает текст на части:

Бот может отправлять не только текст. Методы send_photo, send_document, send_video работают с файлами до 50 МБ. Передавайте либо URL, либо загружайте файл с диска:

Форматирование текста делайте через Markdown или HTML. Чтобы применить стили, укажите режим парсинга:

Иногда нужно отправить сообщение с задержкой. В Rust нет встроенного планировщика задач, но есть tokio::time::sleep:

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

Добавление меню и кнопок

Бот, который только читает и отвечает текстом, — это скучно. Пользователи хотят тыкать на кнопки, листать меню.

В Телеграме есть два типа кнопок:

• Reply — появляются вместо обычной клавиатуры для ввода текста.
• Inline — прикрепляются прямо к сообщению.

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

Создадим простое меню с двумя кнопками:

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

Inline-кнопки отправляют callback-запросы:

«Да» — это текст на кнопке, «answer_yes» — данные, которые получит бот. Чтобы поймать нажатие, нужен обработчик callback-запросов.

Ограничения ботов и ddos-атаки

Telegram API ограничивает количество сообщений, которые бот отправляет одному пользователю или в группу. Если превысите лимит, получите ошибку 429:

• 30 сообщений в секунду.
• 20 сообщений в минуту в один чат.

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

Основное правило — не держать бота напрямую за getUpdates, а использовать вебхуки с ограничением соединений и прокси. Telegram уже фильтрует большую часть мусорного трафика, но важно добавить rate limit (например, через nginx) и иметь таймауты.

Добавьте простую защиту: храните HashMap с user_id и временем последнего сообщения. Если пользователь пишет чаще раза в секунду — игнорируйте его запросы. Ещё один вариант — подключить Redis и вести счётчики запросов там.

Библиотеки для создания ботов на Rust

В экосистеме Rust для тг-ботов есть три основные библиотеки.

teloxide

Вы пишете bot.answer("Привет") — библиотека сама формирует HTTP-запрос, отправляет его в Телеграм API, обрабатывает ответ и возвращает результат.

У teloxide есть встроенная система диалогов. Например, бот спрашивает имя, пользователь отвечает, бот запоминает ответ и спрашивает возраст. Библиотека следит за тем, на каком шаге находится каждый пользователь.

Ещё в teloxide есть диспетчер команд. Вы пишете функцию start(), помечаете её атрибутом #[command], и библиотека автоматически вызывает эту функцию, когда пользователь отправляет /start. Не нужно вручную парсить текст сообщения и проверять, что там написано.

Минус — teloxide тянет за собой много зависимостей. Поэтому увеличивается время компиляции, размер бинарника тоже.

Размер бинарного файла напрямую на производительность не влияет — Rust-компилятор делает статическую линковку, так что даже 20 МБ бинарник работает с той же скоростью. Если размер критичен при деплое, можно попробовать собирать с флагами, которые удаляют служебную информацию из бинарника.

frankenstein

Генерирует структуры данных из официальной спецификации Telegram Bot API. Вы получаете типы SendMessage, Message, User — они точно соответствуют тому, что описано в документации Telegram.

Библиотека не добавляет абстракций. Хотите отправить сообщение — создаёте структуру SendMessageParams, заполняете chat_id и text, вызываете метод api.send_message(). Хотите обработать команду — сами проверяете, начинается ли текст сообщения со /start.

frankenstein компилируется быстрее teloxide и создаёт меньший бинарник.

teloxide-core

Основа teloxide без диспетчера команд и системы диалогов. Вы работаете напрямую с методами API, но библиотека всё ещё помогает с типами и обработкой ошибок.

Используйте teloxide-core, если архитектура вашего бота не вписывается в teloxide и вы не хотите писать всю логику с нуля в frankenstein.

Подведём итоги

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

• Подключите базу данных (PostgreSQL через tokio-postgres или SQLite через rusqlite).
• Добавьте HTTP-запросы к внешним API (reqwest).
• Настройте логирование в файл (log4rs).

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

Главный итог — новая версия работает примерно на 27% быстрее, чем Python 3.13. Ключевое новшество — полноценная поддержка free-threading (многопоточности без глобальной блокировки GIL).

Как тестировали

В тестах участвовали версии CPython 3.9–3.14, а также PyPy 3.11, Node.js 24 и Rust 1.9.

Проверяли производительность на двух алгоритмах: рекурсивном вычислении чисел Фибоначчи и сортировке пузырьком. В однопоточном режиме Python 3.14 показал стабильный прогресс:

• В тесте Фибоначчи ускорение на 27% — 6,4 секунды против 8,2 секунд у версии 3.13.
• В сортировке пузырьком время сократилось до 2,05 секунды против 2,8 секунд.

Революция free-threading

Главный прорыв — free-threading, который наконец снимает системное ограничение GIL и раскрывает потенциал многоядерных процессоров.

В четырехпоточном тесте Фибоначчи скорость выросла в три раза, а в сортировке — в два раза относительно стандартной сборки.

Сравнение с другими

Стоит отметить, что PyPy 3.11 остается недосягаемым лидером — он быстрее CPython 3.14 почти в пять раз в рекурсии и в 18 раз при сортировке.

Node.js приблизился к PyPy в одном тесте, а Rust ожидаемо вырвался вперед — до 70 раз быстрее Python.

Что это значит

Python 3.14 — самая быстрая версия CPython на сегодня. Для проектов с интенсивными вычислениями free-threading дает ощутимый прирост. А вот JIT-режим пока остается экспериментальным — ускорения почти нет.

Если ваша команда может обновиться — это стоит сделать. Python 3.14 не просто быстрее: он впервые по-настоящему раскрывает многопоточность.

Потому что SQL, несмотря на свое превосходство в работе с данными, неудобен, ограничен и рискован в роли полноценного языка программирования.

Логика не по адресу

Как отмечает Эвальд Бенс, фуллстек разработчик и авторов популярного блога об IT, он предпочитает держать как можно больше логики в приложении, а не в SQL-хранилищах, представлениях и процедурах:

Я отношусь к базе как к тупому хранилищу данных. Вся логика — в коде. SQL просто не предназначен для сложных сценариев.

И дело не в том, что SQL чего-то «не умеет». Умеет — особенно с расширениями вроде PL/pgSQL или Oracle PL/SQL.

Но выразительность этих языков — далека от Python, TypeScript, Rust или C#, особенно когда речь идет о бизнес-логике, объектной модели или сложных расчетах.

Зачем выносить логику из базы?

1. SQL невыразителен

Для манипуляций с табличками и JOIN — он король. Но как только начинается рекурсия, классы, вложенные состояния или обработка ошибок — SQL превращается в монстра с BEGIN, IF, LOOP, EXCEPTION, RAISE, CURSOR, FETCH, WHILE и т.д...

2. Развертывание — боль

Обновить приложение можно за минуту, откатить — за две. А вот миграции на проде — это:

• повышенные права доступа;
• согласование с DBA;
• боязнь сломать что-то «наживую»;
• ручной откат схем.

3. Лочит на вендора

Логика, написанная на PL/SQL — это билет в один конец к Oracle. Переезд на PostgreSQL или SQL Server становится в 5 раз сложнее.

4. Меньше инструментов

Вокруг SQL есть утилиты, но полноценной среды с юнит-тестами, статическим анализом, форматтерами, профайлерами, линтерами и отладчиками — почти нет.

А что с производительностью?

Да, есть нюанс: иногда лучше обработать данные прямо в базе, чтобы не гонять десятки тысяч строк по сети. Это особенно актуально, если не хочется получить классическую проблему N+1-запросов.

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

Что делать?

Подход «база — хранилище, логика — в коде» стал де-факто стандартом во многих командах. Но это не догма:

• Для отчетности или простых ETL сценариев логика в SQL может быть уместной.
• Для монолитных решений без CI/CD и DevOps — процедурный SQL вполне оправдан.
• Но в современной разработке с частыми релизами, микросервисами и отказоустойчивостью бизнес-логика в приложении — просто удобнее и безопаснее.

Это означает, что для сборки системы контроля версий потребуется установленный компилятор Rust — как неотъемлемая часть инфраструктуры.

Что происходит

Предложение активно обсуждается в списке рассылки разработчиков Git. Идея заключается в поэтапной интеграции Rust, аналогично тому, как ранее был внедрен стандарт C99:

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

Почему Rust?

Интеграция Rust началась в Git 2.49 (март 2025 года), где появились первые экспериментальные компоненты:

• libgit-sys — низкоуровневая обвязка над внутренними C-библиотеками Git.
• libgit — высокоуровневая библиотека для написания компонентов на Rust.

В июле 2025 года в проект был предложен Rust-патч для утилиты xdiff, который, по замерам, улучшает производительность на 5–19%. Именно тогда впервые прозвучала идея сделать Rust обязательным.

Но не все так просто

Мнения разработчиков Git разделились. Среди основных аргументов «против»:

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

Сторонники же отмечают:

• Рост производительности.
• Безопасность и современный инструментарий, которые дает Rust.
• Возможность постепенного переписывания уязвимых и сложных компонентов Git с более надежным управлением памятью.

Что дальше

Пока решение не принято. Но вопрос об обязательной зависимости Rust будет решаться до релиза Git 3.0, который может состояться в 2026 году.

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

Обязательная поддержка Rust в Git станет важной вехой: Git всегда был проектом, ориентированным на C и минимальные внешние зависимости. Переход к Rust — это потенциальное изменение философии.

Главные отличия Web3 от Web2

Перед тем как углубиться в код и практику, полезно увидеть основные различия между привычной Web2-разработкой и новой логикой Web3.

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

В Web3 логика сильно меняется. Пользователь входит в систему с помощью криптокошелька, например, MetaMask. Каждая задача создаётся транзакцией и записывается в смарт‑контракт, а значит становится частью блокчейна. Удалить её уже нельзя — только отметить статус выполнения. Такой подход даёт прозрачность: любой участник сети может проверить, что задача действительно существует, и её статус изменён честно.

Стек Web3: что понадобится на практике

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

• Блокчейн: Ethereum, Layer‑2 (Arbitrum, Optimism, Base, Polygon), Solana.
• Языки: Solidity (EVM), Rust (Solana), Go (инфраструктура и сервисы).
• Библиотеки: ethers.js, wagmi.
• Фреймворки: Hardhat, Foundry, Truffle.
• Хранилища: IPFS/Arweave для файлов и метаданных.
• Кошельки/подключение: MetaMask, WalletConnect (v2/WalletConnect Network), Web3Auth.

Точка входа для новичка — Alchemy, а также ethers.js.

Пример. Быстрое подключение кошелька (ethers.js).

Архитектура DApp: из чего состоит современное Web3‑приложение

Любое Web3‑приложение строится из нескольких слоёв, каждый со своей ролью. Фронтенд остаётся привычным SPA, но работает не с сервером, а напрямую с кошельком и смарт-контрактами. Контракты содержат бизнес‑логику и хранят ссылки на данные в децентрализованных хранилищах. Оракулы обеспечивают связь с внешним миром, например, передают цены или сообщения между разными блокчейнами. Важную часть играет off‑chain слой — сервисы вне блокчейна (индексаторы, аналитика), которые помогают быстрее искать и обрабатывать данные, при этом не перегружать сеть.

Пример. Возьмём DeFi‑приложение. Пользователь открывает фронтенд и инициирует операцию swap(). В ответ фронтенд обращается к смарт‑контракту, который выполняет обмен токенов. Чтобы определить курс, контракт тянет актуальные данные через оракул. При этом тяжёлые артефакты, изображения или отчёты не хранятся в блокчейне напрямую — они лежат в IPFS. Сам контракт содержит только контент‑идентификаторы CID. Таким образом, получаем баланс: блокчейн отвечает за логику и безопасность, а децентрализованное хранилище — за данные.

Практика: ваш первый DApp за вечер

Давайте попробуем собрать простейшее приложение своими руками.

Шаг 0. Подготовка

Сначала убедитесь, что у вас стоит Node.js LTS и Git. Также нужен браузер с установленным MetaMask, где можно создать тестовый аккаунт. Чтобы оплачивать транзакции в тестовой сети, заранее возьмите немного тестовых монет через faucet — например, для Sepolia или Polygon Amoy.

Шаг 1. Проект

Создадим новый проект и установим Hardhat вместе с тулзами. Эта среда нужна для компиляции и деплоя контрактов.

Шаг 2. Контракт

В папке contracts/ создаём файл TaskTracker.sol и копируем туда код смарт-контракта из первого раздела. Это и будет бизнес-логика нашего приложения.

Шаг 3. Сценарий деплоя

Пишем скрипт, который разворачивает контракт в сети. Это простой скрипт на JavaScript, который вызывает методы Hardhat.

Шаг 4. Конфиг сети

В файле hardhat.config.js добавляем настройки для подключения к тестовой сети. Используем RPC-URL от Alchemy или Infura и приватный ключ от тестового аккаунта — его можно экспортировать из MetaMask, но использовать только для тестовой сети.

Шаг 5. Деплой в тестнет

Теперь запускаем скрипт деплоя. После выполнения увидите адрес контракта — он понадобится для фронтенда.

Шаг 6. Фронтенд (React + ethers.js + wagmi)

Собираем простое SPA: форма, чтобы добавить задачи, и кнопка «complete». Здесь мы используем ethers.js для обращения к контракту. Сделайте вызовы addTask и completeTask.

Подводные камни Web3-разработки и что с ними делать

Комиссии (gas): любая запись в блокчейн стоит денег и иногда комиссия выше ценности операции — например, $10 за простую задачу.

• Что делать: использовать Layer-2 (Arbitrum/Optimism/Base/Polygon), выбирать сети с низкими комиссиями (Solana, Avalanche), оптимизировать контракты и батчи транзакций.

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

• Что делать: показывать «оптимистичный UI», кешировать данные, переносить часть логики off-chain, использовать быстрые сети (Solana, Near, Aptos).

Безопасность: код контракта неизменяем, и одна ошибка может стоить миллионов.

• Что делать: проходить аудит (CertiK, Trail of Bits), использовать проверенные библиотеки (OpenZeppelin), писать тесты в тестовых сетях (Goerli, Sepolia), внедрять баг-баунти и ролевую модель доступа.
• Ресурс: ConsenSys Diligence — Smart Contract Security Best Practices.

UX: вход через кошелёк сложнее привычного логина/пароля. Нужно ставить расширение, пополнять баланс и подтверждать каждую транзакцию.

• Что делать: использовать аккаунт-абстракцию (ERC-4337), социальный логин, gasless транзакции через Paymaster, улучшать UI (подсказки, авто-фокус на MetaMask).

Регуляция: законы о Web3 пока разные в каждой стране. Легальное в одной юрисдикции может быть запрещено в другой (например, токенизация акций без лицензии).

• Что делать: консультироваться с юристами, следить за изменениями. Например, MiCA в ЕС — “Markets in Crypto-Assets Regulation” — это единый регламент по криптоактивам в Евросоюзе.

Безопасность всегда должна быть на первом месте, потому что в Web3 есть риск потерять реальные деньги пользователей.

Карьерные возможности и перспективы

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

Чтобы войти в профессию, начните с изучения Solidity и базовых паттернов смарт‑контрактов. Сделайте пару пет‑проектов и выложите код в GitHub. Отличный вариант прокачки — участвовать в хакатонах и грантовых программах от Ethereum Foundation или Solana Grants. Это даёт и опыт, и контакты, и иногда финансирование.

Пара пет‑проектов + понимание блокчейна — хороший старт в Web3‑команду.

Будущее Web3

Web3 не вытеснит Web2 полностью, но поменяет привычный подход к разработке. Разработчику это открывает новые вызовы: комиссии, безопасность и UX, но одновременно и новые возможности — прозрачные данные, токенизация, децентрализованные бизнес‑модели.

Для тех, кто только входит в сферу, это шанс попасть в индустрию на раннем этапе и быстро нарастить экспертизу. Простые пет‑проекты, хакатоны и знакомство с инструментами дают ощутимый старт.

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

Давайте разберёмся, корректно ли сравнивать эти языки, посмотрим на плюсы, минусы технологий и выясним, в каких сценариях раскрываются их сильные стороны.

Комментарии по теме предоставили: разработчики Василий Зорин, Эдуард Дыкман; автор курсов в Яндекс Практикуме Кирилл Федченко; участники сообщества Golang Go и Rust.

⚠️ Мы не ищем язык-убийцу. В публикации собрали популярные мнения, чтобы помочь в принятии взвешенного решения для ваших проектов.

Почему Go и Rust считают конкурентами, если они такие разные?

Первый со сборщиком мусора больше похож на Java. Второй без сборки мусора, и напоминает продвинутый C++. Но постойте!

Во-первых, языки появились практически одновременно. Go заявил о себе в 2009 году, Rust показали в 2010-м. «Современный язык для разработки быстрых и безопасных приложений», — так говорили про Go, так говорили про Rust.

Во-вторых, несмотря на разные подходы к управлению памятью, оба языка метят в одну и ту же аудиторию. К ним приходят разработчики, которым нужно быстрее Python, но безопаснее C++.

В-третьих, на этих языках пишут схожие типы приложений: веб-серверы, микросервисы, CLI-инструменты и системное ПО. Например, на Go написаны Docker и Kubernetes, а на Rust — Firecracker (AWS), движок Servo, Vector.

Оба языка конкурируют в backend-разработке, облачных вычислениях и инструментах DevOps, где ключевыми являются масштабируемость и параллелизм. Например, в области:

— микросервисов: оба языка используются для создания распределенных систем, при этом функции безопасности Rust могут быть предпочтительнее для критически важных компонентов;
— сетевого взаимодействия: такие инструменты, как gRPC или HTTP-серверы, реализованы в обоих языках;
— облачной инфраструктуры: компании используют Go из-за его простоты, а Rust для компонентов, критически важных для производительности.

Rust лучше подходит для системного программирования (компиляторы, драйверы, ОС), в то время как Go более распространен в крупномасштабных сервисах высокой доступности, где приоритетна быстрая разработка.

Простота сейчас или надёжность потом?

Go следует принципу «простота превыше всего»: минимум синтаксического сахара, встроенная поддержка горутин, автоматическая сборка мусора.

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

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

У Rust другая философия — «лучше потратить время на борьбу с компилятором сейчас, чем часы на отладку багов потом».

Система типов и borrow checker заставляют контролировать жизненный цикл данных, помнить про безопасность потоков и обработку ошибок ещё до запуска программы. Компилятор не позволит собрать код с потенциальными проблемами.

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

Что привлекает в Rust — это инструментарий и экосистема. Язык развивается предсказуемо: стабильные обновления выходят по календарю, есть понятная схема nightly → beta → stable.

Из минусов — интеграция с другими языками требует дополнительных усилий по настройке FFI, но решения для этого есть (#[repr(C)]). Возникают вопросы к архитектуре: например, async/await добавили раньше, чем проработали корутины, и теперь приходится подгонять одно под другое не самыми элегантными методами. Ещё Rust компилируется заметно дольше других языков.

Сколько нужно времени на обучение Rust и Go?

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

Документация Rust не менее подробная. Синтаксис языка сложнее. Обучение затягивается из-за уникальной системы владения памятью (ownership) и концепции времени жизни (lifetimes). Ещё нужно время на принятие borrow checker, когда кажется, что компилятор специально мешает писать код.

Borrow checker — лучший друг программиста, он следит за соблюдением модели владения. Основное правило гласит, что в любой момент времени на переменную может ссылаться либо одна мутабельная ссылка (с правом записи), либо сколько угодно иммутабельных (только чтение). Это нужно соблюдать в любом языке, который поддерживает многопоточность. В Golang, например, с data races приходится бороться своими силами. Также borrow checker убеждается в отсутствии «висячих» указателей (когда ссылка живёт дольше, чем данные).

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

Вы знали, что код на Rust в 2,6 раза проще кода на Go?

В июне 2025 года TIOBE проанализировало 1,5 миллиарда строк кода, измеряли сложность программ на разных ЯП. Считали количество путей выполнения в функциях — чем меньше число, тем проще код для понимания и поддержки.

Как получилось, что Golang в 2,6 раза сложнее Rust?

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

Синтаксис Go минималистичнее и проще для новичков, но код получается более разветвлённым. На Rust пишут программы с меньшим количеством путей выполнения, поэтому кажется, что код проще для понимания и поддержки.

Большое преимущество Go — это низкий порог входа (25 ключевых слов против 70 в Rust). Стандартная библиотека довольно небольшая, но в ней есть практически всё. По моему опыту, в средней кодовой базе на Golang разобраться больше шансов, чем в Rust.

Когда Rust работает быстрее Go, и где это используют?

Представим интернет-магазин: пользователь заходит на страницу товара, сервер идёт в базу данных и отдаёт JSON. В таких случаях Go и Rust работают примерно одинаково быстро — узкое место в скорости ответов БД.

Теперь вы обрабатываете видео в реальном времени или анализируете миллионы финансовых транзакций. В этом случае предпочтительнее Rust, и вот почему.

В Go сборщик мусора может внезапно остановить программу на несколько миллисекунд — «подожди, я тут память чищу». В видеостриме это означает подвисание картинки, в торговых алгоритмах — потерю денег. Rust работает без неожиданных пауз, потому что вы сами управляете памятью.

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

В Rust память удаляется автоматически, как только её владелец выходит из области видимости. Так что любые приложения, в которых важным аспектом производительности является управление памятью, могут выиграть за счёт использования Rust (БД, ОС, браузеры, видеоигры).

Rust приносит реальную пользу в продакшене там, где простои и уязвимости стоят дорого:

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

Параллельная обработка

Допустим, вам нужно скачать 3000 файлов. В Go можно написать цикл с горутинами — синтаксис интуитивно понятный, и базовый вариант заработает без глубокого изучения теории.

В случае с Rust придётся почитать про async/await, разобраться с библиотекой Tokio, понять разницу между async fn и обычными функциями. Зато получите полный контроль над тем, как именно выполняется код.

Потребление ресурсов

Go жирнее по памяти. Каждая горутина занимает от 2 КБ, плюс сборщик мусора держит в памяти объекты про запас. Для веб-сервиса не критично, для встраиваемых систем может стать проблемой.

Rust экономнее — вы платите только за то, что реально используете. Программу на Rust можно запустить на микроконтроллере с 32 КБ памяти. Go туда не поместится.

В чём разница между развертыванием Go и Rust приложений?

Оба языка компилируются в один исполняемый файл — просто скопировали на сервер и запустили. Docker-образы получаются крошечными, особенно у Rust (можно упаковать в scratch-образ размером несколько мегабайт). Go чуть проще интегрируется с существующей инфраструктурой.

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

В каких сферах Go и Rust делят рынок программирования?

Go

• Идеален для микросервисов и REST API. Фреймворки Gin и Echo помогают быстро собрать рабочий сервис — например, для регистрации пользователей или каталога товаров.
• Docker, Kubernetes, Terraform — все написаны на Go. Язык используют для консольных приложений: получается один файл, который запускается везде без дополнительных зависимостей.
• В больших командах с частой сменой разработчиков Go встречается чаще. Простой синтаксис означает, что новые разработчики быстрее разбираются в коде проекта.

Rust

• Операционные системы, драйверы — области, где Rust конкурирует с C++. Язык предлагает сопоставимую производительность, но защищает от ошибок с памятью.
• Rust компилируется в эффективный WebAssembly для запуска вычислений в браузере. Используется в играх, обработке изображений, криптографии.
• Ripgrep (аналог grep) и exa (аналог ls) демонстрируют возможности Rust — они работают быстрее классических Unix-утилит.
  

Rust лучше подходит для системного программирования (компиляторы, драйверы, ОС), в то время как Go более распространен в крупномасштабных сервисах высокой доступности, где приоритетна быстрая разработка

Стоит ли изучать Rust, если более простой Go справляется с большинством задач?

Всё зависит от ваших целей. Кирилл Федченко отмечает:

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

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

Go часто достаточно для решения задач, но более широкое применение и растущий спрос на Rust делают его ценным навыком для карьеры. Уже восемь лет подряд язык признается лучшим в опросе Stack Overflow, а его сообщество растет быстрее, чем у других языков. Именно поэтому многие переучиваются на Rust с Go, C++ или Python, особенно при переходе в системное программирование или области, где безопасность имеет ключевое значение.

Почему Rust не вытеснит Go, несмотря на все преимущества?

Rust не заменит язык Go, потому что последний хорошо решает свои задачи.

Golang и Rust используют для разных целей. Сценариев применения Rust меньше, чем для Go. Поэтому Golang популярнее, но это не замена Rust.

Оба языка далеки от идеала для написания бизнес-логики, она теряется за синтаксическими конструкциями. В зависимости от области, для бизнес-логики я бы предложил рассмотреть typescript, java/kotlin, elixir, clojure.

Комментарии открыты: в каких проектах вы наблюдали, как неправильный выбор языка негативно отразился на продукте?

Репозиторий уже собрал почти 65 000 звезд на GitHub. Разбираемся, как он устроен и какие интересные модули лежат внутри.

Что делает этот алгоритм

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

Например, компонент home-mixer собирает кандидатные твиты из разных источников (например, через search-index, tweet-mixer, user-tweet-entity-graph) и ранжирует их при помощи легкой и тяжелой нейросети (light-ranker, heavy-ranker).

После этого подключаются фильтры (например, visibility-filters), которые убирают нежелательный контент и скрытые посты.

Из чего это все собрано

Проект построен на Scala (66%), Java (20%) и Rust. Некоторые модули используют Python и даже TensorFlow v1 (например, twml). Базовые компоненты включают:

• Данные — tweepypie, unified-user-actions, user-signal-service
• Модели — SimClusters, TwHIN, real-graph, tweepcred, trust-and-safety-models
• Фреймворки — navi (на Rust), product-mixer, representation-scorer, representation-manager

Также присутствуют специфические компоненты для пушей — сервис pushservice, ранжирующие модели pushservice-light-ranker и pushservice-heavy-ranker, предсказывающие, откроет ли пользователь уведомление.

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

Во-первых, X остается одной из крупнейших социальных платформ в мире, и понимание ее алгоритмов дает представление о принципах ранжирования и фильтрации контента.

Во-вторых, открытый код — это редкость в мире коммерческих рекомендаций, особенно на таком масштабе.

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

Что это значит для разработчиков

Этот проект — хорошее поле для изучения реального промышленного машинного обучения. Особенно интересны:

• плотные графовые эмбеддинги в TwHIN
• модели репутации и социальной близости в real-graph и tweepcred
• многозадачные модели в pushservice-heavy-ranker

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

Модель создана с нуля, обучена на реальных пулл-реквестах и задачах из практики. Она уже доступна в IDE.

Новая глава в «вайб-кодинге»

Модель grok-code-fast-1 от xAI позиционируется как конкурент решениям от OpenAI, Google и Anthropic. Она оптимизирована для разработки на TypeScript, Python, Java, Rust, C++ и Go, а значит покрывает большинство реальных кейсов в современной разработке.

Модель уже интегрирована в IDE и CLI вроде GitHub Copilot, Cursor, Cline, Roo Code, Kilo Code, OpenCode и Windsurf. В ближайшее (но ограниченное) время она будет доступна бесплатно.

Быстрая, дешевая и довольно-таки умная

xAI делает ставку на цену, скорость и удобство. Стоимость использования grok-code-fast-1:

• $0,20 за 1 млн входных токенов
• $1,50 за 1 млн выходных токенов
• $0,02 за 1 млн кэшированных входных токенов

Во внутреннем бенчмарке SWE-Bench-Verified, модель показала результат 70,8%, но независимых тестов пока нет — их ждут в ближайшие недели.

В xAI утверждают, что при создании модели основное внимание уделялось практическому использованию и удобству в реальных задачах. Якобы разработчики оценили grok-code-fast-1 как «быструю и надежную» при повседневной работе с кодом.

До 160 токенов в секунду и 90% кэш-хитов

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

Кроме того, реализовано кэширование подсказок, которое обеспечивает до 90% попаданий при работе с GitHub Copilot и другими интеграциями. Это позволяет существенно сократить задержки и стоимость использования.

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

Что такое sudo-rs и зачем он нужен

Проект sudo-rs развивается с прицелом на полную совместимость с оригинальной sudo, но при этом написан на языке Rust, который предлагает строгую модель управления памятью и безопасную систему типов.

Canonical (разработчик Ubuntu) официально утвердила переход на sudo-rs еще в мае 2025 года, однако полноценная замена началась только сейчас — с появлением всех необходимых функций:

• поддержка старых версий ядра Linux (до 5.9);
• поддержка NOEXEC и AppArmor;
• исправления ошибок стабильности;
• переход sudo-rs в основной репозиторий (main) после аудита.

Что с обычным sudo?

Классическое sudo все еще доступно в системе. При желании его можно вернуть командой:

Однако в Ubuntu 26.10 разработчики планируют полностью убрать классическую версию из основного репозитория и оставить только sudo-rs.

Что дальше?

Также обсуждается замена команды su на аналогичную реализацию на Rust — su-rs. Пока что /usr/bin/su остается классическим, но эксперименты с альтернативой уже запланированы.

Ubuntu — не первая система, переходящая на Rust-реализации базовых компонентов. Ранее аналогичный тренд задали:

• Fedora, где тестируется systemd-модуль на Rust;
• System76 Pop!_OS, где часть пользовательских инструментов уже пишется на Rust;
• Redox OS, операционная система на Rust с нуля.

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

Реализация sudo на Rust — не просто «модное» переписывание. Это шаг к устранению целого класса уязвимостей, которые десятилетиями преследуют Linux-инфраструктуру.

Утилиты вроде sudo, su и passwd обрабатывают привилегии и пользовательский ввод, а значит — являются первоочередными целями для атак.

Использование Rust в таких утилитах позволяет:

• Исключить целые классы уязвимостей на этапе компиляции.
• Повысить надежность и читаемость системного кода.
• Упростить последующий аудит и сопровождение.

Если не случится критических багов, sudo-rs появится в LTS-релизе Ubuntu 26.04 по умолчанию и навсегда.

Раунд возглавил венчурный фонд Sequoia Capital. С учетом предыдущих вложений, общая сумма финансирования проекта превысила $42 млн.

Проект возглавляет Натан Собо — создатель Atom, который в свое время стал архитектурной основой для VS Code.

Новые инвестиции позволят команде выйти за рамки построения UI и приступить к реализации глубокой интеграции ИИ в рабочий процесс разработки, а также представить собственную систему управления версионностью под названием DeltaDB.

Что такое DeltaDB

DeltaDB — это система, которая позволяет отслеживать изменения в коде с точностью до каждой операции редактирования.

В отличие от Git, который фиксирует состояние проекта по коммитам, DeltaDB формирует непрерывную временную шкалу изменений, в которую можно «вклиниваться» в любой момент — для обсуждения, анализа или интеграции.

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

DeltaDB спроектирована как надстройка над Git — она не отменяет git-репозиториев, а расширяет их возможностями детального отслеживания и сотрудничества в реальном времени.

Работа с ИИ — в том же контексте

Разработчики делают акцент на том, что обсуждения в Zed охватывают не только взаимодействие между людьми, но и с ИИ-моделями. Это означает, что подсказки от ИИ можно будет сохранять, обсуждать и возвращаться к ним в контексте правок, а не просто как ответы на запросы в отдельном чате.

Что еще важно

• Zed написан на Rust.
• Редактор доступен с открытым исходным кодом. Сам редактор — под GPLv3, серверная часть для многопользовательского редактирования — под AGPLv3, интерфейсная библиотека GPUI — под Apache 2.0.
• GPUI использует GPU для отрисовки интерфейса, что обеспечивает высокую отзывчивость и плавную работу редактора.

Zedless: альтернатива для тех, кто хочет полной автономности

На базе Zed развивается форк Zedless, ориентированный на пользователей, которым критична конфиденциальность.

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

Теперь SSL/TLS-сертификаты можно запрашивать, устанавливать и обновлять напрямую в конфигурации NGINX — без внешних инструментов вроде Certbot.

Модуль реализован на Rust с использованием NGINX-Rust SDK и доступен как для пользователей NGINX Open Source, так и для клиентов NGINX Plus через F5.

Что такое ACME и зачем он нужен

ACME (Automated Certificate Management Environment) — протокол, изначально созданный ISRG в рамках Let’s Encrypt для автоматизации получения и продления SSL/TLS-сертификатов.

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

Версия ACMEv2 поддерживает дополнительные методы проверки, включая wildcard-сертификаты.

Как это работает в NGINX

Встроенный ACME в NGINX позволяет:

1. Настроить ACME-issuer (например, Let’s Encrypt) через директиву acme_issuer.
2. Выделить общую память (acme_shared_zone) для хранения ключей, сертификатов и данных challenge.
3. Обрабатывать HTTP-01 challenge — требуется listener на порту :80 для подтверждения владения доменом.
4. Автоматически выпускать и продлевать сертификаты с помощью директивы acme_certificate в блоке server, используя переменные $acme_certificate и $acme_certificate_key для подключения в ssl_certificate и ssl_certificate_key.

На старте поддерживается только HTTP-01, в будущем обещаны TLS-ALPN и DNS-01. Wildcard-домены и regex в server_name пока недоступны.

В чем важность нововведения

Интеграция ACME напрямую в NGINX:

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

С ростом HTTPS и IoT-устройств, автоматизация управления сертификатами становится базовым требованием и нативная поддержка ACME в NGINX делает этот процесс проще и надёжнее.

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

P.s. Это перевод зарубежной статьи. Предлагаем подискутировать о вопросе в комментариях.

Как выгорание подкрадывается к разработчикам

Через несколько месяцев после того, как вы почувствуете усталость, console.log() начнет казаться непосильной задачей, а баг, который обычно исправлялся за час, ломает изнутри.

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

И статистика это подтверждает: по данным Stack Overflow, 32% разработчиков несчастны на работе, а еще 47% выживают на автомате, не чувствуя вовлеченности. Это значит, что почти 80% специалистов находятся в зоне риска эмоционального выгорания, хотя снаружи всё выглядит стабильно.

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

Но есть и другой путь. Иногда достаточно вернуть в день всего пять минут программирования без давления и ожиданий, чтобы постепенно вернуть ритм и интерес к работе. Маленькая привычка становится якорем, который помогает вспомнить, зачем всё это начиналось, и даёт пространство для восстановления.

Пятиминутная привычка, которая меняет всё

Чтобы преодолеть выгорание, не нужно переворачивать жизнь с ног на голову. Достаточно одной маленькой привычки — пяти минут в день, посвященных программированию без давления и ожиданий. Это может быть что угодно: написание нескольких строк кода, разбор простого алгоритма или чтение документации. Главное — последовательность.

Формула успеха звучит так: Минимальные усилия → Последовательность → Идентичность → Восстановление связи. Начав с малого, можно постепенно вернуть уверенность и интерес к профессии.

Как работает эта практика:

1. Выберите простое действие: например, написать одну функцию или изучить один метод в документации.
2. Установите таймер на 5 минут: это снижает порог входа и делает задачу необременительной.
3. Делайте это каждый день: даже если результат минимален, регулярность формирует привычку.
4. Не ждите вдохновения: действие само по себе создает мотивацию.

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

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

Как вернуться к программированию и не выгореть снова

Если хочется вернуться к программированию без риска снова выгореть, помогут простые принципы:

Опустите планку — и опустите её ещё раз. Если на старт уходит больше минуты, задача слишком сложная.

Не отслеживайте результат. Никаких счётчиков строк, коммитов и диаграмм продуктивности. Задача — восстановить доверие к себе, а не нарастить темп.

Избавьтесь от чувства вины. Пропустили день? Не страшно. Один пропуск не должен превращаться в цикл стыда. Выход из выгорания — не марафон продуктивности.

Не ставьте цели слишком рано. Позвольте любопытству проявиться. Работайте над чем-то странным или бесполезным. Там чаще всего и прячется вся соль.

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

Инструменты и ресурсы для тех, кто выгорел и не знает, что с этим делать

• Книги: «Атомные привычки» Джеймса Клира для понимания силы маленьких шагов.
• Курсы: платформы вроде Codecademy или freeCodeCamp для легкого возвращения к основам.
• Сообщества: нишевые Discord-серверы (например, по Python или Rust) или Reddit (r/learnprogramming).
• Трекеры привычек: приложения вроде Habitica для отслеживания прогресса.

Вместо итогов

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

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

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

Иногда именно пять минут дают больше, чем любой лайфхак продуктивности.

Бонус от экспертов: как пережить выгорание и вернуться к работе

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

Елизавета Якушева, тестировщик, автор тг-канала Press F to Debug:

Для меня выгорание — самая большая и страшная проблема в карьере. Абсолютно всё зависит от неправильно выстроенных ожиданий

Елизавета выделяет два разных типа выгорания:

1. От самой работы — стресс, рутина, груз ответственности.
2. От постоянной учёбы и самосовершенствования — давление трендов, ощущение собственной «недостаточности», переизбыток бесполезной информации.

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

Чтобы справиться, она предлагает задать себе простой, но важный вопрос:

«Зачем я это делаю? Что будет, если я перестану?»

Мы ходим на работу, чтобы получать деньги. Без этого мы не можем оплатить свои счета за ипотеку или продукты.

Стресс от груза ответственности решается простой мыслью: "Я здесь, чтобы выполнять работу так, как могу. Если я не успеваю что-то сделать вовремя, я умираю, у меня температура под 40, у меня отвалилась нога — вселенная не остановится, если ты возьмёшь тайм-аут в виде отпуска или day-off. Ракета не полетит в космос, и никто глобально не умрёт."

Для пет-проектов помогает осознанность: понимание, зачем ты вообще этим занимаешься.

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

Анастасия Егорова, фронтенд-разработчик, автор канала «Код и кофе»:

Анастасия комментирует технику «5-минутных привычек», описанную в оригинальной статье, и делится, как адаптировала её под свой сложный ритм:

У меня был период жизни, когда я полтора года работала на двух фуллтайм-работах… Иногда, просыпаясь зимним утром в 6:45, чтобы выйти на удалённый созвон в 7:00, я думала, что больше всего хочу уволиться со второй работы. Но нужно было работать.

В такие моменты она договаривалась с собой: поработать всего 5 минут, а потом дать себе что-то приятное — сериал, эклер, отдых.

Где-то на второй–третьей пятиминутке меня затягивало, и 5 минут превращались в полноценный час-два работы без переключения. Несколько таких подходов в течение дня — и к вечеру работа была сделана, а иногда ещё и сварен борщ, и приготовлены котлетки.

Да, бывают и провальные дни — но даже тогда, по её словам, важно просто не бросить всё совсем.

Я реально работала 5 минут, а потом 10 минут отдыхала… и к концу дня с помощью этих пятиминуток было сделано не так много. В такие дни я просто от себя отставала, радовалась, что я сделала хотя бы эти пятиминутные задачи, а не прокрастинировала весь день.

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