Исследователи NVIDIA перенесли модель владения Rust в GPU-kernels.

Paper: “Fearless Concurrency on the GPU”. В нём представлен cuTile Rust.

Проблема была в том, что при написании кастомных GPU-ядер на Rust разработчикам фактически приходилось выходить за пределы гарантий безопасности Rust.

cuTile Rust пытается это исправить:

* mutable outputs разбиваются на непересекающиеся части
* запуск kernels сохраняет правила ownership от host до device
* при необходимости остаются локальные opt-out механизмы для низкоуровневого контроля

Производительность тоже держится на уровне:

* 7 TB/s для element-wise операций на NVIDIA B200
* 2 PFlop/s для GEMM, это 96% от cuBLAS
* результат сопоставим с cuTile Python в пределах погрешности измерений

Авторы также собрали Grout, inference engine поверх cuTile Rust, и прогнали реальные модели:

* 171 tokens/s для Qwen3-4B на RTX 5090
* 82 tokens/s для Qwen3-32B на B200
* конкурентный уровень рядом с vLLM и SGLang

Итог - безопасный и идиоматичный Rust почти на полной CUDA-производительности.

Для Rust в ML-инфраструктуре это большой шаг.

http://arxiv.org/abs/2606.15991

#Rust #RustLang #GPU #CUDA #MachineLearning #SystemsProgramming #NVIDIA

@data_analysis_ml

В Rust нашли смешной и неприятный кейс: несколько символов @ могут заставить rustc жрать десятки гигабайт памяти.

Автор копался в macro expansion и заметил, что парсер declarative macros в rustc ведёт себя как упрощённый Earley parser: он одновременно держит несколько возможных вариантов разбора макроса.

Обычно это нормально.

Но если сделать макрос с вложенными повторениями, количество промежуточных вариантов начинает резко расти. Формально ожидался кубический рост, но в тесте всё выглядело ещё хуже.

Результат:

- валидный Rust-код
- всего несколько десятков токенов @
- компиляция на n = 41 заняла около 80 секунд
- пиковая память дошла до 44 ГБ

Самое интересное: код не использует сложные выражения, типы или гигантские зависимости. Только macro_rules и фиксированные токены.

Главная мысль не в том, что «Rust сломан».

Главная мысль в другом: макросы в Rust - это почти отдельный язык внутри языка, и даже маленький паттерн может внезапно превратиться в тяжёлую задачу для компилятора.

Автор предлагает смотреть в сторону packrat-подхода с memoization, где состояние парсинга можно кэшировать и гарантировать линейное число шагов по input.len() * arm.len().

Красивый пример того, как в системном языке проблемы иногда прячутся не в unsafe, не в borrow checker и не в LLVM.

А в маленьком macro_rules, который выглядит безобидно.

Хорошее чтиво на выходные 🦀

bal-e.org/blog/2026/oops-cubic-macro/

Как на самом деле работает .await: пишем свой async-рантайм на Rust с нуля

Если попросить среднего Rust-разработчика объяснить, что делает .await, в ответ обычно звучит что-то про «приостанавливает выполнение, пока не придут данные». Это верно ровно настолько же, насколько «компьютер думает» объясняет работу процессора. На самом деле за .await не стоит ни потока, ни приостановки в привычном смысле. Стоит обычный enum и вызов функции по указателю.

Я полгода писал async-код на tokio, искренне считая рантайм чернм ящиком, в который лучше не лезть. Сломался этот настрой в тот день, когда у меня в проде намертво зависла одна задача: по логам она обязана была проснуться, но не просыпалась. Я потерял на ней вечер, а причина оказалась в одной строчке про Waker, к которой мы ещё вернёмся. Тогда я плюнул и за пару вечеров написал свой рантайм с нуля - и оказалось, что весь фундамент умещается в голове за один присест и примерно в 200 строк кода.

После этого и тот баг стал очевидным, и исходники tokio начали читаться как книга, а не как заклинание.

https://habr.com/ru/articles/1050160/

🔥 Продвинутый Rust без учебных игрушек

Базу уже прошли? Тогда следующий шаг - production-разработка.

На Stepik идет скидка 60% на продвинутый курс по Rust для тех, кто хочет не просто знать синтаксис, а строить реальные системы.

Внутри: async, unsafe, gRPC, lock-free, observability, Kafka, NATS, axum, tower, CI/CD и канареечный деплой.

Финальный проект - production-ready feed-сервис от архитектуры до релиза.

21 модуль, 84 урока, 400+ проверочных шагов.

Если хотите перейти от маленьких Rust-утилит к коммерческой разработке, сейчас хороший момент зайти: https://stepik.org/a/285608/pay

Rust теперь можно компилировать в JVM bytecode.

rustc_codegen_jvm - экспериментальный backend для компилятора Rust, который берёт Rust MIR и превращает его в .class файлы, а затем собирает runnable .jar под JVM 8+.

Что уже заявлено:

- генерация исполняемого .jar
- поддержка базового core
- if/else, match, for, while, loop
- structs, tuples, arrays, slices, enums
- traits, closures, dynamic dispatch
- function pointers, recursion, generics
- часть unsafe, включая unions
- оптимизации вроде constant folding, propagation и dead code elimination

Пайплайн выглядит так:

Rust frontend → MIR → OOMIR → JVM classfile → R8 → .jar

https://github.com/IntegralPilot/rustc_codegen_jvm

Песочницы для агентов не должны каждый раз стартовать с нуля, когда агент создаёт новую ветку.

