LINUX.ORG.RU

Линус высказал своё мнение о Rust в ядре

 , ,


2

4

Поживем - увидим

Мне интересен проект внедрения Rust в ядро. Но я считаю, что авторы этого проекта предвзяты по отношению к Rust, и хотелось бы сначала посмотреть, как это обернется на практике.

Лично Торвальдс не продавливает Rust в ядро, но он «готов оценить обещанные преимущества и возможность избегания граблей, связанных с безопасностью», но также понимает, что «иногда обещанное не исполняется».

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

>>> Источник

anonymous

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 1)

Ответ на: комментарий от shpinog

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

pingvinek
()

РРРРРРРРЯЯЯЯЯЯЯЯ ЭТО НЕ ТОРВАЛЬДС СКАЗАЛ ЭТО СЖВ ЕМУ НАШЕПТАЛИ РРРРРЯЯЯЯЯЯЯ!!1!!!!11

meliafaro ★★★★★
()
Ответ на: комментарий от pingvinek

Зелёные, памагите.

Извини, «зелёный» - ты ошибся тредом.

А так да. Nvidia со своим блобом рулит. Ati/AMD(в плане видео) закопал уже давно. Проблем с блобом не испытывал со времён GT9600 даже под фряхой.

Жалко, что проц в «вине» не способен раскрыть даже 650Ti на полную…

P.S. Хотя надо попробовать в WoT под своим «Арчем» ещё раз…

drfaust ★★★★★
()
Последнее исправление: drfaust (всего исправлений: 1)

ITT пользователи ядра под дефисом «stable api nonsense» недовольны языком который иногда что-то ломал в ранних версиях.

PolarFox ★★★★★
()
Ответ на: комментарий от sartakov

Марсоходы не только на сипипи пишут. Вполне успешно писали на Common Lisp. http://www.flownet.com/gat/jpl-lisp.html

Rust хорошо может в embed. Просто у них уже есть наработки на C++ и пока незачем переписывать.

fuggy
()
Ответ на: комментарий от drfaust

Над Rust теперь работает Rust Foundation (это не только Mozilla). Или ты думаешь, что 4 гиганта (Huawei, Google, Amazon, Microsoft) и Mozilla готовы такие: а, херня, давай все выкинем и перепишем заново? Там Amazon и Microsoft умеют работать с обратной совместимостью и очень быстро пошлют переписывальщиков с нуля лесом, если это не будет давать превосходящего прироста производительности/простоты разработки. Это Google там выкидывает проекты на кладбище, остальные - с совместимостью лишний раз не шутят, это им деньги потоком несет.

ANSI - Американская, не интернациональная, организация по стандартизации. Она представляет интересы США в ISO - уже интернациональной организации. Но тебе обязательно, чтобы ISO-стандарт вышел, чтобы платненький был, стоимостью в CHF198?

Пока не было Rust Foundation, можно было сказать, что какие-нибудь сверхтолерантные переломают все в Rust, заразив Mozilla аутизмом. Но там далеко не только Mozilla теперь.

Правда, есть минус, что они будут только юриков рассматривать в Foundation, с неплохими суммами отчислений. Но это не помешает условным Yandex/MRG так же войти в фонд (Яндекс же стоял за РГ C++), и работать на равных с остальными.

Result-Code
()
Ответ на: комментарий от drfaust

В каком именно ядре ОС и сколько кода приходится на одну платформу?

Плати за аудит и найдём контору которая разберёт. Я тебе предоставил цифру и ответил на «Сколько АСМ кода в ядре». В ядре linux

И да - попробуй заменить эти строки Rust или C.

Так возьми и замени, они же не стандартизированы! Почему я то их должен заменять, если они не соответствуют ТВОЕЙ концепции ?

А они чем руководствуются? Своими «измышлизмами»?

В том числе. Как впрочем и все люди. Или по твоему в ANSI полубоги, рептилойды ?

Не совсем понятно, в чём разница кроме пафоса.

Мелкософт уже «доруководствовлся» - ихним компиляторами пользуются «по инерции», сейчас по всем флангам наступление gcc и clang

Их компиляторы компилируют 99% десктопного софта, которым пользуются 99% юзеров ПК.

Я рад, что gcc и llvm набирают обороты, но это скорее заслуга оных, чем просчёт мелкомягких. Это если объективно.

