Rust *

Почему знакомство похоже на систему с неполной информацией, неопределённость удерживает внимание, а алкоголь временно включает 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.

Всё началось с обычной бытовой боли. У меня был сайт, и сайту иногда нужно было сказать мне что-то важное: «заказ оплачен», «диск на 91%», «пришёл ответ от банка».

Так родилась идея: сервис, куда сайт стучится одним HTTP-запросом, а на всех твоих устройствах через секунду загорается уведомление. Я назвал его Pheme.

А дальше случилось то, что случается со всеми пет-проектами. Ты пишешь «просто релей уведомлений», потом смотришь на код и понимаешь, что у тебя уже есть пользователи, устройства, каналы, история сообщений, лента, комментарии — и остаётся дописать «всего лишь» шифрование, звонки и федерацию, чтобы получился полноценный мессенджер. Что я и сделал.

На Хабре периодически появляются статьи с анализом феномена Python - как один из самых медленных языков программирования стал королём нейросетей, и ответ всегда один: за счёт простого синтаксиса и развитой экосистемы. Но экосистема у C++ значительно больше и богаче, значит, дело не в ней и остаётся только синтаксис. А если проблема действительно в синтаксисе, тогда должен быть ответ и на другой вопрос: почему C++ не стал основой для исследований в этой (или любой другой) области?

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

Но есть и другой способ оценить то же самое - причём гораздо проще, доступнее и без единой строчки анализа кодовой базы. И этот способ даёт неожиданно точный ответ на вопрос, почему именно Python в машинном обучении, несмотря на его репутацию «медленного» языка, стал стандартом.

Я бэкенд-разработчик: пишу на Rust сервис аналитики для продавцов маркетплейсов. Одна из его частей — автоматический биддер, который превращает цель «ДРР не выше 12%» в непрерывное управление ставками. Внутри: контроллер с мёртвой зоной и клампами, per-token бакеты против 429 «Limited by global limiter, per seller», возобновляемые фоновые джобы и борьба с дедлоками параллельных писателей.

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

Признавайтесь: вы пользуетесь std::collections::HashMap примерно каждый день и ни разу не задумывались, что под ним. А под ним, если коротко, сидит алгоритм от Google. С Rust 1.36 (это лето 2019-го) стандартный HashMap это порт SwissTable, той самой структуры из абсейловского flat_hash_map. До этого там был Robin Hood hashing, и если вы где-то ещё видите описание std-мапы как «linear probing and Robin Hood bucket stealing», знайте: оно протухло, актуальная документация уже пишет «quadratic probing and SIMD lookup».

И вот «SIMD lookup» это самое интересное. Весь фокус скорости SwissTable держится на одном байте служебных данных на элемент, который сканируется по 16 штук за одну инструкцию процессора.

В статье глянем, как это устроено внутри, почему ваша мапа по умолчанию устойчива к hash DoS и платит за это скоростью, когда в проде стоит переходить на FxHash, и почему низкоуровневый RawTable существует, но в публичном HashMap его спрятали.

Будет много кода и немного ассемблерной романтики.

WIE — это исследовательский эмулятор пользовательского режима (userspace) для запуска 64-битных Windows-приложений (PE64) на архитектуре macOS Apple Silicon. Проект написан на Rust 1.97, а в качестве бэкенда компиляции используется Cranelift для трансляции x86-64 инструкций на лету в нативный ARM64.

В статье расскажу о PWA‑бенчмарке, который основан на задаче N тел. Физический движок написан на Rust/WebAssembly, визуализация через Three.js, и результаты запусков сохраняются в Supabase. Тут присутствует разбор архитектуры, сравнение алгоритмов расчета — прямой и Barnes‑Hut, а также тут расписаны проблемы, связанные с измерением производительности в браузере.

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

Когда вы пишете вот такую строчку:

const N: u64 = fib(50);

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

И вот вопрос, на который мало кто может ответить с ходу: а кто конкретно это исполняет? Где живёт тот интерпретатор? Почему 255 + 1 в const падает с ошибкой компиляции, а в рантайме просто паникует? Почему можно посчитать таблицу из тысячи элементов циклом, но нельзя написать if a < b для дженерика? И почему 0.0 / 0.0 в const официально разрешили вести себя недетерминированно?

Погнали разбираться.

Здравствуйте, что-бы разобраться c уравнениями, нужно примерно понимать что это не новость а статья.

Разберем кейс о сборке полностью кастомного 3D принтера. Можно ли, имея бескрайний энтузиазм и скидочные купоны в AliExpress, собрать на своем балконе авторский принтер? Может ли Rust быть эффективным инструментом для встроеной разработки? Давайте посмотрим‑с.

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

#[derive(Serialize, Deserialize)] это какая-то одна строка в коде. На холодной сборке за ней прячется двадцать с лишним секунд компиляции, даже если в проекте больше ничего нет. Откройте cargo build --timings на любом не самом маленьком проекте с serde, и serde_derive почти наверняка окажется в первой тройке самых медленных крейтов. При том что в самом serde_derive всего несколько тысяч строк.

Между этой строкой и этими секундами лежит вся инфраструктура процедурных макросов: TokenStream, syn, quote, proc-macro2, watt. Пройдёмся по ней в этой статье.

Rust-компилятор не просто превращает код в машинные инструкции — он проверяет безопасность программы ещё до запуска. Разбираем, как устроен конвейер компиляции, зачем Rust использует сразу несколько промежуточных представлений (HIR, THIR, MIR) и какую роль во всём этом играет LLVM.

Я Артур Валиев, разработчик EVRT

Когда мы форкнули RustDesk и начали строить EvertyDesk — корпоративный удалённый рабочий стол с поддержкой Hyper-V, Proxmox, VirtualBox и умным агентом — первое, во что упёрлись, было видео.

H.264 — стандарт де-факто. TeamViewer, AnyDesk, Windows App — все используют H.264. Он работает. Но он lossy. И вот здесь начинается проблема, о которой в статьях про remote desktop обычно не говорят.

Когда оператор смотрит на терминал с git diff или читает трейс в VSCode — один размытый пиксель в букве это уже другой символ. H.264 при любом разумном битрейте вносит артефакты в области с резким контрастом. Точно туда, где у нас весь текст. Это неприемлемо.

H.264 в lossless режиме (QP=0, lossless profile) существует, но поддержка в декодерах — через пень-колоду, а для mostly-static контента предикторы рассчитанные под видео с движением дают нулевой выигрыш над тривиальным delta-кодером.

Нам не нужен motion estimation. Нам нужно: вот предыдущий кадр, вот текущий, вот список изменившихся тайлов, сожми только их.

Мы написали EVRTCK.