Продемонстрирована возможность разработки частей Linux на Rust

Но тупить в темах про раст это вам не мешает.

Давайте ядро на питоне писать.

Тупняк продолжается. Rust системный язык, python - нет. Ваш КО.

Что значит «тупить»? Смотрю в код на русте - и вижу там фарш из крючков и закорючек. И, очевидно, громоздкость никуда деваться не собирается. Потому что она нужна компилятору.

И это правильно, логично и здорово. Это самое правильное поведение из возможных.

Это не правильно и это не логично. Такое поведение не только порождает безчисленные ошибки, но и ограничивает оптимизации которые может сделать компилятор.

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

Ну вот ты пишешь синтаксически грамотно, а по содержанию - какой-то песец. Потому тебе и раст не нравится: там не любой песец компилируется, а в C и в русском - любой %)

И? Какое решение вы предлагаете? Ныть на лоре? Посмотрите на конкурентов раста - там все ещё хуже.

Openssh тоже на сишке, но почему-то не дыряв.

wut? https://www.cvedetails.com/product/585/Openbsd-Openssh.html?vendor_id=97

Ты так говоришь, как будто, у тебя есть какая-то статистика по этому вопросу. Для меня переволнение - вовсе не магия.

Тупняк продолжается. Rust системный язык, python - нет. Ваш КО.

На питоне написано десятки тысяч приложений, а на rust'е... А он прогрессивный и перспективный! И продвигают его продвинутые люди с чистыми и светлыми лицами.

rust - язык никакой. Рабочего продукта на нем не было.

Ввиду отсутствия *стандартной* возможности вставки в *стандартный* Си ассемблерной вставки. Не говоря уже о том, что *Си* в приведённом коде просто не нуждается.

Вы уверены, что поняли код? Вы уверены, что мы говорим об одном и том же языке С?

У меня такой уверенности нет.

Для справки мой код иллюстрировал приведение типов в С и... более ничего. В частном случае перевод кода в строку и обратно это возможность передать строку по сети или сохранить в файл вместе с набором данных. Итд. еще точнее это иллюстрация неотличимости кода от данных. Код это данные, а данные могут быть кодом. Одна и та же сущность в разных ипостасях.

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

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

Мда...

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

Могу поспорить, если регистр процессора 9битный, тогда переполнения не будет, но у тебя же тип u8, и как сказали выше, компилятор добавит еще код для обрезания до 8бит

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

Си говно. Он даже не говорит будет ли >> работать с переносом старшего бита для знаковых типов. Писать на нём нормальный код невозможно.

Могу поспорить, если регистр процессора 9битный

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

Это не правильно и это не логично.

Прекрасно! Сейчас многоуважаемый Дон сообщит нам как должно быть правильно и логично!

Итак, слушаю, как на языке высокого уровня, коим без сомнения является Rust совершить манипуляции с мантиссой из числа с плавающей точкой в double формате! Ну заодно можно и со экспонентой побаловаться. К барьеру!

P.S. Интересно какой способ одевания штанов через голову изберет Дон, когда в С это решается сразу и в лоб.

Ты даже не понял о чем я говорил

Неправильно разрешать приводить тип (const char *) к типу (char *)

Сложно сказать. Если бы участвовал в разрабоке руста, то ныл бы внутри команды на этот вариант синтаксиса.

Не исключаю, что появится post-Rust язык, в котором синтаксис владения и константности будет очеловечен. Но ядро на русте писать точно никто не будет. Не наберётся достаточное количество гиков, которым нравится ковыряться в синтаксисе.

Интересно каков будет комментарий Торвальдса на предложение перейти на руст.

Торвальдсу нравится раст. Что странно, потому что плюсы он не любит, а раст на них похож больше чем на C

Писать на нём нормальный код невозможно.

Закусывать надо! Большая часть кода в этом мире написана на С. Чтобы сказать, что Linux как ядро это ненормальный код, нужно сначала получить благословение у Линуса в виде известного пальцевого выражения и лишь потом идти пиариться сюда.

Торвальдсу нравится раст.

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

Вряд-ли он каким-то образом соотнес ржавчину и язык программирования.

Хорошее дело так не назовут...

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

;-)

Открою секрет: большая часть кода на Си работает на честном благородном слове в ограниченном количестве вариантов окружения времени компиляции и исполнения.

Элементарный пример - запусти программу, скомпиленую на системе с текущей кодировкой IBM-866, на системе с текущей кодировкой UTF-8.

Ага. А теперь сравни с openssl, где дыр в два раза больше и они критичнее.

Неправильно разрешать приводить тип (const char *) к типу (char *)

Вас никто не заставляет это делать! Есть проблемы в чужом коде? - Проверьте все приведения типов.

