Rust *

Привет, Хабр. Меня зовут Владимир, я бэкенд-разработчик. Это моя первая статья здесь — о том, как пет-проект для нишевого варианта шахмат прошёл путь от «а что, если...» до первого места в рейтинге на chess.com. Без нейронок. На чистом alpha-beta поиске, написанном на Rust.

Статья будет полезна тем, кто интересуется шахматным программированием, оптимизацией CPU-bound задач или связкой Python + Rust через PyO3.

Переезд с macOS на Windows для разработчика часто сопровождается болью от потери привычного инструментария. В моем случае решающим стимулом свитчнуться на ПК стала мощная видеокарта. Сейчас мой верный MacBook всё так же лежит на столе и даже подключен к мониторам, но по факту именно Windows (как бы сильно она мне ни не нравилась) стала основной рабочей системой.

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

Штатный инструмент Windows (Win+V) разочаровал моментально: лимит в 25 элементов, отсутствие поиска и полное обнуление после перезагрузки ОС. Поиск альтернатив тоже не увенчался успехом: Ditto надежен, но выглядит как гость из 2005 года, а мощный CopyQ имеет перегруженный интерфейс суровой системной утилиты. Ни в одном из них не было современных функций вроде OCR «из коробки» или базовой интеграции с LLM для обработки текста на лету.

Решение напрашивалось само собой — написать свой велосипед. Но сделать его легким, быстрым и без Electron. В этой статье расскажу о том, как устроен Beetroot — менеджер буфера обмена с бесконечной историей, нативным OCR и AI-трансформациями.

"Стоит только начать" - я писал бэкенд-сервис на Rust, и мне понадобилась валидация международных телефонных номеров. Как и любой Rust-разработчик, я пошёл на crates.io и скачал самую популярную библиотеку для этой задачи.

А затем я открыл их issues на GitHub.

Вы открываете горячую функцию в профилировщике, видите миллионы вызовов, добавляете #[inline(always)]. Бинарник распухает, время сборки подскакивает, а производительность не меняется. Или ваще падает. Проблема не в атрибуте. Проблема в том, что #[inline] делает совсем не то, что подсказывает интуиция.

После первой статьи в комментариях несколько раз прозвучало примерно одно и то же:
"Всё правильно, но это же про любую зрелую СУБД — что с этим делать?"

Я думал над этим вопросом несколько недель. И в итоге решил не искать ответ в виде
"возьмите правильный инструмент X" — а попробовать честно сформулировать:
какими свойствами OLTP-БД должна обладать сама по себе, независимо от того,
насколько хорош ваш оператор, консультант или runbook.

Что такое "контракт" — и почему это не маркетинг

Попробую объяснить не через определение, а через ощущение.

Когда вы покупаете автомобиль, вы не читаете инструкцию к тормозам каждое утро.
Вы просто знаете: нажал педаль — машина тормозит. Это контракт. Он не зависит от того,
правильно ли вы настроили тормозную жидкость этим утром или не забыли включить
"режим торможения" в меню.

Кому будет полезно

Если вы живёте в Python и одновременно используете statsmodels, lifelines, pyhf, PyMC/BlackJAX, linearmodels (или что‑то похожее).

Если вам важны воспроизводимость и понятная валидация численных оптимизаций (особенно в HEP).

Если вам интересна архитектура «одно вычислительное ядро → много задач» и практические hot paths (AOT, SIMD, zero‑copy).

В начале 2025 года компания MinIO в лице сооснователя Harshavardhana начала поэтапно сворачивать свою версию Community Edition. В феврале из open-source версии был вырезан веб-интерфейс администрирования - управление политиками, мониторинг, репликация, IAM - всё это переехало в коммерческий продукт AIStor с ценником от $96 000 в год. Пользователям оставили лишь базовый object browser и CLI-утилиту mc. В мае последовало удаление поддержки OIDC-аутентификации. В октябре MinIO прекратил публикацию Docker-образов и готовых бинарников - причём аккурат в момент раскрытия критической CVE-уязвимости. А в декабре 2025-го проект официально перешёл в режим maintenance mode: никаких новых фич, pull request'ы не принимаются, только точечные security-фиксы по усмотрению компании.

