Назревает большая революция
May. 30th, 2021 11:14 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoМногие вещи в шелле хороши и создают ощущение, что в этой области всё хорошо и правильно. Условный binutils. Маленькие программы с простыми ясными идеями, которыми удобно пользоваться.
Но... Стоит только на секунду задуматься об их изменении, как архаичный autotools ждёт вас. Причём, он ждёт вас почти всюду. От binutils до cpython.
Моё чувство прекрасного страдает при виде m4. При виде поддержки достандартного С (и макросов вокруг этого). При виде невероятного объёма хаков, написанных с софте, у которого модель garbage in - garbage out, и поверх которого пытаются "сохранить инварианты" в более приличном софте.
У меня ощущение, что это революционная ситуация.
Если раньше у нас не было критической массы софта, который бы решал те, низкоуровневые проблемы, которые раньше решал C (т.е. хочешь системно - вот тебе, падаван, m4, automake, и шуруй воевать с ./configure), и особо вариантов не было, то теперь я вижу альтернативы с более адекватным lore. Это и go, и rust, и (может быть?) swift. Хотя ладно, кого я обманываю. Rust. Его красота - не в "borrow-checker'е", как любят описывать неофиты. Его красота в разумности базовых предположений до самого низа. Спускаясь с красот "асинхронного веб-сервера с job-stealing многозадачностью" до скучных вопросов "каким образом бинарник знает какой номер у сисколла для записи в fd" (если вы этот путь проделаете на условной node, вам будет очень печально), так вот, проделав этот путь, не ощущаешь острого диссонанса от "ненадлежащих средств". (Если что, там снизу libc, так что финальный слой у Rust такой же как у всех, но всё над ним - весьма добротно).
Так вот, революция начнёт происходить из-за awk-дисфории при соприкосновении с внутренностями существующих программ.
Я не знаю, сможет ли сообщество выдержать высочайший уровень инженерной продуманности Rust, но пока что от знакомства с его потрошками (и потрошками всего, что рядом) нет того же ощущения, как от доисторического Си.
Но... Стоит только на секунду задуматься об их изменении, как архаичный autotools ждёт вас. Причём, он ждёт вас почти всюду. От binutils до cpython.
Моё чувство прекрасного страдает при виде m4. При виде поддержки достандартного С (и макросов вокруг этого). При виде невероятного объёма хаков, написанных с софте, у которого модель garbage in - garbage out, и поверх которого пытаются "сохранить инварианты" в более приличном софте.
У меня ощущение, что это революционная ситуация.
Если раньше у нас не было критической массы софта, который бы решал те, низкоуровневые проблемы, которые раньше решал C (т.е. хочешь системно - вот тебе, падаван, m4, automake, и шуруй воевать с ./configure), и особо вариантов не было, то теперь я вижу альтернативы с более адекватным lore. Это и go, и rust, и (может быть?) swift. Хотя ладно, кого я обманываю. Rust. Его красота - не в "borrow-checker'е", как любят описывать неофиты. Его красота в разумности базовых предположений до самого низа. Спускаясь с красот "асинхронного веб-сервера с job-stealing многозадачностью" до скучных вопросов "каким образом бинарник знает какой номер у сисколла для записи в fd" (если вы этот путь проделаете на условной node, вам будет очень печально), так вот, проделав этот путь, не ощущаешь острого диссонанса от "ненадлежащих средств". (Если что, там снизу libc, так что финальный слой у Rust такой же как у всех, но всё над ним - весьма добротно).
Так вот, революция начнёт происходить из-за awk-дисфории при соприкосновении с внутренностями существующих программ.
Я не знаю, сможет ли сообщество выдержать высочайший уровень инженерной продуманности Rust, но пока что от знакомства с его потрошками (и потрошками всего, что рядом) нет того же ощущения, как от доисторического Си.
no subject
Date: 2021-05-30 06:08 pm (UTC)no subject
Date: 2021-05-30 06:41 pm (UTC)До появления Rust'а альтернатив-то не было. С++ никогда не целился в no_std режим, а остальные были нишевыми и не предполагали ответы на все вопросы (всякие naked functions, бездны no_std жизни и т.д.). Вроде бы, ocaml достиг системных высот (до уровня компиляции в no-os по xen), но в силу своей страшной нишевости, дальше xenserver'овых фанов не уехал.
А сейчас есть Rust, который в ядре пока ещё топчется как слон в посудной лавке, но имеет все шансы подобустроиться, потому что от возникающих проблем не отмахиваются (те же naked).
no subject
Date: 2021-05-30 07:29 pm (UTC)P.S. Писать куски Линуксового ядра (ты-же про Линуксовое ядро?) на Расте для меня столь-же дикая идея, как писать их на Го. Или ПХП.
Нет, я ничего не имею против написания какого либо абстрактного ядра с нуля на любом языке. Но Линуксовое ядро:
1. Написано на Си.
2. Написано на Си в некоторых местах с эмуляцией C++ при помощи палки и верёвки.
3. Написано на Си с заточками в некоторых местах под конкретный компилятор.
4. Никогда не будет переписано полностью на Расте.
Отсюда у меня возникает простой вопрос - зачем? Вот минусы я для себя - вижу. Мне приходилось ковырятся в потрохах ядра по локоть в крови для поиска/решения конкретных проблем. Раньше мне хватало для этого знания (на уровне читаю со словарём) ассемблера одной платформы и одного языка. Теперь нужно будет знать еще один язык, с синтаксисом еще более птичьим чем у Си.
Печаль.
no subject
Date: 2021-05-31 11:02 am (UTC)Это не ассемблер. C - он про структурное программирование, и поэтому некоторые вещи, которые можно сделать в асме, в С сделать нельзя. Его неоднократно пытались даунгрейднуть в честный ассемблер, но популярности эти попытки не снискали.
no subject
Date: 2021-05-31 01:36 pm (UTC)no subject
Date: 2021-05-31 04:33 pm (UTC)no subject
Date: 2021-05-31 06:00 pm (UTC)a = b[i++] компилировалось в 1 машинную операцию на PDP11.
Так-же как a = b[++i]
Впрочем, мы не об этом. У всех компиляторов Си, которые я видел, есть инструкция asm. Это, конечно, читерство. Но как по мне - не большее, чем unsafe в Rust. Так что стеком, при желании, порулить можно.
no subject
Date: 2021-05-31 06:03 pm (UTC)asm в Rust есть, так же как и naked functions (в которых компилятор не управляет стеком).
no subject
Date: 2021-06-01 04:00 pm (UTC)Говорите уж полностью - не к ассемблеру вообще, а к ассемблеру PDP-11. Архитектура которой с современными имеет довольно мало общего. Разумеется, на современные архитектуры С ложится просто отвратительно.
> У всех компиляторов Си, которые я видел, есть инструкция asm. Это, конечно, читерство. Но как по мне - не большее, чем unsafe в Rust.
только unsafe в Rust работает консистентно между платформами, а asm-вставки платформозависимы.
no subject
Date: 2021-05-31 11:20 am (UTC)Rust может интегрироваться в существующие ffi (плюс/минус критика Торвальдса). Если можно написать (условный) драйвер USB-звуковухи на Rust вместо C, то почему бы и нет? Ошибок будет меньше, интеграция с С и ядром скрыта в библиотеках и макросах.
no subject
Date: 2021-05-31 01:04 pm (UTC)no subject
Date: 2021-05-31 01:07 pm (UTC)Там была ругань на первую реализацию библиотеки. Всякие panic!, u128 и т.д.
no subject
Date: 2021-05-31 01:55 pm (UTC)P.S. Как по мне - Линуксовое ядро вобще не самое лучшее место, куда стоит стремиться. То, что "green threads" и "garbage collection" приходится реализовывать каждому языку внутри себя - явный признак того, что современные ядра (в целом, не только в Линуксе) занимаются какой-то хнёй. Это как если было - "вот вам драйвер блочного устройства, а файлуху уж делайте сами".
no subject
Date: 2021-05-31 02:25 pm (UTC)green threads внутри языка - это главная причина, почему они быстрее, чем у ОС.
Основная причина в том, что green threads используют тонкий стек (на стек кладётся/вынимается только то, что нужно для async-переключения). ОС не может делать предположения о формате вызова, используемых регистрах и т.д., так что ОС-поддерживаемые тредовые стеки больше и тяжелее. Я не помню откуда я это знаю, кажется, из презенташки про async'овый rust.
Если библиотека ядра (Rust-библиотека) будет в себя вбирать разницу между версиями ядра, то мы можем получить более-менее стабильное compile-time API, базирующееся на макросах и абстракциях (может быть, даже zero cost abstractions).
На самом деле, даже при полностью нестабильном интерфейсе, Rust приносит много здравого (за счёт разумных дефолтов, ownership, marker threads и т.д.) и упрощает процесс программирования (т.к. меньше вещей о которых нужно беспокоиться). Ну и всякая лингвистическая вкусность, типа выразительных типажей, match, lf let и т.д.
no subject
Date: 2021-05-31 03:27 pm (UTC)ОС может (должно) _назначить_ формат вызова, используемые регистры и всё остальное просто как API.
P.S. Как по мне - ponylang и то интереснее чем rust. Но это так, вкусовщина.
no subject
Date: 2021-05-31 06:02 pm (UTC)Как ОС может назначать формат вызова? Вызова чего? Если компилятор решил, что tail recursion - это jmp, то при чём тут ОС?
Ты с сисколами не путаешь?
no subject
Date: 2021-05-31 06:35 pm (UTC)убогийобычный async/await.Просто я человек испорченный Go/Erlang и привык что оно как минимум M:N и мне не надо руками расставлять yeld() (за исключением случаев, когдя я точно знаю что оно тут нужно и явно принесёт пользу).
И разговор про вызовы/API я вел именно со стороны зелёных тредов.
no subject
Date: 2021-06-01 02:15 pm (UTC)Я не понимаю о чём ты говоришь.
Зелёные треды "зелёные" потому, что у них тонкий стек. Стек тонкий, потому что компилятор точно знает, какие переменные сохранять, какие нет, и о чём идёт речь, вплоть до jmp без сохранения регистров.
Притаскивание сюда ОС (а, на самом деле, аппаратного переключения контекстов в процессоре) всё замедлит, потому что процесс должен быть достаточно устойчивым, чтобы ничего не ронять за пределами процесса вне зависимости от усилий процесса.
При чём тут эрланг - я вообще не понимаю. Эрланг - интерпретируемый язык, который исполняется интерпретатором байт-кодов (beam.smp). Сравнивать реальный код и волшебный мир в котором кто-то за тебя всё сделал - ну, можно.
Я вот в питоне могу сделать eval. А Rust - не могу. Какой плохой раст, да.