Rust *

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

Как я думаю, у этой системы довольно большой потенциал, ведь его можно доработать и превратить в какой-нибудь аналог Ansible. Или в базу для SIEM системы. Или прикрутить к какой-нибудь ITSM-системе, чтобы проводить инвентаризацию по нужным параметрам.

Вся система будет строиться на gRPC, так как он из коробки идёт со всем необходимы, включая простую интеграцию систем аутентификации и TLS, плюс описание интерфейсов в .proto файлах позволит писать клиенты и агентов на различных языках и фреймворках. Единственный минус, так это то, что двунаправленное взаимодействие не укладывается в философию фреймворка, но это решим в процессе написания.

Наконец мы добрались до поистине сложной темы. Если вы думаете, что раньше были сложные, вы глубоко заблуждаетесь!

Двусвязный список на Rust. Это вообще возможно? Ну… да. С некоторыми оговорками. Что за оговорки, узнаем из четвёртой главы.

Срочно переписывайте свои устаревшие bloom фильтры на мой богоподобный lz77-фильтр. Совершенно бесплатно! Спасибо великому нанабанана за обложку!

Как я улучшил универсальный код Элиаса 1975 года, заменив длину на popcount — и получил 36% экономии на метаданных. С бенчмарками! Картинка на обложке кринжовая, но тут вроде так принято? 😅

Календарь, задачи, заметки, почта. Мы используем десятки инструментов, но они не умеют жить вместе. Данные размазаны по сервисам. Команда в Битрикс24, семья в WhatsApp, клуб в Google Calendar. Везде свой интерфейс, свои правила, своя изоляция.

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

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

Можно ли написать на Rust устойчивый список? Думаю, вы уже догадались, что да. А как — узнаете из третьей части перевода Too Many Linked Lists.

Вчера автор побывал на прекрасной конференции Backend Talks 360 от компании Yandex и не в силах спокойно спать, не ответив конструктивной критикой на доклад Ильи Абрамова о работе Яндекс.Диска, автор принялся писать очередной «В интернете кто‑то не прав». Что из этого вышло — добро пожаловать под кат.

Полгода использовал Claude, GPT и Cursor как полноценного второго разработчика на Rust в проде. Собрал семь категорий ошибок, которые модели стабильно делают и которые проходят cargo build, cargo test, иногда cargo clippy и при этом являются UB или скрытыми архитектурными ловушками. Lifetime laundering, std::sync::Mutex через .await, Drop у транзакций, unaligned read, async cancellation, orphan rule и массивы на стеке. Разбираю, почему именно Rust ломает LLM и что с этим делать.

Под катом рассказываю про 3a формат для ASCII анимаций, тулинг для работы с ним и коллекцию opensource ASCII артов для ваших cli/tui приложений, игр и постов в r/unixporn.

Продолжаем знакомство со списками в Rust. Перепишем код, избавившись от типа Link и заменив его на Option. Сделаем наш список обобщённым. И добавим в него несколько полезных методов.

По дороге разберёмся с временем жизни и типажом Copy.

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

Существующие в Obsidian плагины останавливаются на алгоритме SM-2 образца 1987 года.

Альтернативные решения есть «где-то еще», вне свободного ПО, вне Markdown‑first архитектуры — привязаны к облаку или проприетарному формату.

Я написал свой, потому что не нашёл подходящего.

FSRS, вычислительное ядро на Rust, скомпилированное в WebAssembly, и SQL‑подобный синтаксис для табличной выборки.

В статье — архитектура с WebAssembly, собственный парсер, лексер, замеры производительности. Любые запросы обрабатываются в сотых долях секунды. Blazingly fast 🦀

Это техническая статья. Если хотите пошаговое руководство для пользователя — вот обзорная статья.

Продолжаем знакомство с ссылочной магией в Rust. Вместе с автором создаём первый работающий список, наступая на все возможные грабли.

В конце взъерошенные, но счастливые наслаждаемся результатом.

async fn в Rust — это не магия и не зелёный поток, а обычный enum, который компилятор генерирует за тебя. Разбираем, почему Future это машина состояний, зачем нужен Pin, как работает Waker и executor, и как одна .await-точка может незаметно заставить твой сервис есть память гигабайтами.

Самая распространённая ошибка в асинхронном Rust — убеждение, что .await означает «подожди, пока операция завершится». Слово в переводе буквально это и значит, поэтому многие расставляют .await после каждого асинхронного вызова, как точки в конце предложений.

А потом оказывается, что сервер обрабатывает один запрос вместо сотни одновременно, мьютекс намертво виснет с одним-единственным вызовом, отмена в select! теряет половину сообщений, и синхронная версия того же кода работает быстрее. Корень всех этих проблем один: .await не означает «жди». Он означает «дай исполнителю право приостановить меня здесь». И пока вы держите в голове первое значение, асинхронный Rust будет вас наказывать.

В статье рассмотрим что компилятор делает с async fn, зачем нужен Pin, как Tokio решает какую задачу опросить следующей, почему std::sync::Mutex в асинхронном коде иногда срабатывает как мина, и почему даже tokio::sync::Mutex может зависнуть.

Rust давно перестал быть языком энтузиастов. На нём собраны куски ядра Linux, движки баз данных и аналитики (TiKV, Materialize, Polars), бэкенды Cloudflare и Discord. Под Rust пишут прошивки для ESP32 и STM32, фронтенд через WebAssembly, инференс LLM.

Microsoft переписывает части Windows, AWS строит на Rust Firecracker и Bottlerocket, Google пускает его в Android и в дерево ядра. По зарплатам Rust пятый год держится в верхнем дециле Stack Overflow Survey, и семь лет подряд - самый любимый язык разработчиков.

Я узнал об отключении не из новостей. Утром мне написал знакомый из небольшого банка: «всё упало, паспорта не проверяются, онлайн встал». В то время как раз дописывал обработку ошибок в smev4-rs, Rust-крейте для работы с СМЭВ 4.

Совпадение так совпадение.

Первые несколько часов ушли на то, чтобы понять, что вообще происходит. Минцифры говорило что транспорт в порядке. Жалобы шли и от тех, кто на СМЭВ 3, и от тех, кто переезжал на СМЭВ 4. Значит дело было не в версии протокола.

Если взять случайный крейт с crates.io и поставить его под Miri, шанс увидеть undefined behavior где-то в зависимостях стремится к единице. Разбираемся, почему: pointer provenance, Stacked Borrows, Tree Borrows и почему noalias в LLVM выключали три раза.

Начал перевод, видимо, базового руководства по сложным темам в Rust (не считая Растономикона, который вообще про чёрную магию) — Learning Rust With Entirely Too Many Linked Lists.

Надеюсь закончить всё с течение мая. Сегодня — введение. Первая глава — после выходных.

Как встроить векторизованный движок в OLTP-ядро с нуля — без отдельного аналитического слоя. Разбираем PhysicalType, SelectionVector, RowToColumnBridge, SIMD на листовых страницах B-Tree и Hash Join. Бенчмарк на 2,25 млн строк: от 1.22× на простых агрегатах до 2.67× на GROUP BY.

Привет, Хабр! Сегодня я хочу осветить тему работы с системой контейнеризации Docker прямиком из программы на Rust. Эта статья будет полезна тем, кто хочет разрабатывать различные программы для автоматизации рутинных действий Docker.