Всем понятно, что пить алкоголь вредно. Но случаи бывают разными. Запрещать его продажу еще более вредное и глупое занятие. Проще запретить его употребление на работе и за Х часов до нее.

Мысль понятна?

P.S. Это не я придумал ключевое слово unsafe в Rust! Оно делает тоже самое. Или Вы считаете написать unsafe это круче, чем «нетрожь»? Не все программисты знают английский. Некоторые могут подумать, что это значит - «несохраненный».

Что странно, потому что плюсы он не любит, а раст на них похож больше чем на C

Чем же Rust похож на плюсы?

В Rust программист будет точно так же думать какие типы данных использовать.

Опять мы уходим от темы.

Что делать с этим идиотским владением на указатели итд итп.

Кто будет думать, что с этим делать. А кто будет просто писать код основываясь на тех гарантиях которые даёт система владения/заимствования. Кто ищет препятствия, тот их всегда найдёт. К сведению, в безопасном Rust указателями не пользуются.

Если код можно написать 5-ю возможными вариантами, то будет использован самый медленный и самый ненадежный.

Но в Rust это будет 5 надёжных способов.

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

Другими словами, ты хочешь, чтобы Rust стал управляемым языком (GC)?

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

Rust — это очень простой язык (проще С) позволяющий делать всё, что угодно и что может быть сделано на любом другом языке.

любой язык написан на С.

А Rust — написан на Rust. Занавес!

Нужна скорость написания и безопасность бери Go. точка.

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

«Открою секрет: большая часть кода на Rust работает на честном благородном слове в ограниченном количестве вариантов окружения времени компиляции и исполнения.

Элементарный пример - запусти программу, скомпиленую на x86-64, на ARM Cortex-M.»

P.S. Вы и дальше будете приводить идиотские примеры?

Чем же Rust похож на плюсы?

Ну можно найти очень много фич которых нету в C, но есть в C++ и в Rust. Начиная с автоматического управления памятью и обобщенного программирования.

Элементарный пример - запусти программу, скомпиленую на x86-64, на ARM Cortex-M.

«И тут Остапа понесло...»

Ну можно найти очень много фич которых нету в C, но есть в C++ и в Rust.

Или в Rust и OCaml. Или в Rust и Haskell. С чего бы вдруг Rust стал похож именно на C++?

Начиная с автоматического управления памятью

Которой в C++ нет. Если только не понимается размещение переменных на стеке.

и обобщенного программирования.

Которое в Rust-е и в C++ ну очень сильно разное.

Да, для сишников нормально иметь код типа

#define NAME_SIZE = 100
char name[NAME_SIZE];

и в упор не видеть что это говно.

Нормальный код на Си в дикой среде не встречается. А встречаются условно-работающие программы на некоем подмножестве всех возможных условий компиляции/исполнения. И это заслуга самого стандарта языка программирования C (даже если исключить ошибки или неквалифицированность программиста).

а конкретно по этому неидиотскому примеру - подсказать, что это динамически изменяемые настройки, или и так понятно?

LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

Это был фееричный бред...

Rust — это очень простой язык (проще С) позволяющий делать всё, что угодно и что может быть сделано на любом другом языке.

Вы со 100% уверенностью путаете C и C++. На свете нет языка проще, чем C. Так же как нет языка более низкоуровневого!

А Rust — написан на Rust. Занавес!

Язык написанный на чем-то означает, что компилятор! данного языка написан на чем-то. Физически невозможно написать компилятор языка на том самом языке, который мы не можем скомпилировать! Сначала используется всегда тот язык, который можно скомпилировать. В конце концов lex и bison генерируют парсер именно на С.

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

У создателей физически не было других вариантов. И не надо нести глупости или строить из себя идиота.

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

«У меня есть соковыжималка - как мне забить гвоздь?» (с)

ответы на подобные вопросы не даю, по причине их тотальной глупости.

ну так про другие языки разговор не идет, мой посыл был в том что если сравнивать между С (который торвальдсу нравится) и С++ (который торвальдсу не нравится) то Rust будет ближе к С++.

Которой в C++ нет.

Я не очень хорошо знаю плюсы, но что тогда делает `unique_ptr` если не управляет памятью?

мой посыл был в том что если сравнивать между С (который торвальдсу нравится) и С++ (который торвальдсу не нравится) то Rust будет ближе к С++.

Так это, имхо, неверный посыл. Rust одинаково далек и от C, и от C++.

что тогда делает `unique_ptr` если не управляет памятью?

Это не автоматическое управление памятью. Если разработчик не напишет unique_ptr или напишет что-нибудь вот такое:

some_func(unique_ptr<A>(new A(...)), unique_ptr<B>(new B(...)), unique_ptr<C>(new C(...)));

На свете нет языка проще, чем C.

Паскаль значительно проще.

Так же как нет языка более низкоуровневого!

Который даже не определяет знаковый тип char или нет. Охренеть низкоуровневый.

Это язык со всеми минусами высокоуровневых языков (нет контроля над железом - даже int8_t не означает «в типе 8 двоичных разрядов») и минусами низкоуровневых языков (байтолюбовь в каждой строчке кода).

Ну значит я не правильно выразился, как это правильно в С++ называется?

Если бы Rust существовал в те времена, когда не было UTF, то у него была бы та же проблема.

Ваши претензии неадекватны. Сравнивать любые вещи можно только когда _все_ условия идентичны кроме одного единственного! И именно по нему производится сравнение.

Вы в курсе, что сравнивать можно только вещественные числа, а уже комплексные числа сравнивать невозможно!

Вы же предлагаете сравнить Rust сегодня и С в 1970 году.

Ручное :)

С возможностью наваять подобие сборщика мусора на основе RAII и подсчета ссылок.

Я думал ручное это new/delete

Это был фееричный бред...

До твоего бреда мне ещё расти и расти.

Вы со 100% уверенностью путаете C и C++. На свете нет языка проще, чем C. Так же как нет языка более низкоуровневого!

Да зачем мелочиться! Ассемблер проще С! У тебя с головой всё нормально? Чем больше нюансов в языке, тем сложнее на нём писать, ты же Go для примера приводишь, там меньше нюансов, так же как в Rust по сравнению с С, а ещё в довесок компилятор, который говорит, что и где исправить, чтобы всё заработало.

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

Это проблема порочного круга. Начнём с того, что C был написан на ассемблере, по твоей же логике С это пустышка. Стоять, ассемблер же был написан в маш-кодах! Всё! Ассемблер тоже пустышка, все писать на маш-кодах!

Маразм...

Для справки, первый копилятор Rust был написан на OCaml. Знаток блин.

«У меня есть соковыжималка - как мне забить гвоздь?» (с)

ответы на подобные вопросы не даю, по причине их тотальной глупости.

Погоди... Ты же написал...

Нужна скорость написания и безопасность бери Go. точка.

точка

Если так, то на кой чёрт ты вообще кому-то советуешь что-то?

Поскольку C++ не запрещает сделать так:

unique_ptr<B> b(new B(...));
unique_ptr<B> b2(b.get());

Паскаль значительно проще.

Кому как. По мне так С на порядок проще Паскаля.

Который даже не определяет знаковый тип char или нет. Охренеть низкоуровневый.

Вам просто никто не объяснил, что char это _код_ некого символа и в коде нет смысла говорить о знаковости или без-знаковости. Это просто код и именно так должен интерпретироваться.

Если Вы поменяете таблицу кодировок, то тот же самый код будет представлять другой символ. Напомню char(acter) - это дословно символ и ничего более. В нем нет числа, а есть набор цифр=код.

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

Это язык со всеми минусами высокоуровневых языков (нет контроля над железом - даже int8_t не означает «в типе 8 двоичных разрядов»)

int8_t это однозначно signed char, а char это всегда 8 байт! Так что сэр, Вы гоните!

и минусами низкоуровневых языков (байтолюбовь в каждой строчке кода).

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

Это проблема порочного круга. Начнём с того, что C был написан на ассемблере, по твоей же логике С это пустышка. Стоять, ассемблер же был написан в маш-кодах! Всё! Ассемблер тоже пустышка, все писать на маш-кодах!

Разумеется. С был написан на ассемблере. Ассемблер был написан в машинных кодах.

В чем проблема я не понимаю? Именно так все и было. И сейчас никак не изменилось!

После того как это сделано один раз тогда можно писать компилятор на С на самом С. И так с любым более или менее адекватным языком.

Вы что школьник или вчера родились????

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

10к пакетов в cargo как бы намекают кому тут мешает синтаксис.

Вы что школьник или вчера родились????

Да долпаёп какой-то

Одна дыра - уже дыра. Rust от этого защищает.

В частном случае перевод кода в строку

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

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

Ага, но работает только в вакуумно-сферических условиях (не говоря уж о всяких современных штучках, типа защиты стека, W^X).

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

Опрос разработчиков от StackOverflow (2017) показал, что 73.1% разработчиков считают Rust любимым языком программирования. Пруф на русском

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

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

А претензий у меня к языку нет. Есть только проблемы, с которыми приходится сталкиваться с частотой не реже раз в 10 строк кода в процессе программирования на плюсах из-за наследия C.

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