Нередко при оптимизации приложений, написанных на языках со статической компиляцией (C, C++, Rust), наступает момент, когда стандартные методы оптимизации, такие как улучшение алгоритмов, подбор структур данных, флаги компиляции вроде -O3, перестают давать дополнительный прирост производительности. В этот момент многие вспоминают про фундаментальное ограничение статических компиляторов. В отличие от JIT, они не знают, какой код будет горячим, а какой холодным. JIT-компиляторы (JVM, V8, .NET) получают эту информацию в runtime и адаптируют оптимизации под реальную нагрузку. Статические компиляторы генерируют машинный код заранее и лишены информации о поведении программы в runtime. Для решения этой проблемы используется подход Profile Guided Optimization (PGO). Он позволяет собрать данные о выполнении программы и передать их компилятору для принятия более оптимальных решений при генерации кода. По сути, PGO - это способ дать статическому компилятору некоторые преимущества JIT, сохраняя при этом все преимущества ahead-of-time компиляции: отсутствие пауз на перекомпиляцию и полный контроль над билдом.

Приветствую.

В 1936 году Алан Тьюринг опубликовал статью, которая среди прочего доказала одну неприятную вещь: невозможно написать алгоритм, который для любой программы и любого входа определит, остановится программа или нет. Проблема остановки. Мы натыкаемся на неё гораздо чаще, чем кажется. Иногда прямо в Cargo.toml.

Cегодня редко встретишь разработчика, который хоть раз бы не слышал о Rust. После долгого хайпа и зародившегося мема RIIR (rewrite it in Rust — перепиши это на Rust) ажиотаж вокруг языка как будто бы поутих. Но оказалось, все и вправду по‑тихому переписывается на Rust (если мой дебют не утонет в минусах, постараюсь написать статью‑исследование на тему, где уже Rust надежно поселился в системе).

Первое, что меня впечатлило — это статья, что вся инфраструктура Cursor написана на Rust в целях экстремальной производительности, и язык с этой задачей, как видно, прекрасно справляется. Второе, что и сподвигло не только читать о Rust, но и начать на нем писать, — это, конечно же, дефицит комлектующих. «640 КБ на самом деле хватит всем» и интерес пал на братьев наших меньших — микроконтроллеров. Вот где действительно можно прочувствовать всю необходимость оптимизации.

Конечно, знакомство с Rust, как и у всех, началось с классики — Rust book для новичков и Embedded Rust для желающих окунуться в разработку встроенных систем. В Rust Book новичкам предлагается написать простую программу Guessing Game — приложение, которое загадывает число, а «игрок» должен попытаться его угадать.

Но просто читать не так интересно как набивать свои собственные шишки, поэтому, вооружившись книгами, документацией, все еще живым StackOverflow и Gemini в качестве ментора, я решила объединить эти два мира и сделать Guessing Game на STM32.

Далее хочу предложить небольшой гайд (или просто объяснение кода) из того, в чем удалось разобраться.

14 месяцев назад я начал разрабатывать гонку. Идея была простой — с дедлайном 4 месяца сделать простую игру без пафоса. Ну, любой разработчик знает, что произошло дальше: без пафоса не вышло.

Я пишу на Python. В последнее время увлёкся Rust — типы, скорость, предсказуемость. Но когда смотрю, как пишут веб на Расте, по спине холодный пот: десятки строк замыканий на один endpoint, Box::pin, lock контейнера, resolve, clone. Хотелось питонячего подхода — без мишуры. Решил расширить своего Urich до Rust. Пошёл дальше: написал растовое ядро (роутинг, протокол приложения, HTTP), поверх него — две обёртки: для Rust и для Python. Один core, два языка. В ядре — зачатки ASGI (scope, receive, send).

Всё в ветке multi. Пока work in progress, но то, что получается, нравится. Ниже — суть, пример кода, ссылки. Зову помогать: комментарии, контрибьюции, реальные использования — буду рад.

Выйдя на пенсию и имея много свободного времени, я решил посвятить себя любимому занятию - разработке высоконагруженных финансовых архитектур, ядер и протоколов межбанковского клиринга (проект Orda). Я создал Qazna - проект, который называю «финансовым Linux», полностью переведенный на строгую открытую лицензию GNU AGPLv3.

Ежедневно ковыряясь в архитектуре систем, отлавливая уязвимости на пайплайнах (вроде недавних багов в crypto/tls в стандартной библиотеке Go) и выстраивая отказоустойчивые сети, я поймал себя на одной мысли. Мы тратим колоссальные ресурсы на защиту серверов и протоколов, но игнорируем самую уязвимую систему с устаревшим legacy-кодом - нас самих.

