История Rust: от стартапа до продакшена

Дело в том, что Rust совсем не гарантирует бинарную совместимость, у него сейчас нет стабильного ABI, они сейчас могут представлять данные в памяти так, как хотят. Даже в пределах одной версии компилятора, компилятор в разных программах может по-разному компоновать в памяти структуры данных. Все библиотеки раста (крейты) предоставляются именно в виде исходных кодов, которые на этапе компиляции статически линкуются. С другой стороны, именно отсутствие гарантированного бинарного интерфейса позволяет компилятору не ограничиваться рамками, и делать очень интересные оптимизации, об этом подробно написано в Rustonomicon. А если уж очень нужно сделать библиотеку на Rust, которая подгружается динамически, используют сишный ABI

Autumn vibes. Как я с кодингом с помощью LLM знакомился

что же там такое можно нарефакторить с моделью на 7 миллиардом параметров...

История Rust: от стартапа до продакшена

Я вас не понимаю. Зачем нам получать Ocaml? Он уже есть. Можно взять и начать писать на нём компилятор для своего языка.

А чтобы сделать массив, память выделять не надо, его вполне можно хранить на стеке, или в bss. В embedded Rust часто пишут no_std и no_alloc код, там аллокатора и вовсе нет, ничего выделить нельзя

История Rust: от стартапа до продакшена

Странно, как это не используют, когда куча продуктов на нём написана, в том числе довольно известных

История Rust: от стартапа до продакшена

Зачем на ассемблере? На другом высокоуровневом языке программирования. Ocaml очень даже хорошо для этого подходит, кстати

История Rust: от стартапа до продакшена

Так фишка раста в том, что все гарантии и проверки на этапе компиляции, а не исполнения. Совсем разные парадигмы. В чем преимущество писать интерпретатор на другом языке, а потом компилятор? Чтобы интерпретировать компилятор? Звучит очень странно

История Rust: от стартапа до продакшена

Можно будет менять. Для этого есть editions. Вы читали статью? И обратную совместимость именно они и обеспечивают, вы можете мигрировать на новый edition тогда, когда удобно. Или не мигрировать вовсе. И среди зависимостей могут быть крейты с разными edition, вполне можно взять крейт, написанный для старого edition и добавить в новый проект с edition 2024, к примеру, и собрать самым свежим компилятором

if err != nil: почему мы (не) любим обработку ошибок в Go? Обзор предложений по её улучшению

Конечно. Дело в том, что Rust не привязан к определенному асинхронному рантайму. Он даёт базовые механизмы: async/await, futures, wakers, pin, context. А асинхронный рантайм пользователь выбирает сам. Обычно это tokio или async-std, во встраиваемых системах самый развитый и мощный сейчас embassy, но есть и альтернативы. А при компиляции все асинхронные таски превращаются в конечный автомат. В embassy для создания тасок не нужна куча и количество, типы запускаемых асинхронных тасок известно на этапе компиляции. Есть другой асинхронный рантайм для микроконтроллеров, называется edge-executor, он уже требует реализацию кучи, но в замен предлагает в рантайме более гибко управлять количеством тасок, и позволяет передавать им дженерики в качестве параметров. Но он менее популярен и особого смысла / применения я для него не вижу, embassy хватает с головой.

if err != nil: почему мы (не) любим обработку ошибок в Go? Обзор предложений по её улучшению

А тот красавчик, о ком вы говорите, случайно не автор Actix?

if err != nil: почему мы (не) любим обработку ошибок в Go? Обзор предложений по её улучшению

Дело в том, что serde – далеко не только для JSON годится :)

Но и для yaml, toml, бинарные протоколы (postcard, cbor). Т.е. у меня на микроконтроллере произвольные структуры данных, которые я с помощью serde + postcard превращаю в бинарный формат, передаю по USB с помощью postcard-rpc, и на компьютере получаю обратно исходную структуру данные. А сейчас ещё и сетевой стек пишут, ergot, очень многообещающий проект, как раз для встраиваемых систем. А использование async во встраиваемых системах, разве это не прекрасно? Какой другой язык позволит писать над микроконтроллере асинхронный код? А здесь это работает очень органично, ISR вызывают wakers, и просыпается таска. embassy.dev - прекрасный проект

if err != nil: почему мы (не) любим обработку ошибок в Go? Обзор предложений по её улучшению

Вот прямо здесь и платят, в VK Tech: https://habr.com/ru/companies/vk/articles/832584/
А ещё платят в Wildberries, Альфа Банк, МТС, YADRO, Газпром. Много где, достаточно поискать в сети.
Насчёт стандарной библиотеки и огромного набора крейтов - тут Rust не устапает Go. Хочется найти применение для rustup? Добро пожаловать, на ваш выбор: embedded rust (stm32, esp32, nrf52, rp2040 - прекрасная поддержка популярных чипов), backend, фронтенд на WASM, CLI-инструменты, GUI-фреймворки (egui, relm4, iced, tauri, slint), можете брать no_std и писать модули ядра Linux, можете писать смарт-констракты для блокчейна или eBPF-программы, операционные системы и СУБД. Что угодно, была бы фантазия) Советую посмотреть такие крейты, как tokio, clap, axum, serde, anyhow, thiserror, tracing. Это такой, базовый набор, я бы сказал, с которым очень удобно и приятно писать различные консольные инструменты. Если уж есть желание взглянуть поближе - у Rust есть официальный учебник, который в том числе переведён на русский язык, в котором всё прекрасно рассказано.
Алгоритмы я каждый день не пишу, но если нужно - сделаю. Есть и опыт в Си, и понимание soundness, unsafe rust. Но, скорее всего, не буду изобретать велосипед, а возьму популярный крейт, хорошо протестированный и с удобным API: pathfinding, petgraph, arena-tree.

