FFI, P/Invoke, EmbeddedResource, DllImportResolver и кроссплатформенная доставка без ручного копирования .dll, .so и .dylib.
Когда .NET-коду нужно вызвать Rust-библиотеку, первый прототип обычно заводится быстро:
Rust собирается как cdylib;
функции экспортируются через extern "C";
C# вызывает их через DllImport;
результат возвращается через указатель.
Я срьрал 100+ вопросов с собеседований по Rust с краткими разборами: владение, типажи, конкурентность, async, unsafe, производительность и др. Отдельный продвинутый блок A1–A21 для staff-уровня. Цель - показать, где обычно спотыкаются даже опытные, и помочь подготовиться к следующему собеседованию. Надеюсь будет реально полезно!
Команда Rust рада объявить о выходе новой версии языка — Rust 1.96.0. Rust — это язык программирования, который помогает каждому создавать надёжное и эффективное программное обеспечение.
Если у вас уже установлена предыдущая версия Rust через rustup, вы можете получить 1.96.0 командой:
$ rustup update stable
Если Rust ещё не установлен, вы можете получить rustup на соответствующей странице нашего сайта и ознакомиться с подробными release notes для 1.96.0.
Если вы хотите помочь нам, тестируя будущие релизы, можете переключиться локально на beta-канал (rustup default beta) или nightly-канал (rustup default nightly). Пожалуйста, сообщайте обо всех найденных ошибках!
Уже год мы небольшой командой пишем на Rust + wgpu редактор топологий интегральных схем — что-то вроде KLayout, только с прицелом на российский рынок. Команда — три человека. Я в роли CTO направляю архитектуру и принимаю основные технические решения. История ниже — про одну такую серию решений, которую я завёл в тупик четыре раза подряд, прежде чем мы поняли, в чём была ошибка.
Тестовый дизайн у нас — Caravel SkyWater SKY130, открытый чип на ~4,4 миллиона полигонов, 1014 уникальных ячеек и 22 уровня иерархии. Полный GDS-файл — 278 МБ.
Первая попытка отрендерить это на экране показала: всё работает, всё на месте. Только мерцает. Не «иногда подёргивается» — а так, что смотреть невозможно. Любой zoom или pan превращал картинку в стробоскоп: половина чипа есть, половина пропала, через кадр — наоборот.
Дальше — история про то, как мы четыре раза по-разному пытались это починить, и как пятая попытка наконец заработала. Если у кого-то такой же случай — может, сэкономлю недели две.
Это статья про небольшой хобби-проект, или как написать очень легковесный клиент для любого приложения с нуля.
Идея зародилась, когда весь этот цирк только начинался. Прогревали новый ГОСТ-мессенджер, поливали его чем только можно. В какой-то момент проскочила новость: В Max нет сквозного шифрования...
И тут зародилась глупая идея: почему бы самому не прикрутить к нему разные функции анонимности и шифрования? Уровень конечно совсем не тот, что у Telegram и Signal, но сама возможность скрыть содержание переписки завораживает, разве нет?!
Спойлер: APK весит 11 МБ против 120 МБ у официального, не греет телефон и показывает каждый запрос к серверам ok[.]ru и vk[.]ru
История идеи проекта
Сидел я и делал чанкирование разбора конфигурации 1С в PostgreSQL. Выгрузка конфы мне досталась с 43 расширениями и ноль документации по этим расширениям после 5 команд разработки.
Ну, нужно было её разобрать, обогатить бизнес-терминами и превратить во что-то удобоваримое вроде как для RAG. Было всё это долго, нудно, на Питоне, с помощью локальной LLM. Сам я в настоящий момент 1с-ник, но начинал я в своё время с MSSQL-2000 (если кто-то помнит такой), T-SQL, PowerScript, Pascal и пр. романтики.
Сидел я, думал о светлом будущем, когда с помощью RAG локальная моделька будет мне писать скрипты, и даже без ошибок (до некоторой степени это получилось). Ну как-то слово за слово, и мне подумалось: есть же семантический поиск по RAG, реализуется MCP-сервером. По сути это запросы — точные, но довольно медленные. А почему тогда во всех остальных случаях, работая с выгрузкой напрямую, модель раз за разом лезет в переборщики файлов — пусть правильно написанные и крайне оптимизированные, но всё же переборщики? КОТОРЫЕ ТРАТЯТ МАССУ ТОКЕНОВ ТУПО НА ЧТЕНИЕ ДЛЯ ПОИСКА?! Почему нельзя это делать запросами в базу данных — нормальными, дешёвыми, точными?
И вспомнил я заодно старую идею: когда-то файловую систему в Windows (проект WinFS, времён Vista) хотели сделать похожей на БД, чтобы радикально ускорить работу с файлами. Идею потом свернули, и она как-то забылась. НО я не забыл :):)
Идея-то была интересная. Итого — нужно было дать модели инструмент, который заметно экономил бы токены и ускорял поиск данных (особенно в больших массивах кода). И подумалось мне, что не один я такой — есть целый коллектив разработчиков, которому такой инструмент может пригодиться. Поэтому Бог с ним, с Питоном, будем писать на Rust, потому что Rust — это база! (с)
Я фронтенд-разработчик. Работаю в Bay Area, в компании, которая выдаёт всем инженерам корпоративные подписки на Claude Code и Cursor. То есть лично из кармана я за токены не плачу — счёт уходит работодателю. Это важная деталь, потому что без неё дальше непонятно: зачем человеку, который ни копейки не тратит, было пилить три месяца open-source инструмент для подсчёта чужих денег.
Если коротко — стало любопытно.
Если чуть длиннее — оказалось, что эта любопытная мысль вытащила за собой целую экосистему репозиториев, два пивота, один выкинутый в мусорку RAG-движок, плагин для JetBrains на Kotlin, расширение для VS Code на TypeScript и Rust-демон, который я бы сам, без AI, не написал никогда в жизни.
Это статья про то, как и зачем я всё это сделал. И почему фронтендер, который последний год почти не пишет код руками, всё равно может зашипить вполне серьёзный системный инструмент — если правильно собрать процесс.
Всем привет!
Меня зовут Артур Валиев. Недавно я уже рассказывал на Хабре о том, как мы собирали собственный RustDesk Pro при помощи патчей и кастомных сборок.
Но со временем стало понятно, что нам тесно в рамках обычной кастомизации. Мы захотели пойти намного дальше.
Начать стоит немного издалека.
Почти пять лет я проработал в районной больнице. И если кто-то когда-либо занимался поддержкой медицинских учреждений, то прекрасно знает этот зоопарк инфраструктуры: старые компьютеры, терминальные серверы, виртуальные машины, Astra Linux, закрытые сети, ограничения безопасности и постоянная необходимость помогать пользователям удалённо.
Тогда я постоянно мечтал об одном инструменте: простом удалённом клиенте, который запускался бы везде и не требовал танцев с бубном. Да и помогал мне избегать лишних выездов из теплой кровати.
Прошли годы, и теперь мы наконец сделали именно такой инструмент.
Так появился EvertyDesk Lite.
Это полностью нативный клиент удалённого доступа на Rust и egui. Один бинарник. Без браузера внутри. Без Electron, flutter. Без десятков зависимостей. Без необходимости тянуть половину интернета через репозитории.
Причём мы специально проектировали его так, чтобы он запускался даже там, где графический стек уже практически сдался. Astra Linux? РЕД ОС? Пожалуйста, старый марсианский корабль? Работает. Старая виртуалка без нормального OpenGL? Тоже запускается.
Для таких случаев мы даже реализовали программную отрисовку интерфейса (Вполне достойную к тому же), чтобы клиент можно было открыть там, где аппаратное ускорение скорее мешает, чем помогает.
StillCore — лёгкое приложение для отслеживания энергопотребления, частоты, нагрузки, температуры и состояния батареи из строки меню macOS. Это анонс и небольшая история о том, как я его писал.
Недавно я решил завести собственный блог. Сначала посмотрел в сторону SSG, но они показались мне не слишком удобными для того сценария, который я хотел получить. Затем попробовал несколько CMS, однако быстро упёрся в другую проблему: мой сервер оказался слишком слабым для большинства современных решений.
В итоге ни одно из готовых решений так и не смогло закрыть все мои требования одновременно. Так и появилась идея сделать небольшую файловую CMS на Rust, которая не требует базы данных, не потребляет много памяти и при этом остаётся достаточно гибкой для повседневного использования.
Со временем идея небольшого блогового движка разрослась в полноценную CMS с SSR, виртуальной файловой системой, поддержкой локализации, визуальным редактором статей и горячей перезагрузкой контента. В этой статье я постараюсь показать, как всё это устроено изнутри.
Почитал у известного чела о пост-условиях (“посткондишнс”) на свифте - и знаете, раст все равно лучше. Тупо приятнее язык даже для создания торговой биржи со своей мудреной бизнес-логикой - тикерами, логикой стопов и лимитных ордеров, многопоточностью, паттерн матчингом, децентрализованной сетью, графиками, распределениями парето, гаусса, стьюдента. Не трогая деревативов и разницу форвард/фьючерс, есть “аск” и “бид”, три вида ордеров, тикеры, взлеты и падения, вискарь-тревоги-роботы - короче, что нужно сделаем (кроме роботов), а для всего остального мастер кард (или МИР, а для европейцев “е-ц” карты).
Простейшая реализаций биржы (тикера) складывается всего из двух куч (binary heap) или двух стаканов: “аск” (продажа) и “бид” (покупка), и следствием их пересечения является сделка. Кто-либо создает ордер на покупку, указывая количество, и ордер исполняется мгновенно по верхней цене в стакане. Если хочется купить дешевле, создается лимитный ордер с указанием цены, а сделка ожидает продавца, согласного продать вам по указанной цене. С точки зрения реализации нет особой разницы между “asap” и лимитными ордерами. Чуть сложнее стопы.
Когда я впервые увидел backtrace паники в Rust, я решил, что это просто аналог исключения. Вызвал panic!, стек раскрутился, деструкторы вызвались, поток умер. Примерно как throw в C++ или raise в Python. Потом я попытался передать панику через FFI-границу, и программа молча упала без backtrace. Потом обнаружил, что catch_unwind перестаёт работать, если в Cargo.toml поменять panic = "unwind" на panic = "abort". Потом выяснил, что двойная паника (когда деструктор паникует во время раскрутки) убивает процесс безусловно, и это не баг, а так задумано.
Оказалось, что за простым panic!("oops") стоит сложная система из сменных runtime-ов, платформозависимой раскрутки стека и кучи граничных случаев...
Как организовать шифрование на уровне протокола? На самом деле тема непростая и пожалуй (имхо) это как раз та самая тема, где прийти к компромиссу почти никогда не получается. Разве что просто не передавать чувствительные данные вовсе.
Я расскажу как шифрование можно организовать на уровне протокола brec и ни в коем случае не буду затрагивать те самые принципиальные решения, влияющие на безопасность (как передавать, куда передавать, отправлять ли, и хранить ли чувствительные данные вовсе). Иными словами нас интересует инструментальная сторона вопроса.
io_uring продавали как убийцу epoll. На деле на HTTP keep-alive разница 0-15%, иногда не в его пользу. Но на NVMe с queue depth 128 - в 3 раза быстрее. Честный разбор с бенчмарками, реальными граблями (SQPOLL, cancel race, partial recv) и почему Google отключил io_uring в ChromeOS.
Эта статья — не руководство по написанию ОС и не туториал. Это срез архитектуры работающего ядра, которое прошло путь от вечных Page Faults и Segmentation Faults (в ring 3) до системы с 95 системными вызовами, сетевым стеком, COW и MLFQ-планировщиком. Все исходники открыты под GPLv3.
С момента последней (и вроде единственной) статьи о brec прошло какое-то время, и мне кажется, что будет полезно лишний раз напомнить о проекте. Даже неожиданно для меня самого он продолжает развиваться. Пусть я пока не могу похвастаться значимым интересом со стороны сообщества, но в паре локальных проектов он уже появился. Да, скорее как эксперимент. Тем даже лучше: можно провести, что называется, полевые испытания.
Я пишу FFI-код на Rust уже несколько лет и за это время понял одну неприятную вещь: на FFI-границе всё, что может сломаться, ломается молча. Компилятор не предупреждает, тесты проходят, а данные на C-стороне оказываются просто мусором. Или, что хуже, оказываются почти правильными, первые три поля совпадают, а четвёртое сдвинуто на два байта, и ошибка всплывает через недели.
Большинство этих проблем связано с двумя вещами: как структура лежит в памяти (layout) и как данные передаются при вызове функции (ABI). В чистом Rust-коде об этом можно не думать, компилятор всё решает за вас. Но на границе с C эти детали становятся вашей ответственностью.
Недавно мне в голову пришла мысль о том, как бы получать список техники, на которой, например, установлен последний патч системы или нужное ПО. Можно написать скрипты, но, как мне кажется, это не совсем удобно и безопасно, особенно когда парк машин неоднообразен. Поэтому я предлагаю реализовать систему, где вся запрашиваемая информация будет собираться с помощью агентов на конечных устройствах в реальном времени с помощью специального языка запросов.
Как я думаю, у этой системы довольно большой потенциал, ведь его можно доработать и превратить в какой-нибудь аналог Ansible. Или в базу для SIEM системы. Или прикрутить к какой-нибудь ITSM-системе, чтобы проводить инвентаризацию по нужным параметрам.
Вся система будет строиться на gRPC, так как он из коробки идёт со всем необходимы, включая простую интеграцию систем аутентификации и TLS, плюс описание интерфейсов в .proto файлах позволит писать клиенты и агентов на различных языках и фреймворках. Единственный минус, так это то, что двунаправленное взаимодействие не укладывается в философию фреймворка, но это решим в процессе написания.
Наконец мы добрались до поистине сложной темы. Если вы думаете, что раньше были сложные, вы глубоко заблуждаетесь!
Двусвязный список на Rust. Это вообще возможно? Ну… да. С некоторыми оговорками. Что за оговорки, узнаем из четвёртой главы.
Срочно переписывайте свои устаревшие bloom фильтры на мой богоподобный lz77-фильтр. Совершенно бесплатно! Спасибо великому нанабанана за обложку!