Этот пост - попытка выйти за рамки классического IT и посмотреть на историю, политику, общество и медицину через призму системного анализа, API-инъекций и социальной инженерии. Документ "Тартар и Я", над которым я работал до этого, натолкнул меня на мысль, что праязык человечества - это не утерянный миф, а живой код. И сегодня я хочу поговорить о том, как этот код компилируется в нашу реальность.

Когда мы говорим о программировании, мы по привычке представляем кремниевые процессоры, серверные стойки и строки кода на Python, Go или C++. Но мы упускаем из виду одну фундаментальную вещь: задолго до появления первых ЭВМ человечество уже создало мощнейший язык программирования - нашу речь.

Язык - это не просто средство коммуникации. Это низкоуровневый фреймворк, на котором «крутится» наше сознание. Как я отмечал в материалах к исследованию "Тартар и Я", слова несут в себе архетипические смыслы, формирующие саму логику мышления. И если мы признаем, что человек программируется языком, возникает закономерный вопрос: насколько хорошо защищена наша внутренняя операционная система?

Язык программирования Rust в последние годы приобрел значительную популярность, выступая в качестве универсального языка, обеспечивающего высокую производительность и безопасную работу с памятью. Разработанный Mozilla, это современный язык программирования системного уровня, который является наиболее популярным среди разработчиков, работающих над различными приложениями, от операционных систем до веб-браузеров.

Эта статья предназначена для тех, кто только начинает свое знакомство с миром Rust. Мы рассмотрим основные преимущества этого языка, установим необходимые компоненты и соберем первое приложение.

Привет, Хабр! В Rust есть тип, у которого нет ни одного возможного значения. Звучит необычно. Но я однажды столкнулся с этим самым никогда‑типом и понял — без него жить в Rust уже не хочется! Что это такое и зачем нужно — разберём подробно. По ходу дела упомянем и связанные фичи: Infallible, новоявленные макросы вроде matches!, разные фишки для оптимизации кода и FFI, про которые часто не догадываешься.

Я занимаюсь разработкой компиляторов, то есть, пишу программы, преобразующие программы в программы. Иногда требуется нацелиться на более высокоуровневый язык, чем, скажем, простой ассемблер, и зачастую именно в таком качестве удобно взять язык C. Генерировать C не так страшно как писать от руки — в частности, потому, что генератор умеет не попадать в ловушки, связанные с неопределённым поведением. А когда пишешь на C вручную, именно неопределённого поведения следует особенно остерегаться. Здесь я опишу некоторые паттерны, которые обнаружил сам, и которые помогают мне результативно работать.

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

Привет! Сегодня рассмотрим инструмент, который поможет вам с низкоуровневым кодом на Rust. Если вы пишете на Rust только безопасный код, возможно, никогда о нём не слышали.

А вот тем, кто периодически заглядывает в тёмные уголки unsafe, этот инструмент сэкономит нервишки.

В предыдущих сериях (От стартапа к протоколу, Почему финтеху нужен капитальный ремонт, Почему мы терпим факс в эпоху ИИ) мы обсуждали, почему современный финтех - это "Ferrari на грунтовке", и зачем мы начали писать с нуля свой леджер Qazna (на Rust) и ERP-систему Orda (на Go).

В комментариях вы справедливо спрашивали: "Зачем изобретать велосипед, если есть PostgreSQL и Kafka?" и "Чем это отличается от Hyperledger/Ripple?".

Сегодня я отвечу на эти вопросы кодом и архитектурой. Мы не просто "переписали базу". Мы построили суверенный стек, который делает три вещи, невозможные в legacy-системах:

340% рост AI-атак за 2025 год, а защита LLM всё ещё — «закиньте промпт в облако, подождите 200ms». Я построил альтернативу: SENTINEL — open-source стек из C, Rust и Python, который фильтрует jailbreak за <3ms on-premise. Ключевая фича — Micro-Model Swarm: рой из моделей <2000 параметров, который ловит то, что не видят регулярки.

Устали прыгать между Jira, Confluence, Notion, Calendar и почтой? Я написал Yttri — мощный комбайн на Rust + Tauri для управления всей цифровой жизнью. Локальный AI, графовая база знаний, приватность и никакой облачной зависимости. Рассказываю, как объединить хаос в одну систему и почему Local-First победит.