Rust *

Привет, Хабр!

У меня есть для вас очень простой способ испортить себе вечер. Поставьте cargo-llvm-lines, запустите на своём проекте и посмотрите не на первую колонку, а на вторую, которая называется Copies. Сверху почти наверняка будет core::ptr::drop_in_place, дальше что-нибудь из Vec, потом хвост от serde. И напротив каждой строчки будет стоять не единица.

Обычная реакция в этот момент: ну да, дженерики, зато быстро, а одинаковые копии потом схлопнет LLVM. Часть действительно схлопнет. Только не тем механизмом, о котором вы подумали, и точно не тем, который вы включили в Cargo.toml.

В статье узнаем откуда берутся копии, почему Vec<u32> и Vec<i32> в бинарнике сливаются в одну функцию, а Vec<u32> и Vec<u64> не сольются ни при каких настройках, что от этого видно в именах символов, как с той же проблемой воюет сам std и куда делась полиморфизация, которую пять лет ждали как лекарство.

Я разозлился на то, что Lens стал платным, и написал свой платный Kubernetes-клиент: закрытый репозиторий, биллинг, версии до 1.7.12. Потом схлопнул историю в один коммит, выкинул платёжный код и выложил всё под MIT. Ирония дошла до меня чуть позже, чем следовало.

Под катом — как правило «не утверждать того, чего не можешь подтвердить» превращается в конкретные баги: под в Running с мёртвым контейнером внутри, Service с исправным селектором и нулём трафика, истёкший токен GKE, который выглядит как пустой кластер. Почему запрет на refetchInterval в линтере сэкономил 77% запросов к API-серверу. Как я трижды поймал одну и ту же гонку с Tauri-событиями. Как пришёл друг и переписал три четверти фронтенда, а я посчитал git blame, чтобы понять, что от меня осталось. И что я узнал, когда скачал собственный релиз, а macOS сообщила, что он повреждён.

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

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

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

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

Привет, Хабр! Меня зовут Сергей Маркизов и я бэкенд-разработчик в Далее. 

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

Node.js отлично чувствует себя в I/O-bound задачах (API, микросервисы, работа с базами данных и очередями), но как только в приложение попадает тяжелая CPU-bound логика (хеширование больших файлов, обработка изображений, видео, криптография) event loop может стать узким местом.

Один из способов решить эту проблему — вынести тяжелую часть в нативный аддон. В статье разберемся, как делать такие аддоны на Rust с помощью NAPI-RS: посмотрим на базовые типы, классы, асинхронные задачи, работу с JavaScript-объектами и управление ресурсами через Reference и External. 

Материал будет полезен Node.js-разработчикам, backend-инженерам и всем, кто хочет понять, когда Rust можно встроить в JavaScript-проект без боли для пользователей библиотеки.

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

Технология eBPF (extended Berkeley Packet Filter) берет свое начало от классического BPF, разработанного в начале 1990-х годов как механизма фильтрации сетевых пакетов, который впоследствии был реализован в Linux и других UNIX-подобных системах. Со временем возможности BPF значительно расширились, и появился eBPF — универсальная виртуальная машина, позволяющая безопасно выполнять пользовательские программы непосредственно внутри ядра без необходимости разрабатывать отдельные модули ядра. Сегодня eBPF применяется далеко не только для обработки сетевого трафика. Он используется для трассировки, мониторинга производительности, обеспечения безопасности, балансировки нагрузки, реализации сетевых политик и многих других задач. Перед загрузкой программа проходит проверку специальным верификатором ядра, гарантируя ее завершаемость, корректность обращений к памяти и соблюдение требований безопасности ядра. Благодаря этому eBPF позволяет расширять функциональность ядра без необходимости писать или загружать собственные модули ядра…

«Шарарам» – это старая, но до сих пор живая MMORPG по «Смешарикам». Огромный срез моего поколения, родившегося в нулевых, нашёл там первых друзей и приобрёл первые социальные навыки. Я до сих пор, в свои 23 года, возвращаюсь туда раз в один-два месяца: пообщаться с ровесниками и повспоминать золотые годы игры.

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

Это желание вылилось в эксперимент, после которого Шарарам почти перестал лагать. Честно замерить FPS сложно – разброс между локациями огромный, – но разница видна невооружённым глазом: играть комфортно даже там, где раньше было слайд-шоу. А заодно игра снова заработала в современных браузерах!

Поиграть можно через альтернативный клиент shararam.sadfun.dev (или его десктопную версию). Надеюсь, когда-нибудь это попадёт в апстрим, и игра станет приятнее для всех. А ниже будет технический разбор, как я это сделал.

