8052
Rust programming language По всем вопросам- @haarrp @ai_machinelearning_big_data - машинное обучение @programming_books_it - бесплатные it книги @pythonl - 🐍 @ArtificialIntelligencedl - AI @datascienceiot - ml 📚 #VRHSZ
Obscura - headless browser для AI-агентов, который не тащит за собой весь Chrome
Обычный headless Chrome давно стал стандартом для scraping, автотестов и браузерной автоматизации. Но для AI-агентов это часто слишком тяжелая махина: много памяти, долгий старт, лишний вес и куча поведения, заточенного под обычный браузер.
Obscura пытается закрыть эту дыру.
Это open-source headless browser на Rust, сделанный специально под web scraping и агентную автоматизацию. Внутри есть V8 для JavaScript, поддержка Chrome DevTools Protocol и совместимость с Puppeteer / Playwright.
Что заявляют авторы:
- около 30 MB памяти против 200+ MB у headless Chrome
- бинарник около 70 MB против 300+ MB
- быстрый старт без отдельного Chrome и Node.js
- CDP-сервер для подключения через Puppeteer и Playwright
- parallel scraping из коробки
- stealth mode с anti-fingerprinting и блокировкой трекеров
- Apache-2.0, без закрытия фич за paywall
Если AI-агенту нужно не «открыть браузер как человек», а быстро пройти сайт, выполнить JS, забрать DOM, кликнуть, авторизоваться и вытащить данные, то полноценный Chrome становится избыточным.
Obscura выглядит как попытка сделать браузерный рантайм нового типа - не для людей, а для агентов.
https://github.com/h4ckf0r0day/obscura
👣 Твой async fn на самом деле enum, а Pin нужен потому, что Rust наступил на грабли самоссылающихся структур
TL;DR. Каждый async fn в Rust компилируется в enum-стейт-машину.
Размер этой стейт-машины равен размеру самого толстого варианта, поэтому забытая через .await переменная на пару мегабайт превращается в утечку памяти, помноженную на число задач.
Pin существует, чтобы запретить перемещать такие стейт-машины после первого poll, потому что внутри них живут указатели на собственные поля. select! молча теряет данные, если использовать в нём future без cancellation safety. И executor в Tokio, при всей его магии, концептуально умещается в сотню строк.
https://uproger.com/tvoj-async-fn-na-samom-dele-enum-a-pin-nuzhen-potomu-chto-rust-nastupil-na-grabli-samossylayushhihsya-struktur/
👣 Твой код на Rust компилируется, проходит тесты и является UB. Ты просто об этом не знаешь
Если взять случайный крейт с crates.io, поставить на него Miri и подождать минут пять, шанс увидеть красное сообщение про undefined behavior где-то в зависимостях стремится к единице. Чаще всего виноват не автор хитрого unsafe-блока ради скорости, а вполне обычная библиотека, которой пять лет, у которой звёзд на гитхабе больше, чем у твоего пет-проекта строчек кода, и которая всё это время спокойно лежит в продакшене.
Самое неприятное в этой истории то, что компилятор ничего не скажет. Тесты пройдут. Бенчмарки покажут красивые наносекунды. А потом LLVM 19 обновится до LLVM 20, поменяет один проход оптимизации, и твой сервис начнёт ронять прод по понедельникам. Чтобы понять, почему так происходит, придётся залезть в три темы, которые в обычной жизни Rust-разработчика не встречаются: pointer provenance, Stacked Borrows и пришедшую им на смену Tree Borrows.
https://uproger.com/tvoj-kod-na-rust-kompiliruetsya-prohodit-testy-i-yavlyaetsya-ub-ty-prosto-ob-etom-ne-znaesh/
👣 Хороший тест на понимание unsafe Rust
Вопрос простой: если запустить пример в Miri со Stacked Borrows, будет ли там UB?
Но важна не только галочка «да» или «нет».
Если UB есть, нужно объяснить:
- какая именно операция ломает правила;
- почему этот указатель больше нельзя использовать;
- где была нарушена модель заимствований;
- какой доступ инвалидировал предыдущий alias;
- почему компилятор может считать такой код невозможным.
Вот в этом и суть unsafe Rust.
`unsafe` не значит «делай что хочешь». Это значит: компилятор больше не проверяет часть правил за тебя, но правила всё ещё существуют.
Miri полезен именно потому, что заставляет смотреть не на ощущение «ну вроде работает», а на формальную модель памяти.
Код может стабильно проходить локально, не падать в тестах и всё равно быть UB.
А потом оптимизатор сделает вид, что такого состояния программы вообще не могло существовать.
📘 На платформе Mentorix вышел курс — «Rust для профессионалов»
Если вы уже знакомы с Rust и хотите углубить знания до уровня реального применения — этот курс даёт системное понимание и практику продвинутых возможностей языка.
В курсе:
• углублённая работа с памятью и моделью владения
• многопоточность и конкурентность
• продвинутые структуры и подходы
• написание производительных и надёжных систем
• практические задачи разного уровня сложности
Материал выстроен последовательно — от углубления базовых концепций к сложным сценариям использования.
Скидка 40% — действует 48 часов
👉 Пройти курс
🔥 Продвинутый 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
🧩 Новый язык программирования для AI-систем
Weft - это язык программирования, написанный на Rust, который упрощает создание AI-приложений, позволяя связывать LLM, людей и API без лишнего "проводки". Он предлагает визуальное представление программ и строгую типизацию, что делает разработку более интуитивной и безопасной.
🚀Основные моменты:
- Первоклассные взаимодействия с людьми через простые узлы.
- Возможность сворачивать группы узлов для упрощения структуры.
- Полная типизация, предотвращающая ошибки на этапе компиляции.
- Устойчивое выполнение программ, сохраняющих состояние после сбоев.
- Встроенные узлы для работы с различными сервисами и API.
📌 GitHub: https://github.com/WeaveMindAI/weft
#rust
Rust-эксперимент, который красиво объясняет, почему `Vec` почти всегда лучший варинт
Автор взял идею из Linux filesystem: inode хранит метаданные и указывает на блоки данных. Потом задал очень опасный, но полезный вопрос: а что если такую же схему перенести в Rust-контейнер?
Так появился PagedSmallVec: сначала маленький inline-буфер, потом данные раскладываются по фиксированным чанкам, а не лежат одним непрерывным куском памяти.
Звучит умно. На практике CPU быстро объясняет, кто здесь главный.
Обычный Vec почти всегда быстрее, потому что он делает ровно то, что любит процессор: данные лежат подряд, доступ предсказуемый, меньше переходов по указателям, меньше ветвлений, меньше cache misses. У PagedSmallVec каждый доступ после inline-части превращается в математику по чанкам: вычислить индекс чанка, offset, найти нужный блок, достать значение. Для u32 это особенно больно: там сама операция дешёвая, поэтому накладные расходы контейнера видны сразу.
Бенчмарки получились ожидаемые, но от этого не менее полезные: в обычных vector-like сценариях Vec чаще первый, SmallVec обычно второй, а paged-структура чаще третья. На push, pop, random indexing и ordered remove магии не случилось.
Когда обход сделали не через get(i) на каждый элемент, а чанками через for_each_chunk, структура стала выглядеть гораздо разумнее. Потому что её естественная единица работы - не отдельный элемент, а блок. И вот тут появляется главный урок: плохой API может убить даже неплохую идею, если заставляет структуру данных работать против своей природы.
Где такая схема может иметь смысл?
В append-heavy системах, где буфер часто растёт, но редко индексируется посередине. Например, логи, event buffers, tracing pipelines, ingestion queues. Там иногда важнее не копировать огромный непрерывный буфер при росте, чем выиграть каждый отдельный доступ.
Ещё один сценарий - chunk-native processing: стриминговая аналитика, batch transforms, сериализация, компрессия, обработка данных кусками. Если ваша логика работает чанками, а не элементами, paged layout уже не выглядит странным.
Если ваша цель - «сделать Vec, только быстрее», inode-style vector в Rust плохая идея.
Если цель - понять, где именно pointer-heavy layout проигрывает contiguous memory, как легко сломать инварианты через MaybeUninit, почему unsafe-контейнеры требуют железной дисциплины и почему API должен совпадать с layout, то эксперимент отличный.
Иногда лучший результат плохой идеи - не победа в бенчмарках, а момент, когда машина наконец показывает, где именно вы ошибались.
https://sot.dev/inode-style-vector-in-rust.html
👣 На Stepik обновили курс «Rust: полный курс разработчика. С нуля до профи»
Представьте: через три месяца вы открываете чужой Rust-код и читаете его как книгу.
Arc<Mutex<T>> не вызывает панику. impl Future не пугает. Вы точно знаете, почему компилятор ругается и как это починить за 10 секунд.
Это не фантазия. Это результат 50 уроков, в которых каждая концепция объясняется через код и закрепляется практикой. Ownership, traits, generics, async, unsafe - всё, что казалось магией, станет рабочим инструментом.
А бонусом - портфолио проектов: от CLI-утилит до REST API и WebAssembly.
Вы и так знаете, что Rust - ваш следующий язык. Этот курс просто сделает это реальностью.
Сегодня - 55% процентов от цены, торопись: https://stepik.org/a/269250/
👣 Rust Совет недели: безопасный newtype для FFI без сюрпризов
Если оборачиваешь указатели или хендлы для FFI, не полагайся на “и так сойдёт”.
Явно зафиксируй layout через repr.
Связка repr(transparent) и repr(C) даёт предсказуемое представление в памяти. Тип снаружи выглядит как обёртка, а для компилятора это тот же layout, что и у внутреннего значения.
Что это даёт на практике
• бинарная совместимость с C
• отсутствие скрытых паддингов и перестановок полей
• возможность делать приведения без transmute
• нормальный, идиоматичный способ оборачивать raw handle и pointer
В итоге ты получаешь типобезопасность Rust без потери контроля над ABI.
Если работаешь с FFI и не фиксируешь repr, ты оставляешь поведение на усмотрение компилятора. И это рано или поздно выстрелит.
Грэйдон Хоар возвращался домой в Ванкувере - лифт в его доме на 21-м этаже снова упал с ошибкой прошивки.
Пока он поднимался пешком, в голове оформилась идея. В тот же вечер он открыл ноутбук и начал проектировать язык.
Назвал его Rust - в честь грибков, известных своей абсурдной живучестью.
Было это в 2006 году, Хоару было 29 лет, он работал инженером в Mozilla.
Проблема, которую он хотел решить, существовала десятилетиями. Системное программирование жило в C и C++ - быстро, близко к железу, но с ценой: ручное управление памятью. На миллионах строк кода даже самые аккуратные инженеры допускают ошибки. Microsoft оценивает, что 70% уязвимостей в её продуктах - это баги управления памятью в C и C++. В 90-х Java, Python и JavaScript предложили альтернативу: сборщик мусора, автоматическая память. Но заплатить пришлось производительностью и непригодностью для bare-metal среды. Поле разделилось на два лагеря: быстро-но-опасно против безопасно-но-медленно.
Rust предложил третий путь. Компилятор просто откажется собирать программу, если нарушены правила работы с памятью. Система владения гарантирует, что на каждый кусок данных в любой момент существует ровно одна ссылка. Никакого рантайм-оверхеда, никакого сборщика мусора - в 2013 году команда вырезала его полностью. Язык стал быстрее и ближе к металлу, сохранив при этом безопасность на уровне архитектуры.
Результаты говорят сами за себя. Discord переписал один из core-сервисов с Go на Rust - он стал работать в 10 раз быстрее.
Dropbox переделал движок синхронизации, потому что Python не справлялся с миллиардами файлов. Cloudflare пропускает через Rust-системы больше 20% всего интернет-трафика. Программы на Rust потребляют примерно вдвое меньше электричества, чем аналоги на Java. Правительство США официально рекомендует переход на Rust как меру национальной кибербезопасности.
Семь лет подряд Rust занимает первое место в опросе Stack Overflow как самый любимый язык среди разработчиков. Сейчас им пользуются 2,8 миллиона человек по всему миру.
Хоар ушёл из проекта в том же 2013-м. Он запустил то, что уже не нуждалось в нём, - и оказался прав.
🦀 Google затащили Rust туда, где его реально ждали - прямо в cellular baseband у Pixel 10.
Не в приложение, не в системный сервис и даже не в очередную утилиту, а в прошивку модема. Это уже совсем другой уровень.
Первым шагом заменили DNS-парсер, который раньше был написан на C и регулярно оставался источником memory-safety проблем. Теперь там Rust на базе hickory-proto: bare-metal, no_std, FFI к существующим C-аллокаторам - все по-взрослому.
И самое важное тут даже не сам DNS-парсер. Главное, что Google уже протащили Rust в build system baseband. А значит, это не разовая демонстрация, а начало нормальной поэтапной миграции.
Вот так и выглядит реальное внедрение Rust в критическую инфраструктуру: без громких лозунгов, но с максимальной пользой. Сначала один опасный компонент, потом еще один, а дальше язык постепенно заходит в самые уязвимые части системы.
Для всей индустрии это очень показательный кейс. Rust все чаще идет не в новые игрушечные проекты, а в старые и сложные куски железа, где цена ошибки слишком высокая.
security.googleblog.com/2026/04/bringing-rust-to-pixel-baseband.html
#Rust #RustLang #MemorySafety #EmbeddedSystems #Android
🚨 uv под капотом
Лучший способ расти как инженер это разбирать сильные кодовые базы.
uv отличный пример. Это не просто пакетный менеджер, а аккуратно собранная система с продуманной архитектурой.
Внутри.
• Как устроен crate graph и резолвер зависимостей.
Как реализована конкуренция без лишних блокировок.
• Как работает кэш и ускоряет повторные операции.
• Как спроектирован инсталлер и пайплайн установки.
Такие проекты формируют инженерный вкус.
Ты начинаешь видеть, где упрощать.
Где разделять ответственность.
Как писать код, который масштабируется.
Это уровень, который не даёт ни один туториал.
Разбор
https://noos.blog/posts/uv-how-it-works-under-the-hood/
🔥 Плохой день для хейтеров ИИ. Сообщество Linux согласилось принимать код, сгенерированный ИИ, если это не низкокачественный мусор.
При этом вся ответственность остаётся за людьми - именно они должны гарантировать, что код соответствует стандартам Linux.
Линус не шутит, когда речь идёт о качестве кода. Это серьёзный шаг. (уже слышно, как он орёт в PR-ах)
На этой неделе в проекте Linux kernel впервые официально разрешили использовать ИИ при написании кода. Но с важным условием - вся ответственность теперь полностью на разработчике.
Позиция Линуса Торвальдса максимально простая: ИИ - это просто инструмент. Если разработчик приносит плохой код, проблема не в инструменте, а в нём самом. Поэтому вместо запретов решили ужесточить правила ответственности.
Ключевой момент - подпись в коммите. Строка Signed-off-by теперь ещё жёстче закрепляет правило: только человек имеет право её ставить. Это юридическое подтверждение того, что именно ты отвечаешь за код. Никакие AI-агенты не могут это делать.
Если, например, Claude сгенерировал race condition в block layer, а ты это пропустил - это твой баг. В истории останется твоя подпись, не модели.
Контекст важен. Open-source сейчас буквально захлёбывается от AI-кода сомнительного качества. Уже есть последствия:
создатель cURL закрыл bug bounty из-за потока галлюцинированных патчей
tldraw начал автоматически закрывать внешние PR
Node.js и OCaml ловят гигантские AI-патчи на 10k+ строк
Linux выбрал самый прагматичный путь - не запрещать, а заставить отвечать.
ИИ можно использовать. Но теперь без иллюзий: написал ты. Проверил ты. Отвечаешь тоже ты.
🖥 Полезные Linux ресурсы 🚀 Max
@machinelearning_interview
🚨 В Rust появился безопасный способ брать указатели на поля без UB
Если работаешь с raw pointers, рано или поздно упираешься в проблему.
Нужно получить указатель на поле структуры. Но через обычную ссылку это может сломать правила borrow checker и привести к скрытым багам.
Особенно если речь про unsafe-код и тонкие места с aliasing.
Для этого в std есть addr_of! и addr_of_mut!.
Они позволяют взять указатель на поле напрямую, без создания временной ссылки. Это важно, потому что ты не нарушаешь stacked borrows и не создаёшь лишних промежуточных состояний.
По сути ты получаешь pointer projection без побочных эффектов.
Это мелкая деталь, но в низкоуровневом коде она решает реальные проблемы. Особенно в FFI, системном коде и оптимизациях.
Если пишешь unsafe в Rust, эти макросы стоит знать.
Энтузиаст собрал «Википедию», где всё на 100% выдумано ИИ
Проект называется Halupedia.
На сайте нет заранее написанных статей. Каждая страница появляется только в тот момент, когда ты её открываешь. Правило одно: эта вселенная существует только пока на неё кто-то смотрит.
Выглядит всё почти как Wikipedia: шрифты, верстка, академический тон, ссылки, случайная статья через stumble. Только есть маленький нюанс - ничего из этого не существовало до клика.
Примеры статей там уже сами по себе прекрасны:
- Великая перепись голубей 1887 года
- Министерство слегка неправильных карт
- Халдическая арифметика - раздел математики, где запрещено вычитание
- Армунд, картограф рек - человек, который нанес на карту 14 000 лиг рек, не вставая со стула
- Общество по предотвращению ненужных вторников
На странице ещё показывается, сколько людей читают статью прямо сейчас. Обычно там фраза в духе: «вы один сейчас изучаете этот фолиант».
Но лучший поинт - описание от автора:
«Энциклопедия вселенной, которая не существует, пока вы её не посетите».
Бэкенд тоже в тему: open-source репозиторий vibeserver с описанием «маленький веб-сервер, который придумывает вещи ровно вовремя».
Мы построили крупнейшую базу знаний в истории человечества, а потом кто-то сделал её кривое галлюцинирующее отражение и выложил в открытый интернет.
Вот это уже нормальное использование ИИ.
halupedia.com
@ai_machinelearning_big_data
🖥 NVIDIA подвинула Rust ближе к CUDA
В CUDA появился экспериментальный проект cuda-oxide. Это компилятор, который позволяет писать GPU-кернелы на Rust и получать на выходе PTX для NVIDIA GPU.
Без отдельного DSL. Без прослойки на C++. Без схемы «Rust только управляет, а настоящая работа всё равно в CUDA C++».
Пока это ранняя alpha, так что ждать production-ready инструмента рано. API будет ломаться, баги будут, часть возможностей ещё не закрыта. Но сам ход показательный.
CUDA много лет была территорией C и C++. Rust рядом с ней обычно жил как host-код, биндинги или инфраструктура вокруг вычислений. cuda-oxide пробует другое: дать Rust зайти прямо внутрь GPU-кернелов.
Почему на это стоит обратить внимание:
- можно писать SIMT-код на Rust
- компиляция идёт напрямую в PTX
- не нужно тащить C++-обвязку для каждого критичного участка
- появляется шанс использовать Rust-эргономику в низкоуровневом GPU-коде
- у NVIDIA, похоже, появился серьёзный интерес к Rust-разработчикам
Сейчас это не «убийца CUDA C++» и не повод срочно переписывать ML-инфру.
Но если проект доживёт до стабильной версии, он может сильно упростить жизнь тем, кто пишет HPC, симуляции, ML-runtime и системный GPU-код.
Rust всё дальше уходит из роли «безопасной замены C для серверов» и залезает в зоны, где раньше почти безраздельно сидел C++.
https://github.com/NVlabs/cuda-oxide/releases/tag/v0.1.0
🦀 Полный roadmap по изучению Rust на русском + бесплатный курс для начинающих + большой список ресурсов.
Rust Roadmap 2026 на русском - пошаговый план изучения Rust для начинающих и продвинутых разработчиков.
Что внутри:
- базовый синтаксис
- ownership, borrowing и lifetimes
- Option, Result, traits и generics
- тестирование и обработка ошибок
- std, smart pointers и многопоточность
- async/await и Tokio
- macros, unsafe и FFI
- web, CLI, embedded, WASM, gamedev и ML
- мини-проекты на каждом этапе
Хорошый Roadmap для тех, кто хочет учить Rust не хаотично, а по нормальному маршруту: от первых программ до production-кода.
Сохраняйте себе и отправляйте коллегам!
https://github.com/Develp10/rust-roadmap-ru/tree/main
Как Rust обманывает процессор. Часть 2: niche сквозь крейты, dropck, Pin и провенанс указателей
В первой части мы коснулись niche-оптимизации, drop flags, MIR, Stacked Borrows и async-стейт-машин. Под статьёй справедливо заметили (спасибо, Mingun): про niche рассказано только в самой простой форме — Option<&T> и NonZeroU8.
А что происходит, когда enum живёт в одном крейте, оборачивается в newtype в другом, и оба варианта внешнего enum хранят один и тот же внутренний?
По факту у такого внешнего типа всего четыре состояния - байта должно хватить. Хватит ли?
Ответ короткий: иногда да, иногда нет, и причина не в теории, а в том, как rustc вообще считает layout. С этого и начнём.
https://uproger.com/kak-rust-obmanyvaet-proczessor-chast-2-niche-skvoz-krejty-dropck-pin-i-provenans-ukazatelej/
🦀 Rust против C в embedded - не на словах, а в реальном тесте.
Исследователи взяли промышленное IoT-железо и запустили на нём две реализации одной и той же функциональности.
Одна команда писала на C.
Другая - на Rust.
Системы работали параллельно несколько месяцев в реальных условиях, а не в синтетическом бенчмарке.
Итог оказался неприятным для старого аргумента «для embedded нужен только C».
Rust не проиграл C ни по памяти, ни по скорости выполнения. Более того, runtime на Ariel OS оказался даже компактнее, чем классический bare-metal стек на C.
Вывод простой: аргумент «C быстрее и легче для прошивок» теперь звучит гораздо слабее.
Rust в embedded - это вполне рабочая альтернатива.
🔗 Подоробности: https://arxiv.org/abs/2604.25679
#Rust #RustLang #EmbeddedSystems #IoT #SystemsProgramming #C
👣 Как Rust обманывает процессор: тайная жизнь niche-оптимизации, drop flags и MIR
Большинство статей про Rust заканчиваются на borrow checker и lifetimes, как будто внутри компилятора живёт только проверяльщик заимствований и злой шрифтовый дизайнер для сообщений об ошибках. На деле там целый зоопарк механизмов, о которых редко пишут даже на конференциях. Я собрал несколько по настоящему любопытных вещей, которые меняют представление о том, как устроен язык изнутри, и подкрепил каждый сюжет кодом, который можно скопировать и проверить самому.
Начнём с того, чего никто не ждёт. Знакомая всем конструкция Option ссылки занимает ровно столько же байт, сколько и обычная ссылка. Это кажется магией: ведь у Option должен быть тег, отличающий Some от None. Никакого тега нет. Компилятор знает, что ссылка в Rust никогда не может быть нулевой, и использует нулевой адрес как представление варианта None. Этот трюк называется niche optimization, и он работает гораздо шире, чем принято думать.
Проверим руками: https://uproger.com/kak-rust-obmanyvaet-proczessor-tajnaya-zhizn-niche-optimizaczii-drop-flags-i-mir/
32 тысячи звёзд на GitHub всего за 10 часов!
Терминал Warp открыли в open-source.
Это одна из самых заметных agentic development environment: терминалом уже пользуются больше 1 млн разработчиков по всему миру. Теперь проект хотят развивать быстрее за счёт комьюнити, внешних контрибьюторов и прозрачной разработки.
open-source-релиз стал возможен при поддержке OpenAI, которые выступили главным спонсором проекта.
Реакция комьюнити мощная: репозиторий за несколько часов собрал уже 30+ тысяч звёзд на GitHub.
И, конечно же, он написан на Rust.
https://github.com/warpdotdev/warp
👣 Rust Совет
MaybeUninit для ручной сборки структур без лишнего drop
Когда значение собирается по частям в unsafe-коде, FFI, парсере или аллокаторе, главная проблема не в самой инициализации. Главная проблема - что делать, если ошибка произошла посередине.
Например, одно поле структуры уже создано, а второе еще нет. В этот момент нельзя дропать всю структуру целиком: для Rust она еще не является полностью готовым объектом.
Правильный подход - явно помнить, какие поля уже инициализированы, и очищать только их. Для этого используют MaybeUninit, ptr::write, drop_in_place и, когда значение уже полностью готово, assume_init_drop.
MaybeUninit нужен не “чтобы обмануть Rust”, а чтобы аккуратно управлять жизненным циклом там, где компилятор уже не может сделать это за тебя.
Для таких случаев есть MaybeUninit:
use std::mem::MaybeUninit;
struct Buffer {
data: Vec<u8>,
meta: String,
}
let mut value = MaybeUninit::<Buffer>::uninit();
unsafe {
let ptr = value.as_mut_ptr();
std::ptr::addr_of_mut!((*ptr).data).write(vec![1, 2, 3]);
// Если дальше случилась ошибка,
// дропаем только уже инициализированное поле
std::ptr::addr_of_mut!((*ptr).data).drop_in_place();
// А всю Buffer не трогаем:
// meta еще не была создана
}
let mut value = MaybeUninit::new(String::from("hello"));
unsafe {
value.assume_init_drop();
}
🚀 DeepSeek выкатили V4 и сделали то, к чему все шли последние два года.
Длинный контекст больше не фича для демо. Теперь это базовый уровень.
Пока Запад празднует релизы с пафосными стримами, китайцы из DeepSeek сегодня утром просто выложили в Hugging Face две открытые модели и пошли пить чай. А теперь весь твиттер пытается осознать, что произошло. V4-Pro на 1.6 триллиона параметров с 49 миллиардами активных и V4-Flash на 284 миллиарда с 13 активными. Обе открытые, обе с миллионом контекста по дефолту, обе уже доступны через API и на chat.deepseek.com.
Главная фишка даже не в размере, а в том, что DeepSeek пересобрали внимание. Они запихнули в модель токенную компрессию и свою DeepSeek Sparse Attention, за счёт чего длинный контекст стал буквально дешёвым.
Не «технически возможным за пять долларов за запрос», как у конкурентов, а реально дешёвым. 1М теперь стандарт во всех официальных сервисах, а не премиум-опция за отдельную плату.
По цифрам V4-Pro претендует на открытый SOTA в агентном кодинге, тащит математику и STEM и в общих знаниях уступает только Gemini 3.1 Pro. Flash-версия идёт следом почти вплотную по ризонингу и ровно держит планку Pro на простых агентных задачах, но с меньшей задержкой и смешным прайсом.
Отдельно интересно, что API теперь поддерживает и формат OpenAI ChatCompletions, и Anthropic, с переключением между Thinking и Non-Thinking режимами. Старые deepseek-chat и deepseek-reasoner отключат 24 июля 2026, так что у команд есть три месяца на миграцию.
И конечно, DeepSeek не забыли ткнуть Anthropic в бок: в треде прямо написано, что V4 «бесшовно интегрируется с Claude Code, OpenClaw и OpenCode». То есть пока у Anthropic вчера был пост-мортем про сломанный харнесс, DeepSeek сегодня предлагает подменить им модель и сэкономить.
Закрытые лаборатории будут делать вид, что ничего не случилось, но стоимость миллиона токенов контекста только что стала публичной ценой, и от неё уже не отмотаешь.
В релизе есть упоминания - «950 supernodes» это отсылка к Huawei Atlas 950 SuperPoD, новой инференс-инфраструктуре Huawei на чипах Ascend. DeepSeek говорят, что во второй половине 2026 года, когда эти суперноды запустят в масштабе, цена Pro заметно упадёт. То есть они планируют гонять инференс не на Nvidia, а на китайском железе Huawei.
📄 Tech Report: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
🤗 Open Weights: https://huggingface.co/collections/deepseek-ai/deepseek-v4
@ai_machinelearning_big_data
#DeepSeek
🦀 Rust не ловит дедлоки, он их просто не компилирует
Вместо того чтобы надеяться, что ты правильно расставил lock’и и ничего не сломаешь в рантайме, Surelock выносит всю проблему дедлоков на уровень типов.
Ошибся с порядком захвата мьютексов?
Код даже не соберётся.
И это не какая-то игрушка. API остаётся удобным.
По факту:
• компилятор сам проверяет порядок локов
• невозможно случайно создать дедлок
• эргономика остаётся на уровне обычного Rust
•
Это тот случай, когда безопасность не «поверх», а встроена в саму модель языка.
Rust снова делает то, что другие языки даже не пытаются.
https://notes.brooklynzelenka.com/Blog/Surelock
🦀 Rust заходит на GPU по-взрослому
Появился мощный разбор от VectorWare: они смогли запустить обычные std::thread прямо на GPU.
Идея простая, но взрывающая мозг: вместо классической модели GPU с kernel’ами и ручной синхронизацией, потоки Rust мапятся на warps.
И код начинает выглядеть как нормальный Rust, а не как низкоуровневый ад с указателями и барьерами.
GPU всегда работал по другой логике: ты пишешь функцию, а она запускается тысячи раз параллельно. Вся синхронизация и контроль — на тебе. Именно поэтому GPU-код сложный и хрупкий
Здесь происходит сдвиг модели:
• пишешь как для CPU
• получаешь параллелизм GPU
• меньше дыр в безопасности и ручной работы
Каждый warp ведёт себя как потокstd::thread становится абстракцией поверх GPU
часть стандартной библиотеки начинает работать прямо на устройстве
Это попытка совместить два мира: thread-based модель CPU и kernel-based модель GPU
Один и тот же код можно гонять на CPU и GPU, сложная логика больше не требует переписывания под kernel.
Если такие абстракции взлетят, GPU перестанет быть «спецрежимом для математики» и станет обычной средой исполнения для сложных систем.
Ссылка на разбор: https://vectorware.com/blog/threads-on-gpu/
Rust 1.95.0 вышел. И это не просто минорный апдейт.
Добавили cfg_select! - теперь проще управлять кодом под разные платформы без каши из #[cfg].
В match наконец завезли if let guards. Условия стали чище, меньше вложенности, код читается быстрее.
Под капотом много стабилизаций API и улучшений const. Больше логики можно выполнять на этапе компиляции, а не в рантайме.
• Меньше костылей
• меньше макросного ада
• больше контроля и предсказуемости
Rust продолжает делать то, за что его любят - тихо улучшать разработку на каждом уровне
blog.rust-lang.org/2026/04/16/Rust-1.95.0/
👣 На Stepik обновили курс «Rust: полный курс разработчика. С нуля до профи»
Представьте: через три месяца вы открываете чужой Rust-код и читаете его как книгу.
Arc<Mutex<T>> не вызывает панику. impl Future не пугает. Вы точно знаете, почему компилятор ругается и как это починить за 10 секунд.
Это не фантазия. Это результат 50 уроков, в которых каждая концепция объясняется через код и закрепляется практикой. Ownership, traits, generics, async, unsafe - всё, что казалось магией, станет рабочим инструментом.
А бонусом - портфолио проектов: от CLI-утилит до REST API и WebAssembly.
Вы и так знаете, что Rust - ваш следующий язык. Этот курс просто сделает это реальностью.
Сегодня - 55% процентов от цены, торопись: https://stepik.org/a/269250/
Spinlock<T> с нуля на Rust.
Без Mutex. Только AtomicBool, UnsafeCell и RAII-guard.
За ~60 строк unsafe-кода разобрался с memory ordering и получил рабочую альтернативу мьютексу 🦀
Репозиторий
https://github.com/1rishuraj/low-latency-rust/tree/main/spinlock
Rust и QUIC уже делают то, к чему ИИ только подбирается
Пока все спорят про агентов и автокодинг, в системной разработке quietly происходит очень важная вещь. Люди начинают нормально проверять сложные системы, а не надеяться на тесты.
Команда Адольфо Очагавии взяла QUIC-симулятор на базе quinn и попыталась убедиться, что он вообще работает корректно. Не на простых кейсах, а на произвольных сетях, включая сценарии уровня Земля–Марс.
Обычные тесты быстро закончились. Покрыть такие сценарии руками невозможно.
Они пошли другим путём. Сначала зафиксировали на бумаге, что считается корректным поведением. Затем встроили audit-лог прямо в симуляцию. После этого написали отдельный verifier, который прогоняет каждую симуляцию и проверяет её автоматически.
Ключевой момент в том, как это реализовано. Основную логику вообще не трогали. Проверка вынесена в отдельный слой. Сам verifier достаточно простой, его можно прочитать и понять без погружения в систему. Поверх этого появились golden-тесты, которые ловят регрессии.
Это выглядит как практическая версия того, о чём сейчас много говорят в контексте ИИ. Не просто генерировать код или тесты, а формализовать поведение системы и проверять его на уровне свойств.
Если переносить на AI-системы, то это ровно та же проблема. У нас есть агенты, пайплайны, куча состояний и внешних эффектов. И почти нет нормальной верификации. Всё держится на эвристиках и наблюдении.
Этот кейс хорошо показывает, куда двигаться дальше. Не усложнять архитектуру, а добавлять слой проверяемости поверх неё.
Разбор здесь
https://ochagavia.nl/blog/a-real-world-case-of-property-based-verification/