На поделке из предыдущей статьи вдохновение не закончилось, решил написать VPN. Был опыт разработки shadowsocks сервера, что не понравилось: под каждое TCP соединение, открываемое каким-нибудь браузеров, VPN клиент открывает отдельное TCP cоединение к серверу, а тот в свою очередь столько же до конечной точки + пришлось руками шифровать/дешифровать payload. Захотелось сделать что-то более простое + самим написать и клиент.
Rust скор во время выполнения, а вот компилируется он не так шустро. Едва ли это удивит читателя, имевшего дело с серьёзными базами кода на Rust. В блогах сложился целый жанр постов, повествующих о том, как скостить пару секунд с cargo build.
В нашем проекте мы реализовали функцию, позволяющую пользователям писать прямо на SQL, определяя таким образом таблицы и представления. Под капотом этот код на SQL компилируется в код на Rust — который затем передаётся rustc и с его помощью компилируется в единый бинарник. В этом двоичном файле путём пошагового приращения все представления актуализируются по мере того, как новые потоковые данные поступают в таблицы.
Ранее мы уже предпринимали всевозможные ухищрения, чтобы ускорить компиляцию: стирали типы, активно продавливали дедупликацию кода, сокращали строки, связанные с генерацией кода. В этом мы достаточно преуспели. Но недавно мы стали осваивать работу с крупным новым клиентом (энтерпрайз), у которого оказалась масса сложного SQL-кода. Они написали при помощи наших инструментов много больших программ. Например, там был образец размером в 8562 строк на SQL, который наш компилятор в итоге превращал примерно в ~100k строк на Rust.
sizeof(Mutex<()>) в Rust 1.61 на Linux был 40 байт. В Rust 1.62 он стал 5 (точнее, 8 с учётом выравнивания, но базовый overhead 5).
За уменьшением размера в восемь раз стоит полная переписка стандартного Mutex с pthread на futex напрямую, ускорение uncontended locks в 2-3 раза, и десятилетие, которое стандартный Mutex провёл в роли «возьми parking_lot, std::sync::Mutex медленный».
Сегодня заглянем под капот всей этой темы, разберём, что лежит внутри std::sync::Mutex после 1.62, какой алгоритм там используется, почему он на самом деле быстрее pthread, как устроен fairness (точнее, его отсутствие), зачем нужен poisoning, и в каких случаях parking_lot всё ещё имеет смысл тащить в зависимости. Заодно вернёмся к моей старой async-статье и поясним конкретнее, почему в async-задачах std::sync::Mutex это проблема, и при чём тут вообще futex.
Небольшая история о том, как я искал для себя читалку, как в итоге придумал новый формат для электронных книг — и, главное, как я месяцами воевал с дешёвыми LLM, чтобы они генерировали этот формат без ошибок. Будет и про устройство формата, и про то, как он «затюнен» под копеечные модели, и про основные проблемы.
Публикуем перевод третьей статьи из серии (первая часть, вторая), посвящённой информационным технологиям в авиаперевозках. Сегодня поговорим о режиме командной строки системы Amadeus, работа в которой опирается на язык, созданный для телетайпов. Этот язык до сих пор обеспечивает огромный процент бронирований билетов во всём мире — как тех, что выполняются различными агентствами, так и тех, что делаются посредством GDS.
Недавно попалось на глаза поворотное устройство для видеокамер PTZ 3050DZ, которое заинтересовало меня невысокой стоимостью и приличным заявленным весом поворачиваемой видеокамеры в 10 килограмм. Подумалось, что оно вполне может подойти для использования с небольшими спутниковыми антеннами. По ходу дела пришлось смастерить для него еще и дистанционное управление с применением модулей LoRa. Жмите кнопку ниже, чтоб узнать подробности.
Как дать админу доступ к виртуальным машинам на удалённом хосте без агента внутри гостевой ОС — на примере VirtualBox и Hyper-V. Один RDP-движок на оба гипервизора, три бага VirtualBox по дороге и таймаут, который переписал всю архитектуру.
Каналы - механизм передачи данных между потоками или асинхронными задачами. Идея простая: один конец отправляет сообщения (отправитель), другой их получает (получатель), а вся синхронизация спрятана внутри. За этим стоит целый подход: вместо того чтобы разделять память и вручную её блокировать, данные передают сообщением.
На практике же стоит копнуть глубже, и оказывается, что каналов в экосистеме Rust целый зоопарк: std::sync::mpsc, crossbeam-channel, tokio::sync, flume, async-channel, kanal и ещё несколько менее известных. Они отличаются моделью, поддержкой асинхронности, скоростью и кучей мелких деталей, о которые легко споткнуться. В этой статье разберёмся, какие каналы бывают, чем они отличаются и какой брать под конкретную задачу.
Я хотел одну простую вещь: чтобы на втором мониторе тихо играло lo-fi, а за виджетами крутилась уютная анимированная сцена. Готового решения не нашлось — зато нашёлся чужой MIT-проект, у которого я в итоге выкинул главный модуль и собрал из остатков совсем другой продукт. Это девлог о том, что я удалил, что добавил и на каких граблях потанцевал.
Под задачу подходящих инструментов хватало, но каждый закрывал только часть. Wallpaper Engine — живые обои, но без радио. Lofi.co — музыка в браузере, но не обои рабочего стола. Noisli — эмбиент, но без всего остального. Покупать три подписки ради фона под код было жалко, поэтому я полез на GitHub смотреть, что можно собрать самому.
Нашёл meel-hd/lofi-engine под MIT — аккуратный Tauri-проект со встроенным генеративным движком, который синтезировал lo-fi прямо в браузерном рантайме. Идея красивая, но мне быстро стало понятно, что я хочу совсем другого продукта. Так появился форк, который я в итоге назвал LoFiTyan.
В феврале я публиковал первую статью про Yttri: что это за приложение, зачем я его делаю и почему мне не хватало Obsidian, Notion, почтового клиента, таск-трекера и AI-чата по отдельности.
Тогда это был первый публичный заход в бета-тестирование. Первая сотня мест ушла быстрее, чем я ожидал, а комментарии оказались полезнее любой внутренней аналитики. Люди спрашивали про локальность данных, закрытый код, запуск без Ollama, связь задач с письмами и заметками, синхронизацию, доверие к приложению и вообще про то, не слишком ли это большой комбайн.
С тех пор Yttri сильно изменился. Это уже не просто «единый интерфейс для всего», а более взрослая local-first среда: с открытыми markdown-данными, локальными моделями, агентом, почтой, задачами, заметками, финансами, записями встреч и нормальной доставкой тяжёлых AI-компонентов.
Сейчас я расширяю бета-тестирование и хочу позвать новых пользователей.
Каждый раз, когда вы пишете .await, происходит не магия, а вполне конкретный механизм: Future, Waker и опрос состояния. Чтобы увидеть это своими глазами, я написал собственный async-рантайм на Rust с нуля - с executor, reactor на epoll и рабочим TCP-эхо-сервером. По пути разобрался, как именно tokio будит ваши задачи, и нашёл баг, который тихо висел у меня в проде. Внутри - весь код целиком и объяснение без отсылок к чёрным ящикам.
GPUI является быстрым и производительным UI фреймворком на Rust c GPU ускорением от команды разработчиков, создавших редактор кода Zed, который как раз его использует для UI части. Данный фреймворк вышел относительно недавно, поэтому его API немного нестабильный, во многих источниках, на которые Вы могли наткнуться на просторах Интернета, включая примеры в официальном репозитории, написаны на более старой версии, из-за чего изучать данный фреймворк становится ещё сложнее. Он поддерживает такие платформы как macOS, Windows, Linux и FreeBSD. В данной работе применяется версия 0.2.2.
Писал парсер строго под свой проект, а получился быстрый декларативный движок для парсинга текстовых форматов. Как?
Я публиковал перевод Too Many Linked Lists по мере готовности, поэтому каждая отдельная глава представлена отдельной статьёй на Хабре.
Книгу в таком виде читать неудобно, так как приходиться искать статьи в ленте автора. Поэтому я собрал Оглавление в одном месте, а именно здесь. Теперь не заблудитесь!
Вот мы и добрались до конца. Перед вами последняя, седьмая глава книги Learn Rust With Entirely Too Many Linked Lists.
И немного дурацких списков. Как вам список, размещённый не в куче, а на стеке? Невозможно? Ещё как возможно! Читаем!
В Tauri фронтенд дёргает Rust-команды через invoke("get_user", { userId: 42 }) — строка, объект, никакой проверки типов. После очередного вечера, убитого на расхождение snake_case и camelCase, я написал генератор, который превращает Rust-команды и serde-типы в готовые TypeScript-файлы — без аннотаций и правок в коде приложения.
Под катом — почему генерировать надо не то, что написано в коде, а то, что serde реально шлёт по проводу; как я выпустил три релиза за один день, воюя с макросами; и при чём тут юникод-эскейпы в TOML на Windows.
Ладно, забудьте всё, что было раньше. Весь этот детский лепет про ссылки и указатели.
Настало время писать настоящий продуктовый код. Посмотрим, как он выглядит на языке Rust.
В шестой главе реализуем двусвязный дек с помощью сырых указателей.
Новая статья из цикла про нашу OLTP-СУБД на Rust.
С самого начала мы выбрали MVCC на UNDO-логе вместо версионирования в heap, как в PostgreSQL. И годами повторяли свой же лозунг: «нет VACUUM, нет bloat». Оказалось, это правда ровно наполовину.
Heap и правда не пухнет от истории версий. Но bloat никуда не делся: он переехал в индексы, в мёртвые слоты и в сам UNDO-лог. А сборка мусора из одного механизма незаметно превратилась в пять, и мы только сводим их к единому координатору.
В статье разобрали без прикрас обе стороны. Что UNDO-модель дала: стабильный TID (UPDATE, который не трогает индексы), rollback пропорционально размеру транзакции, аналитику, не дорожающую от write-нагрузки, и AS OF как «машину времени» почти даром. И чем за это платим: главная эксплуатационная цена это долгоживущий снапшот, который молча останавливает очистку для всех.
Вопрос к тем, кто эксплуатировал MVCC-базы под нагрузкой: что меньшее зло — блокировать GC ради долгих транзакций или отдавать «snapshot too old»? Любопытно ваше мнение в комментариях.
Вероятно, самая важная глава в книге про реализацию связных списков на языке Rust. И уж точно самая длинная.
Здесь автор рассказывает про сырые указатели, неопределённое поведение, стековое заимствование, miri и тип Cell/UnsafeCell.
В конце главы — работающая реализация.
# Как мы четыре раза неправильно диагностировали зависание на джобе 281 339
Несколько месяцев назад я писал, [как мы четыре раза неправильно чинили мерцание](https://habr.com/ru/articles/1042962/) при рендеринге 4,4 миллиона полигонов. Тогда казалось, что это рекорд: месяц блужданий, четыре отброшенных подхода, решение на неделю. Эта история хуже. Баг пережил четыре диагноза подряд, два из которых мы успели «подтвердить числами», получил по дороге три работающих фикса от несуществующих причин - и в итоге оказался файлом, который лежал на рабочем столе.
Напомню контекст: мы небольшой командой пишем на Rust + Vulkan редактор топологий интегральных схем + верификатор (DRC/LVS/Antenna/PEX) с прицелом на российский рынок. Команда - три человека, я в роли CTO направляю архитектуру и принимаю основные решения. В том числе неверные, о которых ниже. Тестовый основной дизайн всё тот же - Caravel SkyWater SKY130: 4,4 миллиона полигонов, 1014 уникальных ячеек, 22 уровня иерархии, 278 МБ GDS (недавно воспользовались прекрасным проектом [TinyTapeout]( https://github.com/TinyTapeout/) - для прогона на различных gds)
К моменту этой истории мы только что закончили перф-кампанию по паразитной экстракции (PEX). Если коротко: чтобы посчитать ёмкости, нужно сначала собрать цепи - обойти иерархию чипа BFS-ом от каждого "сида" (точки на цепи устройства) и выяснить, какие фигуры электрически связаны. На Caravel это 537 748 сидов. Кампания ужала полный холодный прогон с 962 секунд до 70: пространственный грид вместо квадратичного перебора пар, параллельные трейсы на 14 потоках, кеш результата. Все гейты бит-идентичности зелёные, CLI летает.
