Rust *

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 летает.

Миллион асинхронных задач на Rust спокойно живёт в нескольких сотнях мегабайт. Сто тысяч корутин на Python нередко упираются в память раньше. Дело не в том, что “Rust быстрый, а Python медленный” - дело в том, ГДЕ физически лежит состояние приостановленной задачи.

Разбираю, во что превращается ваш async fn после компиляции: стейт-машина на стеке против объекта в куче. Сравниваю модели Rust (Tokio), Python (asyncio), C# и JavaScript - кто аллоцирует на каждый await, а кто нет, и почему это видно на счётчике RAM при 100k задач.

Внутри: что генерирует компилятор, куда уезжает состояние между await, stackful против stackless, и что с этим делать сегодня.

Bounce — быстрый архиватор на чистом Rust без внешних зависимостей. Smart Routing автоматически выбирает стратегию: LZ77 для текста, Byte-Shuffle для весов нейросетей, Huffman для бинарных данных, Raw Store для уже сжатых файлов. Результат: 450 МБ .safetensors сжимается до 71.9% при декомпрессии 1.3 ГБ/с — лучше gzip и zstd. Многопоточный pipeline, пик памяти 73.6 МБ на файл в 450 МБ, размер блока через золотое сечение. Идеально для ML CI/CD, edge-деплоя LLM и смешанных датасетов.

5 марта 2026 года в своём доме, в окружении семьи, тихо умер человек, чей код вы трогали на этой неделе. Возможно, прямо сегодня. Возможно, он уронил вам прод.

Звали его сэр Чарльз Энтони Ричард Хоар. Для друзей — Тони. Для пары поколений студентов — C. A. R. Hoare, тот самый, что в 26 лет придумал quicksort, выиграв у начальника спор на шесть пенсов. Тьюринговская премия 1980 года, логика Хоара, CSP, на которой потом выросла половина теории конкурентности. Большая, красивая, почти безупречная карьера.

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

Это null.

Есть расхожий сюжет: коварная индустрия наплодила багов, а гениальные инженеры героически с ними борются. Красиво. И, как обычно, неправда. Потому что самый дорогой баг в истории софта добавил не злодей и не нерадивый джун. Его добавил один из умнейших людей в истории computer science. 

Вот про эту историю и поговорим.

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

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

Именно это стало отправной точкой для идеи Chrome-расширения, которое добавляет слой аналитики поверх списка проектов Upwork и позволяет быстрее принимать решение, стоит ли откликаться на вакансию.

Каждый раз, когда нужно передать кому-то файл или пароль, выбор бесит: WeTransfer и аналоги видят всё, почта и телеграм хранят файл в плейнтексте вечно, PrivateBin только для текста. Хотелось простого: бросил файл, получил ссылку, а сервер физически не может его прочитать. И чтобы сервер был мой. Так появился share·me, self-hosted сервис, который шифрует файлы и текст прямо в браузере (AES-256-GCM), а ключ кладёт в URL-фрагмент, который браузер никогда не отправляет на сервер. Внутри: Rust/axum, Next.js, потоковое шифрование больших файлов и пара граблей, на которых я споткнулся.

Третья часть написания своего языка программирования на Rust с нуля: Парсинг первых стейтментов языка: вывод и присвоение.

WebSocket — один из самых распространенных транспортов для обмена данными в реальном времени: чаты, биржевые котировки, игровые серверы, IoT. На практике выбор библиотеки редко сводится к вопросу «кто быстрее парсит заголовок фрейма». Важнее сочетание совместимости со старым набором инструментов сборки, поддержки TLS, сжатия per-message-deflate, модели асинхронности или блокировки, размера бинарника и способа обработки ошибок.

Код стало писать дешевле: большие команды и AI-агенты быстрее создают новые файлы, паттерны и, иногда, дубли. Если поиск copy-paste работает медленно, его легко убрать из каждого pull request и запускать только иногда. Я попробовал сделать быстрый Rust-клон jscpd, чтобы duplicate-code check оставался достаточно дешевым для обычного CI.

KODE.market: Как я написал первый в мире поисковик по GitHub и GitLab + P2P-раздатчик open-source кода + Антивирус.

Без модерации, комиссий и SEO-мусора. Мгновенный поиск, проверка идей + гибридная раздача релизов в одном инструменте.

Привет, Хабр! На связи TechnoL0g. Если вы хоть раз пробовали опубликовать своё детище в официальных сторах или годами поддерживали open-source репозиторий, то прекрасно знаете, сколько боли приносит классическая дистрибуция.

Вторая часть по написанию своего языка программирования с нуля на Rust: Написание парсера для выражений.

Гайд о том, написание интерпретируемого языка с динамической слабой типизацией на языке Rust с нуля. Часть 1: Написание лексического анализатора.