Rust *

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

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

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

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

Меня зовут Артур Валиев, я разрабатываю EVRT и EVRTCK. В программировании я привык мыслить состояниями, событиями, ограничениями и переходами между ними.

Но однажды возникает вопрос: можно ли тем же способом посмотреть на человеческие отношения?

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

Попробуем поговорить об этом на языке Rust.

Привет.

Спросите любого, что делает ?, и услышите примерно одно: «сахар для match, который при ошибке делает ранний return». В целом, тут есть правда. Разворачивается ? и правда в match с return, но прячется за этим match целый трейтовый механизм — он умеет конвертировать типы, работает с вашими собственными типами и не имеет ничего общего с try/catch, хоть и выглядит похоже.

Давайте посмотрим, что компилятор на самом деле пишет вместо вашего вопросика, что такое residual в нынешнем дизайне, почему ошибке нужен отдельный тип, и как прикрутить ? к своему типу. И сразу скажу: пользоваться ? на Result и Option можно давно и на стабильном Rust, а вот реализовать поддержку ? для своего типа — это до сих пор nightly. Дальше будет видно почему.

Я занимаюсь изучением синтаксиса языков программирования и пытаюсь отделить фундаментальные закономерности от исторических случайностей. Одна из таких случайностей - почти повсеместное использование терминов выражение (expression) и инструкция (statement) при описании и классификации синтаксиса языков программирования.

Интуитивно кажется, что 2 + 2 и if (x) { foo(); } - это совершенно разные сущности, но при более глубоком анализе оказывается, что подобное разделение искусственное и возникло из-за архитектурных особенностей вычислительных машин почти полвека назад и с тех пор просто «переходит» из языка в язык.

У нас тормозило всё: сборка, дев-сервер, svelte-check, LSP. Я пошёл писать свой компилятор Svelte на Rust. Пять с половиной месяцев ковырял руками и бросил. Через год вернулся с ИИ-агентом и доделал за 106 вечеров и $700.

В прошлой статье я писал о WIE - userspace эмуляторе, который через JIT позволяет запускать PE64 бинарники на Apple Silicon. Казалось бы проект шел хорошо - почему делаешь новое? Дело в том, что я уперся в ужасную скорость - 7zip реальный проект на 200+ мб сжимал в 80-100 раз медленнее, чем нативный macOS бинарник. И это исправить без радикальной переработки проекта и разрушения самой концепции невозможно. Поэтому его разработка к сожалению была приостановлена.

Но мне хотелось попробовать сделать то, что сохранит идею переноса бинарника одной OS на другую, но без JIT. И я нашел. И имя ему Kakehashi

Как разработать собственную ОС в одиночку, если заниматься проектом можно только в свободное время? Рассказываю, как ИИ помог мне пройти путь от изучения AArch64 до работающего ядра с вытесняющим планировщиком, userspace, ELF-программами и shell — и почему ответственность инженера при этом никуда не исчезает.

Ну, привет.

lock xadd. Вот и весь Arc::clone на x86. Одна инструкция. Заглядываешь в дизассемблер и даже немного обидно: столько разговоров про атомарные счётчики ссылок, а внутри обычный атомарный инкремент, который компилятор даже не утруждается оборачивать во что-то крутое.

Вот только эта инструкция вам подыгрывает. На вашем ноуте она бесплатная. А потом тот же код уезжает в прод на пару десятков ядер, и тот же самый инкремент оказывается самым дорогим местом в горячем цикле. Самая подлянка в том, что профайлер на ноуте этого не покажет: чтобы увидеть цену, нужен контеншен, а на одном ядре его нет. Так что вся статья, если честно, про одно. Как научиться смотреть на Arc::clone и видеть не инкремент, а короткий разговор с протоколом кэш-когерентности вашего процессора.

Arc принято звать умным указателем. Мне ближе другая формулировка: это примитив синхронизации, который натянул костюм указателя, чтобы вы его не боялись. Давайте снимем всю эту оболочку и глянем, кто там внутри. По ходу разберёмся, откуда в нём два счётчика, почему clone беспамятный, а drop нет, как живёт Weak, что за толстый указатель прячется в Arc<dyn Trait>, зачем придумали make_mut и где Rc делает Arc по скорости.

Я добавил в Quince AVX2, FMA и немного unsafe. По всем красивым схемам торговая VM после этого должна была полететь.

Она не полетела…

Сначала SIMD проиграл памяти. Потом кольцевым буферам. Затем выяснилось, что сама VM съедает часть ускорения. А в конце оказалось, что CI уверенно показывал результаты кода, который процессор вообще не исполнял.

Туториал на моих ошибках о том, как правильно внедрять SIMD без веры в чудесные х4.