В ответ на замечание Линуса Торвальдса о том, что пример драйвера, прилагаемый к набору патчей с реализацией поддержки языка Rust для ядра Linux, бесполезен и не решает реальных задач, предложен вариант драйвера PL061 GPIO, переписанный на Rust. Особенностью драйвера является то, что его реализация практически построчно повторяет имеющийся драйвер GPIO на языке Си. Для разработчиков, желающих познакомиться с созданием драйверов на Rust, подготовлено построчное сравнение, позволяющее понять в какие конструкции на Rust преобразован код на Си...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55521
завертелось...
Как в машинке "Вятка-Автомат". Жизнь-то закрутится, завертится.
А чем растовый вариант драйвера лучше сишного? Без стёба?
> А чем растовый вариант драйвера лучше сишного? Без стёба?Тем что теплее. Эти гироскутерные смузихлебные вейперы, вместо того чтобы зайти на опеннет, почитать анонимных экспертусов-по-всему и устыдившись собственной слабости, снести раст и начать кодить на чистом си - зачем-то читали ядерную рассылку, где какие-то Греги и Линусы им намекнули взять в качестве примера драйвера что-то уже существующее. Ну и завертелось ...
Из основного я заметил использование правил ownership (проверяемых на этапе компиляции) при использовании lock-ов.
Что невозможно ни в C ни в С++.
> Что невозможно ни в C ни в С++.Вам знаком термин "машина Тьюринга"?
Вы пытались посмотреть, на чём написан транслятор Rust?..
(изучали ли в школе или вообще логику -- не спрашиваю)
>> Что невозможно ни в C ни в С++.
> Вам знаком термин "машина Тьюринга"?
> Вы пытались посмотреть, на чём написан транслятор Rust?..И? Без ограничения семантики - будет вам задача из области NP-hard (самое то для сферическо-вакуумной недетерминированной машины Тьюринга).
Вменяемое время проверки - именно то, во что все еще упираются ЯП с попытками формальной верификации и "глубоких" проверок.
Михаил, вы такими вопросами разрушаете радужный мир розовых пони растоманов! Они привыкли, что за них Гниль думает, самим нынче думать не в моде, некогда...
Не, не разрушает. Тьюринг свою машину возле них не парковал.
Вам знаком термин сложность алгоритма? Вы пытались написать проверку во всех местах, где это делает Rust-компилятор? Изучали ли в университете дискретную математику или вообще математику - не спрашиваю)
> Вам знаком термин "машина Тьюринга"?Хм, но ведь и CSS считается Тьюринг-полным языком, однако никтопочему-то там не пытается накостылять ownership.
Тем что большее количество UB отловлено на этапе компиляции. У кода появляются формальные гарантии
Вы вообще пример драйвера на смотрели?
Если говорить серьезно - ничем.За кодера прошел borrow checker, спаянный со парой слизанных из статических анализаторов фич, засунутых зачем-то в конпелятор. После чего бывший js-макак, он же гуру реакта, повелитель вуе, а ныне - разраб на русте, над которым завис красномордый дядька-начальник и под угрозой увольнения заставил напилить код, расправил крылья и ходит с лыбой от уха до уха, что теперь "супир бишапашно".
Я вот вообще понять не могу всех вот этих разговоров про автоматизированную безопасность, если внутри оно все равно использует те же неуправляемые указатели, но при этом реальный кодер в системных задачах (напомню, для которых он и разрабатывался) все равно вынужден лезть в unsafe.
Ах, да, забыл. Руст же полностью исключает dll hell^W^W UB. Запомните, дети, UB, это такие казуистические случаи, вроде
j = i++ + ++i;
которые при проектировке языка не принимались во внимания - тогда решались гораздо более важные задачи.
Простите экс вебмакаку, но что казуистического в примере?
Прибавится единичка к i до сложения, выполнится сложение и запишется в j, после прибавится 1 к i.
Где-то это не так?
> Прибавится единичка к i до сложения, выполнится сложение и запишется в j, после прибавится 1 к i.как откроете для себя (например) переопределение операторов, не будете столь категоричны.
Два неуча.В С не регламентирован порядок вычисления большинства операндов выражений (за исключением && и ||). Поэтому выражение i++ + ++i может быть вычислено как слева направо, так и справа налево, так еще и результат i++ может быть записан в i после вычисления всего выражения.
Аналогичная беда с выражением func(i++, i++);
На PDP тоже так было, великий гуру?
> На PDP тоже так было, великий гуру?Да. Например, можно глянуть http://mim.update.uu.se/manuals/layered/pdp11c3.pdf (PDP-11 C Guide to PDP-11 C)
Цитирую:
When using the increment and decrement operators, do not
depend on the order of evaluation of expressions. Consider
the following ambiguous expression:
k = x[j] + j++;Is the value of variable j in x[j] evaluated before or after the
increment occurs? Do not assume which expressions the
compiler will evaluate first. To avoid ambiguity, increment
the variable in a separate statement.
>> На PDP тоже так было, великий гуру?
> Да. Например, можно глянуть http://mim.update.uu.se/manuals/layered/pdp11c3.pdf (PDP-11
> C Guide to PDP-11 C)
> Цитирую:Убедил.
Откуда ж вы лезете, знатоки C++ по учебникам C лохматых 90-х?
А причем тут C++? Речь идет о C, который очень жестко стандартизован и, кстати, именно в 90-х, вернее, в 1998. Просто почитайте стандарт ISO/IEC 9899 и сравните с "учебниками лохматых 90-х". Ну и последний 2011-го года гляньте. А потом сравните с ISO/IEC 14882 -- откроете много удивительного.
Для ядра важно, как это делает конкретно gcc.
Для неуча:https://ru.wikipedia.org/wiki/%D0%A2%D0%...
Проблема в значительной мере устарела.
> Для неуча:Иногда лучше молчать и слыть болваном, чем заговорить и развеять все сомнения. (с)
Ты сам свою ссылку то читал? Там ровно то, что написал я.> Проблема в значительной мере устарела.
Что устарело? Операторы как вычислялись в неопределенном порядке, так и вычисляются. Параметры функций как вычислялись в неопределенном порядке, так и вычисляются.
Вообще ничего не изменилось за 30 лет, прикинь?
Полистай: https://en.cppreference.com/w/cpp/language/eval_order
Текст ты вряд ли поймешь, но комментарии к примерам типа:i = i++ + 2; // undefined behavior until C++17
возможно, заставят заподозрить, что в C++17 что-то изменилось.
А в целом, придирка к неопределенному порядку вычислений выражений сама по себе дурацкая донельзя: порядок вычислений не фиксировали в стандарте не потому, что нешмагли, а для того, чтобы не наступать на горло оптимизирующему компилятору, который может сгенерировать более эффективный код, изменив порядок вычислений.
Ага, в этом автомобиле нет ремней безопасности да и вообще нет кресел не потому, что "не шмогли", а потому, что лишний вес мешает разгоняться.
Вы, как мне кажется, забываете контекст, в каких условиях создавался и стандартизировался C, а в каких - Rust. То, что там машины были на порядки медленее, это пол беды, а то, что в комитет входили разные корпорации, производящие аппаратное обеспечение, которые тянули в свою сторону - это совсем беда. Думаю поэтому в стандарте C куча UB, которые кажутся странными - зартачилась какая-нибудь Sun, или там DEC - вот у нас в процессоре это сделано не так, как у всех остальных, давайте сделаем это UB, чтобы мы там по месту сами разбирались, как это делать. Тем более, что тогда в C, не так как сейчас в Rust - куча аппаратных контор писала свои компиляторы для C для своих аппаратных архитектур.
Дело даже не в древних архитектурах, как раз наоборот. Простой пример: вполне можно представить себе гипотетическую ситуацию, когда компилятор, обнаружив, что вычисление аргументов функции не требует синхронизации, на современном многоядерном процессоре запустит оное в параллельных потоках по числу аргументов. Порядок вычисления не определен в принципе? Да. Это ускорит выполнение? Да. Противоречит это стандарту? Нет, всё в порядке. Если вспомнить про транспьютерные архитектуры, то там это тем более актуально.
> Дело даже не в древних архитектурах, как раз наоборот. Простой пример: вполне
> можно представить себе гипотетическую ситуацию, когда компилятор, обнаружив, что вычисление
> аргументов функции не требует синхронизации, на современном многоядерном процессоре запустит
> оное в параллельных потоках по числу аргументов.И у этих параллельных потоков будет общий стек. Ага. Представил. =)
Как там у вас?
let a = 1
undefined
Так?
Нет, не так. Что спросить-то хотел?
Когда мы видим одну операцию присваивания, а реально их три - да, фигня получается.
Зато удобно автоинкрементную/автодекрементную индексацию как бы описывать.
> j = i++ + ++i;Если i было равно 1 до начала этой операции, то по-моему после нее будет i = 3 и j = 4
Постинкремент самая приоритетная операция за ней прединкремент, потом сложение, потом присвоение. Операция сложения работает слева направо, но выражение разбирается справа налево.Прединкремент сработает первым, поэтому i станет сразу равным двум. Потом сработает постинкремент и вернет 2. За ним сложение 2+2=4. Потомпосле завершения присвоения результата в j постинкремент увеличит i на 1. Я где-то ошибаюсь?
> Я где-то ошибаюсь?Везде в своем комментарии.
Немножечко лонгрид, но весь по делу, без воды и с цитатами стандарта (а еще и на русском) - https://habr.com/ru/post/216189/
Вы, батенька, чушь сморозили. UB — это и вполне тривиальное ```int a[] = {1,2}; int b = a[2]``` и вообще до черта всего, особенно в многопоточном коде. Про статические анализаторы, то же ерунда какая-то получилась: статические анализаторы по-разным эвристикам пытаются угадать очепятки, в то время как rust имеет систему типов, которая даёт вполне определённые гарантии, без всяких вероятностных допущений (конечно опуская вероятность ошибок в самом компиляторе). Unsafe, хоть и является вынужденным злом, но позволяет локализировать наиболее опасные места, а не размазывать их по всему коду. В реальном коде unsafe используется достаточно редко. Возможно, вам было бы комфортнее комментировать что-то, в чём вы разбираетесь. Но на всякий случай, вы можете почитать https://en.wikipedia.org/wiki/Undefined_behavior — в английской версии статьи есть много менее «казуистических» примеров неопределённого поведения. Спасибо за внимание.
> В реальном коде unsafe используется достаточно редко.Есть какая-нибудь статистика? а то походив по некоторым проектам крейтов Rust на github, увидел, что unsafe-ов используется довольно много, и даже начало складываться впечатление, что сделать что-либо нетривиальное без unsafe не очень получается.
```int a[] = {1,2}; int b = a[2]```Умышленно выходить за пределы выделенного массива. В чем смысл такого "тривиального" кода?
Можно выходить и неумышленно, к примеру аллоцировав буфер, и взяв смещение в нём из какого-нибудь заголовка кого-нибудь пакета не проверив...
Для начала, при попытке скомпилировать
int a[] = {1,2}; int b = a[2];g++, к примеру, вываливает кучу предупреждений о выходе за пределы массива, однако все же не считает это ошибкой. Банальный cppcheck находит эту ошибку на счет раз.
Во-вторых, на актуальном C++ такое пишется так:
array a = {1, 2}; auto b = a.at(2);и приводит к выбросу исключения с внятным сообщением о причине ошибки. Не уверен -- не обгоняй ;)
Он сделан не для того, чтобы быть лучше. Он создан для того, чтобы посмотреть на более реалистичный пример rust'а в ядре, нежели тот первый пример модуля, который ничего полезного не делал.Невозможно осмысленно создавать инструмент, не делая ничего этим инструментом. Можно спрашивать "зачем гонять ракетный двигатель на стенде, толкая им бетонную стену" -- действительно, зачем? Какой в этом смысл? Дык вот в этом примерно тот же смысл, какой был в написании этого драйвера.
Да, но это же не показательный вариант. Никаких фишек раста не использовано. Давайте ещё на паскале, го, свифте и чистом llvm asm будем модули писать и выставлять их? Причем на первых 3х это уже давно делают.
Сделай.
> Причем на первых 3х это уже давно делают.
> ...уже давно делают...
> Да, но это же не показательный вариант. Никаких фишек раста не использовано.Это что за фишки такие?
#[derive(Default)] -- это не такая фишка?
А Ref<T>, для работы с ref_count -- это не такая фишка? Между прочим в списке рассылки трындец обсуждение, ядрёным C программистам объясняют, как это может работать. Ты, кстати, тоже можешь почитать просветиться. Вопросы к коду задают серьёзные люди, а не анонимы опеннета, и отвечают серьёзно, а не как я тут.
impl amba::Driver for PL061Device
...
impl power::Operations for PL061Device
...
module_amba_driver! {
type: PL061Device,
name: b"pl061_gpio",
author: b"Wedson Almeida Filho",
license: b"GPL v2",
}Это не те фишки раста, которые ты ищешь? Если нет, то каких фишек ты ждёшь от раста? Чтобы он скомпилировал код вида "please, rustc, compile this line into a real kernel driver"?
> Давайте ещё на паскале, го, свифте и чистом llvm asm будем
> модули писать и выставлять их? Причем на первых 3х это уже
> давно делают.Пиши, тебе что кто-то запрещает?
Ух ты, в расте, оказывается, есть ref_count, который в С существует... дайте вспомнить сколько... да уже лет 30, наверное. Если не больше.Одна из библиотек, которые я давно использую:
https://github.com/Snaipe/libcsptrНаслаждайся:
struct log_file *open_log(const char *path) {
smart struct log_file *log = shared_ptr(struct log_file, {0}, close_log);
if (!log) // failure to allocate
return NULL; // nothing happens, destructor is not calledlog->fd = open(path, O_WRONLY | O_APPEND | O_CREAT, 0644);
if (log->fd == -1) // failure to open
return NULL; // log gets destroyed, file descriptor is not closed since fd == -1.return sref(log); // a new reference on log is returned, it does not get destoyed
}int main(void) {
smart struct log_file *log = open_log("/dev/null");
// ...
return 0; // file descriptor is closed, log is freed
}
---
они изобрели смарт-поинтеры, ухахахахахахахах.
> Ух ты, в расте, оказывается, есть ref_count, который в С существует... дайте
> вспомнить сколько... да уже лет 30, наверное. Если не больше.ref_count существовал до всех этих ваших C, не надо его недооценивать.
> Одна из библиотек, которые я давно использую:
> https://github.com/Snaipe/libcsptrИ чё?
> они изобрели смарт-поинтеры, ухахахахахахахах.
Демонический смех у тебя ничё так выходит, мне понравилось. Я б рекомендовал басов немного добавить, хотя в районе 3кГц очень неплохое присутствие. Но, и всё же, мне неясно, каким таким образом тебе удалось придти к выводу об изобретении смарт-поинтеров разработчиками rust?
> ref_count существовал до всех этих ваших C, не надо его недооценивать.Само собой существовал, еще в лиспе, например. А кто его недооценивает?
>> они изобрели смарт-поинтеры, ухахахахахахахах.
> и всё же, мне неясно, каким таким образом тебе удалось придти
> к выводу об изобретении смарт-поинтеров разработчиками rust?Цитирую тебя же:
>> Никаких фишек раста не использовано.
Ordu: > А Ref<T>, для работы с ref_count -- это не такая фишка?
Уникальная фишка раста - смарт поинтер, который минимум как 30 лет есть в С, который раст пытается заменить.
> Цитирую тебя же:
>>> Никаких фишек раста не использовано.
> Ordu: > А Ref<T>, для работы с ref_count -- это не такая
> фишка?Ты тред читал? Человек выше задаёт вопрос, почему никаких фишек раста не использовано. Я задаю ему вопросы о том, что он подразумевает под фишками раста. Привожу потенциальные примеры, которые могут быть примерами фишек раста, спрашиваю каких других фишек раста он ждал.
Не надо выдирать цитаты из контекста. Если ты знаешь каких фишек раста не хватает в том драйвере -- я с интересом тебя выслушаю. Доказывать же мне, что Ref<T> -- это фишка раста, или что это не фишка раста бессмысленно. Не, то есть, я б выслушал твоё мнение, потому что ты меня заинтриговал реально, я не могу понять считаешь ли ты Ref<T> фишкой раста, или ты считаешь его заурядностью из середины XX века, которая настолько общее место, что не стоит упоминания. Или может ещё что?
Я скажу то же самое другими словами, чтобы снизить вероятность непонимания: что мне интересно -- это то каких фишек раста не хватает в коде обсуждаемого драйвера. Мне интересно, что люди считают фишками раста, а что не считают. Не обязательно доказывать своё мнение, достаточно высказать его и может слегка намекнуть каким образом это мнение выстроено. Мне будет вполне достаточно.
Если же тебе интересно моё мнение, то сводить раст к фишкам -- плюс-минус бессмысленное занятие. Раст -- это комплексное решение, и любая фишка по отдельности не заслуживает внимания, интересно как они переплетаются во единое целое в коде.
>который в С существует..."To compile the library, GCC 4.6+ is needed."
Ох уж эти сказочки, ох уж эти сказочники ...
>>который в С существует...
> "To compile the library, GCC 4.6+ is needed."
> Ох уж эти сказочки, ох уж эти сказочники ...Растоманчик не видит разницу между конкретной сторонней библиотекой и всеми другими реализациями?
Впрочем, ничего удивительного. Не ты ли плакался там выше, что что не включено в STL, то у него не получается в с++ использовать?
Я писал, что конкретно эту библиотеку сейчас использую, и использую уже давно. Gcc 4.6 уже больше 10 лет.
>Растоманчик не видит разницу между конкретной сторонней библиотекой и всеми другими реализациями?Растоманчик видит разницу между С и GCC c кучей расширений, и даже деструкторами.
>Впрочем, ничего удивительного
Вот именно, очередной рассказыватель про прекрасную Сишку, пойман с поличным, что не сожет на чистой сишке сделать нормальные умные указатели. Только хаками и расширениями.
Зато так смело клеймит оппонентов, переходит на личности.
С тобой все понятно, лицеменый, туповатый дурачек. Разуй глаза, на чистом С ваще ничего толкового не написано. какой нормальный проект не возьми, везде торчат уши специфических расширений компилятора.
module_amba_driver! {
type: PL061Device,
name: b"pl061_gpio",
author: b"Wedson Almeida Filho",
license: b"GPL v2",
}Тоесть вот это это типа очень удобно и понятно? Ну ладно, яссно с вами ржавыми, как язык назовеш так и поплывет... или утонет.
> name: b"pl061_gpio",
> Тоесть вот это это типа очень удобно и понятно? Ну ладно, яссно
> с вами ржавыми, как язык назовеш так и поплывет... или утонет.Подожди, у них же аджайл, они щас еще такого наворотят...
Тут недавно добавили возможность идентификаторы писать в юникоде (боже, как я ржал, как я ржал... - эта "фишка" даже в боже прости 1С почти 20 лет назад была, чуть не в каждом языке есть - но растаманчики наконец подвезли и себе такую важную мегавозможность).
Так через два месяца они добавят специальный префикс _ для идентификаторов, которые в юникоде, но надо читать не в юникоде. И _& для тех, что в юникоде, но читаются не в юникоде, а надо в расширенном юникоде. А потом и letmut &hui __go__ для тех, которые в юникоде, но надо бы изменить для совместимости с С, который вызывать через ансейф и через два месяца вместо hui утвердят jui.
В общем все как всегда, плана нет, целостного видения нет, заплатка на заплатке и технический долг все похоронит.
>Он сделан не для того, чтобы быть лучше. Он создан для того, чтобы посмотреть на более реалистичный пример rust'а в ядреОсталось только написать остальные более реалистичные примеры: работу с VFS на примере реализации ФС, работу с потоками, сетью, памятью и т.д.
>>Он сделан не для того, чтобы быть лучше. Он создан для того, чтобы посмотреть на более реалистичный пример rust'а в ядре
> Осталось только написать остальные более реалистичные примеры: работу с VFS на примере
> реализации ФС, работу с потоками, сетью, памятью и т.д.У меня сложилось впечатление, что все эти направления не являются приоритетными. Приоритетом является написание драйверов устройств. Может я не прав, а даже если и прав, это не значит, что никто не займётся чем-нибудь из этого на общественных началах, но всё ж.
Растаманы пытались всё это сделать, но редох начал течь... Поэтому переключились на линух.
redox течёт? Ахаха, вот и цена этому продукту. Только вот уже несколько языков (D и nim точно) зашкварились, начав тащить к себе эту дрянь - "концепцию владения".
> redox течёт?Нет, в оригинале 4 года назад было:
> The Redox kernel does not have the structures in place to allow freeing memory.
> The userspace allocator can free, and then reuse, but anything allocated with sbrk from the kernel will be lost.просто местные экспертусы - не умеют в разработку и/или английский ...
> Ахаха, вот и цена мнению местных экспертусов
пофиксил.
А вот это действительно очень круто.
У-ха-ха-ха-ха-ха-ха.
Народ, зацените - для анонима построчно переписать код с С на с-подобный язык, это "круто"!Чувак, транспайлеры были придуманы более 30 лет назад.
Не тупи, это хороший прогресс, который поможет разобраться в написании драйверов, демонстрирует работу драйвера и в целом инфоповод
Инфоповод, согласен. Я три программерских чата заставил ржать аки лошади.
Да вы там гении самые настоящие, раз переписание драйвера на другой язык вызывает у вас приступы хохота. Наверно это очень простая задача для вас, киньте ссылку на какой-нибудь ваш "нормальный" проект на гитхабе, оценим. Постараемся не ржать.
Вот специально написанный для поржать драйвер: https://github.com/icestudent/ontl/blob/master/samples/zenad...Это не GPIO, он всего лишь ловил известные на тот момент ядрёные руткиты для Виндос (включая недетектируемые альтернативами). Написан как раз на "другом языке", на котором тогда нельзя было писать драйвера, да ещё и с использованием стандартной библиотеки, которая в ядре не работала. И Билл Гейтса никто джва года не спрашивал.
Не понял шутки, это же сипипишка, стандартная для шиндовс штука.
Далеко не стандартная, поскольку стандартная библиотека официально отсутствует. Тем более на момент публикации драйвера (2007-й год). Вот ситуация на тот момент http://www.osronline.com/article.cfm%5Earticle%3D4...
вообще-то именно так и делают гайды для тех кто хочет писать драйвер на расте но умеет только на си.
> для тех кто хочет писать драйвер на расте но умеет только на сиНе понимаю этих "тех". Умеешь С - пиши на нём.
Посмотрел бы я на тех людей, которые умеют писать драйверы на Си, но при этом хотят писать драйверы на Расте.
Тут это пруф отсутствия ошибок работы с памятью.
йобу дался чтоль?
Жалко, что не на С++, но вообще молодцы.
Ну так C++ - это почти C, только чуть удобнее, ООП (хотя концепция ООП под вопросом), больше возможностей, но всё такое же с ушами из 80-ых.
Любил C++ до перехода на Rust.
> почти C, только чуть удобнеекоротко про анонимов с опеннет
Бро, я пишу на C++ больше 10 лет.
Да, чуть удобнее C, но всё та же помойка.
скорее всего вы просто за 10 лет не научились писать на С++.
Скорее всего он так и пишет на С++98.
Думаю да ...
но даже там можно писать хорошо, так что проблема скорее всего в руках и голове )
Писать хорошо можно на чём угодно, только статистика говорит о том, что никто на это не способен.
Так что нужен компилятор, который перепроверит код на наличие тупости перед компиляцией.
Только раст на эту роль не претендует
Компилятор должен компилировать то, что дадут. А анализировать должен анализатор.Вы же не просите сантехника вам обед гоиовить?
На си-с-классами.
C++17 в среднем.Да даже в C++20 отовсюду видны уши C, нет модулей (стабильно во всех компиляторах), нет сети в стл, нет дефолт пакетного менеджера, нет дефолт системы сборки (cmake лучший, но синтаксис...), нет нормальной де/сериализации структур/классов без костылей, нет дефолт стайл гайдов (каждый лепит как придумал), да много чего нет.
Морально устаревшее нечто с 100% unsafe кодом, тонной UB, серией крэшей, которое уже ничего не спасет.Не говорю, что в Расте прям всё есть, но с вышеперечисленным всё ок. А это уже львиная для воркфлоу.
И падал у меня ровно один раз. Когда неправильно из C данные передал :)
В чем проблема, пишите на java и c#
Вот это контраргумент, уделал его, уничтожил.
Ну, начнем с того, что у него в предложении совершенно несвзанные вещи в качестве "аргументов"
Ну ты жжощ по детски
Какой отбордый бред. Смузихлеб, это все десятки лет есть в библиотеках!В мире есть тысячи гениальных программистов, которые пишут прекрасные библиотеки, вокруг которых формируются целые сообщества. Используй - нехочу.
> Не говорю, что в Расте прям всё есть, но с вышеперечисленным всё ок. А это уже львиная для воркфлоу.
"Аааааа, перекодировщик видео не включен в стандартную библиотеку, бидабида, я не умею поюзать гит и систему сборки, мне надо чтобы все через карго ставилось, ааааааааа, мама, у миня ни палучаится быть праграмистаааамммм!!!"
ffmpeg куда записывать будешь, гений, в стандартную библиотеку? А sqlite3 тоже? Развелось неучей, ска.
А хотя я понял, тебя пугает разнообразие? Ты не в состоянии все время учить новые вещи? Ну так иди сайты клепай, в программировании то что забыл?
Даже не представляю, как без этого все эти программисты на плюсах живут!А, наверное, библиотеки используют.
А, для смузихлёбов это сложно.
> дефолт пакетного менеджера
> дефолт системы сборки
> дефолт стайл гайдовДефолт случился в 1998 году. Делаем выводы.
главная проблема C++ - шаблоноёбство, из-за которого при наличии развёрнутой системы типов начинается фантастическое раздувание кода.
но в компилируемом языке иначе нельзя, либо делаем разные куски кода, либо придётся вводить условия, косвенные обращения и т.п.
С другой стороны, где золотая середина, сэкономить на лишнем обращении к памяти, или сэкономить на загрузке в кэш очередного куска кода.
ну так весь смысл в пресловутой безопасности раста, так что упоминание плюсов здесь просто неуместно
Не считаю это основным преимуществом Раста. Скорее как приятный бонус, да. Его сила в остальных возможностях.
Всегда убеждался, что люди, ругающие C++, его попросту не знают (или пользуют подпротухшие стандарты типа 98). Удиви меня, приведи обоснованную критику?
Никто его полностью не знает(кроме может пары человек), потому собсна Раст и появился. Он родился чтобы все UB превратить в панику или (что предпочтительнее) в ошибку компиляции
Таких лютых проблем с зависимостями, как в C++, нет больше нигде. Иногда быстрее написать собственную библиотеку, чем разобраться, как заставить собраться уже существующую. Выберите любой крупный проект на github, сделайте git clone, попробуйте собрать. С первого раза не соберётся никогда и ничего (а к ряду проектов написаны целые тома с инструкциями по сборке, это по-вашему нормально?).
C++ всё ещё не может в нормальную кросс-компиляцию - даже банально собирать код под винду, сидя на Linux - это адский ад (а что-нибудь типа OpenCV вы и вовсе никогда не соберёте кросс-компиляцией, только ставить контейнер с целевой осью и собирать в нём).
Пока весь мир на 98% состоял из винды на x86, это было норм. Но в мире, где уже есть пачка платформ и каждый год добавляются новые, кодить на этом будет разве только мазохист, потому что задолбаетесь зоопарк платформ поддерживать с вашей сишкой.
Ля, проблемы с зависимостями. Мы ещё посмотрим на лешаси Раста, лол
А можно пример такого проекта? А то я вполне спокойно собираю хромиум, например. Да и кучи других проектов тоже.> C++ всё ещё не может в нормальную кросс-компиляцию - даже банально собирать код под винду, сидя на Linux - это адский ад
Там выше уже было очень справедливо сказано: "Всегда убеждался, что люди, ругающие C++, его попросту не знают".
Почему я спокойно собираю свою либо под... секундочку... вот: (aarch64 armv5tel armv5te armv6hf armv6l armv7hf armv7l i686 mipselhf mipsel mipshf mips ppc64le ppc64 ppcle ppc). А это не хелловоролд, там несколько десятков тысяч строк, включая платформозависимые части для винды, ведроида, макоси?
c/c++ единственный (!) компилятор, который действительно умеет в кросскомпиляцию. И единственный, который соберет и запустит твой helloworld без каких-либо изменений на всем, на чем вообще можно что-то запускать.
> а что-нибудь типа OpenCV вы и вовсе никогда не соберёте кросс-компиляцией
А при чем тут C++ к системе сборки, которую выбрали ребята из opencv? cmake по твоему то же самое, что с++ компилятор? с++ то как раз прекрасно код opencv собирает.
Удивительно, у меня в системе процентов 15-20 софта собрано из исходников без единой проблемы. Что я делаю не так?
> Удивительно, у меня в системе процентов 15-20 софта собрано
> из исходников без единой проблемы. Что я делаю не так?Собираете их локально, а не в применяемый дистрибутив.
Но это перпендикулярно. :)PS: в альте пакеты поддерживать не так уж сложно, и по-русски подскажут (если не хватит документации на той же вики). Ну, мало ли ;-)
> С первого раза не соберётся никогда и ничегоОх уж мне этот юношеский максимализм. Особенно смешно как майнтейнеру, который этих плюсовых пакетов, в т.ч. и с нуля, понасобирал десятками.
Короче, неправда Ваша.
> C++ всё ещё не может в нормальную кросс-компиляцию [...] а что-нибудь
> типа OpenCV вы и вовсе никогда не соберёте кросс-компиляцией, только
> ставить контейнер с целевой осью и собирать в нём).Деточка, та же ОС Эльбрус собирается именно и исключительно кроссом; libopencv там есть.
> Но в мире, где уже есть пачка платформ и каждый год добавляются новые,
> кодить на этом будет разве только мазохист, потому что задолбаетесь
> зоопарк платформ поддерживать с вашей сишкой.Это именно про Rust. Опять же говорю как практик.
Тот редкий случай, когда Шигорин авторитетно заявляет и прав.
> сишкойплюсы от си не отличаете
Ну сходи в рассылку ядра и ответь на критику Линуса. Или комменты на опеннете - твой потолок?
В с++ инициализацию структур до сих пор тормозят на уровне 90х годов, что вынуждает в с++ проекте всё равно тянуть си файлы...
Вот, типичнейшая иллюстрация к тезису о дремучести критиканов C++. Человек застрял на уровне C и по нему судит о C++.
> Вот, типичнейшая иллюстрация к тезису о дремучести критиканов C++. Человек застрял на
> уровне C и по нему судит о C++.А я для встраиваемых устройств пишу.
А тонны готовых работающих библиотек на си, часто и на дремучем. К счастью не весь проект из подобного.
Что то пишут железячники в таком же древнем стиле, и хоть и получают за это по пальцам, но если сроки жмут, а оно работает...
Что то горе-партнеры пишут, а там ничего не поделаешь.
В итоге утверждают интерфейсы взаимодействия как есть.Но часто бывает задача скормить в новый проект готовое, и получить результат, а не переписывать, отлаживать, перепроверять.. Мы ж не Микрософт, чтоб заказчику глючные обновления вручать.
Да всякий несовместимый код можно обложить обёртками, что б включить в более свежий проект, но, лучше подобной радости по минимуму.
>Особенностью драйвера является то, что его реализация практически построчно повторяет имеющийся драйвер GPIO на языке СиТеперь осталось так же построчно переписать его обратно на Си, и тогда гарантии безопасности, проверенные формальным верификатором раста, перейдут на сишный код. И не надо никакого растового тулчейна для сборки ядра.
"практически построчно"
И внизу полотно комментов, разбирающий и исправляющий ошибки в раст варианте...
Не вижу реальной пользы в перестановке стульев.
Довольно наглядно сравнивать, почему синтаксис Растп делает код приятнее. Думаю, это основная цель.
О да. Сам то понял что ступил?
это у него очень тонкий юмор
Где ступил? Посмотри на код, у Раста и меньше, и красивее
Так женись на нём. Наверно заместили естественный объект красоты и малой ширины на искусственный.
Видать сам женат на C?
Они вероломно использовали одну хитрость, чтобы код на rust занимал меньше строк - не переносили скобки на новую строку :)
Вот чем go не зашёл - требование открывающую скобку фигачить в конце строки и никак иначе.
Не знаю не С, не Rust
Но код на С выглядит понятнее О_о
> Не знаю не С, не RustНе стесняйся, большей части местных "анти" комментаторов это никак не мешает.
>> Не знаю не С, не Rust
> Не стесняйся, большей части местных "анти" комментаторов
> это никак не мешает.s/"анти" //
Ну так это не предполагается для текущих драйверов (именно из-за ошибок при переписывании того что уже работает), а для якобы новых.
недолюбливаю я этот rust, внутреннее чутье подсказывает мне что GPIO будет теперь менее стабилен.
"Не читал, но осуждаю", да?
А тут к бабке не ходи понятно что проблем станет больше. Например со сборкой этих драйверов на новом тулчейне на разных платформах и версиях этого раста.
По сравнению с задачей "обеспечить сборку ядра clang-ом", которую решали лет 5 как минимум - какой-то раст - это вообще семечки.
> По сравнению с задачей "обеспечить сборку ядра clang-ом",
> которую решали лет 5 как минимум - какой-то раст - это вообще семечки.Ему про платформы -- он про семечки. Что за люди...
Почему просто не забанить всех растоманов? Все равно у них интеллект как у js разработчиков и они не смогут ничего путного сказать по определению
Ктобы сомневался что ничего полезного он итаки не сделают. Только вон построчно и могут заменить даже не включая мозга. Но это раст детка.
Ты забыл про бульон!
Теперь все растовички будут гордо тыкать ровно в 1 (один) пример драйвера на расте, который делает хоть что-то.
> On Thu, Jul 8, 2021 at 9:49 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> With my GPIO maintainer hat on I'd say a GPIO driver would be quite
> interesting to look at. We are two GPIO maintainers and Bartosz is...
> This is not to say I promise we will merge it or so, but I just generically
> like new approaches to old problems so I like this whole thing
> overall, despite being critical to some details....
т.е. "перепишите GPIO - мы поглядим, не обещаем что замержим"
переписали - анонимы опеннета опять недовольны.
> Ктобы сомневался что ничего полезного он итаки не сделают.Кто бы сомневался, что бугурт у анонимных экспертов опеннета будет в любом случае ...
обоже, только ослы с опеннета могут глубокий WIP с иными целями посчитать за что-то мегаважное и до* на пустом месте
прошу прощения, психануло)
Ну да, настолько бесполезная вещь что в переписке разрабы благодарят проделанную работу "Thanks a lot, this looks extremely helpful!" и задают разные вопросы и получают на них ответы.
Но кто они такие по сравнению с гуру опеннета...
В Rust меня отталкивает синтаксисом, но если его не учитывать, то плюсов при переходе можно набрать достаточно.Ох, если бы не вырвиглазный синтаксис Rust...
Синтаксис не проблема, тем более он не так сильно отличается от си. Плюс на том же лиспе люди как-то писали и выжили.
Не выжили
Выжили, родили сыновей, внуков и правнуков. И теперь передают правнукам искусство лиспа, оружие для более цивилизованного будущего века.
У lisp синтаксис элементарный, он весь на основе sexp, в отличии от мешанины в rust.
Проще чем у лиспа синтаксиса уже быть не может.
Просто не используйте дженерики и ссылки с временами жизни ;)
Просто не используйте раст.
А более нечего, если хочется скорости.
C малофункционален, C++ легаси и перегружен, а Кристал, Зиг и прочие малопопулярны.
> C малофункционаленЧто значит малофункционален? Как бы новость о том, что на расте драйвер для линукса написали. Вот этот самый линукс написан на С. На С можно написать абсолютно любой код.
Ветка же не связана с ядром, а абстрактна о языках.Да, на C можно сделать огромный проект, где в другом языке это эффективнее решит одна строчка (утрирую, но мысль ясна)
> Да, на C можно сделать огромный проект, где в другом языке...написанном на C...
> это эффективнее решит одна строчка (утрирую, но мысль ясна)
Перловики это давно уж пояснили практически, не грузитесь. :)
Ну дада... Давайте тогда и на yoptascript дрова писать :) Удобно же, одна строчка.
>На С можно написать абсолютно любой кодГромкое заявление, покажи верификатор.
>На С можно написать абсолютно любой код.А нужно работающий.
> C малофункционаленУ Вас устаревшие сведения
>C++ легаси и перегружен
Никто не заставляет использовать всё.
Даже в маломощных встраиваемых решениях, грамотное использование С++ повышает скорость, надёжность, и как ни странно сокращает объём кода.
Ps: отношение к Rust? Нейтральный игнор. Меня интересует переносимость кода как между различными ОС, так и работа без ОС, и прямо сейчас.
По началу есть такое чувство. Это примерно как с пробелами в питоне. Но синтаксис это лишь малая часть языка. Куда важнее сообщество вокруг, написанные библиотеки, тулинг и заложенные подходы. И надо признать что сам дизайн языка вокруг трейтов для почти всего(в том числе динамического диспатчинга) очень элегантен. После осознания этого все складывается и непривычными остаются только лайфтаймы. Но для них все остальные придуманные способы еще хуже.
Лайфтаймы в общем-то есть и в C/C++, но большинство погромистов на этих языках мелкие нюансы мало волнуют :)
Но в питоне не навязывают пробелы. Это в ниме и ямле навязывают.
Разбери немного, перестанет откладывает
У меня тоже раньше подобная "проблема" была, но потом приходит понимание, что там всё логично, красиво и к месту
Нет, там выбраны очень дурацкие символы и конструкции для выражения смысла.
Они не просто так "выбраны". Они были обсуждены сообществом - https://habr.com/ru/post/532660/
А что в нём вырвиглазного? Всё такое же как и везде, плюс пара своих специфических плюшек типа времени жизни. Как минимум куда приятнее современных плюсов, в которых реально непонятно что происходит.
жабоскриптер осуждает с++ и хвалит раст? Не удивлён
Естественно, раст больше на жеес\теес похож, чем плюсы ). Тупо на нём легче писать.
Каким местом он на них похож?
interface MyType {
myFunction(): void
}class MyClass implements MyType {
constructor() {
console.log("MyClass created")
}myFunction(): void {
console.log('myFunction called')
}
}const myCls = new MyClass();
myCls.myFunction();
и
trait MyTrait {
fn my_function(&self) -> ()
}struct MyStruct {}
impl MyStruct {
fn new() -> Self {
println!("MyStruct constructed")MyStruct{}
}
}impl MyTrait for MyStruct {
fn my_function(&self) -> () {
println("my_function called")
}
}let myStr = MyStruct::new()
myStr.my_function()
Разница вообще минимальна. Это не голанг писаный укурками из гулагеля, это язык, который хотя бы похож на 150 других языков.
Штош:1. Неявного конструктора в rs нет, new - просто соглашение. В js классах есть constructor.
2. self в методы явно передается, в js - неявный this (привет с++).
3. Объявленную через let в rs объект нельзя менять, обьявленный c помощью const объект в js - мутабельный.
3. Типы пишутся в конце? Дык, так много где.Короче, все что ты описал очень поверхностное и притянутое за уши сходство.
> 1. Неявного конструктора в rs нет, new - просто соглашение. В js классах есть constructor.Да, сделал так специально для "похожести". Можно и без new.
> 2. self в методы явно передается, в js - неявный this (привет с++).Тут согласен, но в Rust эта явность в плюс. В TypeScript тоже кстати можно this потипизировать, хотя это не нужно в 99% случаев
> 3. Объявленную через let в rs объект нельзя менять, обьявленный c помощью const объект в js - мутабельный.И опять же это плюс. В жеесе очень часто дебажить приходится именно как раз такие объекты. Object.freeze конечно помогает, но частично - его нужно рекурсивно на вложенные объекты применять.
> 4. Типы пишутся в конце? Дык, так много где.Это и хорошо же, не надо снова учить 139 синтаксис очередного сочинения на тему "как я писал свой яп на каникулах"
> Короче, все что ты описал очень поверхностное и притянутое за уши сходство.А я и обсуждаю чисто визуальное сходство. Что с тайпскрипта взять и начать писать на расте куда проще, чем на го с его синтаксисом упорыша (вопреки всем заявлением обратного). А все остальные детали уже в процессе тренируются, особенно если жс был не единственный твой язык.
> Да, сделал так специально для "похожести". Можно и без new.Где тут похожесть? В js нельзя классы без new звать. В rust вообще нет классов и конструкторов в понимании js, а есть просто структуры и связанные методы (как впрочем и в го). Для полноты реализуй наследование классов как в js (не интерфейсов, а именно классов).
> Тут согласен, но в Rust эта явность в плюс.
Мы не обсуждаем плюс это или нет. Мы обсуждаем похожесть. И это ни разу не похоже.
> И опять же это плюс. В жеесе очень часто дебажить приходится именно как раз такие объекты. Object.freeze конечно помогает, но частично - его нужно рекурсивно на вложенные объекты применять.
Анадлгично под видом "похожего" синтаксиса совершенно разный смысл.
> Это и хорошо же, не надо снова учить 139 синтаксис очередного сочинения на тему "как я писал свой яп на каникулах"
Эмм. Вообще распространено 2 вида: тип перед или после. Что тут учить еще?
> А я и обсуждаю чисто визуальное сходство. Что с тайпскрипта взять и начать писать на расте куда проще, чем на го с его синтаксисом упорыша (вопреки всем заявлением обратного). А все остальные детали уже в процессе тренируются, особенно если жс был не единственный твой язык.
Ну это же самообман.
А можно просто взять и обойтись без этой вашей ООПни.
Оно синтаксически сиподобное, или скорее сипипи подобное.
Что конечно ужасно, но видимо время забыть этот жуткий пережиток прошлого навязанный корпорастами ещё не пришло.
х.м. а такое.ok_or(Error::ENXIO)?
разве не вызывает панику
Нет
Панику может вызвать только явный unwrap без предварительной проверки.
Панику зрительных нервов?
А патч очищающий Linux от ржавчины уже есть?Надо сделать обязательно! По аналогии с южноамериканским deblob.
Rust это язык будущего! Быстро извенись перед всеми на каленях, только так тебя простит великий Rust! Сейчас же извенись! Сейчас же!
Я и go, systemd, dbus, polkit+JS, JIT, ... так же в своей системе видеть не желаю! Та что можешь мне соснуть, стоя на коленях.
SystemD это как Chromium, ты можешь его и не ставить, но будешь соcать раком за бортом прогресса!
пох это ты, мы тебя узнали
> SystemDЭто не прогресс, а регрес в безопасности.
Так переходи на вантуз. Разве что только JIT из всего списка останется.
У меня и GNU/Linux без этого списка работает.
Go вроде и ничего, но стандартная библиотека и сплайсы всё жедание осваивать его отбили. Переписал пару утилит дата-конвертеров с питона на го и больше не трогал
> Go вроде и ничегоДумал также, увидел это:
https://gitweb.gentoo.org/repo/gentoo.git/tree/net-p2p/go-ip...
и сразу изменил свое мнение.
Ужас! Даже добавить нечего.
При чем тут Го? Не нравятся импорты, можно писать самому на чём угодно.
> но стандартная библиотека всё жедание осваивать его отбилиЧто с ней не так?
пока, к счастью, не от чего очищать
Только ослы будут очищать a shit of C от прекрасного.
Без Си ты бы даже не смог написать это сообщение. У тебя в смартфоне и компе всё провоняло, получается.
> Без Си ты бы даже не смог написать это сообщение.Мог, мог. Колибря, Редокс, современные браузеры на плюсах? Не, не слышал!
Деточка, слова firmware или там bootloader хоть что-то говорят?PS: очередная перепевка басни "Свинья и Дуб", ага.
По поводу firmware можете посмотреть на oreboot, например.
>> Колибря
> ... или там bootloader хоть что-то говорят?Похоже, что мне - больше чем вам, "дяденька". Работающих агрузчиков для x86 на чистом асме я видел (и писал). А вот наоборот, на хваленой "чистой сишечке", что-то туговато с ними.
Так что кто тут занимается перепевом басни
> PS: очередная перепевка басни "Свинья и Дуб", ага.еще большой вопрос.
А хоть Firmware-то на C пишут, или там может какие-то операционные системы?
> А хоть Firmware-то на C пишут, или там может какие-то операционные системы?Ну вы можете поискать и кинуть ссылок на фирмварь "на чистой сишкечке, совсем без асма" для устройств, с которых можно более-менее удобно запостить комментарий на опеннет, кто ж вам мешает-то?
> А хоть Firmware-то на C пишут, или там может какие-то операционные системы?По-всякому бывает. Хотя, называть их "операционными системами" не совсем корректно --- планировщик и разделение ресурсов там, как правило, вырожденные.
Не обращайте внимания. Шигорин сильно не любит Rust, в силу того, что Rust ВНЕЗАПНО не так уж и безнадёжен, как хотелось бы ему пропагандировать, вот и приходится с ним сталкиваться в своих линуксах и при взаимодействии с Российскими процами, где через C-транспиляцию так просто не извертеться, а АСМ там настолько страшен, что разрабы сами предпочитают избегать его насколько возможно.
Это называется назло маме шапку не надену и отморожу уши. Вот и всё. Великовозрастные юноши как правило считают себя умнее своих родителей, и гордыня выше головы.
> Это называется назло маме шапку не надену и отморожу уши. Вот и
> всё. Великовозрастные юноши как правило считают себя умнее своих родителей, и
> гордыня выше головы.А по существу сказать есть что, балабол? Можешь начать с перечисления "сишных браузеров", работающих в сорвеменном гуглне^W интернете.
Есть https://lexborisov.github.io/myhtml, не знаю, есть ли на базе его браузеры. Но вот Вы, если данный сайт посещаете с Linux/BSD/Android, то явно пользуетесь ОС написанной на C, и наверное, не смогли-бы без неё написать своё ценное мнение.
>> с перечисления "сишных браузеров", работающих в сорвеменном гуглне^W интернете.
> Есть https://lexborisov.github.io/myhtml, не знаю, есть ли на базе его браузеры.Угу, "и вот так - у вас все!" (с)
Сразу бы ссылку на линкс дали, что ли.Я кстати, в курсе его существования и даже какое-то время отслеживал. Но последний коммит "4f98bb1 Nov 28, 2020" немного намекает. Впрочем, без полноценного JS движка никакой работы "в сорвеменном гуглне^W интернете" не будет.
>>> Без Си ты бы даже не смог написать это сообщение
>> Перечисление пары ОС не на си, намек на ЯП современных браузеров
> ... если данный сайт посещаете с Linux/BSD/Android, то явно пользуетесь ОС написанной на C, и наверное, не смогли-бы без неё написать своё ценное мнение.Скилл Кэпа вы прокачали неплохо, осталось прокачать скилл чтения.
> Я кстати, в курсе его существования и даже какое-то время отслеживал. Но последний коммит
> "4f98bb1 Nov 28, 2020" немного намекает. Впрочем, без полноценного JS движка никакой работы "в
> сорвеменном гуглне^W интернете" не будет.Т.е. Вы хотите сказать, что за прошедшие пол-года в современном интернете всё поменялось? уже там, я не знаю, HTML 6 вышел, не совместимый с HTML 5, или ещё что случилось?
> Скилл Кэпа вы прокачали неплохо, осталось прокачать скилл чтения.
Исходное сообщение было:
> Без Си ты бы даже не смог написать это сообщение. У тебя в смартфоне и компе всё провоняло,
> получается.Или Вы уже научились запускать браузер вне каких-либо ОС?
>> Я кстати, в курсе его существования и даже какое-то время отслеживал. Но последний коммит
>> "4f98bb1 Nov 28, 2020" немного намекает. Впрочем, без полноценного JS движка никакой работы "в
>> сорвеменном гуглне^W интернете" не будет.
> Т.е. Вы хотите сказать, что за прошедшие пол-года в современном интернете всё
> поменялось? уже там, я не знаю, HTML 6 вышел, не совместимый
> с HTML 5, или ещё что случилось?Т.е. я хочу скзать "где браузер, Карл!". Ну и о JS там было "вдогонку".
>> Скилл Кэпа вы прокачали неплохо, осталось прокачать скилл чтения.
> Исходное сообщение было:
>> Без Си ты бы даже не смог написать это сообщение. У тебя в смартфоне и компе всё провоняло,
>> получается.
> Или Вы уже научились запускать браузер вне каких-либо ОС?Если вы отвечали на исходное сообщение, то ошиблись веткой. Если на мое - то неплохо бы учитывать ответы и контекст (заодно не выдирая из него цитаты), а не заниматься подменой понятий вида
>> даже не смог написать это сообщение
> если данный сайт посещаете с Linux/BSD/Android, то явно пользуетесь ОС написанной на C, и наверное, не смогли-бы без неё написать своё ценное мнение.
> Или Вы уже научились запускать браузер вне каких-либо ОС?
> Т.е. я хочу скзать "где браузер, Карл!". Ну и о JS там
> было "вдогонку".Извиняюсь за вопрос на вопрос, но "где используемый ширнармассами браузер, на чём-то кроме C++, Карл", да и то там будут, скорее всего, запчасти из других языков.
JS-ов тоже куча есть, как минимум от проекта nginx (http://nginx.org/ru/docs/njs/index.html), от Фабриса Беллара (https://bellard.org/quickjs/).> Если вы отвечали на исходное сообщение, то ошиблись веткой. Если на мое
> - то неплохо бы учитывать ответы и контекст (заодно не выдирая
> из него цитаты), а не заниматься подменой понятий вида
>>> даже не смог написать это сообщение
>> если данный сайт посещаете с Linux/BSD/Android, то явно пользуетесь ОС написанной на C, и наверное, не смогли-бы без неё написать своё ценное мнение.
>> Или Вы уже научились запускать браузер вне каких-либо ОС?Не могли-бы Вы тогда прояснить свою мысль - что Вы хотите доказать?
> Колибря, Редокс, современные браузеры на плюсах?А где можно увидеть "современные браузеры" на "Колибря, Редокс"?
>> Колибря, Редокс, современные браузеры на плюсах?
> А где можно увидеть "современные браузеры" на "Колибря, Редокс"?А где можно увидеть "современные браузеры" на Си?
> А где можно увидеть "современные браузеры" на Си?Я не предлагал браузер на C. Я только хотел увидеть "современный браузер на плюсах" работающий в Колибри и/или Редокс.
>> А где можно увидеть "современные браузеры" на Си?
> Я не предлагал браузер на C. Я только хотел увидеть "современный браузер
> на плюсах" работающий в Колибри и/или Редокс.Т.е. по существу возразить нечего и ты сделал вид, что не заметил запятую в перечислении и прикопатья к формулировке?
Для опеннета современный бразуер(ный движок) не нужен, если что. Что не отменяет факта отсутствия таких движков на сишечке.
Есть на C https://lexborisov.github.io/myhtml/. А так - и на других языках нету, кроме C++, и на Rust тоже (там писали Servo, по потом всех разработчиков Мозилла выгнала).
>> Для опеннета современный бразуер(ный движок) не нужен, если что. Что не отменяет факта отсутствия таких движков на сишечке.
> Есть на C https://lexborisov.github.io/myhtml/./0
> (там писали Servo, по потом всех разработчиков Мозилла выгнала).
Уровень "познаний" опеннета:
https://www.opennet.dev/opennews/art.shtml?num=45385
> Проект Mozilla представил Quantum, комбинированный браузерный движок для Firefox
> 28.10.2016 13:49
> Разработчики Mozilla представили проект Quantum, в рамках которого для Firefox началась разработка браузерного движка нового поколения, сочетающего проверенные временем наработки движка Gecko с новыми возможностями по обеспечению многопоточной обработки данных, предоставляемые языком Rust. В частности, в рамках проекта в Gecko будут перенесены некоторые компоненты из движка Servo,---
> 25.07.2017 20:49
> В Firefox добавлен CSS-движок Stylo, написанный на языке Rust---
> Выпуск Firefox 57 с многопоточным CSS-движком и новым оформлением
> 14.11.2017 17:33
> и новый web-движок Quantum, комбинирующий проверенные временем компоненты движка Gecko с новыми возможностями по обеспечению многопоточной обработки данных, предоставляемые языком Rust и движком Servo.-
> 19.07.2018 20:50
> В ночные сборки Firefox, которые лягут в основу выпуска Firefox 63, в качестве временного эксперимента интегрирована система композитинга Servo WebRender
> Из ожидающих внедрения инициатив проекта Quantum также можно отметить Quantum DOM, который обеспечит распараллеливание операций с DOM (Document Object Model).
>
>>> Для опеннета современный бразуер(ный движок) не нужен, если что. Что не отменяет факта отсутствия таких движков на сишечке.
>> Есть на C https://lexborisov.github.io/myhtml/.
> /0Поясните, пожалуйста, чем он вдруг не подошел?
>[оверквотинг удален]
> https://www.opennet.dev/opennews/art.shtml?num=45385
>> Проект Mozilla представил Quantum, комбинированный браузерный движок для Firefox
>> 28.10.2016 13:49
>> В Firefox добавлен CSS-движок Stylo, написанный на языке Rust
>> 25.07.2017 20:49
>> Выпуск Firefox 57 с многопоточным CSS-движком и новым оформлением
>> 14.11.2017 17:33
>> и новый web-движок Quantum, комбинирующий проверенные временем компоненты движка Gecko
>> 19.07.2018 20:50
>> В ночные сборки Firefox, которые лягут в основу выпуска Firefox 63, в качестве временного эксперимента интегрирована система композитинга Servo WebRenderЧто-же с Rust-ом так всё хорошо, что его кода, судя по https://www.openhub.net/p/firefox/analyses/latest/languages_... меньше, чем C. Так-что выходит, пока на Rust-е то и браузеров нет, точнее они есть, но пока они даже больше C-шные, чем Rust-овые.
Надо весь Linux переписать на Rust!
построчно!!!
Ну раз надо, значит делай. Или у тебя руки способны писать только комментарии в интернете?
>Или у тебя руки способны писать только комментарии в интернете?На некоторых грязных сайтах есть видео отрицающее это
А Rust надо переписать на Linux!
Не понятно, что разработчикам, продвигающим Rust, мешает форкнуть ядро и построчно переписать его. И вообще может кто-то из них сможет транслятор сделать из C в Rust?
Это на данном этапе не нужно, у них же нет тысяч разработчиков для переписывания миллионов строк кода, а то кол-во "хакерских оптимизаций", которое позволил всунуть Си, никаким транслятором не переведешь в другие языки. Большинство ошибок в ядре в драйверах. Достаточно всунуть в ядро возможность писАть на относительно безопасном и быстром языке - и заинтересованные производители железок со временем сами захотят писАть на нем драйвера.
А кто производителей железок заставляет на C писать непременно с хакирскими трюками? Пусть пишут, если им нравится, в соотвествии с MISRA.
Внезапно работать всем вместе на одном проекте -- выгоднее, чем когда каждый пилит свой проект. Сотрудничество вместо конкуренции.
Надо понимать какие цели у лидера проекта. Например, можно было бы вместе с немцами сотрудничать в годы ВОВ - это выгодно по вашему?
Nim > Rust
Запомните этот твит!
Ним вообще зеро, даже без компилятора и никогда не выстрелит.
Запомните этот твит!
Если речь идет о трансляции в машинный код, так для это Nim пользует компилятор C/C++.
Зачем изобретать Nim'у велосипеды и привязка к конкретной платформе?
2 опечатки в слове Zig
Как применить операцию сравнения к нечисловому множеству?
Не очень понятен вопрос
- Что подразумевается под "операцией сравнения"?
- Что подразумевается под "нечисловое множество"?Если принять, что операция сравнения это, например, проверка вложенности,
а нечисловое множесто (фундаментально компьютеры оперируют только числами), это просто
упорядоченые "атомные" литералы, то так
https://play.nim-lang.org/#ix=3tFNтак же см.
https://nim-by-example.github.io/bitsets/
Думаю он спрашивает про то, как применить сравнение для языков.
> Думаю он спрашивает про то, как применить сравнение для языков.Тогда, как обычно это делают, можно сравнить функционал, удобство использования...
Т.е. они взяли изначально нормально работающий и проверенный драйвер. Сделали замену сишных вызовав прекрасными растоструктурами и такие "во, смотрите, мы драйвер написали"Ай да молодцы. Ай да квалификация. Вот это прорыв. Вот это уровень образования. Вот это я понимаю.
Это даже не двойка.....
Учитесь люди как надо драйвера писать.
> Т.е. они взяли изначально нормально работающий и проверенный драйвер. Сделали замену сишных
> вызовав прекрасными растоструктурами и такие "во, смотрите, мы драйвер написали"Т.е они взяли и прочитали сообщения Грега с мейнтейнером GPIO
https://lore.kernel.org/ksummit/YOdJLYmUkoMyszO7@kroah.com/
> From: Greg KH <greg@kroah.com>
> And really, there is no need to dig through a huge spec, try porting an existing C driver will be much easier.
> From: Linus Walleij <linus.walleij@linaro.org>
> With my GPIO maintainer hat on I'd say a GPIO driver would be quiteinteresting to look at.
а надо было анонимов опеннета читать!> Это даже не двойка.....
> Учитесь люди как надо правильно ...не читать ссылки и подробности, а сразу высказывать Особо Ценное Анонимное Менение, ага.
А ты хоть так сможешь сделать?Очевидно, что там иные цели, а не просто сделать драйвер)
Прикинь а. У меня нет проблем ни с памятью ни с логикой.
Что ты тогда на опеннете делаешь?
> Прикинь а.Верим-верим.
> Сделали замену [b\сишных вызовав[/b] прекрасными растоструктурами...
> У меня нет проблем ни с памятью ни с логикой.Только с чтением/аглицким, да.
Ну и еще - с азами и прочими "мелочами".А так-то да, тут каждый второй аноним - как минимум, Лев Толстой и заслуженный разработчик ядра. По крайней мере, на словах.
Эммм, новость мы читаем ж@пой?
Это пример. Пример написания драйвера на расте. Для этого и взят простой драйвер, для этого и сделано построчное сравнение с сишным.
Ты понимаешь как пишется софт?! Проекция в чужой синтаксис не делает программу родной и показать оно не может ничего, кроме говнокодинга
Что, кстати, многое говорит о квалификации этих программистов
А ты понимаешь, как пишутся модули ядра? В этом примере половина кода - привязка к ядерным api, что в растовском, что в сишном случае, а вторая половина простая как табуретка, опять же в обоих случаях.
Понимаю, но, что тогда это должно продемонстрировать, что нужно писать на си?
Это сделано
> Для разработчиков, желающих познакомиться с созданием драйверов на RustНе твое это.
Офигенная аргументация, ага, так держать
> подготовлено построчное сравнение, позволяющее понять в какие конструкции на Rust преобразован код на Си.Превосходно!
Наконец-то можно будет код на Rust переписать на Си!
Зачем? На нём что-то толковое разве сделали? Чтобы не текло и безапастноне падало
ну да, ну да. а в curl например его от нехерделать завезли видимо. и всякие хоть и хипстерские, но рвущие в бенчах ripgrep'ы и прочие cli-утилиты для всяких cloudflare и гугл
Рипгреп-то по функциональности простой греп догнал или всё также уровня хелловорлда? Специально под тесты-то заточить это одно, а дальше всё.
> Рипгреп-то по функциональности простой греп догнал или всё также уровня хелловорлда?А че так скромно, без конкретики и "по пунктам"? Не стесняйтесь!
> Специально под тесты-то заточить это одно, а дальше всё.Довольно неоригинальная отмазка.
На C? Да в общем-то не особо. Всё так же течет и падает. Есть крупные проекты вроде Линукса, где титаническими усилиями заставляют его работать хоть как-то, но получается не всегда.
В отличие от Раста, который не течет и не падает.
Прежде чем писать, что раз подумай, а потом подумай ещё 1000 раз!
Ну да, у растоманов и с логикой смотрю плохо.
Не, сишечка не падает. Просто бажина из-за переполнения буфера 15 лет живет в ядре и позволяет получить рут. А надежно и ничего не падает.
Не течёт и не падает то, чего нет.
А на Rust что-то просто толковое сделали?
Полистал код драйвера. Я не знаю кому удобнее читать/писать на такой смеси крестов с явой и прочей эзотерикой.Уж лучше чистый Си.
может лучше на грязном Си ?
Ща блевану. Притащить ржавого чтобы написать все то же самое, что уже есть на Си и работает прекрасно. ГПИО гребаный это всего навсего сраный COM порт с уартом и проститутками.
Конечно они написали тоже самое и взяли самый простой пример. Надо же было пожалеть старперов с напрочь закостенелой способностью разбираться в чем-то новом.
Пожалеть? Кто-то просил? Этих сумасшедших надо в поликлинику сдать для опытов. Если можно что-то написать на джаве, бейсике, расте, то это не значит что это надо тащить в ядро. Дебилы блин отборные. Есть Си и есть С++, а остальное пусть дауны на Ada, D, Rust используют. А то ща еще одни даунито прибегут и заявят что ассемблерные вставки ненужны, потому что их только старперы используют, ведь есть же божественный ска раст.
Конкретный код про выделение памяти с обработкой ошибки выделения на си занимает 2 строки (выделил, сверил указатель с null), на Rust это какая-то дикость
```
Ref::try_new_and_init(
device::Data::new(
PL061Registrations {
gpio_chip: gpio::ChipRegistration::default(),
},
PL061Resources {
base: IoMem::try_new(res)?,
parent_irq: irq,
},
// SAFETY: We call `irqsave_spinlock_init` below.
unsafe { IrqDisableSpinLock::new(PL061Data::default()) },
),
|mut data| {
// SAFETY: General part of the data is pinned when `data` is.
let gen = unsafe { data.as_mut().map_unchecked_mut(|d| d.deref_mut()) };
kernel::irqdisable_spinlock_init!(gen, "PL061::General");
},
)?;
```По сути и там и там это про управление памятью, только в си оно прямое, а в Rust тебе приходится делать то же самое, но косвенными путями, с болью и мучениями. Читать такой код и понимать, что конкретно он будет делать с памятью - очень сложно, это задача из разряда "а если бы вот ты знал особенности компилятора Rust, ты бы написал лямбда-функцию и итератор вместо простого new с присваиванием, и производительность бы выросла в 1000 раз". Нужна предсказуемость, пожалуйста.
Тут код в основном про безопасную инициализацию, а не про выделение памяти. лямбды иногда пихают для ленивой инициализации, но это общий для многих языков паттерн
Код-то в основном про инициализацию, но именно этот неделимый на более мелкие куски блок кода, над результатом которого выполняется оператор ?, теоретически способен вернуть какую-нибудь информацию об ошибке при аллокации.
Ну вообще вот это написано чисто из-за ядерной специфики.
Отлавливать ошибки аллокации было бы неплохо и в userspace-приложениях, тем более раз уж Rust пытается быть безопасным как в рекламе, а не безопасным от двух багов - use-after-free и double-free
> Отлавливать ошибки аллокации было бы неплохо и в userspace-приложениях, тем более раз
> уж Rust пытается быть безопасным как в рекламе, а не безопасным
> от двух багов - use-after-free и double-freeУ тебя есть use-case для отлова ошибок аллокации в userspace-приложениях? По-моему опыту в linux'е без oom-killer'а, лишь бы сдохли все побыстрее, кто выжрал столько памяти. Если когда они продерутся через всё это и дождутся NULL в качестве результата malloc, ещё вот не хватало, чтобы они пытались бы провести какой-то рекавери после ошибки. Пускай ДОХНУТ суки.
Ну например если бы программа или игрушка при вылете написала, что она вылетела из-за недостатка вот такого конкретного количества оперативной памяти, а не просто паникнула с кашей в консоль, это было бы очень полезно знать конечному пользователю. Сразу ясно, что тут нужно освободить или докупить памяти, а не ругаться на разработчиков со словами "ваша штука сама вылетает без какой-либо вменяемой информации" и удалять эту программную гадость, неспособную даже объяснить, что конкретно ей не понравилось, в чем ошибка.
> Ну например если бы программа или игрушка при вылете написала, что она
> вылетела из-за недостатка вот такого конкретного количества оперативной памяти, а не
> просто паникнула с кашей в консоль, это было бы очень полезно
> знать конечному пользователю.Такого количества это какого? Программа выделяет себе хрена в ступе арену, чтобы потом не кучей общего назначения пользоваться, а чтоб побырому оттуда объекты фиксированного размера выделять? Ну дык ты эту арену всё равно будешь писать ручками, запрашивая память не у кучи, а через mmap. Вот там и обработаешь все ошибки. Вернёшь Result если хочется няшно, или прям оттуда сделаешь panic!("You have not enough memory, moron! Go buy some more of it!").
Или программа выделяет понемногу из кучи, и потом память кончается? Это закончится тем, что у тебя вся система подвиснет, и ты будешь ругаться на разработчиков, что они тебе систему повесили. Если у тебя хватит терпения дождаться, то может ты в консоли что-то и увидишь, а скорее не хватит и ты в PowerOff тыкнешь на системном блоке.
Не, я так думаю, стандартный интерфейс к памяти -- это не для игроманства, игре нужен ограниченный real-time, который может быть разломан swap'ом легко. Надо опрашивать систему на предмет того, сколько есть свободной памяти, неплохо было бы защитить страницы от свопирования (я не знаю, если честно, возможно ли это в linux без рутовских прав?), бла-бла-бла... Не, стандартная куча не для тебя. Тебе надо свой alloc писать -- реализацию кучи можно взять на стороне, но вот проверку доступной памяти, предвыделение её, прибивание гвоздями к физической раме -- это стандартная куча не умеет. Надо вручную запиливать эти возможности в кучу. Можно прям в std'шную реализацию. Можно в какую ещё по вкусу. Можно вообще выкинуть слово куча из лексикона, и заменить аренами и памятью на стеке.
вышеописанная ошибка при выделении памяти для арены не теряет свою актуальностьпамять можно выделять как угодно, это же си, делай как тебе надо!
своп кстати можно отключить, если при его использовании всё так виснет грустно.
проверка доступной памяти? Мне не нужны приложения, которые выделяют память исходя из доступной, они должны выделять сколько им реально понадобится и в идеале ни битом больше. И освобождать что не используется.
> вышеописанная ошибка при выделении памяти для арены не теряет свою актуальностьВозьми такой крейт с реализацией арены, который будет об этих ошибках сообщать. Проблем-то. Или напиши свой, сообщающий.
> своп кстати можно отключить, если при его использовании всё так виснет грустно.
Как твоя замечательная игра сделает это без прав рута?
> проверка доступной памяти? Мне не нужны приложения, которые выделяют память исходя из
> доступной, они должны выделять сколько им реально понадобится и в идеале
> ни битом больше. И освобождать что не используется.Слушай, ты уж определить, что тебе нужно. Тебе хочется, чтобы программа давала диагноз твоей системе? Чтобы дать диагноз, надо собрать телеметрию.
> неплохо было бы защитить страницы от свопирования (я не знаю, если честно, возможно ли это в linux без рутовских прав?)man mlock
Если я правильно понял - пишут, что для непривилегированных процессов есть soft limit RLIMIT_MEMLOCK.
В линуксе даже кеш фс не могут от свопа защитить...
А зачем? Когда юзеры добровольно организуют своп в zRAM))
> А зачем? Когда юзеры добровольно организуют своп в zRAM))Тем более за этим.
Но да, одно изобретение линукса чудесатее другого.
> Если когда они продерутся через всё это и дождутся NULL
> в качестве результата mallocЭто вообще когда при overcommit-то?
У Си с его malloc и проверкой на NULL (ага, NULL, а не null) есть маленькая проблемка. Веделенная память содержит "мусор", т.е. неизвестный набор байт и язык Си не проверит за программиста, не забыл ли тот корректно инициализировать все поля. Без такой инициализации в дальнейшем может прилететь.Громоздкость инициализации в Rust гарантирует что в структуре Data будут только корректные значения, плюс дальше компилятор не даст ни лажу туда записать, ни время жизни нарушить.
Что-то типа https://ru.scribd.com/document/403214728/Modern-Memory-Safet..., только бесплатно
Ваша ссылка вывалила мне кучу рекламы и предложила купить какие-то курсы, а если не куплю - то и читать мне она ничего не даст. Что касается инициализации - берешь структуру (в си есть структуры) и инициализируешь, это ведь делается одинаково что в Rust, что в Си. Можно даже свой конструктор написать, где объединяется выделение памяти и инициализация, получится всё по RAII. А если надо - пишешь геттеры и сеттеры, при правильной работе с типами в Си компилятор Си тоже не даст записать в структуру мусор. Все-таки в си есть свобода - можно писать так и эдак, можно работать с типами и подсказками компилятора, а можно сказать компилятору что разберешься без него и все переменные сделать void* . В Расте же ты гвоздями прибит к его способу работы с ресурсами и данными, это может быть где-то удобно, но не везде, например что если я хочу использовать четыре разных аллокатора памяти? Или написать свой собственный? А вот как в расте написать свой Vec с ручной работой с памятью через unsafe, например хочу чтобы сначала заполнялись четные ячейки массива, а потом нечетные, или чтобы в Vec были куски, при доступе к которым вываливалась бы ошибка (в ядре такое есть, чтобы выявлять доступ куда-то не туда, т.е. баги при работе с памятью)? На Rust я такое не смогу, а на си - достаточно просто. А Zig так вообще практически из коробки дает возможность гибкой работы с аллокаторами (функции принимают аллокатор как аргумент).
для склеротиков есть calloc
calloc не инициализирует, а обнуляет. Разницу объяснять надо?
Вообще-то по стандарту именно "The space is initialized to all bits zero". Реально же есть интересные нюансы https://vorpus.org/blog/why-does-calloc-exist/
memset(ptr, 0, sizeof(...));
это ясен пень, и такое забывать нельзя.
malloc + memset != calloc см. хороший разбор на линке выше.
К сожалению там почти всё "заблюрено". Единственный плюс у calloc() относительно malloc(), это защита от переполнения при умножении числа элементов на размер элемента.
Там еще разные скорости и разные внутренние политики. Позвольте еще раз привести https://vorpus.org/blog/why-does-calloc-exist/ - последний параграф как раз об этом.
В микроконтроллерах STM32 такого нет. Как и zeromem.
calloc есть оказывается, попутал.
Для желающих поугорать:Оригинал (С): https://code.woboq.org/linux/linux/drivers/gpio/gpio-pl061.c...
Ремастер (rust): https://raw.githubusercontent.com/wedsonaf/linux/pl061/drive...
Спасибо, угораю с убогого оригинала
Т.е. ты оценил его по факту написания на Rust, т.к. функционал то один и тот же! Придумали для выпедрёжа этот синтаксис, а не для решения задач? Просто субкультура, какими были панки, готы, эмо... где они сейчас. Очередная иллюзия нового и надежд на избавление от проблем.
Он не оценил. У него память раст сожрал и случилась растоистерика.
Действительно, после раста посмотришь на оригинал и ржать хочется насколько криво на расте всё получается.
> Для желающих поугорать:Существует всего два вида программ: большие и маленькие. Последние не могут работать при наличии ошибок.
Похоже, rust создан для разработки последних.
imho
Да пипец какой-то.
Даже этот полухеллоуворлд на сях в разы более читабелен, сразу понятно, что делается, где и зачем, в отличие от.
Да, в rust уровень вхождения сильно выше. Там требуется больше думать. И это плохо. Но это, мне кажется, недостаточная причина для reject-а. Это думание не напрасно, а на повышение safety и надёжности кода.
Да, дичь как она есть.
Через кровь пот и слезы к железу.
Зачем полумеры?
Берите и переписывайте все ядро на расте.
И варитесь в своем уютном котле.
Я лично в гробу видел поддерживать ядро написанное на двух языках и ломать себе мозг когда вот такое встретится.
Это хуже чем С.
Даже асм и то понятнее.
Вот автор на С оставил автограф, а как же растоман? Боится ручки испачкать? Потом ведь за свю жизнь не отмоется.
2 блока unsafe. Круто, чё
Посмотрел сравнение. Синтаксис реально дичь. Я вижу в этом только желание выделиться, мол смотрите, сколько закорючек в одной строке делают магию (чем-то Perl напоминает, но у него ниша подходящая). Эти :: ? (()), где на Си простые человеческие строки - жесть. В таких конструкциях шансов больше накосячить уже в плане опечаток и невнимательности. Примерно как стих без рифмы, работает, но читается трудно. Даже JS лучше читается.
Вот пример - Го, просто взяли и сделали легкий текст, который в то же время очень похож на Си, и даже легче, чем Си в плане синтаксиса, и возможностей при этом сделали больше, в т.ч. выход за пределы, сборщики, структуры с методами, и прочие паники, и без ООП. Даже без знания языка понятно, что в коде происходит. Но Го не подходит для системного уровня, почему нельзя сделать язык аналогичный для системного - а потому что уже есть Си.
Уже делают zig. Он как С только модный молодежный.
В Россее могут запретить.
Та, что у нацистов, пишется по-другому.
Наши суды не интересует, как там оно у них пишется, звучит-то как у нацистов.
Так раст это идейный продолжитель C++, но никак не Си. Ни в плане абстракций, ни в плане синтаксиса. Мешанины в плюсах не меньше, чем в расте.
Меньше.
Меньше. С++ вполне логичный в плане синтаксиса и строгий. Раст же постоянно перестраивают, потому что то там то там что-то не вяжется.
> Меньше. С++ вполне логичный в плане синтаксиса и строгий. Раст же постоянно
> перестраивают, потому что то там то там что-то не вяжется.Кхм, но ведь синтаксически и семантически несовместимых версий раста только две - 2015 и 2018 версии.
Drew DeVault пилит подобный "секретный язык" https://drewdevault.com/2021/05/24/io_uring-finger-server.html
> Drew DeVault пилит подобный "секретный язык"
> https://drewdevault.com/2021/05/24/io_uring-finger-server.htmlГм, он и по обсуждаемой теме тоже высказался:
---
"Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new programming language"
[...]
Rust is a decent C++ replacement if you have the same goals as C++, but if you don’t, the design has very similar drawbacks. Both Rust and C++ are what I like to call “kitchen sink” programming languages, with the obvious implication. These languages solve problems by adding more language features. A language like C solves problems by writing more C code.
--- http://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repla...
> A language like C solves problems by writing more C codeТо есть он признаёт, что для решения задач на C надо написать тонну бойлерплейта, и при этом C всё ещё единственный самый лучший незаменимый язык? Шигорин, ты...
Опять что-то переписали?
> Опять что-то переписали?Опять устроили в комментах перепись читающих заголовки.
Пытаются показать что могут, но до сих пор не могут внятно сказать зачем.
Учебный проЭкт? Ну ладно, пусть будет, но в ядре-то он нахрен?))
Пусть учаться линуксята молодые.
https://www.opennet.dev/opennews/art.shtml?num=54970
> Ещё одной проблемой стали попытки использования вычислений с плавающей запятой или 128-битными типами, что не является допустимым для таких окружений, как ядро Linux. Это оказалось более серьёзной проблемой, так как в данный момент базовая (core) библиотека Rust неделима и представляет собой один большой blob - в ней нет возможности запросить только некоторые из возможностей, предотвратив использование той или иной проблемной функциональности. Решение проблемы может потребовать внесения изменений в компиляторе rust и библиотеки, при том, что на данный момент у команды ещё нет стратегии, как реализовать модульность библиотек языка.куда интересней как они вот это будут решать
> https://www.opennet.dev/opennews/art.shtml?num=54970
>> Ещё одной проблемой стали попытки использования вычислений с плавающей запятой или 128-битными типами, что не является допустимым для таких окружений, как ядро Linux. Это оказалось более серьёзной проблемой, так как в данный момент базовая (core) библиотека Rust неделима и представляет собой один большой blob - в ней нет возможности запросить только некоторые из возможностей, предотвратив использование той или иной проблемной функциональности. Решение проблемы может потребовать внесения изменений в компиляторе rust и библиотеки, при том, что на данный момент у команды ещё нет стратегии, как реализовать модульность библиотек языка.
> куда интересней как они вот это будут решатьРешать что? Проблемы перевода очередного пересказа "о расте"?
Хехехе. Мне нравится как мэйинтейнеры ядра одним ленивым взглядом находят труднорешаемые проблемы для хипстеров.
Zig модный молодёжный, простой приятный, великий китайский C заменитель язык Xi кнопка УДАР!
Опять занимаются велосипедостроением вместо полезных дел
Полезные дела для тебя оставили.
>> Особенностью драйвера является то, что его реализация практически построчно повторяет имеющийся драйвер GPIO на языке Си.То есть вместо "бесполезного драйвера" они решили положить другой бесполезный драйвер?
Интересный у них подход. Писать код только ради того, чтобы писать код, а не для того, чтобы приносить пользу людям.
Именно!За это расоноркоманов и не любят.
Может в вэб этому убожество нашлось бы место, но мазила Рип, а в вэб пхп, питон и го. И "умерший" перл, внезапно.
Драйвера и на джаваскрипт можно писать. Давайте покажите класс что вы можете.
Ну зачем ты так сразу? Альтернативно одаренные трансгендерные кодеры еще не отошли от проблемы в leftpad (помним (с)), а ты сразу драйвер.
Альтернативно одаренные той проблемы даже не заметили. В зависимости же проблема, значит - не их.
Уважаемые любители раста, Линус Торвальдс привествует вас и передает вам "f*ck you!"
Золотой человек чтобы мы без него делали?
Мне одному это очень сильно напоминает работу по кодингу от какой-нибудь девочки-зубрилки курсе на 2-3м любого ИТ-вуза нашей необъятной?Поясняю: у каждого в группе она была - девушко, хорошистка, но при этом тупая как валенок в профильном предмете и выезжающая только на КВН, самодеятельности, я-волонтёрко-и-ниипёт, просиживанию штанов в профкоме и/или упорным лизанием задниц всем преподам текущего семестра. Которая лабы по тому же кодингу сдавала так же. Ну, вытягивала из реально шарящего студента накаляканный код, просто его красивенько форматировала, меняла пару переменных, а потом этот подсрочник пыталась сдать, падая на самых элементарных вопросах, вроде "зачем вообще нужна эта переменная" или "почему здесь заюзан алгоритм Маршалла-Фуллера вместо Клефа-Брайта?".
Блин, кто-нибудь из местных неананасных неыкспердов с расторассадников, объясните мне сакральную причину переделки в виде подстрочной трансляции в стиле той зубрилко, что ночью перед сдачей уродует код ботана, а не в виде оригинальной реализации GPIO? Где можно и язык показать с лучшей стороны, и вообще? Почему? Или все гуру раста полыхают на опеннете, в святой войне против Ыкспердов?
Нет, тут уже сравнивали эту реализацию с тестовым стендом двигла. Хорошо. Зачем брать уже миллион лет как зарекомендовавший себя ЖРД, стоящий последние полмиллиона лет буквально на всем, от пылесосов до Гиганских Космических Меха-Покорителях Вселенных, заменять каждую детальку кривой китайской копией, а заем снова впихивать на стенд? Не разумнее на основе этого двигла сделать (вырастить?) какой-нибудь Биосовместимый Ветропускающий Двигатель на горохе? Который делает ровно то же, но показывает преимущества органики перед металлом?
Причина простая - показать си разрабам ядра как это выглядело бы на rust - такой себе розеттский камень. И они (в отличие от оппенетовских диванных кодеров) этим остались довольны. Можно посмотреть дальнейшую переписку в рассылке - там задают вопросы, обсуждают почему и как.
Если его переписать не транслирую (напр. поменять структуры данных где это можно) - то им будет очень сложно понять, потому что им этот язык вообще не знаком. Там нет каких-то зубодробительных фишек типа, только минимум чтобы оно работало точно так же. И этого уже достаточно.
>"почему здесь заюзан алгоритм Маршалла-Фуллера вместо Клефа-Брайта?".И почему же? Я вот погуглил, если по первому гугл нашёл парочку ссылок, то по второму не нашёл ничего. Также я очень сомневаюсь, что в универах на лабах нужно накодить алгоритм планирования процессов, и ещё обосновать. Это вообще на многозадачную ОС тянет, а это работа явно не для лабы. И даже внутри ядра ОС планирование процессов вообще нужно только разработчику планировщика процессов и юзерспейсных потоков, то есть почти ни кому не нужно, что есть в стандартной библиотеке и ОС - то и будем использовать.
> Не разумнее на основе этого двигла сделать (вырастить?) какой-нибудь Биосовместимый
> Ветропускающий Двигатель на горохе? Который делает ровно то же, но показывает
> преимущества органики перед металлом?Вместо ваяния сего пафосного опуса - прошел бы по ссылке lkml и прочитал предложение Грега взять в качестве примера имеющийся драйвер и предложение Линуса (не Т, но не суть важно) взять драйвер GPIO.
Но это было бы слишком скучно и вообще, читать дальше заголовка - невместно для уважающего себя опеннетчика, да?
> Поясняю: у каждого в группе она была - девушко, хорошистка,У нормальных пацанов девушку заменяет Бьерн Страуструп. Именно с его книгой они проводят ламповые теплые вечера и встречают рассвет. И эта любовь настолько сильна, что ни одна современная растовая соска ее не заменит.
А потом пацаны одевают на себя пушистые костюмы с хвостмками и ушками и едут на фурфест.
> А потом пацаны одевают на себя пушистые костюмы с хвостмками и ушками
> и едут на фурфест.Вы про растоманов их мурзиллы?
Ну к чему это притворство. Я про С++ пацанов.
Про растенианцев ничего не знаю, в близи не видел. А про кресты все давно знают что там к чему.
Поигравшись немного с растом я пришёл к следующему выводу.1. Раст - сырой нестабильный язык, пользоваться которым на данный момент - боль и унижение. Потому что нет алсолютно необходимых примитивов, которые есть в других языках, потому что их запретил borrow-checker.
2. Из-за этого сообществу и Foundation приходится постоянно изобретать новые примитивы и идиомы, взамен тех, что нельзя использовать.
3. Пока этих примитивов нет, сообщество вынуждено с болью и унижением извращаться.
4. Когда примитивы появляются, счастью каждого разработчика нет предела. Можно выкинуть старое неудобное громозкое говно. Поэтому все сидят исключительно на nightly. Стабильные и бета бесполезны - даже если лично вы предпочтёте извратиться, авторы других ящиков извращаться не будут.
5. Из-за таких вот постоянных подарков разработчикам раст и является самым любимым языком с самыми фанатичными фанатами.
6. Не смотря на быстрое развитие, это всё равно что вычерпывание моря. Пригодным для разработки раст станет нескоро. Но когда станет - всех порвёт. Если раньше профессию программиста не упразднят и не переложат на GPT-5.
Ну, ты из 6 пунктов целых 4 посвятил "абсолютно необходимым примитивам", но не назвал ни одного... Или примитивы твои слишком известны, чтобы ты их называл?)
а ты точно с растом поигрался?)
а ты точно читать умеешь?
> Поигравшись немного с растом я пришёл к следующему выводу.Спасибо, занятно -- и полностью бьётся с упомянутой в #262 статьёй, вот её заключение:
---
The kitchen sink approach doesn’t work. Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has. Wise languages designers start small and stay small. Wise systems programmers extend this philosophy to designing entire systems, and Rust is probably not going to be invited. I understand that many people, particularly those already enamored with Rust, won’t agree with much of this article. But now you know why we are still writing C, and hopefully you’ll stop bloody bothering us about it.
--- http://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repla...А мне этот подход со скачущими "анонимами", которые визжат, что если всё развалить и переделать -- будет точно лучше, кажется сомнительным на основании опыта и этого, и прошлого веков. Уже издали так кажется.
Делающие-то не визжат.
Ну а чего только выводы цитировать? В статье есть более интересные моменты, напр:
"Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows."
Собственно больше добавлять и него.Для автора статьи портабилити, неуменее работать с карго и "C has many implementations" важнее безопасности. Ну ок. Это вполне созвучно с последними новостями с главной (очередная "21.07 Root-уязвимость в ядре Linux")
> Для автора статьи портабилити, неуменее работать с каргопро засаду с cargo автор всё понял.
> и "C has many implementations" важнее безопасности.
О. Вот тут вы и вскрылись: надо отдаться попечительскому совету, который обеспечит подгрузку необходимого кода (с нужными "решениями") прямо в любой проект. Следующий уровень: надо не внедряться в 100500 проектов, а контролировать подкачиваемые бинари.
> Ну ок. Это вполне созвучно с последними новостями
> с главной (очередная "21.07 Root-уязвимость в ядре Linux")Ээээ, а откуда у нас там eBPF завёлся, не поясните? Следом за rust с cargo ядро будет подгружать что-то вроде eBPF-байткода исключительно из "проверенных" источников?
Нет никакой засады. Обычный make и rustc спасет отца русской демократии. Правда будут такие портянки Makefile как и для си.
Плюс сам карго можно локально развернуть - это совсем не сложно. Просто читайте маны https://doc.rust-lang.org/cargo/reference/specifying-depende... и все будет свое локальное.> надо отдаться попечительскому совету
нужно отдать комитету по стандартизации wg14... оу щи, это же совсем другое!
а вообще это круто когда разные компиляторы дают разный результат. это так стабильно и надежно. у нас же есть целый стандарт! правда там часть вещей отданы на откуп разрабам компиляторов... но зато стандарт и множество реализаций.А там не в eBPF дело. Просто очередной выход за границы буфера, дело-то житейское.
> Правда будут такие портянки Makefile как и для си.Вы уж как-то аккуратней мемы с такой коннотацией пользуйте, если не хотите про методичку услышать.
> Плюс сам карго можно локально развернуть - это совсем не сложно. Просто читайте маны ...
Ни разу не видел развернувших "своё, локальное" для ... ну, скажем, мнэ..., node.js.
Зато мемы про результат этой продвинутой стратегии --- на этом ресурсе в избытке.> нужно отдать комитету по стандартизации wg14... оу щи, это же совсем другое!
Раньше было другое. Сечас с ускорением дрейфует в аналогичном направлении. С усилением доли кое-кого.
> а вообще это круто когда разные компиляторы дают разный результат. это так стабильно и надежно. у нас же есть целый стандарт! правда там часть вещей отданы на откуп разрабам компиляторов... но зато стандарт и множество реализаций.
Тут комментировать нечего: один из методов "к победе в дискуссии".
> А там не в eBPF дело.
Да так, оно там чуть более, чем существенно.
Вот читаю ваш отзыв и офигеваю, как же я ухитряюсь на стабильном расте уже 3 года писать в прод и не испытывать проблем? Мистика какая-то..
>построчно повторяющийИ после этого кто-то удивляется травле и глумлением над нарко..оастоманами.
Ну да и пусть. Линукс все равно спасать нет смысла. Да и нечего там спасать. Все, что в нем есть ценного драйвера.
https://lore.kernel.org/ksummit/YOdJLYmUkoMyszO7@kroah.com/
>> From: Greg KH <greg@kroah.com>
>> And really, there is no need to dig through a huge spec, try porting an existing C driver will be much easier.
>> From: Linus Walleij <linus.walleij@linaro.org>
>> With my GPIO maintainer hat on I'd say a GPIO driver would be quite interesting to look at.
>>>построчно повторяющий
> И после этого кто-то удивляется травле и глумлением над нарко..оастоманами.Перепись "не читавших, но ценное мнение имеющих" уже есть выше.
Линус ещё 2 недели назад написал:
"At least the argument is that Rust _fixes_ some of the C safety
issues. C++ would not."Местные комментаторы могли бы ворваться в рассылку ядра и доказать, что раст бесполезен и даже вреден. Но ведь они просто продолжат ныть как маленькие сучки.
Можно почитать рассылку приведенную в посте и увидеть реальные вопросы не в пользу раста. Я пока не вижу восторженных отзывов.
Там предметный технический разговор профессионалов, а тут только байт от неучей.
Годный байт от неучей. Раст - не нужен, Чистый Си - вечен.
Как можно потом искать ошибки в абсолютно нечитаемой лапше из закорючек? Раст не должен восприниматься как язык, позволяющий писать корректный код
А зачем их искать? Можно их оставить ведь это так удобно что при обращении к разыменованному указателю приложение не падает в сегфолт, а делает ничего. А то что указатель это может быть логической ошибкой решительно ни одного хрустика не интересует.
Стиль написания жесть..>>
fn ack(data: &Ref<DeviceData>, irq_data: &IrqData) {
let mask = bit(irq_data.hwirq() % u64::from(PL061_GPIO_NR));
let _guard = data.lock();
if let Some(pl061) = data.resources() {
let _ = pl061.base.try_writeb(mask.into(), GPIOIC);
}
}
>>вот и гадай где data.lock() отпустят. или в какой-то из функций внутри или по выходу..
Предположу, что по выходу, ибо _guard никуда не передается.
> вот и гадай где data.lock() отпустят. или в какой-то из функций внутри или по выходу.._guard начинается с подчёркивания, что является заявлением компилятору, что переменная не используется. В смысле она есть, существует, но код на неё никак не ссылается. Если программист попытается её использовать, компилятор будет ругаться -- я не знаю, не проверял, будет ли он выкидывать ошибку или варнинг, но что-нибудь такое он выкинет по-любому.
Это значит, что переменная будет существовать неизменной вплоть до выхода из зоны видимости, когда она будет уничтожена, то есть лок она будет держать ровно до того момента.
Но в целом, я согласен, несколько странный API. Я бы ожидал чего-нибудь в стиле:
fn ack(data: &Ref<DeviceData>, irq_data: &IrqData) {
let mask = bit(irq_data.hwirq() % u64::from(PL061_GPIO_NR));
let data_ref = data.lock();
if let Some(pl061) = data_ref.resources() {
let _ = pl061.base.try_writeb(mask.into(), GPIOIC);
}
}То как оно написано, неясно что будет, если я, не сделав data.lock(), попытаюсь вызвать data.resources(). Я получу панику? Или чтение без синхронизации? Разве не стоило бы сделать невозможным обращение к resources без синхронизации, если синхронизация нужна?
Если иногда надо с синхронизацией, а иногда можно без неё, я б пометил метод IrqData::resources как unsafe, чтоб соблазна не возникало без нужды его дёргать, а если хочешь без unsafe, то вызови IrqData::lock, получи взамен "умный указатель" IrqDataLocked, который предоставит тебе метод IrqDataLocked::resources, который уже не будет unsafe. Но с другой стороны, я ничего не знаю про этот IrqData, может и есть какое-то обоснование тому, как они сделали.
Какая прекрасная логичность и целостность языка: для указания, что переменная изменятся, надо добавить отдельное слово "мут", а что она не используется - к имени пририсовать подчеркивание.Логика уровня "раст".
> Какая прекрасная логичность и целостность языка: для указания, что переменная изменятся,
> надо добавить отдельное слово "мут", а что она не используется -
> к имени пририсовать подчеркивание.Угу. Очень удобно. Подобные штуки часто встречаются в языках с паттерн-матчингом и деструктуризацией, потому как... ну, например...
Пускай у нас есть функция:
fn rotate_vector(x: f32, y: f32, angle: f32) -> (f32, f32) {
...
}Она принимает координаты вектора и угол и возвращает tuple из двух флоатов, которые представляют собой координаты повёрнутого вектора. Я могу написать:
let coords = rotate_vector(1.0, 0.0, 90.0);
и потом ссылаться на x, через coords.0, а на y через coords.1, но я могу поступить интереснее:
let (x, y) = rotate_vector(1.0, 0.0, 90.0);
это называется деструктуризация: при присвоении я разбиваю структуру из правой части на именованные куски, в данном случае на x и y. Оно так чаще понятнее выходит.
Но что делать, если мне нужен, скажем, только x? Если я оставлю y, то раст начнёт варнинги кидать о том, что переменная y не используется. На такой случай можно написать:
let (x, _) = rotate_vector(1.0, 0.0, 90.0);
тут _ -- это специальное имя для переменной, которая не используется, но она нужна только чтобы место занять конкретно в этом выражении. Этот _ можно читать как "пoxpeн что".
Но иногда хочется в коде оставить подсказку, что же там в _: если переменной дать название, то код будет понятнее, будет сразу понятно, какие части возвращаемого значения мы игнорим. Читать проще. И вот тут как раз можно и рыбку съесть и жoпy не ободрать:
let (x, _y) = rotate_vector(1.0, 0.0, 90.0);
Но это не только так используется -- когда коллбеки передаёшь куда-нибудь, этот коллбек может игнорировать какие-то аргументы. Аргументы тем не менее надо упомянуть в заголовке функции, но потом раст начнёт варнинги кидать о том, что ты их забыл использовать. _ спасает.
> Логика уровня "раст".
Ты льстишь расту. В этом нет ничего нового. Такого рода штуку я ещё в пайтоне видел. Но там, если память мне не изменяет, вместо _ используется *. И я вот не упомню точно, но, вроде, я не только в расте видел использование значка _ в смысле "пoxpeн что".
Вообще-то _ и _y - это принципиально разные вещи. Просто подчеркивание - это вообще не имя, а служебное слово языка, которое в паттерне обозначает игнорирование. Это важно понимать, так как в этом случае никакого связывания вообще не происходит, в отличии от варианта _y, где используется уже действительно имя и оно связывается со значением.
> Вообще-то _ и _y - это принципиально разные вещи. Просто подчеркивание -
> это вообще не имя, а служебное слово языка, которое в паттерне
> обозначает игнорирование.Ты говоришь, что это принципиально разные вещи, в чём "принципиальность" разницы? Что ты называешь принципиальной разницей? Чем принципиальная разница отличается от непринципиальной?
Тебе не кажется, что синтаксис языка определяет, что принципиально разные вещи в этом языке, а что нет? Мне кажется, что именно так. Если синтаксис языка говорит, что if принципиально отличается от foo, потому что if -- это ключевое слово, то значит это принципиальное отличие. Вот lisp, например, не говорит, что if -- это что-то принципиально отличающееся от foo, if -- это просто ещё один символ, и действие его ты можешь повторить, реализовав if как макрос. Ты можешь присвоить значение if'у, или сделать его функцией. В лиспе эта разница непринципиальна. В лиспе просто принято использовать if, как if. В C же if -- это ключевое слово, его поведение невоспроизводимо средствами языка, ты не можешь средствами языка переопределить if и научить его танцевать польку.
> Это важно понимать, так как в этом случае никакого
> связывания вообще не происходит, в отличии от варианта _y, где используется
> уже действительно имя и оно связывается со значением.Связывание происходит в обоих случаях, только в первом с безымянной переменной, во второй с переменной имеющей имя. В любом случае значение будет существовать до выхода переменной из области видимости.
> Ты говоришь, что это принципиально разные вещи, в чём "принципиальность" разницы?
> Связывание происходит в обоих случаях, только в первом с безымянной переменной, во
> второй с переменной имеющей имя. В любом случае значение будет существовать
> до выхода переменной из области видимости.Разница принципиальная, так как в случае использования _ нет никакого байндинга и нет передачи владения (потому что подчеркивание - это не имя). А вот в случае использования имен _x - байндинг есть и передача владения есть. Вот этот код скомпилируется:
let string = Some("foo".to_string());
if let Some(_) = string {
}
println!("{:?}", string);Но если ты заменишь _ на _x - то не скомпилируется.
> вот в случае использования имен _x - байндинг есть и передача
> владения есть. Вот этот код скомпилируется:
> let string = Some("foo".to_string());
> if let Some(_) = string {
> }
> println!("{:?}", string);
> Но если ты заменишь _ на _x - то не скомпилируется.Хм. Да, действительно.
> вроде, я не только в расте видел использование значка _ в
> смысле "пoxpeн что".В паттерн-матчинге _ используется именно в таком смысле, вот пример на OCaml:
let fib n =
let rec fib_aux m a b =
match m with
| 0 -> a
| _ -> fib_aux (m - 1) b (a + b)
in fib_aux n 0 1
в данном случае из-за вывода типов возможные значения _ сужены до "любое целое".
Это ещё в лиспе было в бородатые года когда сишка была бредовой фантазией в головах корпорастов.
> Какая прекрасная логичность и целостность языка: для указания, что переменная изменятся,
> надо добавить отдельное слово "мут", а что она не используется - к имени пририсовать подчеркивание.
> Логика уровня "раст".http://www.cse.unsw.edu.au/~billw/dictionaries/prolog/
>> the appearance of the same variable in two (or more places) in effect says that when the variable is bound to a value, it must be bound to the same value in all the places that it appears in a given rule.
>> The Prolog variable _ (underscore) is a "don't-care" variable, which will match anything (atom, number, structure, …). For example, the rule
>> In Prolog interpreters that report singleton variables (variables that are only used once in a rule - often these are caused by typographical errors in the code, which is why Prolog warns you about them) do not report singleton variables that begin with _Какой прекрасный парад невежества уровня "опеннетный антирастовый комментарий".
как я понимаю претензия была не к переменной "_", а к тому, что к префиксу "_" привязали какой-то функционал/ограничение. Правда я не понял, это так на уровне языка потребовали (в каких-нибудь официальных документах), и я уже не имею права называть свои переменные с символом подчёркивания в начале, или это такая негласная, но широко распространённая договорённость.
Неиспользуемая переменная - это ворнинг компилятора. Несколько раз меня спасал от досадных логических ошибок.
Впрочем, перечитал Ordu - если действительно компилятор на это подчёркивание смотрит, решение довольно странное, более логично было-бы его подкрашивать через ключевое слово, имхо.
> Впрочем, перечитал Ordu - если действительно компилятор на это подчёркивание смотрит, решение
> довольно странное, более логично было-бы его подкрашивать через ключевое слово, имхо.Это могло бы быть логичным в C или в C++. Поэтому в них есть __attribute__((unused)). В расте это не логично. Потому как:
1. Раст настаивает на том, чтобы неиспользуемые переменные были бы помечены как неиспользуемые. Местами он задалбывает этим хуже некуда, когда у тебя неиспользуемость временна, и ты компиляцию используешь только чтобы проверить наполовину написанный кусок кода. Или если ты закомментировал половину кода, чтобы посмотреть на то как будет работать без неё. Писать __attribute__((unused)) к каждой переменной, которая не используется, бррр
А как насчёт такого (допустим, что open там возвращает не -1 в случае ошибки, а очень по растовому Err(some_error), а в случае успеха -- Ok(file_descriptor)):
let filedesc = match open(file_name, O_APPEND) {
Ok(fd) => fd,
Err(_) => panic!("I cannot open file {:?}. I'm panicking now and going to die soon.", file_name),
};Видишь там Err(_)? Это тоже деструктуризация, на этот раз в процессе паттерн-матчинга, и это тоже объявление неиспользуемой переменной. можно было бы написать Err(_error) например. Если ты там не обозначишь переменную как неиспользуемую, то раст начнёт тебя клевать, мол, "переменная не используется". И что, ещё туда вставлять __attribute__((unused))? Как ты потом читать будешь всё это?
2. Компилятор раста, хоть и любит заклёвывать своим перфекционизмом, очень заботливый, и если ты, читая RustBook не обратил внимания на _ или обратил, но забыл потом, то он по-ходу дела объяснит тебе, как и когда его использовать. Если б он не был таким заботливым, я подозреваю, растоманов было бы в разы меньше, потому как через несколько часов возни с компилятором, ведущим себя как дятел-перфекционист, они бы разбили бы себе мониторы и растоптали бы свои клавиатуры. С рядах растоманов остались бы только 100% флегматики, абсолютно неспособные к эмоциям.
А, и ещё, ежели тебе кажется, что трактовать имена переменных с определённым префиксом специальным образом, это изобретение rust'а, то опять это не так. В Common Lisp'е имена символов начинающиеся с : в начале автоматически имеют себя в качестве своего значения, их поэтому можно использовать как символические ключи в парах (ключ значение), не парясь о том, чтобы квотировать их дописывая ' в начале. То есть это вроде как и переменная, но сколько бы раз в процессе вычислений на эту переменную не выполнялся бы eval, она от этого не изменится. Очень удобно. Можно было бы ключами использовать строки, типа ("ключ" значение), но там ряд неудобств возникает: кавычек много писать надо, и :ключ будет иметь ровно одну копию в памяти, в то время как строк "ключ" может быть создано сколько угодно, и хоть они и будут равны друг-другу, но они будут разными объектами, занимающими память, и проверять на равенство их каждый раз придётся посимвольно, то есть со сложностью O(N), вместо O(1).
Тоже кстати дискриминация: почему я не могу называть свои переменные с именем, начинающимся с двоеточия? =)
> http://www.cse.unsw.edu.au/~billw/dictionaries/prolog/О, точно же, в прологе так было!
>> http://www.cse.unsw.edu.au/~billw/dictionaries/prolog/
> О, точно же, в прологе так было!Ну да, правда в раст оно скорее всего из хаскеля попало:
https://typeclasses.com/underscore
> When the underscore appears alone in a pattern,This is perhaps the most common use of an underscore. it is a reserved identifier that acts as a wildcard: a pattern that matches anything A pattern that always succeeds is called an irrefutable pattern. but does not introduce a new variable.
> Beginning a name with an underscore is sometimes used to name variables we will not use – and thus don’t really care about – but care just enough about to give it a name to remind ourselves of what is being discarded.
350 строчный GPIO драйвер, нарошно искали максимально простой драйвер, вместо того, чтоб написать что-то практичное
Даже этот драйвер запороли, например "#ifdef CONFIG_PM" просто выпилили, без какой либо замены на раст код
А это что такое?
}
}
}
}
}
}
6 закрывающих скобок подряд
Еще глянул html файл, синий текст на черном фоне... очень удобно читать
А в html коде "<!-- HTML generated using hilite.me -->", что как бы намекает, что растоман не смог даже простейший html написать ручками
Смузихлебы уже все Unix утилиты (ls, du, etc) на раст переписали, из полезного только ripgrep и то преимущества спорны, зато менее функционален по сравнению с grep. Теперь будут также бесполезно драйверы переписывать. Напомню, свою ос растеры не осилили, течёт как плотина весной.
fuchsia? Правда пока в дикой природе не встретишь.
Ядро всё ещё на C++
> Ядро всё ещё на C++Спасибо! Просмотрел этот момент.
Отцы, ну вы блин развели срач …
Может пусть Торвальдс решит, является ли переписанный код драйвера полезным или нет
А Торвальдс - господь бог, что ли?У нас тоже свои мозги есть. А некоторые из нас еще и программированием на жизнь зарабатывают. И это все называется "коммьюнити".
вы своей комьюнити перепишите линукс на раст и будет вам счатье, и пихайте в него хоть что, ок? а продукт и человека который этому продукту жизнь посвятил, не нужно затрагивать , зопли еще не высохли у тебя под носом. комюнити покемонов.
> Rust для ядра Linux, бесполезен и не решает реальных задач
> Особенностью драйвера является то, что его реализация практически построчно повторяет имеющийся драйвер GPIO на языке СиОни решили наглядно продемонстрировать бесполезность?
Ошиблись в слове безопастность
Да какая там в пень безопасность, один к одному конвертнули сишный код и в unsafe все обернули.
Именно. Линус говорил, что мол ничего полезного не написано. А они не новое написали, а ПЕРЕписали.
А что там с Radix его совсем забросили или будут что-то доделывать?
Не зннаю.
от ваших растов, тошнит уже даже больше чем от опеннета.
RUST безоп-а-а-а-сный, ко-ко-ко!!1!
ну преобразуйте на java, преобразуйте на pascal? питон, и что? уже противно читать про про всякое дерьмо позволяющее улучшить код при помощи языка. может программисты начнут хоть немного втыкать что они пишут?
> может программисты начнут хоть немного втыкать что они пишут?Программированию скоро уже век исполнится. До сих пор не научились. Сколько ты считаешь возможным ждать у моря погоды?
> Программированию скоро уже век исполнится.Какой век?! Пневмо-гидро-логические программируемые элементы были уже в Древней Греции. Не говоря уж про механику программируемую (вал, штыри, верёвка).
Но, как показала практика, древние программисты были умнее современных растаманов.
они есть, просто от той масса новых, которая зашла в отрасль, не требуется разрабатывать структуры данных, оптимизировать. Требуется создавать контент либо решать бизнес-логику котораю уже завтра изменится и потребует переписки уже кода. А сейчас эта масса быдлокодеров считает себя как класс, заявляет свои права на переписку частей ядра (как пример) на модный язык.
> они есть, просто от той масса новых, которая зашла в отрасль, не
> требуется разрабатывать структуры данных, оптимизировать. Требуется создавать контент
> либо решать бизнес-логику котораю уже завтра изменится и потребует переписки уже
> кода. А сейчас эта масса быдлокодеров считает себя как класс, заявляет
> свои права на переписку частей ядра (как пример) на модный язык.Какая у тебя замечательно простая картинка мира. Хорошо с такой жить, мозги вообще напрягать не надо.