Дядя Вася нарисовал в С89 ПИД 15 лет назад, пришёл новый ПЛК - надо его туда воткнуть - он втыкается без проблем, с минимальными корректировками (подстройка специфичных для железа хидеров).

Это обратная совместимость, при чём здесь стандарт? Уже 100 раз объяснили, что одно из другого не следует.

Горжусь, что мой код сможет помочь людям и после моей смерти.

И что, многим помогают тонны кода из 80-90х ? От общей массы это какие-то проценты, даже ядро это статистическая погрешность на этом фоне.

От сюда и страх, обычный, обезьяний. Придут какие-то молодые, что-то будут писать на своём Расте, и через 10-20 лет будут такими-же, как сейчас бородатые Си-старожилы ядра.

Протолкнёте в ANSI - будет почти везде.

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

Производителям «железок» надо проталкивать свой товар, а для этого, чем больше «инструментов» для программирования «железяки», тем лучше

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

Это выбор «разработчика» - решили использовать GNUтые расширения - флаг в руки, к тому же это не противоречит принципам СПО. На производстве сильно иначе.

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

shpinog ★★★
()
Последнее исправление: shpinog (всего исправлений: 1)
Ответ на: комментарий от pingvinek

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

А чего не готов то? Уже несколько лет как готов. Запускаю игори на своей rx570, получаю хороший фпс, как под вайном так и нативные игры.

На счёт видео тоже всё впорядке, можно как через vdpau, так и через vaapi почти всё ускорять, всё то же что и в венде.

Всегда всё работает и не падает, при обновлении ядра ничего не ломается, в отличии от..

shpinog ★★★
()
Ответ на: комментарий от shpinog

Ну ладно. Осталось мобильные APU им починить и я в деле

pingvinek
()

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

Нет, это еще какая проблема

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от shpinog

Я тебе предоставил цифру и ответил на «Сколько АСМ кода в ядре».

Без пруфов.

Так возьми и замени, они же не стандартизированы! Почему я то их должен заменять, если они не соответствуют ТВОЕЙ концепции ?

Моя концепция: «А при чём тут АСМ? - он зависит от архитектуры, какую железяку придумали -таким и будет ассемблер. Или предлагаешь стандартом «заморозить» развитие аппаратных платформ?». Так что не надо перевирать мои слова.

Я рад, что gcc и llvm набирают обороты, но это скорее заслуга оных, чем просчёт мелкомягких. Это если объективно.

Блин, да что за софистская мода рвать фразы на куски???

Мелкомягкие просирают свой компилятор из-за тормозной поддержки стандартов - не успевают. В первую очередь С++, но и в Си косяков хватает. Борланд/Ембарсадеро - те сразу поняли, что bcc они давно (да он хорошим-то и не был) профукали и юзают gcc/clang - зависит от настроек.

Это обратная совместимость, при чём здесь стандарт?

Какая к чёрту совместимость - ПЛК совсем другой, проц другой, порты другие. Будь это на АСМе/Паскале/Расте я заманался бы переписывать код и его отлаживать, а так готовые функции копипастой.

И что, многим помогают тонны кода из 80-90х ?

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

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

Опять софистика?

В теме обсуждается использование Rust в ядре OS. Зачем подменять контекст, словно я говорю об абсолютной ненужности нестандартизированных языков. Речь идёт об очень крупном проекте, который развивается не один десяток лет.

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

Любой инструмент должен строится «по бумажке». Для Раста есть кому их выпускать, но те же китайцы с допотопными SoC на базе ядра i8051 ложили большой и толстый - у них есть ansiС89 и этого достаточно, что бы выпускать «чайники с подсветкой» миллионами и продавать свои микрухи по всему миру десятками миллионов.

На производстве проприетарщина монополист, все там клали на стандарты, и всё остальное.

Как раз наоборот - без стандартов пром-железо никто не возьмёт. OPC Fundation - знакомое слово?

drfaust ★★★★★
()
Ответ на: комментарий от mimico

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

это каким? их ровно 2 и оба совместимы друг с другом

next_time ★★★★★
()
Ответ на: комментарий от mimico

А если в коде на Си используются расширения компилятора,

Твой код уже не соответствует стандарту, а значит нет гарантии переносимости на другую платформу.

Это уже разработчику ПО решать насколько силино отходить от стандарта - запрета же нет.

