#зумеры #rust #rant

Вот есть такой https://wezfurlong.org/wezterm/index.html - весь из себя ниибаца безопасный и на Rust. 11k звезд на github. Альтернатива #alacritty, потому что а почему бы и нет?

Его намертво вешает вот такая программа:

pg# cat qw.py
import sys
for i in range(0, 10000):
    sys.stdout.write(chr(i))

Мораль?

Ну вот не падает программа, написанная пионером, а уходит в бесконечный цикл - кому от этого легче?

https://www.opennet.ru/opennews/art.shtml?num=60303

Первый сетевой драйвер на #Rust в ядре. https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=cbe0e415089636170aa6eb540ca4af5dc9842a60

Ажно 135 строк кода, 134 из которых - взаимодействие с остальным ядром, ничего интересного, проходим мимо.

Зато классный срачик на похорониксе - https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1429237-the-first-rust-written-network-phy-driver-set-to-land-in-linux-6-8

Коллеги спорят, можно ли писать "боевой" код на С, или нельзя.

Это, очевидно, instance of https://ru.wikipedia.org/wiki/%D0%9D%D0%B8_%D0%BE%D0%B4%D0%B8%D0%BD_%D0%B8%D1%81%D1%82%D0%B8%D0%BD%D0%BD%D1%8B%D0%B9_%D1%88%D0%BE%D1%82%D0%BB%D0%B0%D0%BD%D0%B4%D0%B5%D1%86, поэтому принимать участие в этом обсуждении я не вижу никакого смысла, только скажу, что писать надежный код на С - запредельно дорого.

Будни #bootstrap, #gold

Проснулся сегодня с мыслью, что именно сегодня, хоть тушкой, хоть чучелом, хоть вызовом https://play.rust-lang.org/?version=stable&mode=debug&edition=2021 по http, но я затащу Rust в #ix.

Потому что ну сколько можно? И потому что мне нужно было обрести уверенность, что выбранный мной способ #bootstrap, рано или поздно, но приведет к работающему результату.

В #stal/ix теперь есть #rust!

Пока не #bootstrap, пока просто сборка с оффсайта, творчески перепаханная, чтобы уметь работать в full static environment:

* https://github.com/pg83/ix/blob/main/pkgs/bld/musl/ix.sh - сборка shared musl, с динамическим загрузчиком. Особое внимание стоит обратить на мою великолепную реализацию динамических исключений (libgcc_s.so.1) - https://github.com/pg83/ix/blob/main/pkgs/bld/musl/ix.sh#L22-L69

* С помощью patchelf перепахиваем скачанный дистрибутив, чтобы он использовал мой ld.so - https://github.com/pg83/ix/blob/main/pkgs/bld/rust/linux/unwrap/ix.sh#L20-L23

* Цимес, мякотка, соль всего процесса - https://github.com/pg83/ix/blob/main/pkgs/die/rust/cargo.sh#L30-L65 - хрень, которую я подсовываю в rustc в качестве С/С++ компилятора (и линкера). Она решает творческую задачу по редактированию строки вызова компилятора так, чтобы, когда надо, это была динлинковка с моим musl (для последующей загрузки получившейся .so компилятором rustc), а, когда надо, статлинковка финального артефакта.

Заняло это всего час времени.

Нет, реально, все оказалось проще, чем я изначально предполагал, оно просто взяло, и заработало.

Это не финальный результат, но:

* Уже можно использовать какие-то полезные программы на rust, хотя они еще не bootstrapped.

* Я теперь точно знаю, что, если воспроизведу всю цепочку, то получу бинарник, который точно сможет работать в моем окружении.

Продолжаем развенчивать мифы про 3D ускорение терминала. #terminal

Раз уж я заполучил #rust (https://t.iss.one/itpgchannel/1605), то теперь у меня есть работающий #alacritty!

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

#alacritty:

real  0m1.039s
user  0m0.000s
sys  0m0.396s

#foot:

real  0m0.597s
user  0m0.000s
sys  0m0.362s

Что это значит?

Это значит, что, несмотря на свою похвальбу, alacritty не является самым быстрым терминалом, и что 3D ускорение в терминале - совершенно необязательно для комфортной работы.

Ссылки:
https://t.iss.one/itpgchannel/133
https://t.iss.one/itpgchannel/119
https://t.iss.one/itpgchannel/39

UPD: в коментах меня попросили побенчмаркать не бинарный треш, а что-то другое.

Вот, вывод на экран 150 мегабайт текста:

alacritty:

real  0m2.920s
user  0m0.000s
sys  0m1.456s

