Rust *

«Шарарам» – это старая, но до сих пор живая 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 в системном программировании говорят реже, чем стоило бы. Язык закрывает один класс ошибок и оставляет другой нетронутым. И второй класс ловится куда хуже первого.

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

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

В работе с FASTA и FASTQ таких мест неприлично много. Почти все они когда‑то были задуманы как удобство.

Вот три, с которыми я сталкивался чаще всего.

Первое. Инструмент пишет FASTQ, а качества у записи нет. Вместо ошибки он подставляет строку из I. Файл получается валидный, парсер доволен, а фильтр по качеству дальше по пайплайну видит идеальные риды и пропускает всё подряд.

Второе. R1 и R2 разъехались: один файл отфильтровали, второй забыли. На выходе абсолютно корректный FASTQ, просто риды спарены не с теми. Формат не нарушен ни в одном байте. Ни один валидатор не возразит.

Третье. Определение Phred‑кодировки по образцу, который одинаково хорошо подходит и под Phred+33, и под Phred+64. Инструмент молча выбирает вариант. Иногда правильный.

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

Полгода назад я начал писать fastx, библиотеку и CLI для FASTA/FASTQ на Rust. Основное решение в ней сформулировано так: там, где можно либо угадать, либо признать неоднозначность, признавать неоднозначность.

Вслед за Эдвардом Сьоре, или как я писал свою реализацию on disk B+Tree-индекса на Rust. В этой статье попытаюсь осветить нюансы написание своего игрушечного индекса.

DLL sideloading - это когда в каталог программы подсовывают библиотеку с тем же именем, что и нужная ей DLL. В результате Windows сначала цепляется именно за неё и загружает её вместо системного файла. Этот приём по-прежнему работает, даже если включён SafeDllSearchMode, и недавно его использовали в атаках против FileZilla и CPU-Z.

В статье я разбираю этот метод на примере WinSCP. Сначала делаю статический анализ: проверяю зависимости в Import Table и сверяю их со списком Known DLLs, чтобы сразу отсеять те варианты, которые загрузчик всё равно берёт только из системной папки. Затем провожу динамическую проверку в Procmon и смотрю, где именно загрузчик действительно ищет DLL. В финале - прокси-библиотека на Rust.

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

За последний месяц отдельные разработчики Anthropic с помощью Claude Fable 5, Claude Opus 4.8 и dynamic workflows перенесли десять проектов объемом от десятков до сотен тысяч строк кода. В этой статье мы разберем два примера и лучшие практики, сформировавшиеся в ходе этих проектов.

Джарред Самнер, сооснователь Bun и технический специалист Anthropic, использовал Claude Code, чтобы перенести Bun с Zig на Rust. Менее чем за две недели было создано миллион строк кода. До слияния ветки 100% существующих тестов Bun проходили в CI. После слияния обнаружилось 19 регрессий, все они уже исправлены. В июне версия на Rust вошла в состав Claude Code.

Майк Кригер, один из руководителей Anthropic Labs, за выходные перенес кодовую базу на Python в 165 000 строк TypeScript. В процессе работали сотни агентов, использовались восемь контрольных этапов, три раунда состязательного ревью и финальная проверка, которая сравнивала вывод каждой команды с результатом оригинальной версии на Python.

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

Как выбрать биржу для алгоритмической торговли: latency, matching engine и реальная ликвидность

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

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

В результате я протестировал около 40 бирж.

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

Иногда всё наоборот.

Всем привет, Я Артур Валиев, Не хотелось но на этот раз я все-таки попрошу гуся что-бы помог рассказать мою историю.

Три дня назад я сидел и сравнивал integrity level токена процесса с integrity level окна в фокусе, чтобы понять, почему Диспетчер задач блокирует ввод удалённого пользователя. Никто в мире, кроме меня, в этот момент не знал, что это вообще проблема. Я был там один. И мне было хорошо.