Если я пишу демку под MS/Free-DOS и пользую регистры VGA в BC 3.11 под платформу x86, то мне нет надобности заботиться о переносимости на АРМ, т.к. там уже в графике надо не портами рулить, а через OpenGL(или что там есть) всё делать.

А вот когда я лезу я ядро операционки, которая планируется использоваться от «чайника» до «суперкомпа космолёта» - то тут уже надо оглядываться на стандарты и возможность существования «расширений языка» в длительном периоде времени.

drfaust ★★★★★
()
Последнее исправление: drfaust (всего исправлений: 1)
Ответ на: комментарий от shpinog

ripgrep вполне подходит под это описание

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

seiken ★★★★★
()
Ответ на: комментарий от vitus

Попробуйте собрать современным компилятором пример 20-летней давности (я уж не говорю про K&R диалект), и результат будет скорее всего примерно тот же, что с Rust-ом двухлетней давности.

Как раз в случае Си - соберется.

Пруф кода, который не соберется - в студию.

Kroz ★★★★★
()
Ответ на: комментарий от drfaust

Без пруфов. В 4.20

А какие тебе пруфы нужны?

    ansic:     16762933 (97.90%) 
    asm:         271261 (1.58%) 
    … 
    Total Physical Source Lines of Code (SLOC) = 17,122,750 

«А при чём тут АСМ? - он зависит от архитектуры

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

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

Мелкомягкие просирают свой компилятор из-за тормозной поддержки стандартов - не успевают.

Так никогда не успевали, и ? Вся эта дрочка вокруг стандартов началась ближе к концу нулевых, до этого вообще все клали поголовно.

В первую очередь С++, но и в Си косяков хватает. Борланд/Ембарсадеро - те сразу поняли, что bcc они давно (да он хорошим-то и не был) профукали и юзают gcc/clang - зависит от настроек.

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

Какая к чёрту совместимость - ПЛК совсем другой, проц другой, порты другие. Будь это на АСМе/Паскале/Расте я заманался бы переписывать код и его отлаживать, а так готовые функции копипастой.

При том, что стандарт v1 не обязан быть совместимым с стандартом v2. И если под твою железку v2 есть компилятор только стандарта v2, но ты писал под v1 - ты в пролёте, хотя да, стандарт есть, но обратной совместимости нет.

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

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

Опять софистика?

Так это как раз реализм. Вот твоё поклонение неким организациям, и вера в то, что принадлежность к ней наделяет немыслимыми силами, стабильностью и востребованностью - религия. Намного ближе к софистике.

В теме обсуждается использование Rust в ядре OS. Зачем подменять контекст, словно я говорю об абсолютной ненужности нестандартизированных языков. Речь идёт об очень крупном проекте, который развивается не один десяток лет.

А к чему этот аргумент про много лет? Начинаем изобретать незыблемые святыни в виде ядер ОС?

Ну захочется кому-то драйвер написать на расте, мир рухнет? Даже допустим появится группа которая будет переписывать части ядра - just for fun, и?

Я не совсем понимаю эти ультра консервативные догмы высосанные из пальца.

Любой инструмент должен строится «по бумажке».

Так у раста свои бумажки RFC. Ты просто пытаешься навязать какие-то свои концепции развития, полезность которых, относительно иных не совсем очевидна. Из этого не следует, что развитие языка на стандартах как c\c++ = говно, как и не следует что развитие в другой парадигме = говно.

Это всё вообще слабо связанно, и больше смахивает на религиозные предрассудки. В реальности же открытое ПО может быть говном, как и проприетарщина, так и наоборот. Вот с «стандартами» то же самое.

но те же китайцы с допотопными SoC на базе ядра i8051 ложили большой и толстый - у них есть ansiС89 и этого достаточно, что бы выпускать «чайники с подсветкой» миллионами и продавать свои микрухи по всему миру десятками миллионов.

Да кто против то? Только я очень сомневаюсь, что они при выпуске чайников вообще рассматривали критерий «А вот, здесь есть стандарт с89»

Как раз наоборот - без стандартов пром-железо никто не возьмёт. OPC Fundation - знакомое слово?

Не слышал, как и большинство пользователей и потребителей. Следовательно твоё утверждение ошибочно, так как большинство берёт но не знает.

И речь шла про производство, там от общей массы ПО - прошивки почти ничто. Реальное производство это всякие системы автоматизации, NX и тд. Какие там у них общие стандарты?