foot:

real  0m2.059s
user  0m0.000s
sys  0m1.534s

Как увидеть все фичи, которые можно включить на #rust crate?

Никак, пук-среньк.

https://www.reddit.com/r/rust/comments/pwpuas/is_there_anyway_i_can_see_all_the_features_a/

https://blog.polybdenum.com/2024/01/17/identifying-the-collect-vec-memory-leak-footgun.html #perf

Текст про то, как стандартная библиотека #rust оказалось слишком умной, и переиспользовала память Vec после того, как этот Vec был превращен в range, а из этого range снова в Vec.

Насколько я понял, там случилось ажно две смешных штуки оптимизации:

1) into_iter().collect() переиспользовало тот же самый вектор, хотя можно было бы ожидать, что это будет похоже на shrink_to_fit()

2) into_iter().map().collect() переиспользовало старую выделенную память исходного вектора, если размер нового элемента <= размера старого элемента. Поэтому, если размер нового элемента был раз в 10 меньше, чем исходного элемента, то происходил дикий пережор памяти.

Оптимизации, конечно, семантически корректные, но спорные.

#cargo #rust

Cargo довольно сильно сопротивляется патчингу исходников.

Натуральный способ патчинга в случае сборки с cargo - это завендорить все исходники, и, перед сборкой, запатчить завендоренное.

Есть вот такой вот тикет https://github.com/rust-lang/cargo/issues/11063 (полагаю, не единственный), там обсуждаются разные всратые решения этой проблемы.

Понятное дело, что #errogant upstream на хую вертел downstream, потому что "собирайтесь как автор кода захотел левой пяткой", а проблемы негров (конкретно, людей, которым нужно собираться в разных необычных окружениях, типа моего) их не волнуют.

Я потырил решение у IBM RedHat сообщества федоры - https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust.spec#_615, им, сюрприз-сюрприз, тоже хочется уметь развендоренные исходники, чего бы там себе не воображали школота зумеры разработчики на Rust. Потому что баги в libz/libgit2/openssl патчить им, а не тем, кто принудительно завендорил исходники, без возможности сборки с системным вариантом.

Мне на завендоренные исходники, в силу статической сборки, в целом, пофиг, но, к сожалению, авторы этих crates совершенно не думали про то, как эти завендоренные исходники будут собираться в разных странных окружениях, поэтому мне приходится их развендоривать, чтобы можно было собраться с версией, которая может собраться у меня.