if err != nil: почему мы (не) любим обработку ошибок в Go? Обзор предложений по её улучшению

Вполне себе, искал в июле работу, нашёл за пару недель, получил два оффера. Вакансии на hh.ru по расту есть, и платят очень даже прилично, а взамен пишешь на очень приятном современном языке

Samsung представила Bespoke AI — стирально-сушильную машину с ИИ и 20-летней гарантией на мотор

Так речь же идёт о маленькой специализированной для конкретной задачи модели, а не LLM с десятками и сотнями миллиардов параметров

Как ИИ помогает разгрести легаси и ускорить модернизацию

Можно и с бинарником. Загружает бинарь в Ghidra, ставим туда этот плагин: https://github.com/cyberkaida/reverse-engineering-assistant
Подключаем MCP к ИИ-агенту, и просим его проанализировать код. Он через MCP начнёт исследовать код. Лучше попросить его сразу по ходу дела переименовывать функции согласно их назначению и оставлять заметки о том, что он находит, в отдельном MD файлике. Работает не идеально, но весьма неплохо

Инцидент с Therac-25

Делаем поворот заслонки асинхронной операцией:

use embassy_time::{Duration, with_timeout, TimeoutError};

async fn do_something() -> Result<(), TimeoutError> {
    motor.start();
    with_timeout(Duration::from_secs(2), valve.wait_for_closed()).await?;
    motor.stop();
    Ok(())
}

Да-да, async сейчас прекрасно поддерживается в embedded Rust

Arch Linux на ZFS для людей: новый TUI-установщик archinstall_zfs

Ещё раз: если у вас есть ZFSBootMenu, никакой LiveUSB не понадобится. ZFSBootMenu это сам по себе маленький Линукс.

Оттуда можно как откатить систему к прошлому снэпшоту, так и сделать chroot, поменять что нужно в системе. Есть ещё более жирный образ ZFSBootMenu Recovery, я предпочитаю им пользоваться вместо стандартного. Там богатый набор утилит, которые могут понадобиться при восстановлении системы.

Но я так и не пользовался этим. Просто через zrepl настроил снэпшоты раз в час. Если что-то пошло вдруг не так – я всегда из ZFSBootMenu могу парой нажатий кнопок откатить корневой датасет к тому состоянию, в котором он был час, или два часа назад, к примеру.

Arch Linux на ZFS для людей: новый TUI-установщик archinstall_zfs

Я бы протестировал, но у меня на единственной системе с NVMe включено шифрование диска и сжатие, мне кажется, именно они будут узким местом, а не ARC. Хотя может я и ошибаюсь, попробовать потестировать на отдельном датасете

Arch Linux на ZFS для людей: новый TUI-установщик archinstall_zfs

Да, бывает и такое) Но бывает и как сейчас: последняя версия ZFS поддерживает ядро 6.16.

В целом, обычно разработчики ZFS не гонятся со всех ног выпускать новый релиз сразу после релиза нового ядра. Новый релиз выходит тогда, когда становится готов набор пул реквестов, которые они хотят видеть в этом релизе, там свой график.

А вообще, да, есть энтузиасты, которые к последней стабильной версии ZFS добавляют cherry-pick патчи для поддержки наипоследнейшего и новейшего ядра, когда ZFS отстаёт. Тоже видел такие пакеты в AUR

Arch Linux на ZFS для людей: новый TUI-установщик archinstall_zfs

Я советую сделать так: /boot сделать не отдельным разделом, а просто директорией в рутовом датасете, который монтируется в /

А boot раздел превратить в EFI раздел и закинуть туда EFI файл ZFSBootMenu, который можно скачать здесь: docs.zfsbootmenu.org

Таким образом, вся система лежит целиком на ZFS, включаю boot. Не стоит его делать отдельным разделом, пусть просто лежит директорией в рут. А чтобы в UEFI появилась опция ZFSBootMenu, нужно просто добавить в UEFI запись с помощью утилиты efibootmgr.

ZFSBootMenu – это один EFI файлик, он будет грузиться напрямую из UEFI, сканировать ZFS пулы, импортировать, искать там ядро / initramfs и загружать. Подробнее советую прочитать в документации ZFSBootMenu, там очень хорошо написано :)

Arch Linux на ZFS для людей: новый TUI-установщик archinstall_zfs

Дополню на всякий случай про Live флешку с ZFS. ISO можно взять тут: https://github.com/stevleibelt/arch-linux-live-cd-iso-with-zfs/releases

Либо в релизах моего репозитория, там тоже автоматическая сборка ISO с ZFS: https://github.com/okhsunrog/archinstall_zfs/releases

Ещё можно собрать такой ISO самому, в README моего проекта есть инструкции.