Я конечно понимаю, у тебя своя узкая сфера, но ты пытаешься экстраполировать её на весь мир.

shpinog ★★★
()

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

wtj12
()
Ответ на: комментарий от wtj12

да понятно чем закончится

тем же чем и все форки

если не будут в апстрим хреначить останется иди проектом

мне кажется опыт микроядер многому должен был научить (на самом деле нет)

sartakov
()
Ответ на: комментарий от shpinog

А какие тебе пруфы нужны?

Странно, у меня иные цифры:

    ansic:         271261 (1.58%) 
    asm:         16762933 (97.90%)
    … 
    Total Physical Source Lines of Code (SLOC) = 17,122,750 
Где повторяемость пруфа? Где ссылка на независимый от нашего спора источник? Опять софистика: «Бог есть, потому что я верю, а если ты не веришь - на костёр»!!!

И самое главное - где разбиение по платформам?

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

Там же, где и стандарт на «универсальную» железку. АСМ - это язык железа, а так как железяки постоянно разрабатываются/модернизируются то и АСМ для каждой железки свой.

Не стоит вообще впутывать в данное обсуждение ассемблер - речь идёт о Расте и ядре ОС - как я уже говорил, есл уж пришлось писать код на АСМе - то даже Си не смог его заменить, куда там уж Расту с LLVM.

Так никогда не успевали, и ? Вся эта дрочка вокруг стандартов началась ближе к концу нулевых, до этого вообще все клали поголовно.

Тут согласен, «мягкие» «на всех кладут», к началу 2000 о стандартах никто и не задумывался - все мучились с «купленным» инструментом в виде IDE. Примерно в 2010х годах стандарты вылезли в голову - народ начал думать, «а что дальше» (тогда ещё и С++ уважался с С++11 понеслось)....

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