Развендориваю я их довольно грубо - сначала ищу все крейты в которых есть c/c++ файлы (https://github.com/pg83/ix/blob/main/pkgs/bld/rust/devendor/scripts/classify.py), потом "обнуляю" сборку этих крейтов (https://github.com/pg83/ix/blob/main/pkgs/bld/rust/devendor/scripts/devendor.sh#L14-L17) Федора развендоривает какие-то заранее известные крейты - https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust.spec#_585

#rust, bloat #gold

Несколько лет назад, когда я смотрел на rust, мне очень импонировал тот факт, что бинарники с программами на rust были весьма компактны.

Типа, единицы мегабайт, даже для довольно сложных программ.

Сейчас это, к сожалению, уже не так.

Десятки, и даже сотни, мегабайт!

(я не буду тут приводить никаких конкретных цифр и статистик, потому что время и формат канала не позволяет)

Почему так происходит?

Я это связываю с ростом code bloat, со временем.

Что такое code bloat?

Я не знаю, как определить это формально, неформально скажу так - code bloat случается, когда библиотеки начинают в себе содержать те или иные "фабрики" по производству объектов:

if (arg == "x") {return new X(...);}
if (arg == "y") {return new Y(...);}
...

(это, понятное дело, модельный пример, основной признак фабрики - это когда мы связываем какой-то широкий набор функциональности с пользовательским вводом)

Такие фабрики плохи тем, что линкер, даже с LTO, не может выкинуть из программы неиспользуемый код, потому что просто не может доказать, что тот или иной if не случается в runtime.

Благодаря этому, несмотря на то, что код вашей программы растет линейно по времени (при условии неизменности ваших усилий со временем), объем слинкованного (и скомпилированного) кода растет существенно быстрее. В пределе, "что скомпилировали, то и влинковали".

Причем как это - "существенно быстрее", само по себе, очень интересный вопрос.

Чтобы хорошо на него ответить, нужно уметь моделировать реалистичные графы зависимостей большого объема софта, уметь моделировать их развитие со временем, и после этого запустить на этой модели какую-нибудь симуляцию.

Я таких исследований не встречал, если вы что-то видели или знаете, покажите.

Я умею себя убеждать, что code bloat растет примерно как X(t)^depth(dependency tree), где X - примерно линейная функция от времени, с небольшой константой у линейной части. Повторюсь, это верно при линейном росте кода вашего проекта, и при условии, что глубина дерева зависимостей на рассматриваемом участке времени не меняется сильно.

Еще важными факторами в rust является:

* Социальный аспект. Разработчики считают, что код на rust "безопасный", поэтому новые зависимости не страшны. Это сильно отличается от мира C/C++, где каждая новая зависимость - это потенциальные сегфолты, и ну ее в жопу, лучше написать велосипед по месту. Go тут стоит где-то посредине между C/C++ и Rust.

* Отличие модульной системы go и rust, я писал про это в https://t.iss.one/itpgchannel/1155. Вот из ссылки из того моего текста довольно таки очевидно следует, что число зависимостей типового расторепозитория будет выше, чем в go. В C/C++ вообще нет модульной системы и пакетного менеджера, поэтому в ней число зависимостей типового проекта еще меньше (*).

Пока я на вас вывалил некоторое количество моделей, моих предположений про экосистемы, и так далее.

А выводы-то?

Медленнее всего толстеют со временем C/C++ программы, потом программы на Go, а чемпион по росту - rust. Да, да, ваш любимый rust - чемпион по code bloat (на данный момент). По крайней мере, я это весьма четко вижу по размерам бинарников в моей системе. Причем рост этот существенно более быстрый, чем линейный.

А что будет лет через 10, если этот процесс не остановится, я вообще боюсь себе представить!

(*) в больших монорепах, где много тестов и зависимость сделать еще проще, чем в cargo, С/С++ программы растут примерно так же быстро, как rust в open source, и многие из нас знают, что это значит для размера получающихся бинарников.

#rust #rant

Много раз слышал, что, дескать, interop Rust в/из С/С++ "хороший", и что он "лучше", чем другие реализации.

Плюньте в того, кто вам такое скажет, потому что он врет.

Interop Rust совершенно отвратительный, он построен исключительно на грубой силе.

Устроен он примерно так - для всех структур, которые ты хочешь использовать cross language, ты садишься, и меряешь все смещения и все размеры каждого элемента. После чего, по сути, вручную, или с небольшой автоматизацией, описываешь ffi вызовы.

Это, конечно, дичь, потому что вот авторы Rust interop с libc вот так измерили все линейкой, а потом оказалось, что им попалась библиотека, которая похожа на musl, но бинарно с ней не совместима. Хотя совершенно совместима на уровне API - все те же заголовки, с точки зрения C/C++ компилятора все на месте, и все работает.

Но вот если эту библиотеку позвать из Rust, то все взрывается самым интересным образом. Потому что interop "фальшивый", и не парсирует C/C++ заголовки, с учетом системного C ABI.

А запустить какой-нибудь codegen, который бы распарсил настоящие заголовки во время сборки - это, конечно, сделать код зависимым от какой-то там libc, и на такое пойти никто не может.

Я, на самом деле, говорю про две несвязанные друг с другом проблемы в musl (и вокруг musl):

* первая связана с тем, что в musl 1.2.5 удалили заглушки для 64-битных функций, которые работают с файлами. https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4 Rust на версию musl не смотрит (или не смотрел), и считает, что эти функции в ней всегда есть.

* вторая - это уже результат моих издевательств над musl. Я выпилил из musl заглушки про dlopen, и сделал свою реализацию - https://github.com/pg83/dlopen/blob/master/dlfcn.h, она нужна для эмуляции динамического связывания в рамках одного статически слинкованного бинаря. Понятное дело, что ABI этой реализации не совместим с тем, что ожидает Rust от musl.

В итоге, мне пришлось написать 2 прокси, из того, что есть на самом деле, в то, что ожидает Rust:

https://github.com/pg83/ix/blob/main/pkgs/lib/musl/compat/compat.c (https://github.com/pg83/ix/blob/main/pkgs/lib/musl/compat/compat.c#L8 - вот в корректности этой строчки я не уверен, потому что функция open() - "волшебная", она умеет быть запущенной от разного количества аргументов)

И https://github.com/pg83/ix/blob/main/pkgs/lib/dlfcn/abi/fakes.c

Interop такой interop.

Немного довольно очевидных мудростей от PG.

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

Потому что, когда ты точно знаешь, что решение существует, то поиск этого решения идет существенно бодрее, веселее, и продуктивнее.

Самый очевидный метод убедить себя в том, что решение существует, это, конечно, получить хоть какое-то решение задачи.

Самое всратое, тупое, работающее на твоем ноутбуке, и не работающее больше нигде, но решение. Сколько угодно кривое, косое, и которое не может пойти в прод по куче причин.

Хороший пример - https://t.iss.one/itpgchannel/1605

Или утащу случай с работы.

Как-то мне нужно было сделать upver версии gdb для нашей инфраструктуры. gdb не обновлялся много лет, и вообще говоря, было неочевидно, что можно вот так взять новый бинарник с новой мажорной версией, и он возьмет, и заведется.

Поэтому, прежде чем бросаться и строить постоянное сооружение, я пошел и построил херобору - взял новую сборку из какой-то убунты. Эта сборка, конечно, не очень работала в нашей инфре, поэтому я положил рядом с бинарником какие-то недостающие .so со своей рабочей тачки, переписал динамический загрузчик в исполняемом файле, потому что glibc тоже пришлось положить рядом, положил рядом какие-то данные из ncurses, написал враппер, который бы выставил все пути для поиска локальной копии библиотек, упаковал всю эту херобору в tgz, и отправил в условный "testing" (на самом деле, "варить плашку", но это мало кому чего-то скажет).

Благодаря этой хероборе я сумел прикинуть масштаб проблем, и понял, что, в принципе, это подъемная задача, и начал ее "отливать в граните".

(работала ли эта херобора в нашем настоящем проде, история стыдливо умалчивает)

Я, когда писал вот этот вот текст, про то, что rust с его каргой - тихий ужас, с точки зрения дистростроения, тогда еще не имел в своем #CI программ на #rust.

А теперь у меня их порядка 20 штук, и, я должен сказать, что https://t.iss.one/itpgchannel/337, как говорится, не "в бровь, а в глаз".

Потому что мой CI половину (половину, Карл!!!) времени занимается тем, что пересобирает эти несчастные 25 программ. Напомню, что всего у меня порядка 2000 пакетов, и вот где эти 20 программ, и где половина времени моего CI?

Я тогда, конечно, был чересчур оптимистичен, и решение, которое мне тогда пришло в голову, прямо сейчас реализовать не выйдет.

Но я выкрутился тем, что отселил CI для растопрограмм в отдельный контур, на отдельный, более слабый, хост (64 ядра vs 88 в основном контуре). Ну и оно там "как-то" бежит, не замедляя весь процесс.

Я не знаю, какой-нибудь сраный https://github.com/zed-industries/zed - это 1200 крейтов в зависимостях. 1200, Карл!!! Это больше, чем просто библиотек в среднем дистрибутиве Linux! Для сборки текстового редактора! 1200 библиотек!

Меня, признаться, знатно подбамбливает от всей этой экосистемы, так жить нельзя.

Ну, допустим, #meme про изучение #rust.

(thanks @bapho_bush)

#rust #meme 🥲

Source

#rust #gamedev #quotes

Source

https://t.iss.one/dereference_pointer_there/9180

История про то, как один мейнтейнер ядра не пускает к себе в ядро растовые обертки.

Я писал про начало этой истории в https://t.iss.one/itpgchannel/2189

Уважаемые растаманы, а чего вы хотели?

Вы сначала лезете со своим blazingly fast more memory safe изо всех щелей, хаете то, что не поняли, и переписываете то, с чем не осилили разобраться, а потом расстраиваетесь, что серьезные люди не хотят иметь с вами серьезных дел?

Ну меняйте подход, чо.

#prog #rust #suckassstory

https://nitter.net/davidtolnay/status/1883906113428676938

TL;DR: serde_yaml от dtolnay более не поддерживается. Кто-то сделал форк под именем serde_yml и начал кидать туда коммиты, сгенерированые LLM. И этим говном при этом ещё и кто-то пользуется.

On top of this, the crate's documentation has been broken in docs·rs for the last 5 months because AI hallucinated a nonexistent rustdoc flag into the crate's configuration.

(thanks @al_tch)

#rust #meme

old.reddit.com/r/rustjerk/comments/yd770d/how_does_rust_make_me_write_good_code

#prog #rust #article

A Newbie's First Contribution to (Rust for) Linux

Статья о написании драйвера для Linux с использованием R4L вкупе с написанием вспомогательных абстракций для него. Спойлер: написание кода, даже со скидкой на то, что это рерайт, было далеко не самой сложной вещью из того, что нужно было для добавления кода в ядро.

#prog #rust #cpp #meme

(thanks @dev_meme)