👣 В Rust нашли интересный способ ускорить pretty printer - штуку, которая красиво форматирует код, JSON, Lisp и другие структуры.

Обычно есть два подхода.

Первый - собрать всё дерево документа целиком. Так делают Wadler-style pretty printers. Это выразительно, но в Rust быстро упирается в память, аллокации и указатели.

Второй - стримить вывод по кускам. Так работает Oppen-style подход. Он легче по памяти, но часто принимает локально хорошие решения и не всегда находит глобально лучший layout.

Автор предлагает третий вариант: не хранить документ как рекурсивный enum, а описывать его через trait Doc.

То есть Text, Concat, Group, Nest и другие элементы становятся отдельными типами, которые умеют сами себя рендерить через layout().

Звучит как мелкая архитектурная правка, но эффект большой: меньше лишних аллокаций, меньше прыжков по памяти, гибче управление Box, Rc и другими стратегиями хранения.

В proof-of-concept реализации pye автор получил до 60x ускорения по сравнению с прямой Rust-реализацией алгоритма из paper “A Pretty Expressive Printer”. А в обновлённых тестах вариант с таким дизайном и greedy-алгоритмом местами обгонял pretty и arena-версию больше чем в 10 раз.

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

Иногда enum выглядит красиво, но trait-based дизайн лучше ложится на память, ownership и реальные оптимизации компилятора.

blog.wybxc.cc/blog/pretty-printer-pye/

#Rust #RustLang #Compilers #OpenSource #SystemsProgramming

👣 Rust без боли начинается не с синтаксиса, а с правильных паттернов

Microsoft выложила практический гайд Rust: Patterns & Engineering How-Tos - не для тех, кто только открыл println!, а для разработчиков, которые уже упёрлись в реальные production-вопросы.

Что внутри:

- type-state и newtype для безопасного дизайна API
- PhantomData для lifetime branding, variance и zero-cost типизации
- channels, actors и concurrency-паттерны
- async pitfalls, где Rust чаще всего ломает ожидания новичков
- error handling через thiserror и anyhow
- тестирование через unit, integration, doc tests и proptest
- benchmarking через criterion

Это особенно полезно для тех, кто приходит из C++, C# или Go и внезапно понимает, что borrow checker - это не главный враг. Главная сложность в Rust - выбрать правильную форму абстракции до того, как код превратится в набор lifetime-костылей.

Если вы уже прошли Rust Book, но всё ещё зависаете на generics, trait bounds, PhantomData, async и тестировании, это очень хороший следующий шаг.

https://microsoft.github.io/RustTraining/rust-patterns-book/

#rust #rustlang

✔️ Фраза «у Rust тоже есть CVE» часто звучит как аргумент против memory safety.

Но тут есть важная разница.

В C, если вы вызвали функцию не так, например передали NULL туда, где библиотека этого не ждала, и получили segfault, это часто называют неправильным использованием API.

То есть ответственность перекладывается на разработчика: сам виноват, надо было читать документацию.

В Rust логика другая.

Если функция помечена как safe, она не должна приводить к memory bugs. Даже если вы передали странные данные, даже если сценарий неидеальный. Safe Rust по контракту обязан оставаться memory-safe.

Поэтому если safe-функция в Rust падает с segfault или приводит к проблеме памяти, это уже не «ты неправильно использовал API». Это баг библиотеки. И такой случай действительно может стать CVE.

Сырые числа CVE у Rust и C/C++ нельзя сравнивать напрямую.

В C/C++ огромный класс проблем считается нормальным риском неправильного использования. В Rust тот же класс проблем считается нарушением гарантий safe API.

Именно поэтому CVE в Rust часто говорит не «Rust такой же небезопасный», а наоборот: экосистема строже относится к тому, что safe-код вообще не должен ломать память.

Хороший разбор от Jakub Beránek из команды разрабов компилятора Rust:

https://kobzol.github.io/rust/2026/06/15/how-memory-safety-cves-differ-between-rust-and-c-cpp.html

#Rust #RustLang #MemorySafety #Security #CVE