Опять согласен. В результате остались «на плаву» только огнелис и хром(во всех его разновидностях), линкс`ы и пр. полубраузеры я не считаю.

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

Увы - легаси-код так просто не истребить...

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

Это не религия. Это требования без которых жить и зарабатывать на хлеб не возможно. Либо ты подчиняешься ANSI/ISO/ГОСТ, либо попрашайничаешь в подворотне, а котельная стоит и город мёрзнет.

Вот Вы пишите с компа/ноута/планшета и т.п. электричество, пусть через посредник-АКБ поступает из «розетки». Для того, что бы преобразовать ветер/ядро_урана/кинетику_воды_в реке/и_т_п в это электричество требуется соблюсти сотни тысяч ГОСТов/ISO и пр. стандартов.

Ваш Rust для того, что бы стать одним из них, как C89/C99 не готов. С11 так же не готов - промыщленность его ещё не приняла.

Ну захочется кому-то драйвер написать на расте, мир рухнет? Даже допустим появится группа которая будет переписывать части ядра - just for fun, и?

Сколько эта железяка с драйвером на расте на руках у пользователя будет? Где поддержка когда всё поломается из-за того, что «дяди» решили раст закопать(не дай бог - я только за наличие как много большего инструмента для работы)?

Так у раста свои бумажки RFC.

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

Ну так сам себе и ответил, заодно и напомнил про RFC, благодаря которому мы с Вами и общаемся - опять же речь про следование стандартам, которое помогает прожить продукту(от языка программирования до куска провода) долго и счастливо, а так же субпродуктам, с помощью которых оно сделано (Си и ядро ОС)

Только я очень сомневаюсь, что они при выпуске чайников вообще рассматривали критерий «А вот, здесь есть стандарт с89»

При выпуске «SoC мелочи» на это в первую очередь и смотрят - есть компилятор под ядро или самим пилить? Порты/хидеры/либы нарисовать не долго, а компилятор?

Как много «чистых»(без использования Си-компонентов) Rust-поделок на той же Ардуинке? И сравните с использованием там языка Си...

И речь шла про производство, там от общей массы ПО - прошивки почти ничто. Реальное производство это всякие системы автоматизации, NX и тд. Какие там у них общие стандарты?

Там всё ими опутано. Эти «стандарты» скоро станут моей головной болью, как на предыдущей работе отечественные ФЗ

drfaust ★★★★★
()
Ответ на: комментарий от drfaust

Вот читаешь такие комментарии и думаешь, С такой классный, стандарт, все дела. А потом открываешь новость: 15 лет в ядре жил баг с передачей буфера без его длины. Ну ок…

andalevor ★★
()

Это даже не новость о намерениях, это новость о высказывании о намерениях…

Выпускайте метапрога - народ совсем заскучал!

zabbal ★★★★★
()
Ответ на: комментарий от andalevor

С такой классный, стандарт, все дела. А потом открываешь новость: 15 лет в ядре жил баг с передачей буфера без его длины. Ну ок…

Я последнее время начал на читать что пихает мне в дуалбуте мелкософт для 10ки в «необязательных» обновлениях - ужаснулся. Вы просто не видели настоящий «ДУРШЛАГ»… Причём большинство всё в «модном» .net . Из послднего - проблемы с печатью у kyocera и ещё кого-то - да блин если уж пошли на WSL - возьмите CUPS и не парьте мозг ни себе, ни пользователям.

drfaust ★★★★★
()
Последнее исправление: drfaust (всего исправлений: 1)
Ответ на: комментарий от drfaust

Каким институтом это гарантировано?

Ровно так же как и с С. Заходишь на страничку компилятора и смотришь, поддерживает или нет.

andalevor ★★
()
Ответ на: комментарий от drfaust

был счастлив, что он в ANSI и могу использовать уже готовые формулы.

Неужели перенести формулы в другой язык настолько сложно?

andalevor ★★
()
Ответ на: комментарий от Dark_SavanT
$ which cargo
/nix/store/0hkwhcpjf1p32p85bc555bpykvh220kz-cargo-1.50.0/bin/cargo
$ cargo test
<warnings snipped>
warning: 8 warnings emitted

    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running target/debug/deps/xdr-9f713bcf12f8a893

running 9 tests
test empty_string_test ... ok
test ascii_string_test ... ok
test fixed_length_array_test ... ok
test r_w_primitive_test ... ok
test u16_reader_test ... ok
test string_decode_test ... ok
test u16_writer_test ... ok
test variable_length_array_test ... ok
test utf_8_string_test ... ok

test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests xdr

running 2 tests
test src/lib.rs - (line 10) ... ok
test src/lib.rs - (line 22) ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.19s

balsoft ★★
()
Ответ на: комментарий от drfaust

Проблем с блобом не испытывал со времён GT9600 даже под фряхой.

А я вот словил чёрный экран всего пару лет назад.

andalevor ★★
()
Ответ на: комментарий от Dark_SavanT

А тесты работают? примерно два года назад не компилилось. Возможно починили.

Да:

    Finished test [unoptimized + debuginfo] target(s) in 0.62s
     Running target/debug/deps/xdr-fd023e55024a0e26

running 9 tests
test ascii_string_test ... ok
test empty_string_test ... ok
test fixed_length_array_test ... ok
test r_w_primitive_test ... ok
test string_decode_test ... ok
test u16_reader_test ... ok
test u16_writer_test ... ok
test utf_8_string_test ... ok
test variable_length_array_test ... ok

test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

   Doc-tests xdr

running 2 tests
test src/lib.rs - (line 10) ... ok
test src/lib.rs - (line 22) ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Собирал 1.47.0 stable. Обновился до 1.50 - по прежнему всё собирается.

DarkEld3r ★★★★★
()
Ответ на: комментарий от drfaust

Где повторяемость пруфа?

https://www.quora.com/How-much-assembly-code-does-the-Linux-kernel-contain

Где повторяемость пруфа? Где ссылка на независимый от нашего спора источник? Опять софистика: «Бог есть, потому что я верю, а если ты не веришь - на костёр»!!!

Знатно тебя подрывает. А как всё начиналось? Хотел спросить за количество Асма в ядре, оказалось чёт много, и подъехал знаменитый русский -абасрамс.

И самое главное - где разбиение по платформам?

В коде.

Там же, где и стандарт на «универсальную» железку. АСМ - это язык железа, а так как железяки постоянно разрабатываются/модернизируются то и АСМ для каждой железки свой.

Для каждой платформы, и для х86 их множество, а стандарта нет.

Не стоит вообще впутывать в данное обсуждение ассемблер - речь идёт о Расте и ядре ОС - как я уже говорил, есл уж пришлось писать код на АСМе - то даже Си не смог его заменить, куда там уж Расту с LLVM.

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

Это не религия. Это требования без которых жить и зарабатывать на хлеб не возможно. Либо ты подчиняешься ANSI/ISO/ГОСТ, либо попрашайничаешь в подворотне, а котельная стоит и город мёрзнет.

Да вэб как-то живёт например и куча других сфер, которых на самом деле подавляющие большинство. Где-то стандарты нужны, где-то это RFC как в вебе, и ?

На счёт котельных ты уж слишком загибаешь. Вся эта пляска исключительно из-за замены централизованного водоснабжения на локальное. В СССР автоматизацией ограничивались в ТЕЦ, и то в основном это была электронно-механическая автоматизация.

Так что если что, не помрём.

Для того, что бы преобразовать ветер/ядро_урана/кинетику_воды_в реке/и_т_п в это электричество требуется соблюсти сотни тысяч ГОСТов/ISO и пр. стандартов.

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

ГОСТы регламентируют допуски\технологию производства. Ты их перепутал с СНИПами. И да, госты уже тоже во многом не являются обязательными, их если ты не знал как бы «отменили» заочно, добавив возможность делать по ТУ.

Ваш Rust для того, что бы стать одним из них, как C89/C99 не готов. С11 так же не готов - промыщленность его ещё не приняла.

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

https://www.rust-lang.org/production/users

Сколько эта железяка с драйвером на расте на руках у пользователя будет? Где поддержка когда всё поломается из-за того, что «дяди» решили раст закопать(не дай бог - я только за наличие как много большего инструмента для работы)?

Кто помешает взять раст и скомпилить? Его по твоему куда-то спрячут от всего мира? Возьмёшь старую версию и откомпилишь. Не совсем понятно какие дяди должны решать, если код открыт и является общественным достоянием.

Ну так сам себе и ответил, заодно и напомнил про RFC, благодаря которому мы с Вами и общаемся - опять же речь про следование стандартам, которое помогает прожить продукту(от языка программирования до куска провода) долго и счастливо, а так же субпродуктам, с помощью которых оно сделано (Си и ядро ОС)

Ну так у раста есть свои RFC, чем тебя не устраивает такой расклад?

При выпуске «SoC мелочи» на это в первую очередь и смотрят - есть компилятор под ядро или самим пилить? Порты/хидеры/либы нарисовать не долго, а компилятор?

Компилятор как правило никто не разрабатывает из пользователей, его разрабатывают сами производители этих SoC.

Как много «чистых»(без использования Си-компонентов) Rust-поделок на той же Ардуинке? И сравните с использованием там языка Си…

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

Там всё ими опутано. Эти «стандарты» скоро станут моей головной болью, как на предыдущей работе отечественные ФЗ

NX, 3DMAX, Автокад, 1С производство, и ещё куча всего, где никаких «стандартов» кроме «своих» нет.

shpinog ★★★
()

для меня это звучит как драйвера на жабе, с эксепшенеами, gc, подвисаниями, пожиранием памяти, и медленной работой далёкой от реалтайма

zgen ★★★★★
()
Ответ на: комментарий от zgen

Есть надежда, что будет иначе. Как например с ripgrep.

shpinog ★★★
()
Ответ на: комментарий от drfaust

Проблем с блобом не испытывал со времён GT9600 даже под фряхой.

Проблемы с блобом, что он легко отваливается, едва поменяли версию ядра или иксов.

С AMD-ной картой в этом смысле все надежнее, например, спокойно можно выбирать номер ядра при логине в меню груба. С блобом так не выйдет.

praseodim ★★★★★
()
Ответ на: комментарий от zgen

А для меня это высказывание звучит как нонсенс. Какая к нему предпосылка?

anonymous-angler ★☆
()
Ответ на: комментарий от sartakov

не понимаю зачем нужен раст если есть CHERI

не понимаю зачем нужен CHERI если есть дотнет/mono.

Suigintou ★★★★★
()
Ответ на: комментарий от zgen

Но зато нет висячих указателей и переполнений буфера. Он изначально переполнен и вытекает в своп.

Suigintou ★★★★★
()

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

Hangover
()
Ответ на: комментарий от zgen

Ни эксепшенов, ни гц, ни vm. Памяти растовый код жрёт не принципиально больше, ну и линукс он вообще не про реалтайм так-то.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от cvs-255

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

Эрланг например =))
хочу Эрланг в ядре =))

Minona ★★☆
()
Ответ на: комментарий от seiken

А скоро будет и пара версий ядер - одно нестабильное с Раст, второе - стабильное с Go

menangen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.