Последнее время я почти не пишу код руками — значительную часть реализации берут на себя AI-агенты. Но работы меньше не стало: теперь нужно задавать ограничения, проверять архитектуру и понимать результат, не перечитывая тысячи сгенерированных строк. Я попробовал сделать архитектурный граф общей моделью для человека, агента и генератора кода. Из одного графа получил сервисы на Go, Python, C++ и Rust, а затем сравнил их с прямыми реализациями того же HTTP → gRPC сценария. Главный вопрос эксперимента: какова runtime-плата за систему, которую проще понимать, изменять и наблюдать?

Продолжаем изучать, как устроен SFU изнутри: добавляем simulcast, ice restart и мониторинг сети. Дневник разработки на Rust.

Encore зародился как фреймворк на Go, и на Go там были написаны среда выполнения, интерфейс командной строки (CLI), парсер и компилятор. Когда мы решили поддерживать TypeScript, логичнее всего было бы написать на TypeScript и среду выполнения тоже, либо достроить к среде выполнения Go какой‑нибудь мостик. Но в итоге пришли к тому, что написали новую среду выполнения с нуля на Rust.

Сервис жив, CPU в норме, паники нет — а часть запросов зависает на минуты. В async‑Rust привычный стек часто мало помогает: задача могла застрять на блокирующем вызове, мьютексе или просто перестать получать пробуждения.

Разбираем, как отличать эти сценарии в Tokio и куда смотреть, когда отладчик молчит.

Приветствую. В Rust есть целый класс костылей, который лежит буквально в каждом крейте с API на dyn старше пары лет. Методы вида as_super, as_debug, into_dyn_display.

Крутанёшь поиск по большим репозиториям на GitHub, найдёшь такое тысячами. Каждый делает одну и ту же тупую вещь: возвращает тот же самый &self, только под нужным трейт-объектом. Встроенно очевидная операция, которую больше десяти лет не могли завезти в язык.

С Rust 1.86 (3 апреля 2025) все эти костыли стали не нужны. Trait upcasting наконец стабилизирован: &dyn Sub спокойно кастится в &dyn Super, если trait Sub: Super. Причём стабилизировали не с первого раза. В конце 2023-го фичу мерджили, потом откатывали из-за двух багов в соундности, потом чинили, потом снова находили баги. Только к весне 2025 получилось выкатить окончательно.

Прошёл год стабильной жизни с фичей, экосистема переварила, паттерны поменялись. Разберём: как расширили vtable под эту штуку (спойлер: ещё в 2021-м, за четыре года до самой стабилизации), сколько багов в соундности нашли на nightly и в чём была суть, почему dyn MyAny: Any теперь одна из самых частых идиом, и почему Vec<Box<dyn Sub>> в Vec<Box<dyn Super>> всё равно не летит.

Доброго времени суток, читатели!

Хочу представить вам unissh – современный, простой опенсорсный SSH клиент с selfhosted zero-knowledge сервером для синхронизации данных.

Привет, Хабр!

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

Со стандартной библиотекой Rust так постоянно. Она большая, и половину её мы не используем не потому, что она плохая, а потому, что просто про неё не знаем — и пишем руками то, что давно лежит готовым. В первой части уже разбирали такие штуки: never-тип !, matches!, black_box, прозрачные обёртки repr(transparent) и transmute_copy. Подготовил для вас ещё девять.

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

Можно ли одному человеку собрать не демо, а работающую классическую RTS, если почти весь код пишут несколько ИИ-агентов? Я проверяю это на неудобной задаче: Марс 1:1, Rust + wgpu, камера от орбиты до ног робота, отдельная детерминированная симуляция, единая шина команд для человека, сети и ИИ. Разбираю, что уже работает к середине проекта, как устроены научные карты и BUS, почему 15 мс «в API» оказались ожиданием GPU, как тест на одном ПК скрыл сетевой лаг и какие красивые решения пришлось выбросить после измерений.

Я делаю NotiBox — Pusher‑совместимый сервис realtime уведомлений. Под капотом я использую Sockudo — WebSocket сервер на Rust. Прежде чем показывать реальным пользователям, я решил проверить, на сколько Sockudo на самом деле «blazingly fast».

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

Идеальный сценарий — полная загрузка процессора, памяти или сети, тогда ты реально нашёл предел ресурсов. Проверяешь масштабируемость и готово.

Другой сценарий — ничего не перегружено, но новые соединения/запросы не проходят, растёт задержка ответов. Это тоже ожидаемо и понятно как чинить: смотришь на TIME WAIT сокеты, max open files, и другие «предохранители».

А что делать, если там тоже всё по нулям? Вот тут начинается настоящее приключение.

Меня зовут Артур Валиев. Я открыл исходники EvertyDesk Lite — и заодно EvertyDesk Next, то, что должно было стать следующей версией. Полностью. Без купюр.

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

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

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

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

Расскажу про конкретный баг, который я ловил дольше всего.