WIE — это исследовательский эмулятор пользовательского режима (userspace) для запуска 64-битных Windows-приложений (PE64) на архитектуре macOS Apple Silicon. Проект написан на Rust 1.97, а в качестве бэкенда компиляции используется Cranelift для трансляции x86-64 инструкций на лету в нативный ARM64.
В статье расскажу о PWA‑бенчмарке, который основан на задаче N тел. Физический движок написан на Rust/WebAssembly, визуализация через Three.js, и результаты запусков сохраняются в Supabase. Тут присутствует разбор архитектуры, сравнение алгоритмов расчета — прямой и Barnes‑Hut, а также тут расписаны проблемы, связанные с измерением производительности в браузере.
Привет, Хабр!
Когда вы пишете вот такую строчку:
const N: u64 = fib(50);
внутри компилятора происходит странное. rustc не генерирует машинный код для fib, не зовёт процессор и не подставляет ответ откуда-то сбоку. Он берёт вашу функцию, разворачивает её в промежуточное представление и исполняет шаг за шагом прямо у себя внутри, на маленькой виртуальной машине.
И вот вопрос, на который мало кто может ответить с ходу: а кто конкретно это исполняет? Где живёт тот интерпретатор? Почему 255 + 1 в const падает с ошибкой компиляции, а в рантайме просто паникует? Почему можно посчитать таблицу из тысячи элементов циклом, но нельзя написать if a < b для дженерика? И почему 0.0 / 0.0 в const официально разрешили вести себя недетерминированно?
Погнали разбираться.
Здравствуйте, что-бы разобраться c уравнениями, нужно примерно понимать что это не новость а статья.
Разберем кейс о сборке полностью кастомного 3D принтера. Можно ли, имея бескрайний энтузиазм и скидочные купоны в AliExpress, собрать на своем балконе авторский принтер? Может ли Rust быть эффективным инструментом для встроеной разработки? Давайте посмотрим‑с.
Привет, Хабр!
#[derive(Serialize, Deserialize)] это какая-то одна строка в коде. На холодной сборке за ней прячется двадцать с лишним секунд компиляции, даже если в проекте больше ничего нет. Откройте cargo build --timings на любом не самом маленьком проекте с serde, и serde_derive почти наверняка окажется в первой тройке самых медленных крейтов. При том что в самом serde_derive всего несколько тысяч строк.
Между этой строкой и этими секундами лежит вся инфраструктура процедурных макросов: TokenStream, syn, quote, proc-macro2, watt. Пройдёмся по ней в этой статье.
Rust-компилятор не просто превращает код в машинные инструкции — он проверяет безопасность программы ещё до запуска. Разбираем, как устроен конвейер компиляции, зачем Rust использует сразу несколько промежуточных представлений (HIR, THIR, MIR) и какую роль во всём этом играет LLVM.
Я Артур Валиев, разработчик EVRT
Когда мы форкнули RustDesk и начали строить EvertyDesk — корпоративный удалённый рабочий стол с поддержкой Hyper-V, Proxmox, VirtualBox и умным агентом — первое, во что упёрлись, было видео.
H.264 — стандарт де-факто. TeamViewer, AnyDesk, Windows App — все используют H.264. Он работает. Но он lossy. И вот здесь начинается проблема, о которой в статьях про remote desktop обычно не говорят.
Когда оператор смотрит на терминал с git diff или читает трейс в VSCode — один размытый пиксель в букве это уже другой символ. H.264 при любом разумном битрейте вносит артефакты в области с резким контрастом. Точно туда, где у нас весь текст. Это неприемлемо.
H.264 в lossless режиме (QP=0, lossless profile) существует, но поддержка в декодерах — через пень-колоду, а для mostly-static контента предикторы рассчитанные под видео с движением дают нулевой выигрыш над тривиальным delta-кодером.
Нам не нужен motion estimation. Нам нужно: вот предыдущий кадр, вот текущий, вот список изменившихся тайлов, сожми только их.
Мы написали EVRTCK.
Команда Rust рада объявить о новом выпуске Rust 1.97.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.97.0 вам достаточно выполнить команду:
$ rustup update stable
Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску 1.97.0 на GitHub.
Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.
WebAssembly появился для браузерных задач как способ исполнять тяжелый код быстрее, чем это делает JavaScript. Но за последние годы он начал выходить далеко (иногда буквально далеко) за пределы вкладки браузера: серверы, edge-вычисления, плагины, песочницы. Появились рантаймы Wasmtime, WasmEdge, Wasmer, которые исполняют WASM-модули\компоненты прямо на ОС. Звучит красиво - собрал один бинарь, а запускаешь где угодно, да еще и в максимальной изоляции.
Но есть интересное наблюдение. Существуют проекты, которые строили свои виртуальные машины на WASM, но отказались от него. Самый заметный пример - это Polkadot. Они спроектировали собственную PolkaVM на базе набора инструкций RISC-V и переключили исполнительный слой смарт-контрактов на нее (при этом сам runtime Polkadot по-прежнему компилируется в WASM). Если WASM настолько хорош, как заявляется, то почему для нового движка выбрали не его, а регистровую машину?
Недавно в одном из тематических чатов разгорелась жаркая дискуссия на этот счет, что, собственно говоря, и побудило меня на написание этой статьи. Если тебе интересны такие темы - добро пожаловать к нам)
Давайте попробуем разобраться, чем стековая модель отличается от регистровой и где эта разница реально что-то меняет. А также рассмотрим, где же в WASM скрыты компромиссы.
На поделке из предыдущей статьи вдохновение не закончилось, решил написать VPN. Был опыт разработки shadowsocks сервера, что не понравилось: под каждое TCP соединение, открываемое каким-нибудь браузеров, VPN клиент открывает отдельное TCP cоединение к серверу, а тот в свою очередь столько же до конечной точки + пришлось руками шифровать/дешифровать payload. Захотелось сделать что-то более простое + самим написать и клиент.
Rust скор во время выполнения, а вот компилируется он не так шустро. Едва ли это удивит читателя, имевшего дело с серьёзными базами кода на Rust. В блогах сложился целый жанр постов, повествующих о том, как скостить пару секунд с cargo build.
В нашем проекте мы реализовали функцию, позволяющую пользователям писать прямо на SQL, определяя таким образом таблицы и представления. Под капотом этот код на SQL компилируется в код на Rust — который затем передаётся rustc и с его помощью компилируется в единый бинарник. В этом двоичном файле путём пошагового приращения все представления актуализируются по мере того, как новые потоковые данные поступают в таблицы.
Ранее мы уже предпринимали всевозможные ухищрения, чтобы ускорить компиляцию: стирали типы, активно продавливали дедупликацию кода, сокращали строки, связанные с генерацией кода. В этом мы достаточно преуспели. Но недавно мы стали осваивать работу с крупным новым клиентом (энтерпрайз), у которого оказалась масса сложного SQL-кода. Они написали при помощи наших инструментов много больших программ. Например, там был образец размером в 8562 строк на SQL, который наш компилятор в итоге превращал примерно в ~100k строк на Rust.
Привет, Хабр!
Воодушевившись статьёй std::expected в C++23: гайд по миграции с исключений на функциональный error handling, представляю собственную с переписанными примерами на Rust. Код в статье итеративно переписывается и улучшается.
sizeof(Mutex<()>) в Rust 1.61 на Linux был 40 байт. В Rust 1.62 он стал 5 (точнее, 8 с учётом выравнивания, но базовый overhead 5).
За уменьшением размера в восемь раз стоит полная переписка стандартного Mutex с pthread на futex напрямую, ускорение uncontended locks в 2-3 раза, и десятилетие, которое стандартный Mutex провёл в роли «возьми parking_lot, std::sync::Mutex медленный».
Сегодня заглянем под капот всей этой темы, разберём, что лежит внутри std::sync::Mutex после 1.62, какой алгоритм там используется, почему он на самом деле быстрее pthread, как устроен fairness (точнее, его отсутствие), зачем нужен poisoning, и в каких случаях parking_lot всё ещё имеет смысл тащить в зависимости. Заодно вернёмся к моей старой async-статье и поясним конкретнее, почему в async-задачах std::sync::Mutex это проблема, и при чём тут вообще futex.
Небольшая история о том, как я искал для себя читалку, как в итоге придумал новый формат для электронных книг — и, главное, как я месяцами воевал с дешёвыми LLM, чтобы они генерировали этот формат без ошибок. Будет и про устройство формата, и про то, как он «затюнен» под копеечные модели, и про основные проблемы.
В первой части мы загрузили своё ядро на настоящий телефон, вывели «Hello world» в UART и нарисовали квадратик на экране. Во второй — научили ядро управлять памятью и завели кучу.
С тех пор прошло более 4 месяцев, и проект тихо перешагнул важную черту: из bare-metal эксперимента получилось микроядро. В привилегированном режиме остались только процессы, память и передача сообщений, а всё остальное — драйверы, сервисы, будущая графика — обычные программы снаружи. Само ядро при этом выросло с неполной тысячи строк до сорока пяти тысяч.
В этой статье разберёмся, что такое capability и handle и при чём здесь seL4 и Zircon, запустим свой процесс-"калькулятор" на телефоне и поговорим с ним по IPC, а под конец напишем userspace-драйвер часов для устройства, про которое в ядре нет ни строчки.
Это история о том, как я писал балансировщик нагрузки для телеграм-ботов, на полпути понял, что телеграм тут вообще ни при чём, выкинул половину проекта - и теперь у меня Rust-конструктор, из которого одинаково собирается реверс-прокси, самодельный ngrok, мост HTTP -> RabbitMQ -> Kafka и тот самый балансировщик ботов, с которого всё началось.
Проект называется tgin. Раньше это был Telegram Gateway Interface, теперь - Traffic Gateway Interface.
Как хранить генеалогическое дерево у себя, подключить к нему ИИ-агента и что из этого получается на практике.
Проект: gramps-web-mcp-rs
Публикуем перевод третьей статьи из серии (первая часть, вторая), посвящённой информационным технологиям в авиаперевозках. Сегодня поговорим о режиме командной строки системы Amadeus, работа в которой опирается на язык, созданный для телетайпов. Этот язык до сих пор обеспечивает огромный процент бронирований билетов во всём мире — как тех, что выполняются различными агентствами, так и тех, что делаются посредством GDS.
Как устроен SFU изнутри: Publisher, Subscriber, комната-маршрутизатор и никакого перекодирования. Дневник разработки на Rust.