forkd — это runtime для sandbox-окружений AI-агентов на базе Firecracker microVM.

Он помогает быстрее ветвить и распараллеливать задачи: сначала один раз запускается «прогретый» родительский microVM, а затем дочерние окружения создаются из copy-on-write снапшотов памяти вместо холодного запуска каждой VM.

Ключевые возможности:

- Forking от прогретого родителя — дочерние окружения наследуют уже загруженные импорты, зависимости, JIT-состояние, веса моделей и кэши
- KVM-изолированные microVM — каждый дочерний sandbox работает как отдельный процесс Firecracker с собственной изоляцией
- Live BRANCH — можно поставить работающий sandbox на паузу, снять снапшот состояния «на лету» и продолжить выполнение. Для v0.4 заявлено p50-окно паузы исходного окружения 56 мс
- Цепочки diff-снапшотов — можно накладывать runtime-слои вроде numpy → pandas → sklearn без повторного копирования одного и того же базового образа
- Удобная daemon-поверхность — REST API, Python/TypeScript/MCP-клиенты, метрики Prometheus, JSON audit log и поддержка systemd

Проект open-source и распространяется под лицензией Apache License 2.0.

Ссылка в ответе 👇

https://github.com/deeplethe/forkd

Предрелизное тестирование 1.96.1

#rustlang #rust

https://blog.rust-lang.org/inside-rust/2026/06/27/1.96.1-prerelease/

Rust сегодня:

47 веб-фреймворков, 12 async runtime, 8 ORM, 6 logging crates и отдельный crate, который просто сообщает, что ты используешь не тот crate.

Вышел Rust 1.96.1


Что исправили:

• проблемы с retry и timeout в HTTP-клиенте Cargo
• miscompilation в MIR-оптимизации
• три CVE в libssh2, который используется внутри Cargo

Обновление стандартное:
rustup update stable
Патч на стабильность и улучшение безопасности.

rustup update stable

https://blog.rust-lang.org/2026/06/30/Rust-1.96.1/

Частая дилемма в Rust: Tokio отлично подходит для async I/O, Rayon для тяжёлых CPU-задач. Но как связать их так, чтобы не заблокировать async runtime? 🦀

Команда Tantivy, поискового движка на Rust, показала, как решила это в продакшене.

Проблема:

Tokio-задачи не должны блокироваться. Тяжёлая CPU-работа может подвесить весь async runtime.

Rayon-потоки не понимают async. Внутри rayon thread нельзя просто взять и сделать .await.

Передать результат обратно между этими мирами тоже не так очевидно.

Решение - мост через `oneshot`-канал.

Tokio запускает задачу и ждёт результат из oneshot.

Rayon выполняет CPU-работу в своём пуле потоков.

Когда работа завершена, Rayon отправляет результат обратно через канал.

Tokio продолжает выполнение, при этом executor всё это время не блокировался.

Очень полезный паттерн для всех, кто пишет async-код на Rust.

🔗 reddit.com/r/rust/comments/1ulo7pr

LLM уже находят реальные memory safety баги в Rust-коде.

И, что неожиданно, это работает очень хорошо.

Сергей Давыдов, руководитель Rust Secure Code Working Group, использовал GPT-5.5 и Claude Opus для аудита unsafe-блоков в популярных Rust-крейтах.

В итоге нашлись десятки реальных багов:

• use-after-free

• чтение за пределами буфера

• data races

• неправильные реализации Send / Sync

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

Почему в Rust это работает лучше, чем в C?

• unsafe явно помечен и изолирован, поэтому LLM сразу понимает, где искать

• miri может точно подтвердить, настоящий баг или нет

• не нужно отслеживать data flow по всей кодовой базе, как часто бывает в C

Получается, дизайн Rust случайно сделал его почти идеальным языком для LLM-аудита безопасности.

Стоит прочитать всем, кто думает про AI в security tooling.

https://gist.github.com/Shnatsel/eb0a4be79a0657e4eb67c4f085f991bc

https://shnatsel.medium.com/the-unreasonable-effectiveness-of-llms-for-auditing-rust-code-d4df8bf0afd3

#Rust #RustLang #MemorySafety #Security #LLM

Amazon Kani для Rust получил академическую статью, принятую на ASE 2026. 🦀

Kani пытается формально доказать корректность Rust-кода математически.

Что умеет:

* доказывать отсутствие panic, overflow и нарушений memory safety
* проверять, что `unsafe`-код действительно безопасен
* гонять 16 000+ harness’ов на каждый commit в Rust standard library
* находить баги, которые раньше не видели в промышленных Rust-проектах

Главное отличие простое:

fuzzing пытается найти баги через множество входных данных.

Kani проверяет свойства кода формально, в рамках заданного harness’а.

Kani интегрирован в CI стандартной библиотеки Rust.

Каждый commit в std проходит формальную проверку.

🔗 arxiv.org/abs/2607.01504

Borrowed & Owned

Новый open-source каталог для изучения Rust.

Внутри собраны книги, видео, курсы, репозитории, блоги и другие материалы по Rust.

Что есть:

• поиск и фильтры
• learning paths
• категории и теги
• страницы отдельных ресурсов
• starter kits для быстрого старта
• changelog новых материалов
• dark / light theme
• добавление ресурсов через GitHub

По сути, аккуратная база знаний для тех, кто учит Rust и не хочет тонуть в случайных ссылках.

https://github.com/panditdhamdhere/borrowed_and_owned

В Штутгарт не едем )