В день празднования десятилетия с момента выпуска языка программирования Rust 1.0 (проект Rust был основан в 2006 году, выпуск 0.1 был сформирован в 2012 году, а первая стабильная версия предложена в 2015 году) опубликован релиз Rust 1.87. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63242
Невероятный успех.
За 10 лет стать частью таких проектов как андроид и ядро линукса.
Мало какие языки могут таким похвастаться.
> За 10 лет статьСтал разве что предметом холивapов среди фopумных экспepтов всех мастей.
> Стал разве что предметом холивapов среди фopумных экспepтов всех мастей.А разве форумным экспepтам нужно много для холивара?
Кто застал сра... споры с vs c++ ничему уже не удивляется))
И тогда, кстати, тоже кричали что плюсы не нужны, что это переусложнение... а вот как оно оказалось - плюсы везде, сишки - в нишевом легаси.
Какое легаси? Си во всю используется в проде в компании где работаю. Более того, сейчас с плюсов переписываем овнокод на Си.
> Более того, сейчас с плюсов переписываем овнокод на Си.Пришло время офигительных историй...
> Си во всю используется в проде в компании где работаю.А что за софт, если не секрет?
Похоже он еще не придумал :))
> Похоже он еще не придумал :))Тссс... не спугни. Это очень-очень секретный софт!
А вообще страшно представить насколько плохим должен быть код на любом языке, чтобы его переписывать на сишку! Прям аж ощущается безнадега))
Откуда ему знать. Он не программист, а максимум админ в конторе. И краем уза слышал, что переписывают. То ли с с++ на с, то ли с 1с на паскаль, то ли с немецкого на французский. Тут таких экспердов половина опеннета.
Если сам себя не похвалишь, никто не похвалит.
Так вы сравнивайте языки для системного программирования и все будет ок. Ну и учтите американскую рекламу и закрытый код - работает пропаганда, причем очень хорошо судя по вашему комментарию. Языков программирования для этой цели не так то и много.
> Невероятный успех. За 10 лет стать частью таких проектов как андроид и ядро линукса. Мало какие языки могут таким похвастаться.Не совсем так. Стал? - Стал. Но иные языки программирования возникли, когда ваших проектов еще не было, поэтому никак не могла стать их частью. Кстати, ваши проекты написаны целиком на вашем языке? - Не думаю. И далее, сделать пару утилит, скомпилировать - какая разница, на чем были исходники? В-общем, эйфория не оправдана. Хотя если вам это доставляет радость, ну и хорошо, поделитесь ей. Еще один язык, каких десятки, празднует юбилей. Не более того.
> Но иные языки программирования возникли, когда ваших проектов еще не было, поэтому никак не могла стать их частью.Феерично... Л - логика... А какие языки тогда выбираются и "становятся частью наших проектов" - несуществующие? Из далекого будущего (ну раз возникшие ДО проекта - не могут)? Проекты _обычно_ создаются на УЖЕ СУЩЕСТВУЮЩИХ языках. На несуществующем языке новый проект устанешь делать (очень редко и проект и язык под него создаются одновременно).
Поэтому если какие-то языки "никак не стали частью проекта", то это только означает, что когда задумывались эти "ваши проекты" эти УЖЕ СУЩЕСТВУЮЩИЕ "иные языки" оказались не нужны этим проектам. Иначе бы их выбрали для реализации, логично? Или Вы под каждый новый проект новый язык придумываете?>> За 10 лет стать частью таких проектов как андроид и ядро линукса
В продолжение к первой умопомрачительной цитате: а тут даже наоборот - языка еще долго не существовало, когда возникли проекты, но он (язык) показался разработчикам настолько хорош, что они его включили в разработку спустя десятилетия. "Невероятный успех".
Успех будет, когда у него появится нормальная IDE.
Проще. Когда стандартизируют. А пока он просто рыжая струя.
чем тебе RustRover не нормальная?
451 Unavailable For Legal Reasons
Это прикол такой?
Как доступность/недоступность для скачивания определяет «нормальность» IDE?
Это прикол такой?
> Как доступность/недоступность для скачивания определяет «нормальность» IDE?
> Это прикол такой?Нет.
Это вполне "нормальное" заявление, когда аргументы закончились)
Думаю следущим будет "нашего брата ущемили на дискорде", потому язык плохой, а IDE еще хуже.
> потому язык плохой, а IDE еще хуже.Как это проверить, если скачать и ознакомиться нельзя?
> доступность/недоступность для скачивания определяет «нормальность» IDE?Дело не только в этом.
Она ведь ещё и коммерческая, там же нет community версии.Но самое главное, ОНА НЕ НА РАСТЕ, что немного позорно для раста.
> Она ведь ещё и коммерческая, там же нет community версии.Вообще-то есть - Free for non-commercial use
jetbrains.com/ru-ru/rust/download/?section=linuxА по второму набросу... было бы странно, если бы jetbrains не переиспользовали имеющиеся код своих IDE.
На Haiku работает? Набросы-набросы. Если не работает, скажите прямо - не работает. Прощу всё, но не враньё.
Если на Haiku джава работает, то и это и по идее должно.
> было бы странно, если бы jetbrains не переиспользовали имеющиеся код своих IDEА у нас кроме JetBrains больше никто не может IDE создать? Растоманы видимо не в состоянии.
Если вы не заметили, то IDE сейчас не в моде, если говорить про некоммерческие варианты. Сейчас в моде модульный подход, когда языковой сервер, текстовой редактор, и куча других утилит не прибиты друг к другу гвоздями, а свободно заменяются. И с этим у rust всё хорошо.
А ты точно программист, если ты даже VPN поднять не можешь?Может тебе рано ещё IDE пользоваться?
Знаю массу людей из России, которые пользуются продуктами Джет Брейнз.
Или ты из принципиальных, запрещено - знач не буду?
> Успех будет, когда у него появится нормальная IDE.Само собой. Но добавлю еще требования: поддержка основными компиляторами для основных (всех?) ОС, также отладчики, основные фреймворки типа Qt, библиотеки опять же (включая математику, те же IMSL, ESSL и другие). Словом экосистема должна быть. И всё должно быть на этом вашем новом языке - без прослоек в виде extern "C" (а не как в Python или R - языки, да, но куда не сунься, попадаешь на С/С++).
Как в фильме - у нас (вас) всё будет. Лет через 30. Может быть.
для Rust есть GUI либо Slint"Slint is an open-source declarative GUI toolkit to build native user interfaces for Rust, C++, JavaScript, or Python apps."
Хочу GCC на Qt на FreeBSD. Можете на вашем языке? А на C++ можем.
> на Qt на FreeBSD.Можем. Берешь cxx-qt и билдишь для таргета x86_64-unknown-freebsd
> Хочу GCC
А вот с gcc не получится - у них лапки из дупки и раст они не осилили.
> А на C++ можем.
Поздравляю. Вот только не понятно вообще зачем что-то билдить под такую маргинальную платформу.
> Вот только не понятно вообще зачем что-то билдить под такую маргинальную платформу.Чтобы заявить о поддержке нашим ПО всех 5-ти основных платформ.
>> Вот только не понятно вообще зачем что-то билдить под такую маргинальную платформу.
> Чтобы заявить о поддержке нашим ПО всех 5-ти основных платформ.Ахаха, это вы бздю в основные платформы записали?
Давайте туда еще Хурд и Гайку запишем)))
В Genode OS ещё требую!!! И Колибри, пжалста.
> За 10 лет стать частью таких проектов какЯ тебе открою страшную тайну - есть языки, которые стали частью больших проектов сразу же после появления, по той простой причине, что создавались как инструмент для конкретной задачи. Раст же создавался не ради задачи, а ради особенностей ("безопасная работа с памятью", "высокий параллелизм"), и десять лет не имел никакого применения, кроме как быть знаменем кучки крикливых токсичных фанатиков.
>Я тебе открою страшную тайну - есть языки, которые стали частью больших проектов сразу же после появленияКривизна доморощенного велосипеда никак не исправляется наличием проекта, для которого этот самый инструмент навелосипедели
> Я тебе открою страшную тайну - есть языки, которые стали частью больших проектов сразу же после появления, по той простой причине, что создавались как инструмент для конкретной задачи.Да. Например Го.
> Раст же создавался не ради задачи, а ради особенностей ("безопасная работа с памятью", "высокий параллелизм"),
Т.е то что нужно в куче программ?
Не каждому нравится дарить рут из-за очередной ошибки "заблудился в трех буферах".> и десять лет не имел никакого применения,
Хехе, если у тебя телефон на андроиде, то выкинь его - там же куча растокода)
> кроме как быть знаменем кучки крикливых токсичных фанатиков.
да-да, амазон, гугл, майкрософт, клоудфларя, а так же лично Грег Хартман - это просто крикливые фанатики...
Спасибо что открыл мне глаза!
Кстати у тебя нос упал 🔴.
> да-да, амазон, гугл, майкрософт, клоудфларя, а так же лично Грег Хартман - это просто крикливые фанатики...Почему нет?
> Почему нет?Потому что они реально используют раст в своих кодовых базах.
Причем все кроме линя, где диды все еще копротивляются, в существенных количествах.
Посему у нас идет спор между теми, кто что-то рельно делает, и теми, кто где-то что-то слышал.
> Хехе, если у тебя телефон на андроиде, то выкинь его - там же куча растокода)Кхем-кхем, его там пара процентов от силы.
> Язык сфокусирован на безопасной работе с памятьюЕщё в турбопаскале под ДОС это всё можно было делать. В чём прикол? Только не говорите, что мол, в паскале это рантайм. Да, рантайм. Но если писать для bare metal что-то системное, то все эти фичи в Rust нафиг не нужны и вы всё равно пишете с unsafe.
Так прикол ещё в том, что Паскаль это делал безопасно и быстро на машинах того поколения, современные процы переварят подобные проверки в рантайме и не захлебнутся.
На машинах того времени и операционнки не всегда были, и все было безопасно по умолчанию.
>> обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами, учёт времени жизни объектов (области видимости) и оценку корректности доступа к памяти во время выполнения кода.
> Ещё в турбопаскале под ДОС это всё можно было делать. В чём
> прикол? Только не говорите, что мол, в паскале это рантайм. Да,
> рантайм. Но если писать для bare metal что-то системное, то все
> эти фичи в Rust нафиг не нужны и вы всё равно
> пишете с unsafe.Прикол тут видимо лишь в громком и унылом выпуске метана Военами Супротив Раста - причем каждый раз одной и той же тональности ...
Кстати, Воен(ы) - вы бы хоть разок посмотрели, что такое unsafe, что ли:
You can take five actions in unsafe Rust that you can’t in safe Rust, which we call unsafe superpowers. Those superpowers include the ability to:Dereference a raw pointer
Call an unsafe function or method
Access or modify a mutable static variable
Implement an unsafe trait
Access fields of a unionIt’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety.
Проблема рacта не в самом языке, а в его крайне тoкcичном сообществе. И интонация в твoeм кoммeнтapии тому ярчайшее доказательство.
Вот вот. Если бы не сообщество, язык многим бы зашел.
Вам сообщество мешает использовать язык? Вот прям стоит над вами и поносит вас скверными словами? Какой же отборный бред.
> крайне тoкcичном сообществеНа реддите постоянно всплывают такие посты кстати, что люди из-за сообщества интерес к языку теряют.
Пфф. Это либо откровенная ложь, либо рационализации, в тех случае когда реальная причина либо неизвестна самому говорящему, либо ему не хочется в ней признаваться.Я по жизни увлекался разными языками, и когда какой-то язык меня увлекает, меня увлекает язык, а не сообщество. Тут вопрос причины и следствия: если я хочу быть членом сообщества и для этого изучаю язык, вокруг которого сообщество сформировалось, то да, токсичность сообщества -- это повод отказаться от языка. Но если я контактирую с сообществом, потому что оно состоит из людей с интересами, пересекающимися с моими, то токсичность сообщества может быть поводом отказаться от контактов с ним, но не от моих интересов.
Зачем оно вообще нужно это сообщество? Мне кажется, что есть две основные нужды, которые сообщество может удовлетворить. Во-первых, это ответы на вопросы, во-вторых совместная разработка. С "во-первых" если ты знаешь примеры тому, как люди не могут получить ответы на вопросы связанные с растом, то мне было бы интересно посмотреть, поскольку я не знаю как там дела с этим обстоят: я сам не задаю вопросы, если гугл не знает ответов на мои вопросы, я задаю их знакомым. С совместной же разработкой, какое тебе дело до сообщества? Ты общаешься с ограниченным кругом людей, а не с сообществом.
Короче, не надо верить всему, что люди говорят. Надо включать голову и разбирать их заявления критично.
Что удивительно, потому что Реддит это та ещё эхокамера.
Видимо, растосектанты настолько достали "своих", что их критикуют даже там.
Кстати иам в коммeнты под постом обязательно сиюминутно налетают растовики и начинают разводить демагогию в своём стиле и лайкают друг-друга. Серьезно кажется, что это какая-то агрессивная ceкта. Больше ни в одном комьюнити из других языков такого не видел.
Значит, кто-то сильно заинтересован в продвижении раста и тратит на это деньги
Конечные фанатики могут работать за идею, но, сбор их в кучу и организация и направление их активности - это уже требует каких-то но денег и смежных расходов, причём, постоянно
Я бы предположил прямо противоположное - кто-то форсит агрессию, потому что реально не хочет, чтобы раст пошёл в массы, а хочет чтобы он оставался уделом Гугла и Клаудфлары.
А я бы предположил, что владельцы ресурсов, где эти файты между агрессорами и фанатами происходят, держат на зарплате троллей, которые вбрасывают иногда с обеих сторон, чтобы файты не утихали. Это же всё клики. Attention Economy, вы что никто не слышал про неё? Я даже не удивлюсь, если они сейчас уже не держат на зарплате троллей, а вбрасывают искусственным интеллектом.
> кто-то форсит агрессию, потому что реально не хочет, чтобы раст пошёл в массы,Хм.. предположение интересное, но как ты себе это представляешь?
Если меня интересует какой-то ЯП, то я иду на офф.сайт и читаю документацию.
Меня мало волнуют какие-то kykареки на форумах.Думаешь есть большая масса людей, которая почитав срач решит "что-то не хочу связываться"?
> хочет чтобы он оставался уделом Гугла и Клаудфлары.
Но и у первых, и у вторых код открытый.
Ты можешь буквально построчно изучить что и как они делают.ps ИМХО тут сpач скорее спортивный - просто ради сpача и сброса агрессии, типа как фанаты футбольных команд.
> Меня мало волнуют какие-то kykареки на форумах.потому что ты можешь их не читать. Есть еще вариант, что свой продукт ты открывать не будешь.
А можно вспомнить драму с actix-web, когда какие-то kykареки целенаправленно искали автора.
В репу гугла такие деятели вряд ли пойдут, а к обычным людям вполне
Не совсем комьюнити языков, но сравни комментарии под постом эхокамеры и эхокамеры побольше.
https://www.reddit.com/r/godot/comments/1kdp57g/my_first_ste.../
https://www.reddit.com/r/gamedev/comments/1kdozd9/my_first_s.../
"Why are you downvoted lol. Open source doesn't mean anything when it comes to fixing regression. It could be that a bug will be fixed in a day, or a year."
"It's this weird combination of toxic positive and elitism; Godot can do no wrong but if something is wrong then it's your fault and the engine is open source so just go fix it yourself. And don't even get me started on the whole "Godot has <x> feature" parroted by people who have obviously never used said feature and dealt with its excruciatingly long list of caveats and issues."
Комментарии подобного рода если и появляются под первой ссылкой, они сразу улетают в минуса, а пользователи оказываются [DELETED].
>растосектантырастоманы?
> Проблема рacта не в самом языке, а в его крайне тoкcичном сообществе.Опять это мифическое "сообщество".
Извини, но на Расте пишут дяди на зарплате корпораций, и на визжания интернетных непойми кого им глубоко наплевать.
Разработчики "стандарта" языка токсичные. Чего тут непонятного?
А можно пример?
Ну типа "вот чел в pull request'е посылает всех матом, его работодатели из гугла/хуавея/майкрософта закрывают глаза на такое некрасивое поведение".
Пока это выглядит как "на меня наорал случайный чел на реддите и я обиделся!"
Был эпизод, когда вся команда модерации уволилась из за поведения Центральной команды.
https://github.com/rust-lang/team/pull/671
Лол. И из-за этого все эти визги про токсичность?
У вас типичный пример демагогии в токсичной манере.Вот из-за таких комментариев и идут "визги про токсичность".
Взрослые люди решают возникшие конфликты, дети ходят обиженные и ноют.
Кто есть кто - смотрите сами.
Рабы работают на чём прикажут, это и так ясно. Нашёл, чем гордиться. Опеннет-эксгибиционист.
Самодостаточные парни из Сообщества(TM) выбирают инструмент по душе. Не завидуй.P.S. Такой большой дядь, а всё на подсо^W зарплате у корпораций..
> Рабы работают на чём прикажут, это и так ясно. Нашёл, чем гордиться.Ты совсем тугой?
Ты смотришь на вакансию, если там то что тебе нравится - ты ее принимаешь.
И все.> Самодостаточные парни из Сообщества(TM) выбирают инструмент по душе. Не завидуй.
А следовало бы "инструмент под задачу")
Чтобы потом всякие маргинальные поделки не рождались в муках и дохли, как только первый и последний мейнтенер переехал от мамы и ее пенсии.> P.S. Такой большой дядь, а всё на подсо^W зарплате у корпораций..
ps Примерно как и разработчики, которые пишут почти 90% кода в ядре.
Могу собой гордиться.
ps2 всякие "сосательные" аналогии это обязательный аттрибут Сообщества™ или это просто твоя особенность?
>> Рабы работают на чём прикажут, это и так ясно. Нашёл, чем гордиться.
>Ты совсем тугой?
>Ты смотришь на вакансию, если там то что тебе нравится - ты ее принимаешь.Нет. В каждой области есть какой-то определённый список языков, на которых вам неизбежно придётся работать. И чем сильнее вы будете погружаться в эту область, тем меньше у вас будет выбор. Хорошо если у вас будет выбор между топ 10 языками
>А следовало бы "инструмент под задачу")Было бы сказано. Инструмент выбирается в первую очередь по хайпу: количеству библиотек, доступности разработчиков, обкатанности в определённой области. И каким бы хорошим не был новый инструмент, раскрутится ему будет крайне тяжело. Именно по этому почти все языки в топ 10 из нулевых и раньше. Поскольку на раздутие хайпа нужны ресурсы типа гугловских, когда они голанг раскручивали
Никогда не замечал такого. Наоборот, ребята, которые на крестах пишут влазят в любой тред про любой ЯП и начинают вонять.
>Никогда не замечал такого. Наоборот, ребята, которые на крестах пишут влазят в любой тред про любой ЯП и начинают вонять.назвать чёрное белым - невероятно продвинутая техника среди ддибилов, потому что среди других людей не очень эффективна.
Кто постоянно пишет под всеми практически новостями не про раст про некую. "дыряшечку"? Кто потоянно пишет про раст в темах не про него? Наверно это те ребята которые пишут на крестах? В такое поверит только дибил.
> Кто постоянно пишет под всеми практически новостями не про раст про некую. "дыряшечку"?Почему это про некую? Пишут про очень даже определенную "дыряшку". Это же просто сокращение от "дырявая сишка".
> Кто потоянно пишет про раст в темах не про него?
Сишники!
Вот тебе отличный пример opennet.ru/openforum/vsluhforumID3/136833.html#2
В новости про сишный GNU screen человек пишет про сишную же функцию strncpy... и дальше прибегают сишники с криками "а вот в вашем расте, пок-пок-пок"Или вот opennet.ru/openforum/vsluhforumID3/136272.html#16
Новость о неисправленной на тот момент уязвимости. Приходит клоун и начинает пурну про растовиков гнать. Хотя это известный персонаж на опеннете и его овнокод на сишечке все уже успели оценить.Они сами первый приплетают раст!
И таких примеров просто сотни, ужас-то какой!
Зачем? Вот как это называет???> Наверно это те ребята которые пишут на крестах?
Нет, в основном пишут те, которые вообще ни на чем не пишут. Остальные - это пейсатели на дыряшке, которым обидно что в их любимке очередную классическую дыру нашли.
>Проблема рacта не в самом языке, а в его крайне тoкcичном сообществеНичуть не токсичнее сишников и крестовиков. Напишет кто-то программу на голанге, так ему сразу начнут предъявлять, что это у вас тут за бинарники на 30 Мб. А если на java...
А на джаве просто неприкрытая зависть. У джавистов легаси в банках полно.
А кривым кодом самой продаваемой на свете игры (Minecraft) можно троллить сишников.
> Проблема рacта не в самом языке, а в его крайне тoкcичном сообществе.Т.е. "аргументы" окончательно кончились (хотя там, в методичке, должно еще быть про жирный и не отключаемый рантайм и проч), начались виляния ...
>> Растоманы
>> растосектанты
>> растоверов-евангелистов
> И интонация в твoeм кoммeнтapии тому ярчайшее доказательство.Че, "свое не пахнет"?
> Ещё в турбопаскале под ДОС это всё можно было делать. В чём прикол?Ну... можешь писать на турбопаскале под ДОС, кто ж тебе запрещает)
> Только не говорите, что мол, в паскале это рантайм. Да, рантайм. Но если писать для bare metal что-то системное, то все эти фичи в Rust нафиг не нужны и вы всё равно пишете с unsafe.
А если нет) Чо если нет?
Надеюсь раст исправит хотя бы ошибки вида "28 раз нажал backspace, получил рута".
> Надеюсь раст исправит хотя бы ошибки вида "28 раз нажал backspace, получил рута".Не опасаетесь, что в вашем языке окажется, скажем, "228 раз нажал backspace, получил рута". Если кто-то проверил 28, кто помешает ему проверить 228?
>В чём прикол?В нибируанском синтаксисе.
Я тоже считаю, что у руста идиотский синтаксис.Сделали бы нормально, как в Си, javascript, или bash.
> Сделали бы нормально, как в Си, javascriptИ как ты предлагаешь внедрить в такой синтаксис аннотации времени жизни для чекеоа борова?
> или bash.
Извини, но вот это уже дурка.
Давай, клонируй раст и поменяй в нём синтаксис, разумеется, если осилишь лапками
Например, программу на С можно сделать внешне очень похожей на тот же паскаль или что-угодно с помощью #define. В вашем языке, вернее всего, это тоже можно сделать. Только нужно ли? Думаю, это просто трата времени.
> Ещё в турбопаскале под ДОС это всё можно было делать. В чём прикол?Borrow checker и RAII в турбопаскале?
В расте не сухари, а крутоны! Не блины, а панкейки!
Крутон - это сухарик который обжаривается в масле или в тостере, может быть пропитан молоком или обвалян в яйце.
Сравнивать его с general сухарем, который могли сушить на печке или просто под крышей, слегка странно.Панкейки - это толстые "блинчики", которые больше похожи на оладушки по форме и толщине.
Готовятся с молоком и крахмалом, иногда и с маслом.
В отличии от блинов, которые могут делаться на кефире, ряженке или сыворотке.
Если какой-то невежа будет называть тонкие блины панкейками, то я готов плюнуть ему в лицо (и в тарелку)).
> Крутон - это
> Панкейки - это
> В отличии от блинов, которыеНу так не удивительно.
У сишников всегда были проблемы с типизацией, вот они даже блюда отличить не могут.
> В отличии от блинов, которые могут делаться на кефире, ряженке или сыворотке.Рецептов блинов много. То, что сказали Вы - подобие кислых блинов. По уму надо для них дрожжевое тесто специально заводить, однако можно и так либо развести обычное тесто до нужной консистенции, добавив яйца. Но я люблю пресные блины - делаю на молоке, однако обязательно добавляю столовую ложку 25% сметаны (на литр 3,2% молока) для некоторого поднятия жирности и специфического сливочно-кислого оттенка вкуса, характерного для деревенских блинов (имитация, но что делать). Главный секрет вкусных блинов - в муке. Не буду называть здесь, но предпочитаю муку только одного производителя.
> Рецептов блинов много. То, что сказали Вы - подобие кислых блинов.На молоке они кислыми не будут.
> По уму надо
Использовать нормальные аналогии.
Персонаж выше начал сравнивать разные блюда и умничать.
В итоге сел в лужу.ps а еще можно вспомнить пасту "блины без муки" и "сбор угашенных об дерево"))
Крутон - это сухарик который обжаривается в масле или в тостере, может быть пропитан молоком или обвалян в яйце.То есть, крутон это либо сухарь, либо гренка?
Зачем тогда этот термин?
> То есть, крутон это либо сухарь, либо гренка?
> Зачем тогда этот термин?Зачем нужны уточняющие термины? Ну даже не знаю))
Сухарь это любой сушеный хлеб (и даже некоторые люди или часть механизма).
Где он сушился всем побоку.А у крутона есть способ приготовления, который и определяет название.
Крутон - неопределённый термин. Это либо сухарь либо гренка. Зачем?
Для блинов самый близкий аналог - это французские crepes. Панкейки, как сказал анон, СЛИШКОМ толстые для этого.
https://en.m.wikipedia.org/wiki/Cr%C3%AApe
>Ещё в турбопаскале под ДОС это всё можно было делать.Нельзя, поскольку в турбопаскале нет линейных и даже афинных типов
>Только не говорите, что мол, в паскале это рантаймРазумеется, не только сишники не обременены знаниями, сторонники паскаля точно такие-же. Про зависимые типы они ничего не слышали. И даже сейчас, когда им в 100500 раз указали на чудовищный пробел в их знаниях, они опять ничего не поняли
С нетерпением жду тот день, когда си будет там же где и паскаль, в настольгии стариков, которые только и настольгируют, а программы не пишут
> в турбопаскале нет линейных и даже афинных типовВидимо потому, что оно нафиг не нужно? Не приходила тебе такая мысль в твой гуманитарный мозжечок?
Паскаль не нужен, всецело согласен. А зависимые и афинные тип нужны
Мякотка в том, что и у раста рантайм, и довольно жирный и запутанный.
> Мякотка в том, что и у раста рантайм, и довольно жирный и запутанный.И основывается эта "мякотка" на каких-то реальных фактах или обыкновенном "мы все на опеннете это повторяем, а значит это правда!"?
> вы всё равно пишете с unsafeТак и задумывалось. Это механизм локализации кода, который требует ручной проверки.
Действительно, жаль что язык стал жертвой своего же сообщества и токсичного маркетинга, фичи у него интересные.
Стал бы я использовать его в своих личных проектах? Думаю что нет.
Я одержим максимальной производительностью, и в этом плане си все еще впереди. Ну и я в состоянии следить за указателями в своих проектах, где кода пара тысяч строк.
Сообщество всё портит. Факт. Причем это не чисто наш менталитет, американцы на реддите жалуются постоянно.
> Причем это не чисто наш менталитет, американцы на реддите жалуются постоянно.А разве реддит не был создан для того чтобы ныть и жаловаться?
У них могут быть 2 соседних темы, участники которых жалуются друг на друга "какие те плохие, а мы хорошие"))Да и "сообщество" это размытое понятие - вон у линукса тоже есть сообщество, крикливое и поавнивающее, но код пишут чуваки на зарплате корпораций.
> я в состоянии следить за указателями в своих проектахВсе так думают. Но человеческий мозг -- это мясо, а не машина по точному определению того, какую память освобождать, а какую нет. Ты уверен, что мясо способно на точные математические задачи? У тебя калькулятор электронный или мясистый? Машина должна следить за указателями, а от мяса требуется лишь подчиняться боров-чекеру.
У кого мясо, у кого тонкая нейросетка. Вот первым раст зайдёт таки. Потому что да, от мяса требуется только подчиняться.
> Потому что да, от мяса требуется только подчиняться.Господи, кто о чем, а Tron is Whistling все о подчинении и кнутах. У тебя травма какая-то на этой почве, или что?
Там было ещё не просто подчиняться, а борову подчиняться. Хочешь попробовать?
> Там было ещё не просто подчиняться, а борову подчиняться. Хочешь попробовать?Угу, а еще "подчиняться" ПДД, ПУЭ и здравому смыслу)
По дороге на работу я часто (слишком часто к сожалению) вижу борцунов с системой, которые то на красный проезжают, то по обочине пробку объезжают.
И помни, изоляцию проводов придумали специально чтобы тебя подчинить и ограничить!
Так что лезь в щиток сразу мокрыми руками)
вы забыли упомянуть про ремни и подушки безопасности, динозавров которые вымерли, извощиков разных
(надеюсь я больше ничего не пропустил из кривых аналогий)
Спасибо что добавил.
"Кривость" аналогии у тебя определяется чем?
Вон чела выше боров угнетает. Я уже боюсь представить кто или что над ним доминирует и унижает, что он аж про "подчинение" написал.
Давай покажи мне кривость следующей налогии:Раст - это смирительная рубашка.
И да, если ты "подчиняешься" ПДД - у меня для тебя плохие новости, адепт садо-мазо вовсе не я. Потому что ПДД не подчиняются, ПДД соблюдают.
Если ты "подчиняешься" борову, то у меня для тебя еще худшие новости...
Борову не нужно подчиняться, нужно просто писать соблюдая правила владения и ты никогда не увидишь ошибок от него. Элементарно же!
Не юли. Подчиняться борову ты хорошим счёл.
И к кому Вы себя относите, к мясу или тонкой нейросети?
Безопасность и производительность всё равно не сильно дружат, глядя на ситуацию с процессорами.
Вот что действительно жаль - это что находятся подобные личности, которые считают, что техническое средство плохое не потому, что у него не хватает каких-то технических же возможностей, а потому, что им пользуется (или его рекламирует) неприятный тип. Почему жаль? Потому что у таких людей явные проблемы с логическим мышлением. Но при этом у них находятся сторонники, которые тоже, увы, обделены природой в этом плане. И вот эти все горлопаны в итоге и придают негативную окраску довольно таки продвинутому языку программирования.
> Ну и я в состоянии следить за указателями в своих проектах, где кода пара тысяч строк.Круто что ты можешь себе позволить такую роскошь - писать проекты (как же гордо это звучит!) на целых пару тысяч строк! Даже интересно стало, что же они делают, если написаны на таком многословном языке как си.
Стоит ли изучать как первый ЯП?
Нет. Как первый яп лучше взять си. На него и документации гора, и язык заметно проще. А после си уже можно учить хоть раст, хоть го, хоть динамические языки. Си - это хорошая основа.
Начинать с Си - это ошибка. Сам начинал с C++.Возьмите лучше Джаву.
жабу до пенсии можно изучать и так и остаться дураком
либо потому что не доучил, либо - потому что появился котлин и жабаненужна
Когда я говорю Джава, на самом деле я имею в виду Котлин.
На собственном примере или от балды придумали?
МЫ сначала учили Си, потом С++. Если ты знаешь СИ, то любой другой сможешь. Начинать изучать с Java это ошибка.
> Если ты знаешь СИ, то любой другой сможешьС чего ты взял? Ты слышал что-нибудь про парадигмы языков или концепции?
Если ты учил только голоый Си, то тебе тем как минимум надо будет осваивать концепцию ООП.> Начинать изучать с Java это ошибка
Вы что, сразу собираетесь заниматься системным программированием?
Начните-ка лучше с прикладного, а дальше уже как пойдёт.
начиная с джавы, ты уже никогда не поймёшь, как оно работает под капотом
Если вы в программирование пришли по призванию, а не просто деньги загребать, то это чушь собачья.
> Если вы в программирование пришли по призванию, а не просто деньги загребать, то это чушь собачья."По призванию" это как?
Работать бесплатно? Писать попенсорс для бесполезных и неблагодарных?
Зарабатывать деньги это не грех и не какое-то преступление.
Труд должен быть оплачен.
> бесполезных и неблагодарныхПочему неблагодарных? Вполне благодарных.
Ты что-нибудь слышал про экономику дарения?https://ru.wikipedia.org/wiki/Экономика_дара
> Труд должен быть оплачен.
Мартышкин труд наверно тоже должен быть оплачен.
> Почему неблагодарных? Вполне благодарных.Почитай комментарии про дроп старого железа, где "благодарные" пользователи проклинают программистов, вместо того чтобы сказать "спасибо что поддерживали наш хлам столько лет".
Причем их совершенно не волнует что у программера просто нету ресурсов. Они решили что ОН ОБЯЗАН! и будут стоять на свое до конца.Или посмотри комментарии про КДЕ и банер с просьбой задонатить.
> Ты что-нибудь слышал про экономику дарения?
> https://ru.wikipedia.org/wiki/Экономика_дараОтличная ссылка.
Эта идеология использовалась во всяких туземных племенах, среди пиратов софта (ну легче же просто скачать пиратку, чем сделать что-то самому)
Термин придумал какер-либертарианец.
Насколько помню ни туземцы, ни либератариасты не смогли построрить успешное сообщество.>> Труд должен быть оплачен.
> Мартышкин труд наверно тоже должен быть оплачен.Если нашелся кто-то, кому он подходит - то почему бы и нет.
Иначе не было бы профессии скомороха или клоуна, и никто не плясал в фурри-сьюте антилопы.
> пользователи проклинают программистовТакие пользователи всегда найдутся.
Программеру и не надо всех выслушивать, он просто делает то, что считает нужным.> Эта идеология использовалась во всяких туземных племенах
Если ты внимательно читал, то там кроме туземцев есть и другие примеры.
Опенсорс тем и хорош, что вы выкладываете библиотеку, кто-нибудь её использует и выкладывает другую библоитеку, таким образом выстраивается экосистема. Программисты дарят библиотеки обществу, и при этом взамен получают все библиотеки от этого общества.
Даже если вы ничего не даёте обществу, вы всё равно получаете всё бесплатно. Это позволяет вам обучаться и накпливать опыт, изучая чужой код.> ни туземцы, ни либератариасты не смогли построрить успешное сообщество
Опенсорс сообщество уже стало успешным.
> Иначе не было бы профессии скомороха или клоуна
Художественное творчество штука субъективная.
> Такие пользователи всегда найдутся.
> Программеру и не надо всех выслушивать, он просто делает то, что считает нужным.Ага.
А потом мейнтейнеры сваливают, тк им такие деятели начинают слать угрозы.> Если ты внимательно читал, то там кроме туземцев есть и другие примеры.
Я читал внимательно.
А ты мог бы эти другие примеры привести. Если они конечно существенные.
> Опенсорс тем и хорош, что вы выкладываете библиотеку, кто-нибудь её использует и выкладывает другую библоитеку, таким образом выстраивается экосистема.Или начинается базар-вокзал с кучей форков.
Типа как либре-коре-каное-бут.
Или как пару сортов БСД.
Или как 100500 дистрибутивов различной степени васянистости.> Программисты дарят библиотеки обществу, и при этом взамен получают
... фигу)
Как например создатель curl'а.
А когда он пробует сделать платные LTS - то его предсказуемо объявляют предателем.> все библиотеки от этого общества.
Даже если это дырявый кусок кода на СИ, который ему нафиг не нужен.
> Даже если вы ничего не даёте обществу, вы всё равно получаете всё бесплатно. Это позволяет вам обучаться и накпливать опыт, изучая чужой код.
Я предпочту брать платно и отдавать тоже.
Играть в коммунизм у меня желания никакого нету.
>> ни туземцы, ни либератариасты не смогли построрить успешное сообщество
> Опенсорс сообщество уже стало успешным.Только если за ним стоит корпорация или бизнес.
Без финансирования проекты сдыхают слишком быстро.
Ага, даже корпорации играют в коммунизм. А они в отличии от тебя знают выгоду.Вообще ПО сильно отличается от других продуктов: если ты подарил или продал (не исключительные права на ПО) то само ПО у тебя остаётся. Легко сделать хоть миллиард копий ПО. К примеру такое с автомобилями сделать нельзя.
ты не путай свои джава-курсы с людьми, которые сами всё учили
Вот ты и не путай.Ты щас сам себе только что и ответил.
Нормальный программист по призванию это самоучка. Он не идёт на курсы, чтобы потом хорошо устроиться, а просто изучает то, что ему интересно.
> Нормальный программист по призванию это самоучка.Какое пафосное разделение.
А есть определение "нормальности" для программистов?> Он не идёт на курсы, чтобы потом хорошо устроиться, а просто изучает то, что ему интересно.
Он может идти в университет и получать фундаментальное образование.
Как делали создатели что СИ, что паскаля.
Да он будет учиться всю жизнь (или по крайней мере пока работает программистом, а не идет пасти гусей).
> А есть определение "нормальности" для программистов?Ну разумеется.
Это явно не вайбкодер.
Он способен учиться сам, может заставить себя почитать чужие исходники и починить баги. Он пишет на универсальном языке (не HTML, не SQL, не Bash) и немного знает ещё несколько языков. Он не брезгует опенсорсом, разбирается в экосистеме, сборке ПО, инструментах. И этим надо заниматься долго и интенсивно, 5 лет минимум.
Ну тут ещё есть что дополнить.
Правда "нормальность" штука относительная. В одном сообществе ты будешь хакер крутой, а в другом быдлокодер.> Он может идти в университет и получать фундаментальное образование.
> Как делали создатели что СИ, что паскаля.Для этого надо обязательно идти в унивеситет? Сами учиться не способны?
Хороший универ надо ещё поискать, и заплатить, а то так и не станете "нормальным" программистом.
> Он способен учиться сам, может заставить себя почитать чужие исходники и починить баги.Т.е это не 99% сишников который уже 50 лет не могут победить use-after-free и double-free, делают ошибки в размере буфера и пишут велосипеды для сплита строки (в которых тоже ошибаются, кто ж мог подумать!?).
Ошибки которые делают даже мега-прогеры типа Теодора Тцо, который написякал CVE которая жила 9 лет.> Он пишет на универсальном языке (не HTML, не SQL, не Bash) и немного знает ещё несколько языков.
Т.е это не 99% сишников, которые не хотят учить ничего нового кроме С89, тк это же надо включать мозг и вообще ваши луы и пихоны для смузихлебов.
Максимум это С++ на котором они пушут как на СИ.> Он не брезгует опенсорсом, разбирается в экосистеме, сборке ПО, инструментах.
Опенсорсом невозможно "брезговать", тк большая часть прикладного софта это свободные лицензии типа МИТ.
Миллиарды людей используют опенсорсный хром или андроид.> И этим надо заниматься долго и интенсивно, 5 лет минимум.
Т.е 5 лет обучения в универе)
> Правда "нормальность" штука относительная. В одном сообществе ты будешь хакер крутой, а в другом быдлокодер.
О, а это уже ближе к правде.
Потому что супер крутой эмбедедщик может обделаться на этапе "сделать gui", а игродел напишет код, для которого падение "ну ничего страшного".> Для этого надо обязательно идти в унивеситет? Сами учиться не способны?
Именно потому что способен, то лучше пойти в место где мне готовы предоставить знания.
> Хороший универ надо ещё поискать, и заплатить, а то так и не станете "нормальным" программистом.
А ты думал бдет легко?
Чтобы учиться самому, нужно точно так же поискать хорошие книги, хорошие обучающеие курсы и тд.
По крайней мере не будет иллюзий, что понимаешь.
Знаешь, в школах преподают ньютоновскую физику. Она в принципе в корне неверна по сравнению со спешал релативити и прочей квантовщиной, но в первом приближении сойдет. Так и тут. Первым языком бери сишечку, чтоб понять, как диды прогали в эпоху до безопасных языков. Узнаешь, что такое освобождение памяти и все такое, и будешь потом с благодарностью смотреть на раст, который все это делает за тебя.
> Она в принципе в корне невернаОна верна не менее, чем остальные.
> по сравнению сосравнивать не с чем.
А чО не аристотелеву-то?! Откуда эта дискриминация? Понапридумывают всякой новомодной бнопни - потом загаживают ей мозги молодому поколению... "Ньютоновская" - это жаба какая, а ся - это вот аристотелева и есть. Куды ни ткни - дырки в логике, ничего не толком не объясняет - но для решения задач вида "квадратное катаем, круглое носим" вроде даже и годится.
> загаживают ей мозги молодому поколениюЗагаживали и раньше. Почему гравитация? Не знаете? Когда узнаете - приходите, послушаем.
>> загаживают ей мозги молодому поколению
> Загаживали и раньше. Почему гравитация? Не знаете? Когда узнаете - приходите, послушаем.Вы что, о концепции "естественного места" не слышали? На все объекты действует сила, двигающая объекты к их "естественному месту", это же ОЧЕВИДНО?!
Фу таким быть, плохой сишник, негодный!
Я бы порекомендовал паскаль (хороший современный есть lazarus). Он научит правильно понимать типизацию и в целом наиболее академический язык из всех. Зная паскаль освоишь всё что угодно.
Похоже, скоро советчиков начинать-с-паскаля уже начнут бить
Лет 10-15 как эталонное ненужно. Можно даже в палату мер и весов отправлять или в стеклянную коробочку - и в шкаф, рядом с куском кости динозавра
Все верно. Тот же Rust мультипарадигмальный язык и студни смогут на его базе получить разные подходы в программировании без необходимости изучать синтаксис и особенности других языков. С учетом того что язык активно внедряется в корп сегменте - они и без работы не останутся после окончания. А кому нужны паскалисты?
> Все верно. Тот же Rust мультипарадигмальный язык и студни смогут на его
> базе получить разные подходы в программировании без необходимости изучать синтаксис и
> особенности других языков. С учетом того что язык активно внедряется в
> корп сегменте - они и без работы не останутся после окончания.
> А кому нужны паскалисты?А вот тут скорее "нет". "Мультипарадигменность" для _обучения_ штука скорее вредная. Т.е. по хорошему, для получения нормального бэкграунда тебе нужно иметь крепкое представление о:
1. Низкоуровневом программировании. Работа с железом, организация памяти - вот это вот всё. И нет, это НЕ сишка, а, скорее ассемблер, причем НЕ для одной архитектуры.
2. Классическое императивное программирование, хорошо бы еще со строгой типизацией. При этом п. 1 и п. 2 можно и местами поменять - императивщина _с гарантией_ лезет в любую голову, а вот low-level а) уже не факт б) слабонервных может и спугнуть.
3. Классическое ООП, причем скорее даже не в стиле C++\Java где legacy-специфика системы типов во все поля, а ну вот - pure python 3, в котором нонеча "объекты" примерно вот всё.
4. Классическая функциональщина в виде lisp'а может с модными диалектами типа clojure, чтоб совсем уж людёв не отпугивать
5. Всякая специфическая экзотика вроде прологов или там SQL'ейИ вот всё это друг от друга хорошо так отличается и в мозги, одно после другого - не так чтобы радостно лезет, и если язык для этого вот всего у тебя один - переключаться трудно, голова так и будет норовить "срезать углы", сделать "по старинке", "как проще" и т.д. В жизни понимание границ применимости методологий и осознание того, когда что лучше применять - только в плюс, а вот для учебы - нет.
>1. Низкоуровневом программировании. Работа с железом, организация памяти - вот это вот всёАссемблер, это очень специфичный язык, и нужен он либо тем, кто хочет глубоко уйти в системное программирование, либо вообще для тех, кто будет писать для микроконтроллеров(и то, там уже мощные микроконтроллеры). Для остальных эти знания практически бесполезны, а с учётом того, что в течении этого времени можно было бы что-то более актуальное изучать - вредны
>3. Классическое ООП, причем скорее даже не в стиле C++\Java где legacy-специфика системы типов во все поля, а ну вот - pure python 3, в котором нонеча "объекты" примерно вот всё.Бидон - классическая свалка, когда от парадигм взяли недостатки и ссыпали их в кучу. Например, вычисление длины - len([1,2]) - это самая настоящая процедурщина. И сколько бы подобных примеров не приводилось, бидон продолжают считать хорошим языком. Да руби в этом плане куда лучше.
>4. Классическая функциональщина в виде lisp'а может с модными диалектами типа clojure, чтоб совсем уж людёв не отпугиватьПро типизированные функциональные языки вы скромно умолчали. Надобность лиспа - весьма сомнительна
>>1. Низкоуровневом программировании. Работа с железом, организация памяти - вот это вот всё
> Ассемблер, это очень специфичный языкЪ. Но мы же тут про "фундаментальное обучение" вроде? Именно для этого он - лучше сишечки прям сильно. Без этого понимания "а почему в ней столько и таких ub" не возникнет, и будет патамучта-патаму, "ну тупые!"(тм) диды налажали!
>>3. Классическое ООП, причем скорее даже не в стиле C++\Java где legacy-специфика системы типов во все поля, а ну вот - pure python 3, в котором нонеча "объекты" примерно вот всё.
> Бидон - классическая свалка, когда от парадигм взяли недостатки и ссыпали их
> в кучу. Например, вычисление длины - len([1,2]) - это самая настоящая
> процедурщина. И сколько бы подобных примеров не приводилось, бидон продолжают считать
> хорошим языком. Да руби в этом плане куда лучше.И снова ъ. "хорошим" - нет, подходящим для... Возможно. Ruby может и лучше, но я с ним, почитай, не знаком.
>>4. Классическая функциональщина в виде lisp'а может с модными диалектами типа clojure, чтоб совсем уж людёв не отпугивать
> Про типизированные функциональные языки вы скромно умолчали. Надобность лиспа - весьма
> сомнительнаМы ж про обучение, да? Оно и так-то "нидляффсех", а дополнительно строгой статический типизацией усложнять... Вам студней совсем-совсем не жалко?
> Без этого понимания "а почему в ней столько и таких ub" не возникнет, и будет патамучта-патаму, "ну тупые!"(тм) диды налажали!Оуууукей. Вот ассемблер, знаковое переполнение определено.
Вот сишочка, знаковое переполнение - UB, не implementation defined.Поддержку музейных архитектур с целыми не в дополнительном коде в 23 стандарте убрали, UB оставили.
Как-то не помог фундаментальный ассемблер прояснить ситуацию, только хуже стало.
>> Без этого понимания "а почему в ней столько и таких ub" не возникнет, и будет патамучта-патаму, "ну тупые!"(тм) диды налажали!
> Оуууукей. Вот ассемблер, знаковое переполнение определено.
> Вот сишочка, знаковое переполнение - UB, не implementation defined.
> Поддержку музейных архитектур с целыми не в дополнительном коде в 23 стандарте
> убрали, UB оставили.
> Как-то не помог фундаментальный ассемблер прояснить ситуацию, только хуже стало.Ну согласись, что дiды к этому отношения уже не имеют).
> Ну согласись, что дiды к этому отношения уже не имеют).Имеют прямое отношение к тому что корректность никого не интересовала.
В ассемблере как напишешь - так оно и будет работать (в однопотоке), никто не придёт и не оптимизирует код добавлением уязвимостей.
>> Ну согласись, что дiды к этому отношения уже не имеют).
> Имеют прямое отношение к тому что корректность никого не интересовала.Да, да, по этому вот в C23...
> В ассемблере как напишешь - так оно и будет работать (в однопотоке),
> никто не придёт и не оптимизирует код добавлением уязвимостей.С разморозочкой, что ли. У тебя примерно с pentium pro управление контролируется обновляемым микрокодом, который делает... А вот хрена-с-два ты знаешь, что он делает. Это не говоря про всякое out-of-order управление, предсказание ветвлений и прочие фокусы, из-за которых мы имеем то, что имеем.
> Это не говоря про всякое out-of-order управление, предсказание ветвлений и
> прочие фокусы, из-за которых мы имеем то, что имеем.Потому я и уточнил что в однопотоке, для однопотока out-of-order исполнение всё прочее не имеют видимых эффектов, последнее известное изменение микрокода которое в этом плане что-то меняло - FDIV и пара фиксов AVX. Однако это всё фиксы, и все компиляторы предполагают что они везде реализованы, никто не реализует от этого защиту. Есть контрпримеры - в студию
В то время C имеет UB, что может вносить непредсказуемое поведение даже в однопоточные программы
>> Это не говоря про всякое out-of-order управление, предсказание ветвлений и
>> прочие фокусы, из-за которых мы имеем то, что имеем.
> Потому я и уточнил что в однопотоке, для однопотока out-of-order исполнение всё
> прочее не имеют видимых эффектов, последнее известное изменение микрокода которое в
> этом плане что-то меняло - FDIV и пара фиксов AVX. Однако
> это всё фиксы, и все компиляторы предполагают что они везде реализованы,
> никто не реализует от этого защиту. Есть контрпримеры - в студиюНу, осталось научиться запускать эту свою "ассемблерную программу" в этом самом "однопотоке", а не как "ОС на ядро положит", и...
Ассемблер (Как и сишечка, кстати) создает опасное представление "как напишу, так и будет исполняться" - а оно, в общем, давно уже вот нифига не так. В этом смысле если куда и смотреть - то в сторону какой LLVM\JVM - на этом уровне абстракции нуээээ... можно считать, что "что пишешь - то и выполняется" - но может я и тут уже ошибаюсь :).> В то время C имеет UB, что может вносить непредсказуемое поведение даже
> в однопоточные программыА с этим вот вообще никто не спорит...
>Но мы же тут про "фундаментальное обучение" вроде?Фундаментальное обучение чему? Вы поймите, задачи у разработчиков очень разные. Для почти всех разработчиков знание ассемблера не нужно вообще. Для тех редких людей, кому он всё же нужен, изучать его нужно исключительно в прикладном применении. Никакого особого курса "ассемблер" быть не должно, должно быть что-то вроде "создание компиляторов и декомпиляторов, написание драйверов и всё прочее низкоуровневое". Где ассемблер будет даваться строго дозировано, но на реальных задачах, и для современных процессоров, а не в стиле, достаём ms-dos и пишем. Посколку если вы хотите написать ОС, то для многозадачности вы напишете несколько функций на ассемблере, может строк на двадцать. Всё остальное будет либо си, либо раст, либо что-то ещё. На дворе уже 2025 год. Ещё чуть больше чем полгода, и 2026 будет. Да для большинства разработчиков какой-нибудь эликсир в разы полезнее ассемблера будет, так напрямую связан с той предметной областью, где они работать будут
>Без этого понимания "а почему в ней столько и таких ub" не возникнетОно и с понимание ассемблера не возникнет
>и будет патамучта-патаму, "ну тупые!"(тм) диды налажали!Деды действительно налажали. Ибо в си до сих пор живут, как лет пятьдесят назад. А любая попытка вытащить из полувекового отставания от реальности вызывает острую болезненную реакцию со стороны дедов. Ибо приходит понимание, что уже лет двадцать назад, как минимум, можно было выкинуть все эти костыли и сделать по нормальному. А с учётом некоторых вещей, си уже лет через десять можно было начать закапывать, а то и раньше
>"хорошим" - нет, подходящим для...Ещё раз, руби лучше бидона, поскольку в руби лучше ооп чем в бидоне, где оно перемешано с процедурщиной. Вы же сами выбрали критерий, сравнивать по ооп
>Возможно. Ruby может и лучше, но я с ним, почитай, не знакомТипичный советчик. Ни с чем не знаком, но советует. Вы откройте глаза, в мире больше двух языков. И прежде чем отказываться от java в пользу python, сравните этот самый python хотя бы с ruby
>Вам студней совсем-совсем не жалко?Студентам нужно прививать хороший вкус, для этого Ocaml подходит куда лучше чем clojure. Ибо на отсуствие типизации они ещё насмотрятся в уже написанном г-коде на работе
>>Но мы же тут про "фундаментальное обучение" вроде?
> Фундаментальное обучение чему?Программированию, вестимо. С этим вот "вам это в жизни не понадобится" - можно в ПТУ одно из java'е\C#\PHP\JS учить - для 99% процентов за глаза хватит.
>>Без этого понимания "а почему в ней столько и таких ub" не возникнет
> Оно и с понимание ассемблера не возникнетНу, если у вас не возникло - то РАЗУМЕЕТСЯ, так оно и есть.
>>и будет патамучта-патаму, "ну тупые!"(тм) диды налажали!
> Деды действительно налажали. Ибо в си до сих пор живут, как лет
> пятьдесят назад. А любая попытка вытащить из полувекового отставания от реальности
> вызывает острую болезненную реакцию со стороны дедов. Ибо приходит понимание, что
> уже лет двадцать назад, как минимум, можно было выкинуть все эти
> костыли и сделать по нормальному. А с учётом некоторых вещей, си
> уже лет через десять можно было начать закапывать, а то и
> раньшеТак кто бы спорил-то? Только те "дiды" что делали C вот таким, какой он есть 20 лет назад хорошо так уже от дел отошли.
>>"хорошим" - нет, подходящим для...
> Ещё раз, руби лучше бидона, поскольку в руби лучше ооп чем в
> бидоне, где оно перемешано с процедурщиной. Вы же сами выбрали критерий,
> сравнивать по оопА с чем вы спорите? Я с вами уже согласился, вроде как?
>>Возможно. Ruby может и лучше, но я с ним, почитай, не знаком
> Типичный советчик. Ни с чем не знаком, но советует. Вы откройте глаза,
> в мире больше двух языков. И прежде чем отказываться от java
> в пользу python, сравните этот самый python хотя бы с rubyА почему не с simula'ой или smalltalk'ом? Ой, патамучта ни вы, ни я с ними не знакомы? Ну, бывает, чоужтам. В мире больше двух языков, ага.
Суть моего комментария - с _RUBY_ (И еще кучей всего, ага) я НЕ знаком, но при этом считаю, что "модель ООП" в python'е "лучше" ("Адекватней современной реальности"), чем в c++\java'е. Если у ruby она _еще лучше_ - замечательно! То, что ruby в плане ООП "чище" - так я ж по мере своего (не)знакомства с ruby согласен и не спорю. Но as for me "оценочно\относительно" ООП лучше изучать на примере python'а, нежели жабы\крестов. Всё.>>Вам студней совсем-совсем не жалко?
> Студентам нужно прививать хороший вкус, для этого Ocaml подходит куда лучше чем
> clojure. Ибо на отсуствие типизации они ещё насмотрятся в уже написанном
> г-коде на работеНе, ну если вы собираетесь учить дизайнеров... В жизни же полезность Ocaml для 99,995% программистов - ну вот примерно на уровне ассемблера, да. Вероятность столкнуться с ассемблерными вставками пожалуй что и выше будет.
> Классическая функциональщина в виде lisp'а может с модными диалектами типа clojure, чтоб совсем уж людёв не отпугиватьВот если это для человека первый язык откуда он узнает что может быть по другому? Он будет считать что так и надо. Просто все текущие люди наученные на java/pascal, до сих по считают что ООП это серебряная пуля. Уже 30 лет прошло, а мода на ООП никуда не прошла.
>> Классическая функциональщина в виде lisp'а может с модными диалектами типа clojure, чтоб совсем уж людёв не отпугивать
> Вот если это для человека первый язык откуда он узнает что может
> быть по другому? Он будет считать что так и надо. Просто
> все текущие люди наученные на java/pascal, до сих по считают что
> ООП это серебряная пуля. Уже 30 лет прошло, а мода на
> ООП никуда не прошла.Тю! Где пасквиль, а где жаба? Меня на этом трупе учили - и ой, "объектов" там в то время не то, чтобы было... Вот дельфя таки да.
>Я бы порекомендовал паскаль (хороший современный есть lazarus)Закопайте его там, где откопали
>Он научит правильно понимать типизациюЕсли вы хотите понимать типизацию, то вам сюда: Ocaml(легко), Rust(сложно), Haskell(сложно), Idris(ещё сложнее). Можно Standard ML или ATS(для специалистов) взять, если не смущает экзотика с почти полным отсутствием документации.
>и в целом наиболее академический язык из всехАбсолютно оторванный от реальности. Уж лучше Go взять, он хотя бы практичный
С типами научит, а с памятью - не научит.
А что, в Паскале кто-то запретил указатели и динамическую память?
Ну и будут портить память, наряду с сишниками.
из академических еще хаскель интересный язык.
я бы наверное хотел с него начать, но уже поздно - мозги испорчены си.
Учить лучше всего не языки, а учебники, в которых всё нормально разъясняется.Рекомендую Robert Strandh, "архитектура ЭВМ", Абельсон и Сассман "Структура и интерпретация компьютерных программ" и Феллейсен-Кришнамурти "How to design programs".
Вирт, "алгоритмы+структуры данных=программы"
Раст не стоит. Сначала СИ, потом С++, потом можно Java.
А потом сразу в дворники, да - к пенсии закончишь с крестами (Но это не точно - они новые стандарты пишуть!) обернешься - а там чятжопэта все уже понагенерила.СЕЙЧАС если и вкладываться - то в какие python-julia чтоб порог входа поменьше, а к предметной области - поближе и фигачить эту самую "предметную область" до посинения. Эпоха, когда "программизм" нёс какую-то самостоятельную ценность - закончилась.
> А потом сразу в дворники, да - к пенсии закончишь с крестами (Но это не точно - они новые стандарты пишуть!)То ли дело rust, который клепает новые методы при каждом релизе, да? Так ещё и синтаксис меняет.
>> А потом сразу в дворники, да - к пенсии закончишь с крестами (Но это не точно - они новые стандарты пишуть!)
> То ли дело rust, который клепает новые методы при каждом релизе, да?
> Так ещё и синтаксис меняет.Ну, rust в части job security правда лучше - кода для обучения copilot'ов кратно меньше, репутация - лучше, legacy меньше (Если что - по тому и "лучше", что "меньше" - как только аналогичным объемом костылей обрастет, так вот сразу и...), хайпа - больше, ляпота! Но учить "с нуля" - хз, как бы поздновато уже. С двух ног запрыгивать с опытом сишки\крестов да, а вот вайти-в-айти уже и нет.
К чему это всё сказано? Я конкретно написал про клепание методов. Зачем мне в ответ про жоп секюрити?
> К чему это всё сказано? Я конкретно написал про клепание методов. Зачем
> мне в ответ про жоп секюрити?Ну, исходный вопрос был "куды крестьянину податься?!" - и вот есть у меня мнение, что части фермеров сено определенным образом лучше соломы :).
В любой день возьму 6 недельный выпуск, чем ждать reflection 8 лет.
> Сначала СИ, потом С++, потом можно Java.Всё наоборот.
Как человек, который время от времени пишет на Rust, могу сказать, что Rust очень сложен в том плане, что есть много не совсем очевидных вещей, от которых тебе периодически "прилетает", поэтому готовься, будет трудно. Отсюда, кстати, и вопли хейтеров на OpenNET - люди просто неАсилили и, дабы оправдать себя в своих глазах, поливают язык грязью.PS Подсказка на будущее: почитай про std::mem::replace(), в ряде случаев это просто незаменимая ИМБА.
хейтеров нет, есть люди, которые не видят смысла нюхать ваших фанатиков, агрессивную рекламу и убогий синтаксис. ничего больше обсуждать смысла тоже нет
> хейтеров нет, есть люди, которые не видят смысла нюхать ваших фанатиков, агрессивную рекламу и убогий синтаксис. ничего больше обсуждать смысла тоже нетНу так фигли ты приперся в тему про раст и начал вонять?
Просто сдрыстни мамке под юбку и не порти воздух своими разглагольствованиями.Так же тебя никто не заставляет пользоваться расто-содержащими продуктами, будь то андроид сейчас или ядро линукс в ближайшем будущем.
Вы не отличаете пользования языком от комментариев в интернете? Это разные вещи.
> Ну так фигли ты приперся в тему про раст и начал вонять?Здесь половина комментариев в стиле:
"Я три дня гналась за вами, чтобы сказать, как вы мне безразличны."
python
Язык, в котором отступы определяют синтаксис, недостоин даже упоминания.
> Язык, в котором отступы определяют синтаксис, недостоин даже упоминанияЛол. На этом языке весь machine learning и анализ данных.
Так что если тебе действительно нужно деньги зарабатывать, а не гордо прозябать в нищете со знаниями никому не нужных языков из 70-90х, то альтернатив не особо много.
ML, точней скрипты, а не сами модели, на питоне, потому что внезапно математик не программист и в нормальные языки не умеет
> внезапно математик не программист и в нормальные языки не умеетЛол)) "нормальные языки" это какие?
Математик берет питон или что-то подобное, потому что ему работать нужно, а не с сишными указателями прдлиться. Пока ты будешь писать на "нормальном языке", конкуренты уже в прод выкатят.
> конкуренты уже в прод выкатятОбычно на такой скорости выкатки получается овнокод и тормоза. Либо на пользовательской стороне, либо на серверной. Кто-то да заплатит.
> Обычно на такой скорости выкатки получается овнокод и тормоза. Либо на пользовательской
> стороне, либо на серверной. Кто-то да заплатит.Но какой-то код лучше чем никакой. И они уже будут получать деньги и/или аудиторию.
А идеалисты потом будут догонять и пытаться найти местечко на поделенном рынке.
> А идеалисты потом будут догонять и пытаться найти местечко на поделенном рынке.Как это верно подмечено! Про rust!! Долго-о-о ему догонять и место искать придется!!!
Кроме си и питона существует куча языков. Есть go, есть haskell, есть Ocaml, есть C#, и куча других яызков, выбирай по вкусу.
>Математик берет питон или что-то подобное, потому что ему работать нужноМатематики, как и физики, это классические неосиляторы из палаты мер и весов. Они знают только предметную область, а всего сопряжённого с ней - не знают. Доходит до того, что с помощью нейросети можно за несколько часов написать то, что математики месяцами пишут. И да, сейчас ещё и Джулия появилась, так что бидону пора потесниться
Нейросети не могут ни в физику, ни в математику. Ибо подборка алгоритмов через прогонку по бигдата, это не ИИ.
В формулах ИИ тупо убирают члены уравнений, абсолютно не понимая, как нужно считать. ИИ нет ни в математике, ни в физике, потому что нет никакого ИИ.
Вот беда, математик могут месяцами писать загрузку данных из файла или что-то подобное. Вы переоцениваете способность математиков к программированию, хорошо хоть они python освоили, а то считали бы в каком-нибудь маткаде или excel. Это не показатель python, это показатель математиков. Это всё равно, что по учителям информатики судить о программистах
Для идиотов: я математиков вообще ни где не оценивал.
А теперь моя оценка: Любой математик, при надобности, легко освоит большинство ЯП на уровне мидла, но далеко каждый программист поймет, хотя бы, что такое интеграл.
>А теперь моя оценка: Любой математик, при надобности, легко освоит большинство ЯП на уровне мидлаАга, сразу, даже не работая программистом. Вот просто возьмёт и поймёт. Это без учёта того, что ему кроме программирования нужно свою основную работу работать
>но далеко каждый программист поймет, хотя бы, что такое интегралДо тех пор, пока это не программист графического/физического движа, на качестве кода это никак не сказывается. А у математиков это сказывается буквально сразу же
> "нормальные языки" это какие?Явно не питон, с его бредовым синтаксисом и производительностью ниже плинтуса.
Синтаксис очень даже хорош, потому что легко читается. Производительность не нужна для языка для обучения. Да и вообще мало где нужна, по большому счёту.А вот что действительно плохо в Питоне (как языке для обучения) - это то, что он интерпретируемый. А также то, что там динамическая типизация. Ну и про работу с памятью вообще, считай, ничего нет, потому что за всё в ответе среда исполнения.
> Синтаксис очень даже хорошЛишний пробел меняет поведение скрипта. Да, отличный синтаксис!
Чем это принципиально отличается от языков, где терминатором является, например, точка с запятой? Отсутствующий символ или символ не в том месте меняют поведение программы.Зато код на Питоне очень и очень легко читается, благодаря отступам. Для новичков - самое оно.
>Чем это принципиально отличается от языков, где терминатором является, например, точка с запятой?Тем, что пробелам теряться легче. Может быть, по невнимательности при смене отступа затронута лишняя строка. Может быть редактор имеет другие настройки в количестве пробелов/табуляций, может быть какой-то сайт съедает ведущие пробелы, может быть при копировании и вставке влезли лишние отступы. Просто предствьте, что на си-подобных языках у вас бы часто возникали фантомные скобки
>Зато код на Питоне очень и очень легко читается, благодаря отступамПитонисты, прогресс не стоит на месте, табуляцию больше не надо нажимать, только Enter. Для нормальных языков уже давно есть утилиты автоформатирования, которые самостоятельно ставят/убирают отступ на основе синтаксиса. Например, как здесь https://try.ocamlpro.com/
>Просто предствьте, что на си-подобных языках у вас бы часто возникали фантомные скобкиЕсли вы не выделили по невнимательности такую скобку при копировании, то она у вас пропадёт при вставке.
Я согласен, что у Питона эти проблемы более ярко выраженные. Но читать Питоновский код всё же куда приятнее, чем код на языке с терминальными ограничителями. Потому что отступы - это стандарт, ему программист обязан следовать. А вот отступы в другом языке не обязательны, их можно и не поставить, легко превратив код в нечитаемую кашу.
>Для нормальных языков уже давно есть утилиты автоформатирования
Они-то есть, только пользоваться ими необязательно. А отступы в Питоне обязательны.
Кстати, что такое "нормальный язык"? Я вот всегда думал, что у любого языка есть своя сфера применения, и вот там его можно считать нормальным. То есть, в общем случае нет нормальных или ненормальных языков. Есть подходящие или неподходящие.
>Если вы не выделили по невнимательности такую скобку при копировании, то она у вас пропадёт при вставке.Если скобка лишняя/недостающая, будет ошибка компиляции. Питон же подобные ошибки очень легко проглотит молча
>А вот отступы в другом языке не обязательны, их можно и не поставить, легко превратив код в нечитаемую кашуЯ вас удивлю, но для того, чтобы найти на другом языке код без отступов, вам придётся очень сильно постараться. Проще вего будет самому под виртуалом написать. Домашние задания на паскале в расчёт не берём, так как пишут их не программисты, а школьник
>Они-то есть, только пользоваться ими необязательно. А отступы в Питоне обязательны.Даже если мне достанется такой исходник, что уже маловероятно, то я без проблем могу его поправить. Он же не в граните высечен и не в бронзе отлит
>Кстати, что такое "нормальный язык"?Нормальный язык, это тот язык, в котором проблемы не возникают на ровном месте
>Я вот всегда думал, что у любого языка есть своя сфера применения, и вот там его можно считать нормальнымСфера применения будет у любого, даже объективно неудобного языка
>Синтаксис очень даже хорош, потому что легко читаетсяgolang читается ничуть не хуже. Как и Ocaml. А вот необходимость вручную набивать пробелы раздражает
>Да и вообще мало где нужна, по большому счётуТак вот почему всё тормозит
>Ну и про работу с памятью вообще, считай, ничего нет, потому что за всё в ответе среда исполненияРабота с памятью, это либо суровая теория, вроде линейных указателей, зависимых типов и подобного, либо постоянная порча памяти
> golang читается ничуть не хуже. Как и Ocaml. А вот необходимость вручную
> набивать пробелы раздражаетПоставьте себе нормальную IDE, ну или хотя бы современный текстовый редактор и радуйтесь жизни.
> Работа с памятью, это либо суровая теория, вроде линейных указателей, зависимых типов
> и подобного, либо постоянная порча памятиМы до сих пор говорили о языке для обучения, вдруг вы забыли. Любому сколь-либо вменяемому программисту надо понимать принципы работы компьютера.
>Поставьте себе нормальную IDEУ меня локально стоит ocamlformat, он польностью форматирует код за меня. Попробовать можно тут https://try.ocamlpro.com/. А вот вам всё равно придётся набивать отступы вручную, например, если удалите if
>Мы до сих пор говорили о языке для обучения, вдруг вы забыли.Для обучения вам хватит уровня ocaml-а или golang-а
>Любому сколь-либо вменяемому программисту надо понимать принципы работы компьютера.Есть большая разница между знанием о существовании указателей, и возможностью писать с их использованием код так, чтобы он не падал. Для большинства современных программистов знания о указателях так, для общего развития
> А вот вам всё равно придётся набивать отступы вручную, например, если удалите ifЗа меня это сделает IDE.
> Для обучения вам хватит уровня ocaml-а или golang-а
Мне не надо обучаться. Я давно уже обучен, и не тольку Питону с Растом. Это человек выше спрашивал.
> Есть большая разница между знанием о существовании указателей, и возможностью писать с их использованием код так, чтобы он не падал. Для большинства современных программистов знания о указателях так, для общего развития
В общем и целом согласен. Многим это не особо нужно. Но эти многие, как программисты, скажем так, не представляют из себя большой ценности для отрасли. То есть, нет, они, конечно, нужны. Но их ценность невысока.
>За меня это сделает IDE.IDE уже научилось читать мысли? Есть код
a()
if b:
c()
d()
e()
Допустим, я удалил b. Откуда IDE знает, что делать дальше? Я могу вставить его в любом месте, хоть перед "a", а могу так и оставить. Куда какой блок менять?
>Но эти многие, как программисты, скажем так, не представляют из себя большой ценности для отраслиДа, да, да. Разумеется, программист на golang, в котором указателей нет, а есть только ссылки обязан знать, как работают указатели. Только вот беда, чтобы писать код с указателями, ему внезапно нужно начать работать либо на си, либо на расте
Стоит! Язык не сложный и производительный.
Лучше Golang
Тоже неплохой вариант, если сравнивать с Java!
> Тоже неплохой вариант, если сравнивать с Java!
Если у тебя есть какое-то математическое образование и тебя не будут пугать "аффинные типы" - то да.Но лучше начать с СИ.
Желательно взять какой-то большой проект и попытаться что-то дописать.
Тебя ждет увлекательное путешествие по "а какого тут происходит?" и ночные забеги с дебагом "почему оно крашится и что попортило память"?.
Возможно ты оценишь древние хаки дидов которые используют "особенности" компилятора, которые через пару версий отстреливают ноги по самую зaдницy.После этого можно переходить на хруст и чувствовать себя белым человеком.
Конечно. Он попутно учит писать правильный код на других языках.
Для каких конкретно целей вам нужно программироание? Как только ответите на этот вопрос - берите соответствующий язык! Если вы ещё не знаете что к чему и зачем оно вам нужно а просто хотите потыкаться и понять а нужно ли оно вам - берите Питон, и не *бите себе мозги!
Питон - плохой язык для обучения, выше написал почему.
Нет, не стоит. Будет непонятно зачем такие ограничения и какую проблему вообще решаем. Для первого языка всё ещё не придумали ничего лучше Паскаля.
>Для первого языка всё ещё не придумали ничего лучше Паскаля.Придумали. Если хотим быстро получить продуктовых программистов, берём Go, если нужно приобщить к типизации - Ocaml. Зачем вам паскаль?
> Если хотим быстро получить продуктовых программистовНе хотим. Мы хотим получить программиста на Rust или C++. Вроде контекст такой.
> Ocaml
Это функциональный язык и не лучший среди таковых. Безусловно, в какой-то момент нужно познакомиться с функциональным программированием, но никак не в качестве первого языка.
Кто нибуть использует slint на встраиваемых устойствах с Linux? Чета я так и не смог победить кросскомпиляцию для своего окружения.
Меня больше интересует, а зачем его американцы так активно впаривают? Реклама весьма заметна, код закрыт. В связи с чем думаю что как минимум нужно перепроверить заявленные его супервозможности на нормальных тестах. Язык по факту ещё в разработке - стандарта нет. По стоимости - бесплатный. Странно.
Наверно американцы решили таки осчастливить весь мир замечательнейшим доступным и быстрым языком программирования!
Обязательно к ознакомлению.
Особенно последние 2 абзаца: https://veresov.pro/rustmustdie/
Я б порекомендовал начать читать с начала. Вот прямо с первой строки "Постмортем: Это довольно неловкая и слишком негативная статья." Дальше можно не читать, потому что я здесь могу объяснить что там написано гораздо короче. В один абзац уложу всю статью.Это заурядная реакция на первое знакомство с растом вида "ничего не понял, но критикую". Статья не датирована, но я предположу, что она была написана 5+ лет тому назад. Я с этим эпистолярным жанром не сталкивался как минимум с 2020 года, но когда-то он был очень популярен, тысячи самоназванных экспертов в языках программирования наперегонки писали такие стены текстов, которые абсолютно ничего не говорят о расте, только об их knee-jerk реакции на раст.
Я прочитал, и мне скорее понравился Руст в его описании.Синтаксис похож на С++, но меньше шаблонного страдания, всё остальное логично довольно
Хорошая статья, официальный перевод на английский просто необходим.
Херня собачья. Высосанные из пальца "проблемы" перечислены, а реальных проблем, рубящих весь ЯП на корню (статическая линковка, cargo, 10 версий одной и той же зависимости, заточенность экосистемы под оные, как следствие - сплошное bloatware с уязвимостями, которые пофиксить невозможно на практике - так как требует переписывания исходника каждой зависимости (Cargo.toml + Cargo.lock + переписывание исходника, так как смузихлёбы ломают API в каждой версии, ведь "всегда можно использовать старьё, его у вас никто не отнимает" )) - ни одной.
> а реальных проблемЭто такие же реальные проблемы, как я - балерина.
>статическая линковка
Хотите динамическую линковку? Их есть у нас.
>cargo
Что с cargo не так? Отличный инструмент на самом деле.
>10 версий одной и той же зависимости
Кто-то вас заставляет использовать эти зависимости? Изобретайте свой велосипед. Никто ж не запрещает.
Забавно, я думал про этот опус студня Столярова уже забыли... ан нет, периодически достают и опять начинают размахивать.С другой стороны, эта статья - прекрасная демонстрация как уровня преподавания, так и самого преподавателя)) Слава богу в МГУ есть нормальные преподаватели, жаль что фрика слышно намного сильнее.
В гнилом МГУ им. Ломоносова больше не осталось преподов уровня Столярова.
Физфаковские методички Задорожного весьма неплохие. Они прямолинейные - никаких дурацких вступлений и рассуждений на околокомпьютерную тему, информация о C/C++, список задач, в конце список источников для дальнейшего изучения программирования.
Ну вот и сборщики мусора нашлись. Аж два или может четыре - для макросов наверно отдельные, тоже синхронные и асинхронные.
И похоже часть с макросами другого авторства.
Написавший это понятие не имеет про что пишет. Одно только "ансейф отключает все проверки" чего стоит. Обратно в школу к букварю.
> Обязательно к ознакомлению.
> Особенно последние 2 абзаца: https://veresov.pro/rustmustdie/Ну да, к мнению чувака, даже не знающего разницу между дебаг и оптимированным билдом - стоит конечно же прислушаться ...
Пустые придирки. Да он своей статьёй разгромил Раст.
> Пустые придирки. Да он своей статьёй разгромил Раст.Да ладно. Такими "разгромами" (вида "придумать что-то от балды и яростно оспорить") - тут каждый первый Воен Супротив Раста похвастать может.
Конечно, человек не разобрался в языке, но ведь это же показывает что язык слишком сложный. Как ни странно, но выводы автор делает совершенно правильные, и насчёт языка и насчёт фанатиков. Rust - плохо спроектированный, чрезвычайно неудобный и очень сложный. Ну и что что он надёжный, если пользоваться им невозможно.
>Как ни странно, но выводы автор делает исходя не из реальных знаний, а своих фантазий, обусловленных не очень высокими когнитивными способностями или предубежденностью.Поправил.
>Rust - плохо спроектированный, чрезвычайно неудобный и очень сложный.
Rust - очень даже неплохо спроектированный ЯП. Возможно, местами не идеал, но в общем и целом вполне хорош. И что немаловажно, его развитие не остановилось.
>чрезвычайно неудобный и очень сложный
Только для не желающих или не имеющих возможности его изучать. На самом деле, для освоения базы нужно от 40 до 60 часов примерно.
> Rust - очень даже неплохо спроектированный ЯП. Возможно, местами не идеал, но в общем и целом вполне хорош.Просто местные (ну, кто вообще соблаговолил с ним ознакомится не только по комментам на опеннете) путают сам ЯП и его std либу.
Вот в последней да, тут и там (взять хотя бы *fmt или Error) выпирает "сначала мы сделали так, но на практике оказалось, что эдак - будет лучше".Подход с эдишенами теоретически таки позволит все это переделать под что-то более удобноваримое, но нюанс в том, что все это легаси все равно придется тянуть, т.к. уже слишком много написанного кода на него завязано.
>Rust - очень даже неплохо спроектированный ЯПRust примитивнее чем ATS.
Предположим (хотя я совершенно незнаком с ATS, чтобы дискутировать с вами на эту тему). И что из этого следует?
Раст не отлавливает все ошибки связанные с памятью, например выход за границы массива в релизной сборке. Зависимые типы это могут
В Раст ещё возможны утечки памяти при определённых обстоятельствах. Но что из этого следует?
Кстати почитал тут тг чатик раста: там куча людей с аватарками в стиле аниме или котами спрашивают базовые вещи типа "не понимаю как устроен тип Result" или пиарят свои библиотеки для "красивого" задания дат :) А потом они же в других чатах пишут про сегфолты в си :D Ну вы поняли уровень экспертов.
И вот таких в раст сообществе очень много. Приходят из веба и тащат с собой не поймт что. Проект на расте зависит от огромного числа зависимостей, в которую автор может встроить бэкдор как делают в npm.Сообщество раста очень токсичное. Напоминает поведение меньшинств: если ты в чем-то не согласен с нами, то ты автоматически плохой. Также в блоге к релизам у них проскакивает политота.
Вы же как разработчики должны понимать, что не существует универсального инструмента. Что за дополнительные проверки нужно чем-то платить. Не везде это нужно. А втирают (да именно агрессивно) его как золотую пилюлю, как крупный выигрышь или заоблачный процент для ваших средств.
Думайте!
Как сказал классик: "Rust – это язык написания статей для блогов и сценариев для ю-туба, о том как хорош раст." (с)
>И вот таких в раст сообществе очень много. Приходят из веба и тащат с собой не поймт чтоВот таких вот ненависников раста просто необходимо посадить писать любой проект со сложной бизнес логикой, желательно на си. За каждый баг штрафовать. Зарелизил код, он оказался с багом - штрафовать за затягивание сроков. Незарелизил код, так как искал баг - аналогично. Потекла память - штраф, побилась - аналогично. Запретить увольняться, пока не отработают все штрафы
>там куча людей с аватарками в стиле анимеХорошо же
>Сообщество раста очень токсичное. Напоминает поведение меньшинствНичуть не токсичнее сишников/плюсовиков/паскалистов. Ходят и размахивают своими сями/крестами/паскалями. Ненавидят тех, кто не настоящий сишник, и пишет на голанге, джаве, руби, пхп или джаваскрипте. Панически боятся любой продвинутой системы типов, ибо осилить её не в состоянии
>Проект на расте зависит от огромного числа зависимостейХарактерный синдром заражения сишостью/плюсонутастью/паскальностью - nih терминальной стадии, выраженной в постоянном велосипедостроительстве. Изобретают не то чтобы велосипед, изобретают колесо, будь то строки, хеш таблицы или xml-парсеры. Все их велосипеды кривы, и не соответствуют ни спецификации, ни здравому смыслу
>Вы же как разработчики должны понимать, что не существует универсального инструментаСуществуют хорошие инструменты, и существуют плохие. Почему-то сейчас каменными топорами и палками-копалками никто не пользуется. Вместо лучин используют лампы.
> штрафовать за затягивание сроковПри таком раскладе все растовики будут в минус работать.
и за баги растовиков надо штрафовать вдвойне, ведь поскольку с памятью они работают безопасно, то и времени на отладку других типов багов у них полно
>> штрафовать за затягивание сроков
> При таком раскладе все растовики будут в минус работать.Эх, жаль, поздно ветку прочёл, но отвечу:
"Ларс Бергстром (технический директор Google): "Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++"."
Заявлению техдиректора гугла я доверяю больше, чем твоему ценному мнению.
> "Ларс Бергстром (технический директор Google): "Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++"."Давай я тебе что-нибудь очень тебе нужное продам очень дешево, раз ты такой доверчивый.
Этот Ларс Бергстром как раз свою должность получил за то что внедрил rust и наричовал красивые отчеты. Что он по твоему должен говорить?
Если еще учесть, что он сам же признавался, что пришло осознание что не все задачи подходят для внедрения туда rust. Это после того как пара направлений совсем умерла.
каменный топор это си, а металлический это раст?
металлический топор безопаснее каменного?
> каменный топор это си, а металлический это раст?
> металлический топор безопаснее каменного?Анон использовал не совсем корректное сравнение.
Я бы написал так "каменный топор - т.е случайная палка к которой камень привязан лианами", и "металлический топор с прорезиненной ручкой".Но лучше сравнить "современные перфоратор или болгарку у которых есть двойная изоляция, ударостойкий корпус и кожух пильного диска" с болгакой с напяленным на нее пильным диском или перворатором с оголенными шестернями и проводами под напряжением.
На все претензии нужно будет отвечать "ну пользуйтесь аккуратнее")
> Но лучше сравнить "современные перфоратор или болгарку у которых есть двойная изоляция, ударостойкий корпус и кожух пильного диска" с болгакой с напяленным на нее пильным диском или перворатором с оголенными шестернями и проводами под напряжением.вы перегибаете с аналогиями. На самом деле у вас два однотипных инструмента, но на одном прикручен здоровенный такой кондуктор, назначение которого — выкручивать руки пользователю при некоторых положениях инструмента. На кондукторе дополнительно предусмотрена кнопка для его сброса
> вы перегибаете с аналогиями.Ваше право так считать.
> На самом деле у вас два однотипных инструмента, но на одном прикручен здоровенный такой кондуктор, назначение которого — выкручивать руки пользователю при некоторых положениях инструмента.
Вот просто так выкручивать руки?
Или все таки ограничивать перемещение, чтобы эти ручки на вал не намотало?> На кондукторе дополнительно предусмотрена кнопка для его сброса
Именно! Тот самый unsafe позволяет делать абсолютно все что пожелаешь, но тогда, когда это реально необходимо.
> Именно! Тот самый unsafe позволяет делать абсолютно все что пожелаешь, но тогда, когда это реально необходимо.Вот тут и высвечивается концептуальная незавершенность. Почему кнопка одна?
При написании можно разрешать или запрещать использовать разное.
И это разное можно дифференцировать.
> Вот тут и высвечивается концептуальная незавершенность. Почему кнопка одна?А зачем плодить сущности и переусложнять?
unsafe это просто знак "валидность этого кода в данный момент компилятор доказать не может и все". А если не может, то значит доказывать должен разработчик.> При написании можно разрешать или запрещать использовать разное.
М... типа тут можно писать за границы буфера, но нельзя дважды освобождать память, а вот в другой функции за границы буфера ни-ни, а вот дабл-фри делать можно?))
> И это разное можно дифференцировать.
Но зачем? Приведите конкретный пример, где это было бы полезно.
> А зачем плодить сущности и переусложнять?Потому что это не переусложение, а возможность настроить использование под свои нужды.
Кому-то нужны более жесткие требования. Кому-то менее жесткие.
> М... типа тут можно писать за границы буфера, но нельзя дважды освобождать память, а вот в другой функции за границы буфера ни-ни, а вот дабл-фри делать можно?))
Типа. В одном куске кода нельзя выделять память на куче, а в другом можно.
> Но зачем? Приведите конкретный пример, где это было бы полезно.
Как пример. MSIRA - ты не обязан выполнять ВСЕ возможные требования. Для своего проекта ты можешь выбрать необходимый минимум.
> Кому-то нужны более жесткие требования. Кому-то менее жесткие.
> Типа. В одном куске кода нельзя выделять память на куче, а в другом можно.Но только косяк в выделении памяти в куче легко испортит память и для кода где это было делать нельзя. И разрешая это это в одном месте вы по сути разрешаете везде.
> Как пример. MSIRA - ты не обязан выполнять ВСЕ возможные требования.
Нет, это не конкретный пример, а пространственное рассуждение.
Тем не менее повторюсь, в мисре есть Mandatory Guidelines, которые ты выполнять обязан (если не возпользуешься админкостылем re-categorization, но это вообще позор что такое протащили)> Для своего проекта ты можешь выбрать необходимый минимум.
У раста очень небольшие требования к safe code - соблюдение ownership, запрет на dereference для raw pointer и так далее. В нем нет запретов на выделение памяти в куче, ограничений цикломатической сложности, рекурсии, еще сотни других вещей, которые регулирует MISRA.
Возможно когда-то появится список требований для SuperSafeRust, где все это будет. И вот там ты будешь выбирать как в мисре. Но сейчас в этом нет необходимости, т.к. правила unsafe уже позволяют избавиться от большого количества багов и повысить надежность.
MISRA же не часть стандарта си, а надстройка, поэтому непонятно почему вы требуете чтобы у раста это было из коробки.
> MISRA же не часть стандарта си, а надстройка, поэтому непонятно почему вы требуете чтобы у раста это было из коробки.Почему это высказывание о концептуальной неполноте стало требованием.
Разрабатываются языки с дополнительным управлением доступности средств языка. Их делают концептуально полноценными.
Спорить с тем, что rust недоделан и концептуально незавершен сложно.
Однако религиозный фанатизм заставляет вас писать хоть что-то. Даже не задумываясь о том, что вы никак не опровергаете...
> Вот просто так выкручивать руки?таки да. Если бы программу нельзя было неправильно написать, то это было бы ограничение. А тут как раз происходит отмена "неправильного перемещения" уже после написания, т.е. воздействие на руки пользователя.
> Именно! Тот самый unsafe позволяет делать абсолютно все что пожелаешь, но тогда, когда это реально необходимо.вот бы еще у всех было одинаковое представление, о том, что необходимо
Не приверженец и не противник раста, но аналогии направленные на запугивание уже порядком надоели.
Нет никакой дрели с поврежденной проводкой, болкарка с кожухом все так же опасна. Любой инструмент опасен и степень его опасности определяется самоуверенностью того, кто его держит.
Нравится использовать кондуктор - пользуйся, не нравится - хоть изготавливай свой инструмент. Пока между людьми нет "контрактных обязательств" все стороны свой выбор делают сами
> металлический топор безопаснее каменного?Да. Когда ты бьёшь каменным топором во все стороны разлетаются осколки камня. Один такой осколок получишь в глаз, и сомнений в том, что опаснее у тебя не останется.
> Да. Когда ты бьёшь каменным топором во все стороны разлетаются осколки камня.
> Один такой осколок получишь в глаз, и сомнений в том, что опаснее у тебя не останется.А в ответ ты получишь
1. просто н̶е̶ ̶д̶е̶л̶а̶й̶т̶е̶ ̶о̶ш̶и̶б̶к̶и̶ ̶с̶ ̶п̶а̶м̶я̶т̶ь̶ю̶ закрывайте глаза
2. ну и что? разве ты от этого потрадал?
3. диды этими каменными топорами построили цивилизацию, так что, а ну быстро проявляй уважение!
4...
если раст за вас запятые не ставит, то поставлю я где удобно мне...
> Когда ты бьёшь каменным топором во все стороны(запятая) разлетаются осколки камняне бей топором во все стороны, первое.
а второе саблюдайте ТБ, работайте в очках. И не только с небезопасным каменным топором, но и например с безопасными ушм, касилками и тд
Мне в этом качестве больше нравиться сообщество в дискорд сервере (не реклама). Там Есть отдельные каналы для вопросов и обсуждения, обсуждения там как раз более глубокие с отдельными каналами на различные темы. Мне там даже помогли оптимизировать параллелизм для дизеринга изображений. Кажется, что если к вам везде в сообществе относятся с негативом, то наверное вам там не особо рады, и нужно либо не взаимодействовать, либо менять подход в общении.Говорят же в чужой монастырь... Как ты, так и к тебе...
> Кажется, что если к вам везде в сообществе относятся с негативомМогу тебе предъявить то же самое, но сказав, что ни в одном другом сообществе я не встречал таких токсиков, как в сообществе растоверов-евангелистов.
Так что не ВЕЗДЕ и не ко МНЕ одному, учитывая регулярное уличение в токсичности именно раст комьюнити. Кстати, что-то в адрес других языков я не видел таких упрёков.
> Могу тебе предъявить то же самое, но сказав, что ни в одном
> другом сообществе я не встречал таких токсиков, как в сообществе растоверов-евангелистов.Ну вот смотри, анон выше негатива не заметил.
Я тоже не заметил. А ты куда не придешь в обсуждения раста, так так одни токсики.
Может это в тебе дело?> Кстати, что-то в адрес других языков я не видел таких упрёков.
Ну-ну. А как настоящие сишники™ и плюсовики называют программистов на JS?
А как относятся к питощикам? Что говорят про PHP? Или про паскелистов?
Или это классическое "это_другое"?Вы же в своем глазу бревна не видите.
Посмотрите на себя со стороны, насколько вы белые и пушистые
не нужно оскорблять меньшинства сравнением с фанатиками раста
Уже видел эту копипасту. Вы там методички хотя бы иногда обновляйте.
> Кстати почитал тут тг чатик растаНе читайте советские газеты перед обедом (c) Булгаков "Собачье сердце".
Это какая-то высшая степень о-гофр-нии судить о языке программирования по чатику в Телеграме. Я просто оф-ваю от уровня умственного развития нынешних "экспертов" Опеннета.
> Думайте!
Это явно не то, что вы любите и умеете делать.
> Из блоков "asm!" с ассемблерным кодом разрешено осуществлять переходы на блоки с кодом на языке Rust, что упрощает разработку низкоуровневого кода, например, реализации оптимизаций в ядре или организации взаимодействия с оборудованием.Криво, косо, но хотя бы работает. Так глядишь, пока пытаются хоть что-то сделать в ядре и сделают более менее работающий язык программирования. Правда темпы этого делания. Я к тому времени уже на пенсии буду.
> Разрешено точно указывать захваченные обобщённые типы и время жизни в определениях типажей с использованием возвращаемых типов impl Trait.Наконец-то.
Ребята, а какие есть удобные веб-фреймворки для этого чуда техники? Наподобие кваркуса или микронавта есть что-нибудь?
Если попроще для восприятия - Rocket, нужна максимальная производительность - Actiх. Есть еще Axum, но я его пока не щупал.
https://github.com/poem-web/poem
https://rocket.rs
Топовое, самое популярное и фичастое решение - Axum.
Если руст такой хороший, то почему на него только переписывают, но не создают ничего нового?
Новое не язык программирования упирается, технически можно новое и на асме написать. Новое упирается в идею, потом в архитектуру и так далее.
у рестоманов _всегда_ виновато что угодно, но не они и не их недоязык
Лжёшь. На Расте пишут те, кто понимает цену ошибок. Это сишники в каждой новости про очередную дырень твердят, что так и должно быть.
наглая ложь, на расте пишут те веб-синьоры, которым на ночь стали страшные сказки про сишное UB. они даже сами этого не понимают. с ними разговаривать - это как разговаривать с морковкой
в смысле переписывают, конечно. никто на нём не пишет
> Лжёшь. На Расте пишут те, кто понимает цену ошибок. Это сишники в
> каждой новости про очередную дырень твердят, что так и должно быть.Спутники летают десятки лет, там софт навигационной системы на С, одна ошибка спутник упадет, а разработчик сядет. Значит можно писать на С нормально-))) Язык программирования дело десятое, вначале идет нормальное проектирование софта, потом корректная разработка, потом нормальное тестирование, на практике кроме редких случаев, что проектирование, что тестирование хромает на обе ноги, про качество кода я вообще умолчу. В результате получают фуфло-софт, а дальше судорожно ищут кто виноват и начинают грешить на язык программирования-)
Так толсто, что аж тонко.
А зачем создавать что-то новое в опенсорсе: за новое что, деньги заплатят? Нет.
Это же опенсорс, кому что надо, тот то и делает.
Большинство фанатов сишки только советы раздают, а сами код не пишут.
Потому что зло неспособно создать что-то новое, оно лишь способно извратить старое.
Смотря что называть новым, но то о чем слышал/пользовался:
Cosmic DE
Alacrity, Wezterm
nushell
hyperfine
just
jj
uv, ruff
Zed, helix
Bevy
Axum
Leptos
TikToken/bpe
Embassyнаверное на awesome списке ещё найдется чего.
Ты правда думаешь, что у окружающих есть ответ на вопрос про выдуманный мир, который существует только у тебя в голове?
Менеджеры где-то узнали, что программы на Rust е быстрее Go-шных и Java-ских на 30%, и дали задание своим программистам переписать свою бизнес-прогу на Ruste. Однако пока программисты переписывали её 4 месяца, конкуренты, у которых проги на Go, успели за 2 месяца добавить в свои проги новые фичи, и переманили клиентов к себе.
А потом эти конкуренты, писавшие на Джаве или Гоу получили счета от облачных провайдеров и обанкротились. 😂
Почему с такой упоротостью нет новостей о других языках, например:
Кобол, Ада, Фортран, Форт, Алгол, Бейсик, ЭсОдин наконец?Неужто этот сайт достоин только этого божественного языка?
> Почему с такой упоротостью нет новостей о других языках, например:
> Кобол, Ада, Фортран, Форт, Алгол, Бейсик, ЭсОдин наконец?потому что их позорные разработчики неспособны отметить день рождения своего языка, выпустив очередной несовместимый релиз единственно-верного компилятора, попутно сделав несобираемыми им исходники на не-единственноправильной платформе.
Они и день-то этот, наверняка, не знают.
Это про ЭсОдин?
Ну потому что язык активно развивается. Завидуете? Ж)
В чем развитие? Добавить восклицательный знак, перенести код из одной библиотеки в другую, увеличить циферку в версии?
добавить эмодзи в ридми, их вечно не хватает
> Кобол, Ада, Фортран,А что нового можно написать про кобол? Что пенсы практически вымерли и писать некому?
Или какие новости были о Ада и Фортране? У них последние версии вышли в 23 году.> Форт,
Невзлетевшая маргинальщина. Зашла только там, где использовались специализированные форт-микроконтроллеры, вроде космоса/военки где деньги не считают. Хотя и это время прошло.
А обычного софта даже у раста больше наберется чем на форте.> Алгол
Последняя версия языка - ALGOL 68, а новейшая реализация S-algol 1979 года.
Что предлагаете про него писать? Историческую справку? Некролог?> Бейсик
Тоже мертво.
> ЭсОдин наконец?
Это не язык программирования :)
> Неужто этот сайт достоин только этого божественного языка?
Этот сайт достоин только новостей про божественный Го!
И их публикуют после каждого релиза.
стандарт C++ выходит раз в три года
несовместимые версии Rust каждые несколько мнсяцев
Зачем врать только про несовместимость версий Rust? И почему ни слова про "замечательную поддержку" очередного стандарта C++ компиляторами?
> Зачем врать только про несовместимость версий Rust?А Вы попробуйте собрать so/dll на одной версии компилятора и вызвать её из кода, скомпилированного другой версией. Или Вы предлагаете для каждой новой версии компилятора Rust перекомпилировать всю операционную систему со всеми установленными приложениями?
Динамическое связывание вроде бы Rust поддерживается, но по факту толку от него никакого, так как не только опубликованного стандарта, но даже какой-то стабильности у ABI нет.
В результате сейчас все проекты на Rust пользуются C ABI, на границе с которым прощаются с безопасной работой с памятью. А вызвать so/dll на Rust из других языков вообще не представляется возможным, если они не сделаны оберткой через тот же самый C ABI и с таким же прощанием с безопасной работой с памятью.
Собственно говоря, именно это объясняет, почему тот же su/sudo на Rust переписать можно, а вот куда более критичный для безопасности PAM - уже нет.> И почему ни слова про "замечательную поддержку" очередного стандарта C++ компиляторами?
Во-первых, если, как в Rust, объявить "стандартом" конкретный компилятор, то он по определению будет соответствовать этому "стандарту". Во-вторых, по крайней мере Itanium ABI сейчас поддерживается большинством компиляторов.
Лично мне в Rust катастрофически не хватает сейчас двух вещей:
1. Стабильного ABI, позволяющего свободно использовать динамическое связывание.
2. Наличие write-only объектов, которые не надо инициализировать и из которых разрешается читать только то, что ранее в коде было записано. Про unsafe MaybeUninit я в курсе. Но он unsafe и никак не запрещает читать из неинициализрованных объектов. Поэтому его применение небезопасно.
> Во-первых, если, как в Rust, объявить "стандартом" конкретный компилятор, то он по определению будет соответствовать этому "стандарту".Ну так это же прекрасно. Плюс этот компилятор всегда реализует все фичи языка.
А не как в некоторых языках, не будем показывать пальцем, где стандарт есть уже несколько лет, а компиляторов его реализующих нет.> Во-вторых, по крайней мере Itanium ABI сейчас поддерживается большинством компиляторов.
Это все равно не гарантирует совместимость, а проблемы искать еще сложнее.
>> Во-первых, если, как в Rust, объявить "стандартом" конкретный компилятор, то он по определению будет соответствовать этому "стандарту".
> Ну так это же прекрасно.Полное отсутствие выбора - это по Вашему прекрасно? А что Вы, простите, тогда тут делаете? OpenNET - это платформа для тех, кто всегда хочет иметь выбор, а не зависеть от одного единственного поставщика. Вам тогда прямая дорога к решениям MicroSoft. У него вообще на все продукты свои собственные "стандарты" )))
>> Во-вторых, по крайней мере Itanium ABI сейчас поддерживается большинством компиляторов.
> Это все равно не гарантируетЗа гарантиями обращайтесь в страховые компании. В IT гарантий никто и никогда Вам не даст.
> Полное отсутствие выбора - это по Вашему прекрасно?Нет, это ужасно.
Например, монополия такого древнючего копролита как хорг привело к полнейшей деградации графики на линуксах.Но тут у вас есть выбор - пользоваться растом или нет. Вы даже можете форкнуть и написать свои фичи. Вон недавно какой-то Crab был представлен.
Я уже молчу про то, что по такой извращенной логике у нас есть монополия на фичи есть у коммитета С, который решит как будет развиваться язык.> А что Вы, простите, тогда тут делаете?
Комменты пишу с умным видом, естественно)
> OpenNET - это платформа для тех, кто всегда хочет иметь выбор, а не зависеть от одного единственного поставщика.
А вообще если посмотреть сорцы этого самого опеннета, то там
<TITLE>Проект OpenNet - всё, что связано с открытым ПО, открытыми технологиями, Linux, BSD и Unix</TITLE>
Не вижу чтобы что-то говорилось про какой "выбор".> Вам тогда прямая дорога к решениям MicroSoft. У него вообще на все продукты свои собственные "стандарты" )))
Конечно. Трудно не пользоваться самой популярной ОС в мире.
Но я все-таки предпочитаю macos, для случаев когда нужно работать, а не прдолиться с системой.Возможно майкрософт подсмотрел свое EEE у создателей ядра линукс, которые прибили его к единому рассово-идеологически-верному компилятору GCC. Понадобились годы работы чтобы избавитьтся от такого подлого вендорлока.
> За гарантиями обращайтесь в страховые компании. В IT гарантий никто и никогда Вам не даст.Пока не дадут.
Но процесс уже идет, пока на стадии предложений.
И судя по сгоревшим пятым точкам оно многих напугало.
opennet.ru/opennews/art.shtml?num=60273Cyber Resilience Act заработает в конце 2027, посмотрим как поведут себя любители AS IS.
>> Полное отсутствие выбора - это по Вашему прекрасно?
> Нет, это ужасно.То есть монополия rustc на стандарт это всё же плохо?
> Но тут у вас есть выбор - пользоваться растом или нет.
А это при чем? Для Rust я сейчас использую три компилятора, не считая форков rustc+LLVM для поддержки некоторых реализаций RISC-V. И с таким зоопарком стандарт явно становится необходим. Ну не поддерживает rustc+LLVM ни восьмибитные МК, ни целый ряд стандартов RISC-V (даже E до сих пор экспериментальный в LLVM, в отличии от GCC), ни даже некоторые особенности ARM, вроде PIO у RP2040. Предлагаете пользоваться ассемблером или intrinsics? А как же безопасность при работе с памятью?
И всё же, что предлагаете делать с отсутствием стандарта ABI? Или Вы отвечаете только на те вопросы, которые Вам удобно?
> Я уже молчу про то, что по такой извращенной логике у нас
> есть монополия на фичи есть у коммитета С, который решит как
> будет развиваться язык.У Вас глюки. Стандарт не запрещает расширения (фичи).
Зато стандарт позволяет использовать один и тот же код на самых разных архитектурах. Начиная с двухцентовых Padauk и заканчивая Nvidia H100. Что с Rust сейчас не представляется возможным.> предпочитаю macos
Прикольно получается. С одной стороны токсичные растоманы предлагают переписать всё на Rust, но с другой стороны, из-за отсутствия стандарта ABI это невозможно физически. Или Вы считаете возможным перекомпилировать всю операционную систему со всеми приложениями, включая сторонние, каждый раз, когда выходит новая версия Rust?
>> За гарантиями обращайтесь в страховые компании. В IT гарантий никто и никогда Вам не даст.
> Пока не дадут.Никогда не дадут. Нет программных продуктов без ошибок.
Например, Rust вроде бы гарантирует безопасную работу с памятью. Но при этом спокойно сейчас позволяет use-after-free. И никаких средств у языка против этого пока нет. Можете в любой момент освободить буфер, в который по кольцу пишет DMA, и компилятор даже не предложит перед этим остановить DMA.
> То есть монополия rustc на стандарт это всё же плохо?Хм... а где монополия?
Любой может форкнуть rustc и сделать по своему. Это раз.
Во-вторых, есть другие реализации, например gccrs или cranelift.
В мире С ситуация примерно такая же - есть топовые компиляторы, а есть догоняющие.> А это при чем? Для Rust я сейчас использую три компилятора, не считая форков rustc+LLVM для поддержки некоторых реализаций RISC-V.
Т.е, как я и предполагал, монополии нету.
> И с таким зоопарком стандарт явно становится необходим.
> Ну не поддерживает rustc+LLVM ни восьмибитные МК, ни целый ряд стандартов RISC-V (даже E до сих пор экспериментальный в LLVM, в отличии от GCC), ни даже некоторые особенности ARM, вроде PIO у RP2040.Очень печально, но как бы вам помог стандарт?
Как будто от его наличия появилась бы поддержка восьмибитных МК.> Предлагаете пользоваться ассемблером или intrinsics? А как же безопасность при работе с памятью?
Подозреваю что никак.
Если ваши целевые платформы полностью не поддерживаються даже LLVM, то скорее всего вы играете роль первопроходца и собирать шишки.> И всё же, что предлагаете делать с отсутствием стандарта ABI? Или Вы отвечаете только на те вопросы, которые Вам удобно?
Ничего не делать)
В С++, например, тоже нет стандарта ABI. Есть некоторые договоренности, но они тоже нарушаются. Common Vendor ABI поддерживают далеко не все.
В 11 версии его очень хорошо поломали, и думаю в ближайшей сломают еще раз.
Т.к будет выбор или стабильность или производительность (местами в разы)
www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf> У Вас глюки. Стандарт не запрещает расширения (фичи).
> Зато стандарт позволяет использовать один и тот же код на самых разных архитектурах.Ага, только один и тот же код может давать разные результаты.
Причем не всегда нужно переходить на другую архитектуру, достаточно обновить версию или вендора компилятора.> Начиная с двухцентовых Padauk и заканчивая Nvidia H100. Что с Rust сейчас не представляется возможным.
Возможно создатели раст не хотят заморачиваться с "двухцентовыми Padauk".
Это их полное право.> Прикольно получается. С одной стороны токсичные растоманы предлагают переписать всё на Rust, но с другой стороны, из-за отсутствия стандарта ABI это невозможно физически.
Почему невозможно. А просто собрать из сорцов не выход?
Вон гентушники так постоянно делают и кажется никто не умер.> Или Вы считаете возможным перекомпилировать всю операционную систему со всеми приложениями, включая сторонние, каждый раз, когда выходит новая версия Rust?
Да, считаю возможным.
Игрался с гентой в молодости, так что не вижу в этом трагедии.Создание ABI для активно развивающегося ЯП станет просто гирей на ногах, ограничевающее изменения. Сразу будет куча людей кричащих "не смейте ломать, у меня скомпилированный код и мне лениво его пересобрать".
> Никогда не дадут. Нет программных продуктов без ошибок.
Разумеется. Все определяет кол-во и "качество". Например метрика ошибок на 1к строк, или вероятность отказа в часах работы.
Другие индустрии это уже прошли, что авиация, что пищевая промышленность, что автомобильная.
Есть и другие метрики, которые можно применить.> Например, Rust вроде бы гарантирует безопасную работу с памятью. Но при этом спокойно сейчас позволяет use-after-free. И никаких средств у языка против этого пока нет.
Вопрос не в безопасной работе как таковой, а в последствия ошибки.
Например утечка памяти это неприятно, но если оно не приводит к повышению привилегий, то важность такой ошибки резко снижается.> Можете в любой момент освободить буфер, в который по кольцу пишет DMA, и компилятор даже не предложит перед этим остановить DMA.
Про DMA вы уже писали тут opennet.ru/openforum/vsluhforumID3/136517.html#416
Как по мне это была логическая ошибка "просто забыли остановить DMA".
И память портил не раст, а DMA который писал куда бог пошлет.> и компилятор даже не предложит перед этим остановить DMA
Если бы то же самое сделали в коде на С или С++ какой был бы результат?
Может ли компилятор раста проверять такие вещи и, главное, "а должен ли?"Возможно раст или программисты на расте не готовы к микроконтроллерам.
Но кроме них есть множество других применений.
Вы же смотрите с учетом одной вашей проблемы и весьма узкой ниши.
Что-то вроде "а вы знаете что ваш телефон не работает на семи тысячах метрах над уровнем моря!?"
>> То есть монополия rustc на стандарт это всё же плохо?
> Хм... а где монополия?Перечитайте обсуждаемую новость. Выпуск новой версии rustc автоматически обозначает выпуск новой версии Rust. Просто потому, что его объявили эталоном (стандартом).
> В мире С ситуация примерно такая же - есть топовые компиляторы, а
> есть догоняющие.Ну есть стандарты, которым они так или иначе соответствуют.
> Очень печально, но как бы вам помог стандарт?
Я уже неоднократно писал. У Вас проблемы? Стандарт позволяет использовать один и тот же код на всех платформах, а не под каждую платформу и её компилятор адапатировать код.
> Как будто от его наличия появилась бы поддержка восьмибитных МК.
Зато крейты, написанные в соответствии со стандартом, можно было бы использовать без патчей под конкретный компилятор.
> Если ваши целевые платформы полностью не поддерживаються даже LLVM
Восьмибитные МК LLVM не будут поддерживаться никогда из-за минимум 32-х битной сущности IR.
RISC-V еще не скоро будет полноценно поддерживаться LLVM. Одного BR в IR достаточно, чтобы оптимизация для RISC-V превратилась в задачу для AI.>> И всё же, что предлагаете делать с отсутствием стандарта ABI? Или Вы отвечаете только на те вопросы, которые Вам удобно?
> Ничего не делать)Тогда Rust никогда не сможет заменить C.
> В С++, например, тоже нет стандарта ABI.
Зато он есть в C. И тот же Rust в костыле под названием abi_stable именно им и пользуется, при помощи спецификатора extern "C" для функций на Rust. Где при этом оказывается безопасная работа с памятью, надеюсь, объяснять не надо?
> Common Vendor ABI поддерживают далеко не все.
По сути, только MS сопротивляется.
>> Зато стандарт позволяет использовать один и тот же код на самых разных архитектурах.
> Ага, только один и тот же код может давать разные результаты.
> Причем не всегда нужно переходить на другую архитектуру, достаточно обновить версию или
> вендора компилятора.А Вы пишите код соблюдая стандарты. Не пробовали?
У меня есть куча кода еще на C86, который без проблем компилируется SDCC, GCC и CLang под самые разные платформы. Никаких проблем, если не использовать расширения компиляторов и последний стандарт (С23), который еще не все компиляторы полностью поддерживают.
Если в том же GCC или CLang я явно могу указать, что использую C11, то в Rust стандартов нет и нет возможности указать компилятору, какой именно стандарт используется в коде. Поэтому, нередко, крейт, который замечательно собирался еще год назад, компилироваться отказывается. Я уже забодался после каждого нового релиза Rust коммитить в чьи-то проекты или переходить на их форки.>> Начиная с двухцентовых Padauk и заканчивая Nvidia H100. Что с Rust сейчас не представляется возможным.
> Возможно создатели раст не хотят заморачиваться с "двухцентовыми Padauk".Во-первых, Вы опять путаете язык и компилятор. Rust вполне можно использовать для Padauk. Нельзя использовать rustc. К слову, в Mozilla Rust развивался именно как замена C. А область применения C включает в себя MK.
Во-вторых, rustc использует для кодогенерации LLVM. То есть разработчики rustc c 2011 года о кодогенерации не задумывались вообще.>> Прикольно получается. С одной стороны токсичные растоманы предлагают переписать всё на Rust, но с другой стороны, из-за отсутствия стандарта ABI это невозможно физически.
> Почему невозможно. А просто собрать из сорцов не выход?Нет, конечно, так как на практике, за исключением особо свободных установок ОС, на которых невозможно в реальности работать, имеется целый ворох блобов, которые не перекомпилить. Не только всяческие Zoom, Citrix, Discord, драйвера и т.п., но даже игры, которые все пользуются ABI.
>> Или Вы считаете возможным перекомпилировать всю операционную систему со всеми приложениями, включая сторонние, каждый раз, когда выходит новая версия Rust?
> Да, считаю возможным.Начните тогда с Вашей любимой макоси. Расскажите о результате )))
> Игрался с гентой в молодости, так что не вижу в этом трагедии.
Не верю. Даже в родном portage немало блобов, которые не перекомпилить.
> Создание ABI для активно развивающегося ЯП станет просто гирей на ногах, ограничевающее
> изменения. Сразу будет куча людей кричащих "не смейте ломать, у меня
> скомпилированный код и мне лениво его пересобрать".Кто мешает использовать разные версий ABI в зависимости от ключей компилятора?
А отсутствие стабильного ABI вообще не позволяет вести многие виды разработки. Подавляющее большинство более-менее крупных проектов сейчас требуют динамического связывания хотя бы для поддержки расширений.> И память портил не раст, а DMA который писал куда бог пошлет.
Но DMA был запущен средствами Rust.
А если портит CPU через некоторые реализации NUMA или PIO - тоже нормально? )))>> и компилятор даже не предложит перед этим остановить DMA
> Если бы то же самое сделали в коде на С или С++
> какой был бы результат?А с каких пор C/С++ стали гарантировать безопасную работу с памятью?
> Может ли компилятор раста проверять такие вещи и, главное, "а должен ли?"
Да, если хочет действительно гарантировать безопасную работу с памятью.
> Возможно раст или программисты на расте не готовы к микроконтроллерам.
Вы думаете DMA есть только на МК? Некоторые даже области памяти под Linux средствами DMA копируют.
> Вы же смотрите с учетом одной вашей проблемы и весьма узкой ниши.
Перечитайте:
>> Начиная с двухцентовых Padauk и заканчивая Nvidia H100.CPU общего назначения тут где-то посередине.
Так что это как раз Вы смотрите с учетом весьма узкой ниши. Даже на ПК RISC-V уже представлен на рынке несколькими производителями. Но с поддержкой Rust исключительно через GCC toolchain.
> Перечитайте обсуждаемую новость. Выпуск новой версии rustc автоматически обозначает выпуск новой версии Rust. Просто потому, что его объявили эталоном (стандартом).Не совсем так.
У раста нет "стандарта" ИСО, но это не единственный способ стандартизации.
Например Official Internet Protocol Standards справляются RFC822.Есть RFC которые определяют поведение языка. И rustc их имплементирует после принятия.
Ничто не мешает следить за драфтами, их развитием, имплементировать соответственно им в жцц.
Тогда gcc мог бы выходить в тот же день что и rustc.> Ну есть стандарты, которым они так или иначе соответствуют.
Для меня ключевое "так или иначе")
> Я уже неоднократно писал. У Вас проблемы? Стандарт позволяет использовать один и тот же код на всех платформах, а не под каждую платформу и её компилятор адапатировать код.
Да, моих познаний в 8 битах не хватает чтобы понять чего не хватает.
Тут я признаю свои пробелы.> Зато крейты, написанные в соответствии со стандартом, можно было бы использовать без патчей под конкретный компилятор.
Чем не устраивает РФЦ? Если вам нужно, напишите RFC под в бит.
> Восьмибитные МК LLVM не будут поддерживаться никогда из-за минимум 32-х битной сущности IR. RISC-V еще не скоро будет полноценно поддерживаться LLVM. Одного BR в IR достаточно, чтобы оптимизация для RISC-V превратилась в задачу для AI.
Т.е крупнейший компилятор мало волнуют восьмибитки? С чего вдруг раст должен их поддерживать?
>> Ничего не делать)
> Тогда Rust никогда не сможет заменить C.Но он уже его заменят.
Так что правильное утверждение должно выглядеть так "Тогда Rust никогда не сможет заменить C во всех нишах, которые мне нужны".
Насколько я помню в списке платформ нет PDP-11. Так что раст УЖЕ не замена С.
А требования поддержки 8битных МК от него не слишком далеко.>> В С++, например, тоже нет стандарта ABI.
> Зато он есть в C.Это была ремарка к тому, что С++ как-то с этим живет.
А на нем, на минуточку, написана большая часть важнейшего софта в мире.> И тот же Rust в костыле под названием abi_stable именно им и пользуется, при помощи спецификатора extern "C" для функций на Rust. Где при этом оказывается безопасная работа с памятью, надеюсь, объяснять не надо?
Естественно она пропадает.
Но этот подход понятен - использовать уже существующие, распространенные "ресурсы" в виде существующего extern "C".
Судя по всему пока авторам языка это норм.>> Common Vendor ABI поддерживают далеко не все.
> По сути, только MS сопротивляется.Подумаешь, 70% дестопа.
> А Вы пишите код соблюдая стандарты. Не пробовали?
Пробовал. Мне понравилось.
Но во-1х тут я скорее меньшинство, а во-2х стандарт тоже меняется.
Например в С23 поменяли поведение zero-sized reallocations.> У меня есть куча кода еще на C86, который без проблем компилируется SDCC, GCC и CLang под самые разные платформы.
C86? Даже не слышал про такой. 89 знаю, K&R даже видел код.
> Если в том же GCC или CLang я явно могу указать, что использую C11, то в Rust стандартов нет и нет возможности указать компилятору, какой именно стандарт используется в коде.
Хм.. разве edition не решает эту проблему?
> Во-первых, Вы опять путаете язык и компилятор. Rust вполне можно использовать для Padauk. Нельзя использовать rustc.
Я исхожу из вашего предположения что "новый rustc == новый rust".
И что команда которая пишет rustc, в какой-то мере определяет развитие стандарта.> К слову, в Mozilla Rust развивался именно как замена C. А область применения C включает в себя MK.
И много браузеров запускается на МК? Особенно восьмибитных)
Мозилла разрабатывала раст, как замену СИ в ФФ. Не больше и не меньше.
Вы себе что-то придумали, а теперь используете как агрумент.Я бы попросил цитату от команды ФФ про использование на МК или c сайта раста "мы являемся заменой СИ". Но сомневаюсь что вы сможете такое найти.
> Во-вторых, rustc использует для кодогенерации LLVM. То есть разработчики rustc c 2011 года о кодогенерации не задумывались вообще.А в чем проблема в кодогенерации через LLVM?
То что оно не работает на всякой маргинальщине? Ну так не используйте.
LLVM позволил использовать готовые наработки и ускорить разработку языка.> Начните тогда с Вашей любимой макоси. Расскажите о результате )))
Отличный пример передергивания)
Но нет, за меня это сделает эпл и разработчики софта. Я не зря им деньги плачу.
Более того для меня мак это инструмент.
И да, меня так же не смущает то, я не могу перепрограммировать свою стиралку или перфоратор.> Не верю. Даже в родном portage немало блобов, которые не перекомпилить.
Это было почти 10 лет назад. Может память подводит, может просто повезло.
> Кто мешает использовать разные версий ABI в зависимости от ключей компилятора?
Сложность поддержки? Как минимум надо следить за этим, писать доку, прогонять тесты.
Ради чего?> А отсутствие стабильного ABI вообще не позволяет вести многие виды разработки.
А можно перечислить эти "многие виды разработки".
Как-то здоровые проекты типа андроида справляются.
Причем они даже bare metal как-то умудряются писать.> Но DMA был запущен средствами Rust.
Т.е если код который я вызвал в раст сделает "rm -rf для корня диска", то в этом тоже будет виноват раст?
> А если портит CPU через некоторые реализации NUMA или PIO - тоже нормально? )))Не знаю. Не буду делать выводы про вещи в которых я плаваю. С NUMA я не работал.
>> Если бы то же самое сделали в коде на С или С++ какой был бы результат?
> А с каких пор C/С++ стали гарантировать безопасную работу с памятью?А раст гарантирует "я буду следить за DMA и что там программер включает"?
>> Может ли компилятор раста проверять такие вещи и, главное, "а должен ли?"
> Да, если хочет действительно гарантировать безопасную работу с памятью.Что значит "действительно гарантировать")?
У раст есть четкое определение что он гарантирует. Если туда не попадают ваши случаи, то это печально и это возможность для улучшения.Я бы подумал что вы нуб, который про раст знает только из комментов.
Но ведь это не так! Вы отлично разбираетесь в теме, ведете и разработку.
Поэтому меня еще больше удивляет то, что вы не используете описание гарантий, которые обещал язык, а рассказываете какие-то свои хотелки, которые насколько я вижу, никто и не обещал.Это как говорить "вольво обещало безопасную машину, но столкновение с груженым самосвалом разваливает ХС90".
Поэтому я повторю вопрос "Обещал ли раст гарантии на случай ʼзабыли включить-выключить ДМАʼ? ".> Вы думаете DMA есть только на МК? Некоторые даже области памяти под Linux средствами DMA копируют.
Но раст на линуксе как-то работает.
> Так что это как раз Вы смотрите с учетом весьма узкой ниши.
> Даже на ПК RISC-V уже представлен на рынке несколькими производителями. Но с поддержкой Rust исключительно через GCC toolchain.Несколько производителей? Давайте сравним это с х86 и АРМ.
Получится реально мизер.Вы пишете про какие-то развивающиеся платформы типа риск5 или все еще используемые древности типа 8биток.
Придумываете какие-то "обязательства" типа "раст должен поддерживать всё что и СИ".
Это странно.ps если с растом столько проблем, то зачем вы его вообще используете?
Можно же писать на СИ по стандарту.
Или даже взять какой-то compcert который вполне развивается (недавно вышла 3.15).
Не обижайтесь, но это слегка выглядит как мазохизм.
>> Перечитайте обсуждаемую новость. Выпуск новой версии rustc автоматически обозначает выпуск новой версии Rust. Просто потому, что его объявили эталоном (стандартом).
> Не совсем так.
> У раста нет "стандарта" ИСО, но это не единственный способ стандартизации.У него нет никакого стандарта. Есть https://rust-lang.github.io/fls/general.html
This document specifies the form and meaning of programs written in the programming language Rust, as implemented by the rustc 1.84.0 compiler shipped with Ferrocene.
А разработчики rustc пишут https://blog.m-ou.se/rust-standard/ "Unfortunately, we currently do not have a complete specification of the language and standard library."
Так и живем, с референсным описание очередной версии rustc.> Есть RFC которые определяют поведение языка. И rustc их имплементирует после принятия.
И где RFC на сам Rust?
> Ничто не мешает следить за драфтами, их развитием, имплементировать соответственно им
> в жцц.То есть rustc Вы считаете эталоном? )))
> Тогда gcc мог бы выходить в тот же день что и rustc.
А почему не наоборот? Получается, что есть комьюнити, которое пытается всем диктовать свою волю и которому плевать на остальных. А ведь в истории такое уже случалось. С одним и тем же итогом, кстати. Вы действительно этого хотите?
>> Ну есть стандарты, которым они так или иначе соответствуют.
> Для меня ключевое "так или иначе")Ну так не пользуйтесь стандартом сразу после его выхода, до того, как разработчики не реализуют его в компиляторе. Это так сложно?
> Да, моих познаний в 8 битах не хватает чтобы понять чего не
> хватает.
> Тут я признаю свои пробелы.У Вас явно проблемы и в других архитектурах, кроме amd64.
>> Зато крейты, написанные в соответствии со стандартом, можно было бы использовать без патчей под конкретный компилятор.
> Чем не устраивает РФЦ? Если вам нужно, напишите RFC под в бит.Где RFC для крейтов?
>> Восьмибитные МК LLVM не будут поддерживаться никогда из-за минимум 32-х битной сущности IR. RISC-V еще не скоро будет полноценно поддерживаться LLVM. Одного BR в IR достаточно, чтобы оптимизация для RISC-V превратилась в задачу для AI.
> Т.е крупнейший компилятор мало волнуют восьмибитки? С чего вдруг раст должен их
> поддерживать?Хотя бы потому, что их вокруг нас десятки миллиардов.
>>> Ничего не делать)
>> Тогда Rust никогда не сможет заменить C.
> Но он уже его заменят.Только в той узкой области, где можно обходится без динамического связывания. Или используя C ABI, что ставит крест на безопасной работе с памятью и нитями.
> Насколько я помню в списке платформ нет PDP-11. Так что раст УЖЕ
> не замена С.
> А требования поддержки 8битных МК от него не слишком далеко.Вы давно видели PDP-11? А Вы не в курсе, что, например, почти в каждом литиевом аккумуляторе стоит восьмибитный МК? А про то что тот же Padauk за прошлый год реализовал почти 10 миллиардов восьмибитных МК, выручив 1.3 миллиарда долларов США тоже не слышали? В типово ПК сейчас не меньше десятка МК. В современном автомобиле - два-три десятка. Даже в концевиках дверей и кнопках стеклоподъемников, которые сейчас все на CAN.
>> И тот же Rust в костыле под названием abi_stable именно им и пользуется, при помощи спецификатора extern "C" для функций на Rust. Где при этом оказывается безопасная работа с памятью, надеюсь, объяснять не надо?
> Естественно она пропадает.
> Но этот подход понятен - использовать уже существующие, распространенные "ресурсы" в виде
> существующего extern "C".
> Судя по всему пока авторам языка это норм.Авторам "норм", что безопасность при работе с памятью и нитями накрывается медным тазом? Ну это уже много говорит о таких авторах )))
>>> Common Vendor ABI поддерживают далеко не все.
>> По сути, только MS сопротивляется.
> Подумаешь, 70% дестопа.И уже ноль процентов среди суперкомпьютеров. MS просто держится за свой COM. Поддержка Itanium ABI просто похоронит его окончательно.
>> А Вы пишите код соблюдая стандарты. Не пробовали?
> Пробовал. Мне понравилось.
> Но во-1х тут я скорее меньшинство, а во-2х стандарт тоже меняется.В разработке для критической инфраструктуры, где бал правит MISRA и тому подобные линтеры, не соблюдать стандарты невозможно. Просто заказчик не примет код.
> Например в С23 поменяли поведение zero-sized reallocations.Знаю, поэтому до сих пор C23 не пользуюсь. Да и MISRA его не поддерживает.
А с UB и на Rust приходится до сих пор кувыркаться. Например, при исчезновении порядка чисел с плавающей запятой. До сих пор это отдано на откуп архитектуре и, что и следовало ожидать, поведение на разных архитектурах в этом случае различно. Например, с учетом того, что в amd86 регистры FPU 80 бит, а в памяти храним f64 или даже f32 - последствия очевидны. Совершенно разный результат можно получить при разной регистровой оптимизации и разной последовательности операций умножения.
>> У меня есть куча кода еще на C86, который без проблем компилируется SDCC, GCC и CLang под самые разные платформы.
> C86? Даже не слышал про такой. 89 знаю, K&R даже видел код.Описался. Естественно C89.
>> Если в том же GCC или CLang я явно могу указать, что использую C11, то в Rust стандартов нет и нет возможности указать компилятору, какой именно стандарт используется в коде.
> Хм.. разве edition не решает эту проблему?Нет. Последний раз править код из-за того, что он перестал собираться пришлось с выходом Rust 1.85.0. В пару мест стандартной библиотеки тихо поменяли i8 на u8. Не я один возмущался.
>> Во-первых, Вы опять путаете язык и компилятор. Rust вполне можно использовать для Padauk. Нельзя использовать rustc.
> Я исхожу из вашего предположения что "новый rustc == новый rust".Где я такое писал? Я наоборот против того, чтобы каждая новая версия rustc объявлялась референсным эталоном языка без коммуникации с другими заинтересованными комьюнити.
> И что команда которая пишет rustc, в какой-то мере определяет развитие стандарта.
Вот это и плохо.
>> К слову, в Mozilla Rust развивался именно как замена C. А область применения C включает в себя MK.
> И много браузеров запускается на МК? Особенно восьмибитных)А Вы не в курсе, что та же Mozilla разрабатывала кроме браузера еще массу библиотек и компонентов? Например, nss.
> Мозилла разрабатывала раст, как замену СИ в ФФ. Не больше и не
> меньше.
> Вы себе что-то придумали, а теперь используете как агрумент.Это придумал Graydon Hoare, а не я http://venge.net/graydon/talks/intro-talk-2.pdf
> Я бы попросил цитату от команды ФФ про использование на МК или
> c сайта раста "мы являемся заменой СИ". Но сомневаюсь что вы
> сможете такое найти.Выше дал ссылку "C++ is well past expiration date". Ну и далее по тексту.
>> Во-вторых, rustc использует для кодогенерации LLVM. То есть разработчики rustc c 2011 года о кодогенерации не задумывались вообще.
> А в чем проблема в кодогенерации через LLVM?
> То что оно не работает на всякой маргинальщине? Ну так не используйте.С каких пор тот же RISC-V или ARM с PIO стал маргинальшиной? Да у них все шансы похоронить в итоге amd64.
> LLVM позволил использовать готовые наработки и ускорить разработку языка.
>> Начните тогда с Вашей любимой макоси. Расскажите о результате )))
> Отличный пример передергивания)
> Но нет, за меня это сделает эпл и разработчики софта. Я не
> зря им деньги плачу.И с чего Вы решили, что тот же HP будет перекомпилировать для Вас драйвер принтера, который он давно не поддерживает? )))
Может внимательно изучить даты динамически загружаемых библиотек на своем ПК. Да их годами никто не пересобирал. А тут Вы хотите каждые шесть недель? )))
Самый смак будет когда выявится 0-day уязвимость, исправленная и скомпилированная свежей версией rustc, а Вы не сможет её установить, дожидаясь пока не только Apple, но и все поставщики всех приложений на Вашем компьютере перекомпилируют ей свои программные продукты. После чего, вместо нескольких килобайт Вам потребуется качать и устанавливать добрую сотню гигабайт софта, потратив на это целый день, если не больше. Ради чего такие мучения?>> Не верю. Даже в родном portage немало блобов, которые не перекомпилить.
> Это было почти 10 лет назад. Может память подводит, может просто повезло.И тогда так было. Тем более 10 лет назад, когда open source драйвера для GPU могли использовать только энтузиасты. Такие монстры, как LibreOffice, FireFox и GCC 99% пользователей устанавли из через portage из блобов без перекомпиляции. LibreOffice даже сейчас компилируется часов шесть. А десять лет назад, без хотя бы двух дополнительных хостов с distcc, перекомпилировать его было самоубийственно.
>> Кто мешает использовать разные версий ABI в зависимости от ключей компилятора?
> Ради чего?Уже десятый раз пишу: ради поддержки динамического связывания без ущерба безопасности при работе с памятью и нитями.
>> А отсутствие стабильного ABI вообще не позволяет вести многие виды разработки.
> А можно перечислить эти "многие виды разработки".Ну тогда расскажите, как без динамического связывания можно на Rust написать, например, аналог PostgreSQL. Или Вы думаете кто-то согласится линковать все его расширения статически? А если мне, например, понадобится auto_explain, то я вместо LOAD 'auto_explain'; должен буду останавливать продуктивную СУБД, чтобы перекомпилировать её с auto_explain?
В общем случае, почти любой более-менее сложный программный продукт невозможен без динамического связывания.
Представьте себе, что та же mesa размером в 20МБ будет статически связываться с каждым приложением, которое его использует. У меня сейчас таких приложений запущено десятка три. Итого только на одной библиотеке получаем 600МБ расхода RAM без динамического связывания.
Или возьмем k8s. Если на C#/Java/Go на одном хосте с 32ГБ RAM спокойно поднимается двести подов (проверял на локале), то в при статическом связывании потребуется, как минимум, 256 ГБ только за счет дублирования библиотек protobuf, http/2 и ssl. За чей счет банкет?Вы и вправду не понимаете для чего нужно динамическое связывание или просто троллите?
> Как-то здоровые проекты типа андроида справляются.
Как я уже писал выше, отказываясь от безопасности при работе с памятью и нитями. Как в той же Redox, использующей для динамического связывания C ABI. Вот только мне непонятна цель таких проектов, так как главное преимущество Rust перед C тут пропадает.
> Причем они даже bare metal как-то умудряются писать.
Ну так для этого и есть usafe. Вот только беда в том, что unasafe физически не может контролировать корректность объектов, используемых в нем. Поэтому, чаще всего, ошибки при работе с памятью приходится править не в unsafe блоке, а где-то намного выше.
>> Но DMA был запущен средствами Rust.
> Т.е если код который я вызвал в раст сделает "rm -rf для
> корня диска", то в этом тоже будет виноват раст?Вы сначала процитируете, где это Rust гарантирует.
> А раст гарантирует "я буду следить за DMA и что там программер
> включает"?Rust гарантирует безопасную работу с памятью и потоками. Без оговорок, применяется ли там PIO, NUMA или DMA. Так что назвался груздем - полезай в кузов.
> Что значит "действительно гарантировать")?
> Цитирую "Our rich type system and ownership model ensure memory and thread safety". Как видим, не всегда.Воспользуйтесь гугл переводчиком https://translate.google.com/?hl=ru&sl=en&tl=ru&text=Our...
Я вижу ensure, а sometimes provide.> Я бы подумал что вы нуб, который про раст знает только из комментов.
> Но ведь это не так! Вы отлично разбираетесь в теме, ведете и разработку.
> Поэтому меня еще больше удивляет то, что вы не используете описание гарантий,
> которые обещал язык, а рассказываете какие-то свои хотелки, которые насколько я
> вижу, никто и не обещал.Я вообще то ещё коммитер нескольких проектов на Rust. И искренне считаю, что любой проект должен ориентироваться на потребности пользователей, а не свои собственные хотелки. И если комьюнити rustc будет и дальше игнорировать потребности рынка, он просто уйдет в историю. Чего я совсем не хотел бы.
>> Вы думаете DMA есть только на МК? Некоторые даже области памяти под Linux средствами DMA копируют.
> Но раст на линуксе как-то работает.А с чего Вы решили, что и на Linux в Rust где-то те же самые ошибки free-after-use из-за DMA или NUMA не возникают? Точно так же, как и при любом использовании DMA или NUMA.
>> Так что это как раз Вы смотрите с учетом весьма узкой ниши.
>> Даже на ПК RISC-V уже представлен на рынке несколькими производителями. Но с поддержкой Rust исключительно через GCC toolchain.
> Несколько производителей? Давайте сравним это с х86 и АРМ.У x86 есть GPU, где rustc применим ну с очень большими издержками. А на ARM, кроме GPU, полно сопроцессоров со своей системой команд, как уже упомянутый мной PIO. Так что и там всё совсем не радужно.
> Получится реально мизер.Только один Espressif еще год назад отрапортовал, что продал свыше миллиарда МК. В 2024 году было реализовано ~3 миллиарда RISC-V CPU/MC на сумму почти 20 миллиардов долларов США. Прогноз на 2030 году - ~16 миллиардов чипов RISC-V на сумму около 100 миллиардов долларов США.
> ps если с растом столько проблем, то зачем вы его вообще используете?
Я по мере сил коммичу в проекты на Rust для того, чтобы иметь возможность в будущем повсеместно использовать его вместо C/С++. И если усилиями комьюнити rustc это станет возможным только c gccrs - ну что же, это их выбор.
Я бы очень хотел использовать Rust не только на МК, а и в реальных проектах на работе. Но без стабильного ABI это не получается. Всё же там нужны не десктопные консольные утилиты, а, например, сервисы в k8s, где без динамического связывания стоимость хостов становится запредельной.
Поэтому в продуктивной эксплуатации не на МК приходится использовать Rust только в виде процедурного языка plrust в PostgreSQL.
В корпоративной среде, там где платят деньги, разработка для десктопа сейчас почти не требуется - везде веб. На смартфонах лидирует Java/Kotlin, который и без Rust всех устраивает. А в backend сейчас задач, где можно обойтись без динамического связывания почти нет.
> Так и живем, с референсным описание очередной версии rustc.Да. Вам бы стало легче если бы они писали "complete specification is under development and not complete yet"? А ведь это было бы абсолютной правдой.
СИ отсутствие стандарта не помешало распространиться. Думаю в знаете когда был K&R, а когда появился первый ISO.> И где RFC на сам Rust?
Предположу что тут github.com/rust-lang/rfcs
> То есть rustc Вы считаете эталоном? )))
Получается что да.
> А почему не наоборот? Получается, что есть комьюнити, которое пытается всем диктовать свою волю и которому плевать на остальных.
Разве? Я вижу комьюнити, которое делает то что считает нужным, но оставляет остальным возможность для своих интерпретаций, благо код открыт.
Команде gcc никто не мешает принимать активное участие в разработке и к моменту релиза уже иметь нужные изменения. А учитывая граффик релизов раста - можно даже обогнать на день-два.> А ведь в истории такое уже случалось. С одним и тем же итогом, кстати.
Давайте без напускания тумана. Из современных проектов, которые работают по такому принципу сегодня, я могу вспомнить только вейланд - у него есть референсная реализация в виде вестона.
Но каких-то ужасных проблем я не вижу.> Вы действительно этого хотите?
Если бы вы упомянули эти ужасные проекты, то я бы может ответил.
Пока могу сказать "я не вижу в этом проблемы".> У Вас явно проблемы и в других архитектурах, кроме amd64.
Возможно. Но тк amd64 и АРМ - самые распространенные архитектуры, то по моему скромному мнению, их поддержка обеспечивается в первую очередь.
А остальные пусть делают те, кому они нужны.> Где RFC для крейтов?
Предположу что тут github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md
>> Т.е крупнейший компилятор мало волнуют восьмибитки? С чего вдруг раст должен их поддерживать?
> Хотя бы потому, что их вокруг нас десятки миллиардов.Это не ответ. У команды разработки есть капасити. И оно не безконечное.
Как вы предлагаете решить эту проблему? Отказаться от LLVM и всех преимуществ?
Скорее всего разработчики решили что оно того не стоит.> Только в той узкой области, где можно обходится без динамического связывания. Или используя C ABI, что ставит крест на безопасной работе с памятью и нитями.
Отлично! Т.е у нас есть "узкая" область, в которой можно сконцентрировать усилия.
Т.к делать все одновременно просто не хватит ресурсов.> А про то что тот же Padauk за прошлый год реализовал почти 10 миллиардов восьмибитных МК, выручив 1.3 миллиарда долларов США тоже не слышали? В типово ПК сейчас не меньше десятка МК. В современном автомобиле - два-три десятка. Даже в концевиках дверей и кнопках стеклоподъемников, которые сейчас все на CAN.
В мире было продано 1223 миллионов смартфонов на андроиде.
В котором с 13 версии миллионы строк раст кода.> Авторам "норм", что безопасность при работе с памятью и нитями накрывается медным тазом? Ну это уже много говорит о таких авторах )))
Какие они плохие.
Но я не автор, так что вины не чувствую.> И уже ноль процентов среди суперкомпьютеров. MS просто держится за свой COM.
Волнуют ли меня проблемы суперкомпьютеров или я хочу чтобы мой комп не взламывался 28 нажатиями бекспейс? Думаю меня больше парит второе.
> В разработке для критической инфраструктуры, где бал правит MISRA и тому подобные линтеры, не соблюдать стандарты невозможно. Просто заказчик не примет код.
Это если он его сможет про-аудировать.
Скандал с овнокодом тойоты показал, что в "критической инфраструктуре" тоже не все так хорошо.>> Например в С23 поменяли поведение zero-sized reallocations.
> Знаю, поэтому до сих пор C23 не пользуюсь. Да и MISRA его не поддерживает.А если это не поменяется? Придется сидеть на С11 до скончания времен?
> А с UB и на Rust приходится до сих пор кувыркаться. ... Совершенно разный результат можно получить при разной регистровой оптимизации и разной последовательности операций умножения.
Звучит не очень хорошо.
Но мало чем отличается от С или С++ с UB или ID.>> Хм.. разве edition не решает эту проблему?
> Нет. Последний раз править код из-за того, что он перестал собираться пришлось с выходом Rust 1.85.0. В пару мест стандартной библиотеки тихо поменяли i8 на u8. Не я один возмущался.Что-то меня терзают смутные сомнения что это не обсуждалось, но поверю на слово.
>> Я исхожу из вашего предположения что "новый rustc == новый rust".
> Где я такое писал?Я так понял вот эту строку "Выпуск новой версии rustc автоматически обозначает выпуск новой версии Rust. Просто потому, что его объявили эталоном (стандартом)."
> Я наоборот против того, чтобы каждая новая версия rustc объявлялась референсным эталоном языка без коммуникации с другими заинтересованными комьюнити.
Как вы себе это представляете?
Прийти к разрабам gcc и спросить "а вам норм?", потом к программистам МК, потом к китайцам с RISC-V, потом...
Если кто-то заинтересован, то он добавит своего представителя и будет активно участвовать в разработке.
Я не вижу Padauk в этом списка rustfoundation.org/members/, в отличии например от ARM, так что предположу что оно им не интересно.>> И что команда которая пишет rustc, в какой-то мере определяет развитие стандарта.
> Вот это и плохо.По вашему мнению. С моей точки зрения это отлично, тк не получается типичного для опенсорса "лебедь-рак-и-щука", когда взаимоисключающие требования просто разваливают проекты.
> А Вы не в курсе, что та же Mozilla разрабатывала кроме браузера еще массу библиотек и компонентов? Например, nss.
И сколько таких библиотек они написали?
> Это придумал Graydon Hoare, а не я http://venge.net/graydon/talks/intro-talk-2.pdf
Спасибо за ссылку.
Вижу, что я был не прав и СИ даже не упоминается. Поэтому прикручивание раста к МК как замену сишки.. противоречит идее Грейдона.
Но забавно видеть там планы на локальные GC.
Замечу что он уже отошел от разработки весьма давно, и немного разочаровался в том что получилось
graydon2.dreamwidth.org/307291.html
Продолжение.> С каких пор тот же RISC-V или ARM с PIO стал маргинальшиной?
Не стало.
А пока еще маргинальщина.> Да у них все шансы похоронить в итоге amd64.
Про wintel'о-капцы я слышу уже лет 15.
Давайте вернемся к этому вопросу, когда у RISC-V будет хотя бы 5-10 процентов рынка.> Самый смак будет когда выявится 0-day уязвимость, исправленная и скомпилированная свежей версией rustc, а Вы не сможет её установить, дожидаясь пока не только Apple, но и все поставщики всех приложений на Вашем компьютере перекомпилируют ей свои программные продукты.
У меня будет выбор "или 0-day или часть продуктов перестанет работать".
Это очень не приятная ситуация... но что поделать, жизнь не всегда сахар.> После чего, вместо нескольких килобайт Вам потребуется качать и устанавливать добрую сотню гигабайт софта, потратив на это целый день, если не больше. Ради чего такие мучения?
Не знаю. Я в такую ситуацию пока не попадал.
Да и на наличие или отсутствие стабильного ABI в расте не влияю вообще никак.> Уже десятый раз пишу: ради поддержки динамического связывания без ущерба безопасности при работе с памятью и нитями.
Уже десятый раз спрашиваю, если оно настолько необходимо, то почему нет "патчей" с реализацией, предложений и обсуждений?
> Представьте себе, что та же mesa размером в 20МБ будет статически связываться ...
> Или возьмем k8s ... 256 ГБ только за счет дублирования библиотек protobuf, http/2 и ssl. За чей счет банкет?За счет пользователя который на халяву получил ЯП.
Если вас она не устраивает - вы просто не пользуетесь. Тут же нет никакого принуждения.> Вы и вправду не понимаете для чего нужно динамическое связывание или просто троллите?
Нет. Не троллю.
Просто реально не понимаю, почему вы требуете от ЯП вещей которые он пока не умеет и возможно его создатели не видят его подходящим под эти требования.
Просто это инструмент не подходит для ваших задач.
В этом нет ничего плохого, если создатели видят его применение в ограниченной области (например только десктопы и мобилки).> Как я уже писал выше, отказываясь от безопасности при работе с памятью и нитями.
Но в пределах отдельных "кусов" она будет сохраняться.
Может этого уже для кого-то достаточно.> Как в той же Redox, использующей для динамического связывания C ABI. Вот только мне непонятна цель таких проектов, так как главное преимущество Rust перед C тут пропадает.
Но при этом остается: проверки корректности в пределах одной программы или библиотеки, удобная система типов, всякие result, pattern matching и другие современные и удобные вещи. Команда редокса просто работает с тем что есть.
> Rust гарантирует безопасную работу с памятью и потоками. Без оговорок, применяется ли там PIO, NUMA или DMA. Так что назвался груздем - полезай в кузов.
>> Цитирую "Our rich type system and ownership model ensure memory and thread safety". Как видим, не всегда.
> Я вижу ensure, а sometimes provide.Значит обманули ¯\_(ツ)_/¯
> Я вообще то ещё коммитер нескольких проектов на Rust.
Я знаю. Вы писали про stm32 и еще что-то.
> И искренне считаю, что любой проект должен ориентироваться на потребности пользователей, а не свои собственные хотелки.
Это ваше мнение.
Кто-то считает что СПО проект должен ориентироваться на собственные хотелки, а если еще кому-то он подойдет, то ну чтож им повезло.> И если комьюнити rustc будет и дальше игнорировать потребности
рынка, он просто уйдет в историю.
А какие потребности у рынка? И какие ниши?
Судя по всему members rust foundation решили что то что есть сейчас их устраивает.> Только один Espressif еще год назад отрапортовал, что продал свыше миллиарда МК.
> Прогноз на 2030 году - ~16 миллиардов чипов RISC-V на сумму около 100 миллиардов долларов США.Это если не будет ядерной войны. И я не про выход новых ryzen))
Если все так круто, то где представители этой отрасли в rust foundation? Почему они не участвуют в разработке?> В корпоративной среде, там где платят деньги, разработка для десктопа сейчас почти не требуется - везде веб.
Не буду спорить, но мой опыт показывает обратное. Часто есть бизнес ядро, поверх которого какая-то вебня типа электрона.
И оно должно быть быстрым и надежным.
На всякий случай. Я другой человек, не тот, с кем вы общались.> Выпуск новой версии rustc автоматически обозначает выпуск новой версии Rust.
Это, конечно, не так. Новая версия компилятора может появляться вследствие исправления ошибок в предыдущей версии. И к языку это отношения не имеет.
> Ну есть стандарты, которым они так или иначе соответствуют.
Немножко беременны?
> Стандарт позволяет использовать один и тот же код на всех платформах, а не под каждую платформу и её компилятор адапатировать код.
Интернет (глобальная Сеть) функционирует без всяких стандартов. Вот чудеса-то.
Далее. Если ваш "стандарт" - это сплошные описания возможных UB, то правда-правда это всё ещё полноценный стандарт? Правда-правда, при таком стандарте вы всегда будете получать один и тот же результат на всех возможных платформах? Или, всё-таки, придётся лепить write only лапшу из IFDEF?> Тогда Rust никогда не сможет заменить C.
Уже заменяет. Не сказать, чтобы везде, но процесс пошёл.
> Где при этом оказывается безопасная работа с памятью, надеюсь, объяснять не надо?
Если Rust пользуется кодом Си, то безопасности, понятно, никогда не будет. И? Причём здесь Rust?
> А Вы пишите код соблюдая стандарты. Не пробовали?
Ещё раз про UB, который прописан прямо в стандарте. Предлагаю вам немного напрячься и подумать, что это означает на практике.
> К слову, в Mozilla Rust развивался именно как замена C. А область применения C включает в себя MK.
У вас проблемы с логическим мышлением. То, что Мозилла придумала Раст, как замену Си в своей сфере, совершенно не означает, что они также думали о МК при этом. Это потом уже народ начал задумываться о МК, типа, а почему бы и здесь не попробовать.
> Во-вторых, rustc использует для кодогенерации LLVM. То есть разработчики rustc c 2011 года о кодогенерации не задумывались вообще.
Ну так и предъявляйте тогда претензии разработчикам LLVM.
> имеется целый ворох блобов, которые не перекомпилить
Эти блобы будут притащены с собой. Когда-то в Винде была такая проблема, как DDL hell. Потом, с увеличением ёмкости жёстких дисков, проблема перестала быть актуальной, потому что в системе можно теперь дёшево хранить кучу версий одной и той же DLL. Собственно, это и с Си может быть такая же ситуация, если автор библиотеки по какой-то причине решил изменить API, и, как следствие, ABI.
> А отсутствие стабильного ABI вообще не позволяет вести многие виды разработки.
На Rust пишут разный софт: начиная от ОС, заканчивая прошивками для автомобилей. Для каких именно видов разработки, зная теперь об этом факте, вы видите проблемы?
>> Выпуск новой версии rustc автоматически обозначает выпуск новой версии Rust.
> Это, конечно, не так. Новая версия компилятора может появляться вследствие исправления
> ошибок в предыдущей версии. И к языку это отношения не имеет.К сожалению, разработчики rustc считают его эталоном. Поэтому подавляющее большинство крейтов следуют установленному им стандарту. После чего они перестают компилиться тем же GCC или форками rustc.
>> Ну есть стандарты, которым они так или иначе соответствуют.
> Немножко беременны?Нет, конечно. Просто разработчикам компилятора требует время для того, чтобы реализовать поддержку этих стандартов. Например, в SDCC поддержка C23 появилась только в январе этого года. Да и то, у меня пока нет уверенности в её полноте. Странно, что Вы считаете, что разработчки должны мгновенно после принятия стандарта его реализовать.
>> Стандарт позволяет использовать один и тот же код на всех платформах, а не под каждую платформу и её компилятор адапатировать код.
> Интернет (глобальная Сеть) функционирует без всяких стандартов. Вот чудеса-то.Впервые слышите о https://datatracker.ietf.org/ и IETF standards?
> Далее. Если ваш "стандарт" - это сплошные описания возможных UB, то правда-правда
> это всё ещё полноценный стандарт? Правда-правда, при таком стандарте вы всегда
> будете получать один и тот же результат на всех возможных платформах?Именно так, потому что избегаю UB. Вы правда не знали, что это можно? )))
>> Тогда Rust никогда не сможет заменить C.
> Уже заменяет. Не сказать, чтобы везде, но процесс пошёл.Ну тогда расскажите, как без динамического связывания можно на Rust написать, например, аналог PostgreSQL. Или Вы думаете кто-то согласится линковать все его расширения статически? А если мне, например, понадобится auto_explain, то я вместо LOAD 'auto_explain'; должен буду останавливать продуктивную СУБД, чтобы перекомпилировать её с auto_explain?
>> И тот же Rust в костыле под названием abi_stable именно им и пользуется, при помощи спецификатора extern "C" для функций на Rust.
>> Где при этом оказывается безопасная работа с памятью, надеюсь, объяснять не надо?
> Причём здесь Rust?Квотить надо полностью )))
>> А Вы пишите код соблюдая стандарты. Не пробовали?
> Ещё раз про UB, который прописан прямо в стандарте. Предлагаю вам немного
> напрячься и подумать, что это означает на практике.Это обозначает, что их следует избегать. И большинство линтеров, обнаружив UB сразу на это указывают. Я уже молчу о MISRA.
>> К слову, в Mozilla Rust развивался именно как замена C. А область применения C включает в себя MK.
> У вас проблемы с логическим мышлением. То, что Мозилла придумала Раст, как
> замену Си в своей сфере, совершенно не означает, что они также
> думали о МК при этом. Это потом уже народ начал задумываться
> о МК, типа, а почему бы и здесь не попробовать.Вообще не понял о чём Вы. Я широко использую Rust на МК. И далеко не только я один.
Проблема не в Rust, а в rustc, гвоздями прибитому к LLVM.>> Во-вторых, rustc использует для кодогенерации LLVM. То есть разработчики rustc c 2011 года о кодогенерации не задумывались вообще.
> Ну так и предъявляйте тогда претензии разработчикам LLVM.А они то при чём? Например, ограничения IR в LLVM для RISC-V были известны изначально еще в 2010 году. Это разработчики rustc решили облегчить себе жизнь, используя LLVM, а не GCC, которых таких ограничений не имеет. А теперь мешают развитию того же gccrs, продвигая в качестве эталона rustc.
>> имеется целый ворох блобов, которые не перекомпилить
> Эти блобы будут притащены с собой.А кто, простите, их перекомпилит в очередной версии rustc? Например, тот же Citrix последний раз обновлял свой nsgclient еще для Ubuntu 20.04, после чего даже не пытался его переделать под новые библиотеки. А что будете делать со сканером или принтером, уже не поддерживаемым производителем?
Любимые компьютерные игры кто Вам перекомпилировать будет?> решил изменить API, и, как следствие, ABI.
Изменение API не обозначает изменения ABI. Похоже, Вы просто не понимаете, чем они отличаются.
>> А отсутствие стабильного ABI вообще не позволяет вести многие виды разработки.
> На Rust пишут разный софт: начиная от ОСМерворожденное дитя. Как раз из-за отсутствия стандарта ABI. Там всё в unsafe extern "C" из-за этого. Так же, как в abi_stable. И снова, о какой безопасной работе с памятью может идти речь, если системные вызовы и динамическое связывание реализовано через C ABI?
> Для каких именно видов разработки, зная теперь об этом факте, вы
> видите проблемы?Я привел пример выше. В общем случае, почти любой более-менее сложный программный продукт невозможен без динамического связывания.
Представьте себе, что та же mesa размером в 20МБ будет статически связываться с каждым приложением, которое его использует. У меня сейчас таких приложений запущено десятка три. Итого только на одной библиотеке получаем 600МБ расхода RAM без динамического связывания.
Или возьмем k8s. Если на C#/Java/Go на одном хосте с 32ГБ RAM спокойно поднимается двести подов (проверял на локале), то в при статическом связывании потребуется, как минимум, 256 ГБ только за счет дублирования библиотек protobuf, http/2 и ssl. За чей счет банкет?Вы и вправду не понимаете для чего нужно динамическое связывание или просто троллите?
>К сожалению, разработчики rustc считают его эталоном.Хорошо бы ссылками подкреплять подобные высказывания.
> Поэтому подавляющее большинство крейтов следуют установленному им стандарту.
Не им, а RFC, если это вменяемые разработчики. Только не говорите, пожалуйста, что это почти все такие, в и этом Rust виноват.
> После чего они перестают компилиться тем же GCC или форками rustc.
gcc, насколько мне известно, пока только в альфа-версии. Поэтому вряд ли от него стоит ожидать полной поддержки всех RFC.
> Впервые слышите о https://datatracker.ietf.org/ и IETF standards?
Цитата специально для вас отсюда: https://www.ietf.org/process/rfcs/
"The IETF publishes its technical documentation as RFCs, an acronym for their historical title Requests for Comments. "
Вот в случае Rust применяется та же практика. Ещё один такой язык - Python.
> Именно так, потому что избегаю UB. Вы правда не знали, что это можно?
Можно, конечно. Но это НЕ ОБЯЗАТЕЛЬНО. Другими словами, вы - возможно, избегаете. А другой программист на Си - нет, не избегает. Надо ли дальше продолжать логическую цепочку?
> Это обозначает, что их следует избегать.
"Следует" не означает необходимость. Вы реально не понимаете, чем обязанность от возможности отличается?
> И большинство линтеров, обнаружив UB сразу на это указывают.
Как следует из вашего предложения, не все линтеры. Что уже напрягает. Далее. Пользоваться линтерами ЖЕЛАТЕЛЬНО, но НЕ ОБЯЗАТЕЛЬНО. Вот какое-то множество программистов ими и не пользуется, то ли в силу незнания, что так можно, то ли в силу лени, то ли в силу нехватки времени.
> Я уже молчу о MISRA.
И правильно делаете.
> Вообще не понял о чём Вы.
Я о вашем утверждении, что Мозилла придумала Раст на замену Си. А раз так, то должна была позаботиться и о МК. В этом ваша логическая ошибка.
> А они то при чём?
Ответ содержится в вашем следующем предложении (см. ниже).
> Это разработчики rustc решили облегчить себе жизнь, используя LLVM, а не GCC, которых таких ограничений не имеет.
По всей видимости, они что-то знали о GCC, раз это их остановило.
> А теперь мешают развитию того же gccrs, продвигая в качестве эталона rustc.
Как это проявляется на практике? Дайте, пожалуйста, какие-либо ссылки на внешние источники.
> Проблема не в Rust, а в rustc, гвоздями прибитому к LLVM.
Но есть же gccrs. Вы же сами сказали. Хотя пока только в альфе. Что же вас до сих пор не устраивает, и причём здесь разработчики Rust?
> А кто, простите, их перекомпилит в очередной версии rustc?
Очевидно, тот, кому это надо - поставщик того или иного ПО. Ведь такое ПО в бинарниках поставляется, да? В мире C++, как вам уже другой участник написал, это совершенно не является проблемой, софта на этом языке написано при этом предостаточно.
> Например, тот же Citrix последний раз обновлял свой nsgclient еще для Ubuntu 20.04, после чего даже не пытался его переделать под новые библиотеки.
Зачем бы Citrix-у этим заниматься? Работает же и так на старых библиотеках, насколько я понимаю.
> А что будете делать со сканером или принтером, уже не поддерживаемым производителем?
Если им ещё можно пользоваться - буду пользоваться. Если уже нельзя - выкину, куплю новый. Моему сканеру примерно лет 20 уже. Тем не менее, до сих пор работает под Виндой.
> Любимые компьютерные игры кто Вам перекомпилировать будет?
Производители игр, очевидно, если сочтут необходимым. Если нет - я их винить не буду, все хотят кушать, а для этого нужны деньги. Или вы из параллельной коммунистической реальности?
> Мерворожденное дитя.
Написал уже двоим, будете третьим. А парни из Мозиллы, Майкрософт, Гугл, Клаудфлэр, Вольво, Дропбокс, Дискорд, Амазон об этом знают?
> И снова, о какой безопасной работе с памятью может идти речь, если системные вызовы и динамическое связывание реализовано через C ABI?
Если программа пользуется системным вызовом из библиотеки на Си и эта библиотека содержит ошибки, понятно, что в этом конкретном месте программа на Раст будет ограниченно стабильной. Но ведь ПО на Раст - это не только лишь сплошные системные вызовы, правда? Есть же и другая логика. Так вот, в этих других местах работа с памятью будет безопасной. А там, глядишь, подтянутся нативные библиотеки на Раст.
Предположим, что вы имели ввиду нативные библиотеки на Раст. Они сами по себе работают с памятью безопасно, хотя их вызов может быть оформлен, как unsafe. И? Из-за этого unsafe в вызывающей программе появится опасность? Очевидно, что нет. Ну, или приведите пример, который бы показал, что я ошибаюсь.> Я привел пример выше.
Это умозрительные примеры. При всё к вам уважении, мне ваши фантазии не особо интересны и не являются сколь-либо весомым аргументом. Я готов признать, что нестабильный ABI может являться проблемой. Неразрешимой? Как показывает практика из мира C++ - нет, проблема успешно решается.
> В общем случае, почти любой более-менее сложный программный продукт невозможен без динамического связывания.
Но это неправда. Компании, которые я перечислил выше, доказали это на практике.
> Представьте себе, что та же mesa размером в 20МБ будет статически связываться с каждым приложением, которое его использует. У меня сейчас таких приложений запущено десятка три. Итого только на одной библиотеке получаем 600МБ расхода RAM без динамического связывания.
Прекрасно представляю. У вас есть два способа решить эту проблему. Либо оставить всё, как есть сейчас, либо перекомпилировать библиотеки под необходимую вам версию компилятора. Может ли это быть проблемой - да, может, при очень жёстких ограничениях по аппаратным ресурсам. Но для такого железа, насколько я понимаю, ПО не может быть сверхсложным по определению. Поэтому перекомпиляция библиотек - вполне себе нормальное решение.
Если же у вас сложный проект, то и железо будет навороченным под него. Поэтому дополнительные 400 Мб памяти вряд ли будут большой проблемой. Но если всё-таки будут - тогда остаётся перекомпиляция.
Хотя возможен ещё третий вариант (для некоторых случаев) - замораживание версии компилятора на какое-то время.
> Вы и вправду не понимаете для чего нужно динамическое связывание или просто троллите?
Прекрасно понимаю. Но, как вам уже заметили, нестабильный ABI не является непреодолимой проблемой в C++. Поэтому логично предположить, что не будет являться проблемой и в случае Rust.
>>К сожалению, разработчики rustc считают его эталоном.
> Хорошо бы ссылками подкреплять подобные высказывания.https://blog.m-ou.se/rust-standard/
>> Поэтому подавляющее большинство крейтов следуют установленному им стандарту.
> Не им, а RFC, если это вменяемые разработчики. Только не говорите, пожалуйста,
> что это почти все такие, в и этом Rust виноват.Подтвердите это ссылками на RFC с описанием Rust, который можно считать стандартом.
>> После чего они перестают компилиться тем же GCC или форками rustc.
> gcc, насколько мне известно, пока только в альфа-версии. Поэтому вряд ли от
> него стоит ожидать полной поддержки всех RFC.Там сейчас целый ворох форков, в основном от китайцев, которые поставляют эти форки в качестве продуктивного компилятора для своих RISC-V CPU. Само собой, постепенно эти разработки попадают в мэйнстрим. Например https://barretts.club/posts/i-got-a-milkv-duo/
>> Впервые слышите о https://datatracker.ietf.org/ и IETF standards?
> Цитата специально для вас отсюда: https://www.ietf.org/process/rfcs/
> "The IETF publishes its technical documentation as RFCs, an acronym for their
> historical title Requests for Comments. "
> Вот в случае Rust применяется та же практика. Ещё один такой язык
> - Python.И где и как происходит утверждение, как в случае IETF? Помнится, UUIDv7 в RFC 9562 пробивалась четыре года через целый ряд конференций и обсуждений.
>> Именно так, потому что избегаю UB. Вы правда не знали, что это можно?
> Можно, конечно. Но это НЕ ОБЯЗАТЕЛЬНО. Другими словами, вы - возможно, избегаете.
> А другой программист на Си - нет, не избегает. Надо ли
> дальше продолжать логическую цепочку?Конечно продолжать. У меня почти все заказчики прогоняют код через линтеры. Иногда даже MISRA. Очень интересно узнать, что будет этот другой программист в этой ситуации делать )))
>> Это обозначает, что их следует избегать.
> "Следует" не означает необходимость. Вы реально не понимаете, чем обязанность от возможности
> отличается?Огранизационными мерами при CR (Code Review) и сдаче кода заказчику. Не более того.
>> И большинство линтеров, обнаружив UB сразу на это указывают.
> Как следует из вашего предложения, не все линтеры. Что уже напрягает.Так же, как и в Rust. Например, проблему с UB при исчезновении порядка числа с плавающей запятой Rust никак решает. Идеал, простите, недостижим.
> Пользоваться линтерами ЖЕЛАТЕЛЬНО, но НЕ ОБЯЗАТЕЛЬНО.
GIT тоже можно настроить для мержа без CR. Вот только захотите ли Вы кодом из такого проекта пользоваться?
В Rust ведь аналогичная картина с clippy.>> Я уже молчу о MISRA.
> И правильно делаете.Наконец-то! Хоть тут согласились, что с MISRA UB - практически не реален.
>> Вообще не понял о чём Вы.
> Я о вашем утверждении, что Мозилла придумала Раст на замену Си. А
> раз так, то должна была позаботиться и о МК. В этом
> ваша логическая ошибка.Это тогда логическая ошибка не моя, а Graydon Hoare, который не указал, что предлагает Rust в качестве замены C/C++ для новых проектов и забыл указать, что это относится только к ПК )))
>> Это разработчики rustc решили облегчить себе жизнь, используя LLVM, а не GCC, которых таких ограничений не имеет.
> По всей видимости, они что-то знали о GCC, раз это их остановило.Я же указал - облегчить себе жизнь. Промежуточное представление в GCC намного более гибкое, чем в LLVM, но требует и больше усилий для его генерации.
>> А теперь мешают развитию того же gccrs, продвигая в качестве эталона rustc.
> Как это проявляется на практике? Дайте, пожалуйста, какие-либо ссылки на внешние источники.Попробуйте сами сейчас, после выхода новой версии rustc, собрать код для того же Milk-V без вытаскивания std из релиза годовалой давности. Как собирать ссылку я дал выше.
>> Проблема не в Rust, а в rustc, гвоздями прибитому к LLVM.
> Но есть же gccrs. Вы же сами сказали.Я просто не хочу, чтобы rustc остался забыт в истории из-за упорного нежелания ориентироваться на потребности бизнеса.
>> А кто, простите, их перекомпилит в очередной версии rustc?
> Очевидно, тот, кому это надо - поставщик того или иного ПО.Ему это зачем? Откуда у Вас уверенность, что тот же HP перекомпилит драйвера принтера, который уже несколько лет не выпускается?
> В мире C++, как вам
> уже другой участник написал, это совершенно не является проблемой, софта на
> этом языке написано при этом предостаточно.А там и использование C ABI не влияет на безопасность вообще никак.
>> Например, тот же Citrix последний раз обновлял свой nsgclient еще для Ubuntu 20.04, после чего даже не пытался его переделать под новые библиотеки.
> Зачем бы Citrix-у этим заниматься? Работает же и так на старых библиотеках,
> насколько я понимаю.Вот и я спрашиваю, зачем Citrix рефакторить свой VPN клиент каждые три месяца, если можно забить на Rust и рефакторить его раз в несколько лет?
>> А что будете делать со сканером или принтером, уже не поддерживаемым производителем?
> Если им ещё можно пользоваться - буду пользоваться. Если уже нельзя -
> выкину, куплю новый. Моему сканеру примерно лет 20 уже. Тем не
> менее, до сих пор работает под Виндой.Работает, потому что его DLL поддерживают C ABI. Вот именно то самое C ABI, которое не позволяет обеспечить безопасность при работе с памятью.
>> Любимые компьютерные игры кто Вам перекомпилировать будет?
> Производители игр, очевидно, если сочтут необходимым. Если нет - я их винить
> не буду, все хотят кушать, а для этого нужны деньги.Вот Вам и будут продавать игру на три месяца, а за каждую новую версию потребуется платить деньги. Этого Вы хотите? )))
> Или вы из параллельной коммунистической реальности?
Это Вы про себя? Выше Вы пишете о дополнительных затратах для производителей программного обеспечения. И как раз я указываю, что этим производителям такие затраты совершенно не нужны.
>> Мерворожденное дитя.
> Написал уже двоим, будете третьим. А парни из Мозиллы, Майкрософт, Гугл, Клаудфлэр,
> Вольво, Дропбокс, Дискорд, Амазон об этом знают?Естественно. Не видеть сплошь и рядом extern "C" в код невозможно.
>> И снова, о какой безопасной работе с памятью может идти речь, если системные вызовы и динамическое связывание реализовано через C ABI?
> Если программа пользуется системным вызовом из библиотеки на СиВы трезвы? Я уже третий раз пишу, что C ABI используется сейчас для динамического связывания кода на Rust. Потому что другого варианта для динамического связывания просто нет из-за отсутствия стабильного Rust ABI.
> А там, глядишь, подтянутся нативные библиотеки на Раст.
Которые опять вызываются через C ABI.
>> Я привел пример выше.
> Это умозрительные примеры. При всё к вам уважении, мне ваши фантазии не
> особо интересны и не являются сколь-либо весомым аргументом.Простите, но дальше отвечать хаму я не хочу. Прощайте.
> Если же у вас сложный проект, то и железо будет навороченным под
> него. Поэтому дополнительные 400 Мб памяти вряд ли будут большой проблемой.
> Но если всё-таки будут - тогда остаётся перекомпиляция.Действительно хам. Я явно писал:
>> Или возьмем k8s. Если на C#/Java/Go на одном хосте с 32ГБ RAM спокойно поднимается
>> двести подов (проверял на локале), то в при статическом связывании потребуется,
>> как минимум, 256 ГБ только за счет дублирования библиотек protobuf, http/2 и ssl.Так что речь вовсе не о 400МБ, а о 200 с хвостиком ГБ.
> https://blog.m-ou.se/rust-standard/Это ссылка на чьё-то мнение. Покажите, пожалуйста, ссылку на официальную позицию Rust foundation, которая бы утверждала, что наш компилятор и то, что он поддерживает в данной конкретной версии, это и есть суть языка программирования.
> Подтвердите это ссылками на RFC с описанием Rust, который можно считать стандартом.
Вы статью из приведенного вами блога читали? Там есть ссылки.
https://github.com/rust-lang/rfcs
https://rust-lang.github.io/rfcs/
https://doc.rust-lang.org/nightly/reference/> И где и как происходит утверждение, как в случае IETF? Помнится, UUIDv7 в RFC 9562 пробивалась четыре года через целый ряд конференций и обсуждений.
Ещё раз предлагаю перечитать вам вами же приведённую статью. Там описывается процесс обсуждения и утверждения.
>>> Именно так, потому что избегаю UB. Вы правда не знали, что это можно?
>> Можно, конечно. Но это НЕ ОБЯЗАТЕЛЬНО. Другими словами, вы - возможно, избегаете.
>> А другой программист на Си - нет, не избегает. Надо ли
>> дальше продолжать логическую цепочку?
> Конечно продолжать. У меня почти все заказчики прогоняют код через линтеры. Иногда даже MISRA. Очень интересно узнать, что будет этот другой программист в этой ситуации делать )))Ок, продолжаю, хотя, казалось, бы это итак очевидно. Кроме вас в этом мире существуют и другие программисты на Си. И плевать они хотели на MISRA, линтеры, которыми вы пользуетесь и стиль программирования, который вы исповедуете. Вы заранее, можете и не знать, какую конкретно методологию они применяют при разработке своей библиотеки, которую вы потом можете использовать в ваших проектах.
> Огранизационными мерами при CR (Code Review) и сдаче кода заказчику. Не более того.
У каждой команды могут быть свои организационные меры и свои способы осуществления Code Review. Сам по себе процесс CR не гарантирует ничегошеньки. Надо, чтобы он ещё проводился правильными людьми с правильной методологией.
> Так же, как и в Rust. Например, проблему с UB при исчезновении порядка числа с плавающей запятой Rust никак решает. Идеал, простите, недостижим.
Идеал - нет, не достижим. Но это не означает, что к нему не надо стремиться. Если можно пользоваться безопасным инструментом, который ЗАСТАВИТ вас соблюдать эту самую безопасность в БОЛЬШИНСТВЕ случаев, лучше пользоваться им, при прочих равных условиях. В Rust, если и есть ситуации с UB, их на порядок, наверное, меньше, чем в том же Си. И да, даже линтеры не способны обнаруживать некоторые проблемы работы с памятью, как прекрасно демонстрируют многие программные продукты на Си, а также отчёты команд из Гугл и Майкрософт.
> GIT тоже можно настроить для мержа без CR. Вот только захотите ли Вы кодом из такого проекта пользоваться?
Зависит от обстоятельств. Например, автором коммита и автором продукта может (часто так и есть) быть один и тот же человек. Зачем ему CR, для кода, который он сам же и написал?
> В Rust ведь аналогичная картина с clippy.
Нет, не аналогичная. Компилятор Rust и без clippy ловит гораздо больше ошибок. Ваш код попросту не скомпилируется, в отличие от кода на Си, где компилятор даже не пикнет на очередное use-after-free, double-free и подобное.
>>>> Я уже молчу о MISRA.
>> И правильно делаете.
>Наконец-то! Хоть тут согласились, что с MISRA UB - практически не реален.Я не это имел ввиду. Я подразумевал, что MISRA НЕ ОБЯЗАТЕЛЬНА к исполнению до тех пор, пока заказчик не настоит на этом. В итоге кода без соблюдения MISRA в природе намного больше того, который соблюдает MISRA.
> Это тогда логическая ошибка не моя, а Graydon Hoare, который не указал, что предлагает Rust в качестве замены C/C++ для новых проектов и забыл указать, что это относится только к ПК )))
Простите, но вы чем дальше, тем больше демонстрируете несостоятельность в построении простых, казалось бы, логических цепочек. Пожалуйста, остановитесь. Поясню, в чём на этот раз вы ошиблись. Graydon Hoare не декларировал, что он хочет заменить Си на микроконтроллерах. И ничего никому, поэтому, он не обязан был указывать.
>> По всей видимости, они что-то знали о GCC, раз это их остановило.
> Я же указал - облегчить себе жизнь. Промежуточное представление в GCC намного более гибкое, чем в LLVM, но требует и больше усилий для его генерации.Так почему вы, понимая это, продолжаете обвинять их в этом? Или такой подход противоестественен для вас, и вы всякий раз ищете способы усложнить себе жизнь?
>> В мире C++, как вам
>> уже другой участник написал, это совершенно не является проблемой, софта на
>> этом языке написано при этом предостаточно.
>А там и использование C ABI не влияет на безопасность вообще никак.Причём здесь C ABI? Речь шла о том, что в мире C++ отсутствие стабильного ABI не является проблемой.
> Вот и я спрашиваю, зачем Citrix рефакторить свой VPN клиент каждые три месяца, если можно забить на Rust и рефакторить его раз в несколько лет?
Ещё раз. Citrix может снабдить свой клиент нужными библиотеками? Правильный ответ - да, может. И не надо ничего рефакторить при этом. Кроме того, ничто не мешает Citrix сделать так, чтобы их библиотека на Rust предоставляла C ABI для их VPN клиента, и не париться с перекомпиляцией после этого так же, как это происходит сейчас.
Подробности:
https://docs.rust-embedded.org/book/interoperability/rust-wi...,the%20header%20and%20calling%20them!> Работает, потому что его DLL поддерживают C ABI. Вот именно то самое C ABI, которое не позволяет обеспечить безопасность при работе с памятью.
Не C ABI не позволяет обеспечить безопасность при работе с памятью, а код, написанный на любом небезопасном языке, который потом используется с помощью C ABI. C ABI - это интерфейс, а не способ работы с памятью. И такое вам надо объяснять?
> Это Вы про себя? Выше Вы пишете о дополнительных затратах для производителей программного обеспечения. И как раз я указываю, что этим производителям такие затраты совершенно не нужны.
Я пишу, что проблема решаема даже при нестабильном Rust ABI. Как? Путём использования стабильного C ABI. Ссылку, как это делать, см. выше.
> Естественно. Не видеть сплошь и рядом extern "C" в код невозможно.
Троллинг глупостью? Они продолжают внедрять и использовать этот язык программирования, не считая его мертворождённым.
> Вот Вам и будут продавать игру на три месяца, а за каждую новую версию потребуется платить деньги. Этого Вы хотите? )))
Я уже объяснил, как обойти эту проблему. Такого не будет. Потому что если будет, производитель игр разорится, так как его игры никто не будет покупать.
> Я уже третий раз пишу, что C ABI используется сейчас для динамического связывания кода на Rust. Потому что другого варианта для динамического связывания просто нет из-за отсутствия стабильного Rust ABI.
Да хоть в десятый. И что с того? Зато есть стабильный C ABI. Код на Rust может его использовать. В том числе в своих библиотеках. И такой код даже можно использовать в программах на Си. А можно также и в программах на Rust.
> Которые опять вызываются через C ABI.
Ещё раз. В последний. Интерфейс вызова функций из библиотеки не вносит дополнительные риски в вызываемый код. А что же вносит? Язык программирования, который использовался при написании кода для библиотеки. Это так сложно для понимания? Вы точно программист?
> Простите, но дальше отвечать хаму я не хочу. Прощайте.
И где здесь хамство? Вы что-то на ходу выдумываете, но хам - я. Слив засчитан. Прощайте.
> Так что речь вовсе не о 400МБ, а о 200 с хвостиком ГБ.
Я уже указал, как это можно обойти.
> Вы точно программист?А вот Вы явно не программист. Поэтому дальнейшую дискуссию считаю бессмысленной.
> Интерфейс вызова функций из библиотеки не вносит дополнительные риски в вызываемый код.
Отсутствие стабильного ABI как раз такие риски вносит.
На пальцах объясняю для не программиста.Например, для структур Rust гарантирует лишь
The fields are properly aligned.
The fields do not overlap.
The alignment of the type is at least the maximum alignment of its fields.
Иными словами разные версии rustc имеют полное право размещать поля структуры по разному и в разном порядке.
И если для структур данных есть возможность хотя бы указать #[repr(C)], то для структур trait, включая vtable, такой возможности нет.
Таким образом, динамическое связывание в Rust возможно только в случае, если и вызыващая программа, и все вызываемые ей динамические модули скомпилированы одной версией Rust. В противном случае, получим те самые UB, от которых хотели уйти. Или ограничиваемся C ABI, лишаясь одной из ключевых возможностей Rust - трейтов. Включая и всю std library на границе ABI.И это лишь вершина айсберга, так как полноценный ABI должен включать в себя еще многое другое.
> В общем случае, почти любой более-менее сложный программный продукт невозможен без динамического связывания.Но это неправда. Компании, которые я перечислил выше, доказали это на практике.
Упс. Не дочитал до конца ваше предложение. Согласен, что для сложных проектов желательно динамическое связывание. Но как видим на практике вот тех компаний - проблема успешно решается.
>Полное отсутствие выбора - это по Вашему прекрасно?У кучи языков есть только один компилятор, у того же хаскеля актуален только ghc. Несколько компиляторов могут себе позволить только те языки, которые примитивны и не развиваются. Как например golang, язык, словно из прошлого века. Наличие нескольких компиляторов не даст языку никаких дополнительных фич
> стандарт C++ выходит раз в три года
> несовместимые версии Rust каждые несколько мнсяцевЕще бы компиляторы выходили с полной поддержкой вышедшего стандарта сразу, а не с опозданием.
> Почему с такой упоротостью нет новостей о других языках, например:
> Кобол, Ада, Фортран, Форт, Алгол, Бейсик, ЭсОдин наконец?Потому что они уже давно издохли, лол.
Справедливости ради, Ада действительно развивается, но используется она в таких серьезных нишах, куда не берут гребцов по объявлениям. А потому на массовом рынке труда она не актуальна.
>Почему с такой упоротостью нет новостей о других языках, например:
>Кобол, Ада, Фортран, Форт, Алгол, Бейсик, ЭсОдин наконец?В музее нет новостей, есть только архив. Ну и некролог
Для тех кто думает что rust обеспечивает безопасность без накладных расходов. В реальных проектах это не так. Приходится выбирать между накладными расходыми или дополнительными трудозатратами.The related post on performance optimization is extremely interesting, in particular, the considerations drawn while moving from the unsafe ported code to safe¹:
> The first performance issue we hit was dynamic dispatch to assembly, as these calls are very hot. We then began adding inner mutability when necessary but had to carefully avoid contention. We found as we removed pointers and transitioned to safe Rust types that bounds checks increasingly became a larger factor. Buffer and structure initialization was also an issue as we migrated to safe, owned Rust types.
Based on their conclusions², each of those issues amounts to a few percentage points (total: 11%).
Based on the article, it seems that with highly complex logic, safety does come at the cost of raw performance, and it can be very hard to compensate (withing the safety requirements).
[¹]: https://www.memorysafety.org/blog/rav1d-performance-optimiza...
[²]: https://www.memorysafety.org/blog/rav1d-performance-optimiza...
Да ты не парься, чувак! Вон в джаве нужны сотни кластеров сотнями тысяч гигабайт ОЗУ для солидной компании, и ничо, никто не волнуется, ибо джава - солидно. А раст, он то полегче джавы намного будет, НО на опеннете никто не пишет насколько жирна джава, а вот про раст пишут кучу негатива, ибо модно хэйтить раст.
Нет. Java не заявляет что она супер быстрая и не жрёт ресурсы. А фанатики rust постоянно твердят об отсутствии накладных расходов. Это не одно и то же. Пусть признают что не правы и можно тему закрыть.
А что, фанатики раста кому-то что-то должны или обязаны? Нет. И фанатики сишки тоже что-то должны? Нет. Расслабься! Ты слишком серьёзен. Это же развлекательный форум, здесь наука - совсем не главное!
А я обязан расслабляться или быть несерьёзным?
Спустя год разница уже примерно(sic) в 5% и была установлена награда с фондом в 20'000$ по сокращению разрыва.
> sic
> год
> 20'000$
> 5%А могли бы писать на Си с соблюдением стандартов безопасности и не пришлось бы столько пыжиться.
> А могли бы писать на Си с соблюдением стандартов безопасности... и вообще бы не смогли бы ничего написать.
Ты почитай какие требоваяния к сишным стандартам безопасности вроде MISRA.> и не пришлось бы столько пыжиться.
Пришлось бы еще больше чем на расте. Попробуй написать что-то на сишке без dynamic heap memory allocation, без привычной pointer arithmetic, и еще без десятков других вещей.
Писать безопасно на дыряшке или очень-очень сложно и дорого или невозможно :)
> Ты почитай какие требоваяния к сишным стандартам безопасности вроде MISRA.Для мимокрокодилов:
Для конкретных проектов набор используемых правил MISRA может быть своим. Это не одна большая кнопка unsafe а множество тонких настроек.
> Для конкретных проектов набор используемых правил MISRA может быть своим.Да, мы насмотрелись на такие проекты. Когда нельзя, но очень хочется - то можно :)
Тем не менее, чтобы получить MISRA Compliance нужно выполнить Mandatory Guidelines и Required Guidelines. Так что у тебя не получится взять пару рандомных пунктов и получить сертификацию.Но забавнее всего, что они оставили лазейку с возможность re-categorization для Required Guidelines, которые вжух и превращаются в Advisory.
> Это не одна большая кнопка unsafe а множество тонких настроек.
Разумеется! Иначе на нем же практически ничего нельзя было бы написать))
Поэтому приходится идти на компромисы чтобы этот... код остался работоспособным.
> Тем не менее, чтобы получить MISRA Compliance нужно выполнить Mandatory Guidelines и Required Guidelines. Так что у тебя не получится взять пару рандомных пунктов и получить сертификацию.Но это только часть всех возможных требований.
> Разумеется! Иначе на нем же практически ничего нельзя было бы написать))
Очень сильное передергивание. Так как написать можно. Чем больше требований, тем меньше возможностей - это так. Но это и есть тонкая настройка.
> Поэтому приходится идти на компромисы чтобы этот... код остался работоспособным.
Это не компромисс - а необходимое свойство, что бы покрывать максимально возможное количество вариантов использования.
И в данный момент разрабатываются языки не с одним usafe - а с множеством управлений ограничений на код.
Так как если сказал А то говори и весь алфовит.
В этом плане язык rust - недоделка во всех смыслах.
1. Реализует концепцию владения памятью, но не реализует контейнеры с этой концепцией.
2. Реализует разные возможности для разных участков кода, но только 2-варианта из множества возможных.
3. Реализует низкоуровневые возможности, но для использования разных железяк приходится дублировать (в случаем множества - стоировать) код. Из-за очень ограниченной условной компиляции.
>1. Реализует концепцию владения памятью, но не реализует контейнеры с этой концепцией.Что вы понимаете под контейнерами?
>2. Реализует разные возможности для разных участков кода, но только 2-варианта из множества возможных.
Safe, unsafe имеются ввиду? И что в этом неудобного или недоделанного?
>3. Реализует низкоуровневые возможности, но для использования разных железяк приходится дублировать (в случаем множества - стоировать) код. Из-за очень ограниченной условной компиляции.
Шта? Какой-то поток сознания.
> Что вы понимаете под контейнерами?Под контейнерами я подразумеваю контейнеры.
> Safe, unsafe имеются ввиду? И что в этом неудобного или недоделанного?
В том что только два варианта ограничений на возможный код или все можно или все нельзя. Это огрызок от всех возможных вариантов приводящий к сильному сужению вариантов использования.
> Шта? Какой-то поток сознания.
Если ты далек от железяк - это не страшно. Но язык метит в системные. А с той реализацией условной компиляции которая у него есть - будет многократное (реальное сотни раз) дублирование одного и того же кода.
> Под контейнерами я подразумеваю контейнеры.Нет такого типа, как "контейнер", в Rust. Поэтому потрудитесь изъясняться более понятно, если хотите, чтобы вас понимали.
Есть, например, структура (это контейнер в вашей терминологии?). На неё распространяются все ограничения по работе с памятью, точно так же, как, например, на тип int (хотя вот конкретно с этим типом работать чуть проще, потому что для него некоторые методы определены из коробки).> В том что только два варианта ограничений на возможный код или все можно или все нельзя.
Unsafe не означает, что можно всё. Попробуйте почитать для начала документацию, а потом уж высказываться на эту тему. Подсказка: borrow checker не выключается даже в этом режиме.
> Это огрызок от всех возможных вариантов приводящий к сильному сужению вариантов использования.
На Rust пишут игры, операционные системы, веб-фреймворки, прошивки для автомобилей, пользовательское ПО, типа редакторов, утилит командной строки и так далее. То есть, практический весь спектр современного ПО. О каком сужении вариантов использования вы тут говорите?
> Если ты далек от железяк - это не страшно. Но язык метит в системные. А с той реализацией условной компиляции которая у него есть - будет многократное (реальное сотни раз) дублирование одного и того же кода.
Хотелось бы больше примеров из практики, а не умозрительных размышлений. Тем более, что как выясняется, вы не очень-то хорошо осведомлены о возможностях этого ЯП.
> Есть, например, структура (это контейнер в вашей терминологии?). На неё распространяются все ограничения по работе с памятью, точно так же, как, например, на тип int (хотя вот конкретно с этим типом работать чуть проще, потому что для него некоторые методы определены из коробки).Контейнер - это то что содержи множество других элементов. Как пример список. В сторону разработки лайфтамов и системы заимстований включающей контейнеры сейчас копоает майкрософт (по итогу работы с rust).
> Unsafe не означает, что можно всё. Попробуйте почитать для начала документацию, а потом уж высказываться на эту тему. Подсказка: borrow checker не выключается даже в этом режиме.
Вы явно не на том сфокусировались. Весь посыл был в ДВУХ вариантах вместо НЕОГРАНИЧЕННОГО МНОЖЕСТВА вариантов.
> Хотелось бы больше примеров из практики, а не умозрительных размышлений. Тем более, что как выясняется, вы не очень-то хорошо осведомлены о возможностях этого ЯП.
Простое письмо разработчика rust в ядро с вопросом сколько заглушек нужно написать для работы rust. Ответ был такой для одной конкретной версии rust около ста. Поэтому поддерживать все версии rust смыла нет. В итоге ядро rust компилируется только конкретной версией rust.
>но для использования разных железяк приходится дублировать (в случаем множества - стоировать) код. Из-за очень ограниченной условной компиляции.Это про вложенные ифдефы? В сишочке допустим этот write-only шлак можно оправдать нищетой языковых средств, а в современном языке это зачем?
> Это про вложенные ифдефы? В сишочке допустим этот write-only шлак можно оправдать нищетой языковых средств, а в современном языке это зачем?Вот раст настолько богат средствами, что у него только многократным дублированием одного и того же можно аналог реализовать. Список дурных запахов кода помните? Многократное дублирование - один из сильнейших.
В Rust есть макросы. Они при этом являются частью ЯП. Вы о них хоть что-то знаете?
> В Rust есть макросы. Они при этом являются частью ЯП. Вы о них хоть что-то знаете?Как они могут имитировать условную компиляцию?
Покажи мне структуру, которая не дублируется а обложена макросами так, что резные варианты компиляции содержат разные количества полей и разные типы полей. И все это множество отображается одной функцией по разному в разных вариантах компиляции.
> И в данный момент разрабатываются языки не с одним usafe - а
> с множеством управлений ограничений на код.Примеры в студию. И да, они пока разрабатываются, а раст - он вот тут уже работает. Как разработают - тогда и поговорим :)
> Так как если сказал А то говори и весь алфовит.
Кто это сказал? (алфавит)
А нас есть си где по стандарту есть только один вариант правил - "можно все". Все остальные ограничения - это надстройки.
У раста есть два варианта - safe и unsafe. И вам никто не запрещает сделать свою надстройку с более детальными правилами. Просто это оказалось пока никому не нужным.
Но уже 2 варианта лучше чем один в си.> В этом плане язык rust - недоделка во всех смыслах.
Громкое заявление))
> 1. Реализует концепцию владения памятью, но не реализует контейнеры с этой концепцией.
Язык еще развивается, может доделают.
> 2. Реализует разные возможности для разных участков кода, но только 2-варианта из
> множества возможных.И в этом нет ничего плохого.
> 3. Реализует низкоуровневые возможности, но для использования разных железяк приходится
> дублировать (в случаем множества - стоировать) код. Из-за очень ограниченной условной
> компиляции.Да, есть такое ограничение. Но это не такая большая проблема.
Вот мне например не хватает зависимых типов. И даже есть какие-то наработки вроде internals.rust-lang.org/t/pre-pre-rfc-dependable-types-in-rust/15500, но я понимаю, что это будет совсем не скоро. Но я не говорю, что "раз там нет зависимых типов, то раст плохой, вернемся к сишке".
если раст такой хороший, почему для него все IDE написаны на джаве? а я вам расскажу: потому что язык от веб-синьоров для веб-синьоров
> если раст такой хороший, почему для него все IDE написаны на джаве?потому что написаны. Вот если б начали переписывать - то было бы на хрусте.
Но поскольку пользоваться начатым переписываться ты все равно не сможешь - незачем было и начинать.
но ведь начинать переписывать это их святая обязанность
Вы правильно начали вашу цепочку рассуждений, но закончили, как обычно, газификацией лужи. Полно софте на Раст, которым уже пользуются куча людей.
Вопрос нужно ставить более широко. Например, где вообще софт, написанный на paстe (кроме пары-троек xипсторских подeлок где-то на гит-xaбе).
У Гугла в Андроиде, у Клаудфлэр в прокси-сервере, у Майкрософта в Винде, у Дискорд в мессенджере, у Дропбокса в их софте, в Линукс в некоторых дистрибутивах в некоторых утилитах (типа ripgrep), у Амазона в их софте (не помню название, но легко ищется). И у кучи других фирм поменьше, которые тоже используют этот ЯП.
как же ваши попытки нелепы, жалки и смешны, даже грустно
В чём вы видите их жалкость и нелепость? Указанным софтом пользуется несколько миллиардов планеты.
Хороший язык для начинающих и малоопытных программистов с "защитой от дурака", в своём сегменте это неплохой инструмент, чтобы нубы не сразу всё сломали в продакшене. Желаю развития проекту!
"Rust для нубов: Освой Hello World за 21 день" O'Reilly(R)
То ли дело сишнеки, которые не умеют правильно обращаться с памятью компьюктора, вот где мастер-класс!
Всё они умеют, весь базовый софт сейчас на Си написанный и на нём всё держится, как на гранитном фундаменте! А ошибки лепят желторотики или кого менеджер с кнутом подстёгивает пятилетку за один день делать.
По твоей логике все линуксовые приложения, в которых когда-либо были найдены CVE из-за сишки, написаны желторотиками. Лихо ты принизил сишку и опенсорс в частности!
Ну найдены, дальше что? Упал самолёт из-за этого или атомная электростанция взорвалась? Нашли - исправили и всего делов! Плохо, когда ошибки не обнаруживаются, а они есть.
Что за чушь ты пишешь? Сишку не допустят на самолет или станцию. Сишка уже лет 30 последних только в опенсорсе юзается, и в основном фанатами GNU, что как бы намекает, что GNU - сишные фанатики!
> Сишку не допустят на самолет или станциюСпасибо, поржал))
>Ну найдены, дальше что?Плохо то, что они допущены. Сишники игнорируют весь прогресс, за последние полвека в области типизации.
> Плохо то, что они допущеныДа, надо просто взять и не допускать ошибок, тогда заживём!)
Точно! На Rust определённый класс ошибок допустить нельзя. Прикинь? И да, освободившееся время можно потратить на поиск других, менее распространённых ошибок.
> Точно! На Rust определённый класс ошибок допустить нельзя. Прикинь? И да, освободившееся время можно потратить на поиск других, менее распространённых ошибок.Как ни странно можно. Правда для этого постараться придется. Но сама эта возможность закрывает огромный пласт возможностей для использования rust.
> Как ни странно можно.Как ни странно, нельзя. Компилятор не даст.
> Но сама эта возможность закрывает огромный пласт возможностей для использования rust.
Например, каких?
> Как ни странно, нельзя. Компилятор не даст.Примеры тут приводили. Если постараться то можно. rust не защита а защита от дурака.
> Например, каких?
Например: Разрешить использование всех пользовательских программ, не использующих unsafe в системе где безопасность возлагается на компилятор rust. Но так как есть методы обойти проверки то так делать нельзя.
> Плохо, когда ошибки не обнаруживаются, а они есть.Ну так они и не обнаруживаются годами или десятилетиями :)
Потом оказывается, что все это время они использовались.
А уже потом, ее наконец-то фиксят.
Ну так опенсорсники много чего неспособны написать, не все из них профессионалы высочайшего уровня.
Потому что профи уже разрабатывают проприетарщину. У них нет интереса работать за бесплатно, чтобы потом получить плевок в лицо и остаться ни с чем.
Расскажи это внезапно сокращённым программистам из Microsoft и Google, набравшим ипотек глядя на текущую зарплату
И что, они теперь будут писать код за бесплатно, вместо того, чтобы устроиться на работу?
> И что, они теперь будут писать код за бесплатно, вместо того, чтобы устроиться на работу?Если что, у меня есть примеры хороших программистов, которые "ушли на пенсию" в 38 лет.
Один исследованиями в области алгоритмов сжатия занимался. Очевидно, теперь его знания оказались не сильно нужны. Ж:(
> Если что, у меня есть примеры хороших программистов, которые "ушли на пенсию" в 38 лет."которые ушли" или "которых ушли"?
Так я бы тоже не против уйти на пенсию до сорока, и жить с ренты или каких-то других доходов))> Один исследованиями в области алгоритмов сжатия занимался. Очевидно, теперь его знания оказались не сильно нужны. Ж:(
Алгоритмы сжатия развивают уже лет пятьдесят, а то и больше.
И теория - вообще первая половина прошлого века (всякие теоремы Шенона и тд).
Думаю просто уперлись в технологический потолок.
Или в потолок "разумной достаточности", когда новые алгоритмы дают профит в пару процентов.
Как это не покажется странным - да, желторотиками. Практически все известные программы начали писать давно, когда их авторы были молодыми и начинающими программистами, и начинали писать как раз чтобы изучить программирование. Поэтому в старых программах неудачная архитектура, плохой дизайн, не используются техники надёжного программирования, потому что авторы про них просто не знали. К тому же большинство старых хорошо известных программ написаны непрофессиональными программистами.
Проблема не в том, что авторы чего-то не знали. Проблема в том, что Си изначально не предназначался для современного сложного ПО. Авторы языка понятия не имели, что программы будут измеряться десятками тысяч строк. Их предел на то время - несколько тысяч строк. Сам же язык не предусматривал никаких средств контроля над типовыми ошибками. В итоге имеем как бы работающий, но не так чтобы надёжно, код. В итоге пользователи на этих дырах теряют кучу денег.
> и на нём всё держится, как набольшой куче костылей и багов.
> А ошибки лепят желторотики или кого менеджер с кнутом подстёгивает
А кто наделал ошибок в иксах еще в прошлом веке?
opennet.ru/opennews/art.shtml?num=59906 1988, 1996
opennet.ru/opennews/art.shtml?num=62795 1991, 1994, 1996?Не диды ли?
Этих Кнутом погоняли :)
Нет, это были дети цветов. Тяжелое наследие ЛСД.
> большой куче костылей и баговВ большинстве случаев базовый софт написан изящно, нет там никаких костылей. А баги были, есть и будут, так устроен мир. Важно не наличие багов, а их последствия.
> А кто наделал ошибок в иксах еще в прошлом веке?
> Не диды ли?"Кто пишет без багов, пусть первый бросит в дидов камень"
>"Кто пишет без багов, пусть первый бросит в дидов камень"Бизнес бросает камень в сишных дидов, медленно избавляясь от сишки, и выбирая RUST. Уж бизнес деньги умеет считать, и поэтому бизнес приказал Линусу добавить RUST в ядро.
> Бизнес бросает камень в сишных дидовБизнес всегда ориентируется на самые днищенские решения, лишь бы они приносили быстрое бабло...
Ты просто смотришь по себе. Ясен пень, мелкий бизнес так делает, а у кого куча денег - те предпочитают надёжность. Пример: банки юзают джаву а не пых, потому что банкам нужна надёжность, а всякие локалхосты юзают пых из-за дешевизны.
> Бизнес всегда ориентируется на самые днищенские решения,
> лишь бы они приносили быстрое бабло...Вот оно что! Теперь понятно почему бизнес выбрал линукс в качестве серверной платформы.
Это же вот прям всё объяснило! Спасибо тебе, добрый человек!Ну и бизнес выбрал сишку вместо напр. той же Ада.
> А кто наделал ошибок в иксах еще в прошлом веке?
> Не диды ли?В прошлом веке? Нынешние диды, таки желторотыми были. Не?
То ли дело современные растовщики, если ещё не диды, то уж точно дядьки, умудрённые опытом и седыми мyдями (10 лет с первого релиза + 9 лет с основания проекта), осилили хеловрот, мантру о безопасности и пару-тройку реальных проектов.
Про какие иксы говорите? Если про Xorg, так он появился в 2006-м году. Если про X86Free, так его же MIT написал, то есть студенты. Конечно там будут ошибки.
>весь базовый софт сейчас на Си написанныйЯ вам советую почаще вылезать из криокамеры. Уже куча системного софта на go написана.
>как на гранитном фундаментеВы забыли сказать "дырявом"
>А ошибки лепят желторотикиДа, да, везде ненастоящие сишники. То в screen, то в grub, то в linux, и так во всех проектах. Удивительно, да?
> куча системного софта на go написанаСпасибо, посмеялся от души)))
> Да, да, везде ненастоящие сишникиПочему ненастоящие? Ты привёл пример хороших, надёжных программ.
>Ты привёл пример хороших, надёжных программ.Надёжность - это нажмите 28 раз backspace
>Ты привёл пример хороших, надёжных программ.Возможность получить права привилегированного пользователя - это, по-вашему, хорошо и надёжно? А все перечисленные программы это делали возможным в том или ином виде.
> Уже куча системного софта на go написана.А почему не на хрустяшке? Ниасилили за 10 лет?
> То в screen, то в grub, то в linux, и так во всех проектах.
Прям таки во всех? Или в перечисленных? Ну, linux из списка можно уже и исключить - rust вкорячили. Вот теперь заживём... когда ядро перепишут... лет через дцать... если осилят!!!
> Уже куча системного софта на go написана.Забавно что зумеры нынче называют системным софтом даже тот софт, который системным не является от слова совсем. Но объяснять им это бесполезно, т.к. для этого всё же требуется хоть какое-то техническое профильное образование, а не курсы вайтишников и прочих веб-"разработчиков".
>Вы забыли сказать "дырявом"Куда лучше что-бы эти дыры приходили в режиме JIT (just in time)?
Никто не гарантирует, что там в прицепном составе Rust вылезет.
> Уже куча системного софта на go написана.можно примеры такого системного софта на go?
И растокодеры тоже не умеют, поэтому и пользуются растом.
> для начинающих и малоопытных программистов с "защитой от дурака"Но по такой логике они дypaками и останутся ввиду отсутствия понимания глубинных процессов происходящих с ЭВМ в момент выполнения программ.
Наоборот. Rust учит (обучаемых) пониманию времени жизни переменных, бережному обращению с .clone() и прививает привычки явно прописывать гарантии в типах.
Что делает програмиста лучше.Главное — слушать, что говорит компилятор, а не бороться с ним.
> Что делает програмиста лучше.А так же послушнее в контексте управляемой биомассы снежинок, которые даже не знают чем отличается стек от кучи.
> слушать, что говорит компилятор
Если трава забористая, то конпилятор будет не только говорить, но и петь!
Причём здесь стэк и куча? Надо было что-то ляпнуть? Программист на Rust сразу учится понимать, где стэк, а где - куча. Потому что разные типы за это отвечают. Стандартные типы.
> Причём здесь стэк и куча? Надо было что-то ляпнуть? Программист на Rust сразу учится понимать, где стэк, а где - куча. Потому что разные типы за это отвечают. Стандартные типы.Притом что вполне можно писать код, в котором большим участкам кода можно запретить работать с кучей. Но в rust так нельзя. И это незавершенность концепции ограничения возможностей кода.
> Притом что вполне можно писать код, в котором большим участкам кода можно запретить работать с кучей.Это как, например? В коде написать комментарий для другого программиста: "Ни в коем случае нельзя работать с кучей"?
В Rust за работу с кучей отвечают переменные определённых типов. Вы или их используете, или нет. Или вы что-то другое имели ввиду?
Я имел ввиду систему ограничений на доступные средства языка.Например декларировал, что в конкретной функции нельзя работать с кучей. И компилятор проходя по этой функции и всему древу вызовов проверяет что нигде куча не трогается никаким образом.
Думаю, знаете, где это может пригодиться.
> Хороший язык для начинающих и малоопытных программистов с "защитой от дуpaка",Так это не "защита от дуpака", а защита от невнимательности.
Или ты называешь всех программистов ядерщиков, которые по 20-25 лет опыта имеют, и тем не менее делают use-after-free, выходят за пределы массивов и тд, дуpaками?
Он в бессознанке часто пишет. Так что я бы большого внимания ему не уделял.
Идею Rust - возможно и синтаксис - надо подхватить, а "инфраструктурный длинный прицепной состав" - отбросить. Ну куда такой жирный бинарник "на гора"?
Какой "такой"? Сколько он у тебя занимает, и почему именно столько тебе не подходит?
"let mut command = Command::new("path/to/bin")"
В каком уме пришла идея назвать бинартник командой?
Stephen Bourne?
Врёшь у Степана Борна не было команды - command.
>В каком уме пришла идея назвать бинартник командой?Не понял претензию (кстати, что такое "бинартник"). Command — тип, подготавливающий запуск процесса. Точно так же, как любой шелл, когда исполняет (внезапно) — команду.
Или хочется назвать Process? Будет хуже, так как всё это уже по пути std::process.
Птенцы вылупляются, и им кажется, что весь мир только сейчас появился, а раньше ничего не было. Так и молодым программистам кажется, что раньше никаких технологий надёжного программирования не было, а весь мир появился только с ними.
С благоговением молятся на RAII и borrow checker, не понимая что это "костыли", и что для действительно надёжных языков программирования эти костыли не нужны.
> для действительно надёжных языков программирования эти костыли не нужны.Это какие? Ada spark?
Basic. Супернадёжный язык: надёжный синтаксис, строгая типизация (имена переменных, в которых числа одинарной , двойной точности, строки - синтаксически различаются), надёжная работа с памятью ( указатели отсутствуют, для низкоуровневой работы с памятью применяют команды PEEK/POKE, надёжная работа с динамической памятью - динамически выделяется через DIM и изменяется размер через ReDIM, контроль за индексами массивов и строк, невозможно напортачить со статическими данными, которые в области DATA), надёжная работа со строками, автоматическое управление памятью и ресурсами.Для бейсика были расширенные наборы команд для всех случаев жизни. И графический API.
А также Java, Python, Typescript и другие интерпретаторы. Вы, прежде чем писать, не пробовали думать вначале?
На всякий случай. Rust - это компилируемый ЯП. И большинство его абстракций ничего не стоят в плане производительности (нулевые затраты). Надеюсь, больше подобной чуши писать не будете. Впрочем, наверное, зря надеюсь.
Хотя счас кто-то прибежит и скажет, что Java - это тоже компилируемый язык. Одно маленькое "но" при этом его смущать совершенно не будет - необходимость наличия среды выполнения. Но кого волнуют подобные "мелочи".
У Сишки, Плюсов и Паскаля тоже есть рантайм библиотеки, это не показатель.
А вот интерпретация байткода - это показатель, да.
FreeBasic - компилируемый бейсик (https://freebasic.net/).
Gambas - бейсик с JIT (https://gambaswiki.org/website/en/main.html)
Спасибо. Не знал, что Бейсик уже компилировать можно. Но всё равно, сомнительно, что его можно сравнивать по функциональности с Rust. Например, нет поддержки асинхронщины, параллельного программирования. Поддержка типов весьма ограниченная и довольно примитивная. Про модульность тоже не совсем всё очевидно и понятно. Ассемблер никак не вставить в исходный код. И так, наверное, ещё долго можно продолжать.
>FreeBasic - компилируемый бейсик (https://freebasic.net/).Это какой-то извращённый троллинг? Этот freebasic - ни что иное, как загриммированный си/кресты. Ровно как и freepascal
>- For object destruction and memory deallocation, Delete must be called on a proper typed pointer (otherwise the object destructor will not be called or miscalled, and that may result in a memory leak or even a crash with Delete[]).
>- After destruction + deallocation, the pointer value becomes invalid (pointing to an invalid memory address), and its reuse (for dereferencing or calling Delete again) will result in undefined behavior.
>- If used, the special Placement New (using memory already allocated) induces only object construction, so use Delete is forbidden (to avoid double request of deallocation). If necessary, the only destruction of the object must be manually do by user (calling the destructor by using member access operator).Вы будуте портить память с тем же успехом, что и на си
Программисты тоже любят шутить
"let mut output = Vec::new();"
Массив чего вы создаёте?
Сущность определяется неявно.
let mut output: Vec<_> = Vec::new();
может аналог вектор void-ов?
std::vector<void*>
Вы сейчас как на экзамене гадаете?
Можно же посмотреть сайт (вместо спеков)fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize>
Так что правильный ответ let mut output:Vec<u8> = Vec::new();
Можешь явно указать. Иначе компилятор посмотрит что ты туда пытаешься вставить и будет использовать этот тип. Это называется type inference.
Сишники про Хиндли-Милнера когда наконец-то усвоят? Его уже применяли в восьмидесятые, вылезайте из своего невежества.
>таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.пЭто же всë реализовано во FreePascal.
А кому нужен BEGIN-END?
Как пелось в классической песне> A thousand people people swear that
> T.P. Seven is the one for me.
> I hate the word PROCEDURE,
> Write in C.
Да, но есть тонкость. Во Free Pascal'е всё будет в порядке если придерживаться правил хорошего программирования. Например, освобождать объекты путём вызова FreeAndNil, а не метода Free объекта, использовать try/finally и т.д. Но что делать если кто-то случайно (или из-за безответственности) что-то сделает не по правилам?А Rust не даёт делать не по правилам.
>что-то сделает не по правилам?Бить по рукам линтером :)
Но что делать, если кто-то ансэйфит в расте?
Unsafe не означает вседозволенность. Попробуйте почитать документацию.
Доки - на что? Стандарта-то нету.
Отсутствие стандарта не означает отсутствие документации на спецификацию языка. Не знали? Откройте для себя Интернет. Стандарта нет, а он работает как-то. Вот чудеса!
Другой подобный язык - Питон. Тоже нет стандарта. А он один из самых популярных языков в мире.
> Но что делать, если кто-то ансэйфит в расте?Принимать #этодругин 3 (три) раза в день, независимо от приёма пищи.
На самом деле есть куда более надёжное решение. Почитать документацию и убедиться, что unsafe не означает вседозволенность. Но разве ж местные "эксперты" умеют читать?
> Почитать документацию и убедиться, что unsafe не означает вседозволенность.Хе-хе, этот unsafe, чей надо unsafe! Это другое!! Ничё вы не понимаете!!!
>Например, освобождать объекты путём вызова FreeAndNil, а не метода Free объектаСколько раз повторяется этот вредный совет. FreeAndNil может работать только при наличии единственного указателя. При наличии хотя бы двух указателей(двусвязный список как самый простой пример), у вас останется один висячий указатель, который будет не обнулён. Это вам нужно сразу двойной указатель делать, чтобы гарантировать
Паскальщики, это переодетые сишники. Они точно так же портят память и ненавидят прогресс. А ещё, они лжецы https://wiki.freepascal.org/Memory_Management#Memory_Leaks https://wiki.freepascal.org/Memory_Management#Use-After-Free
Укажите правильные ссылки https://wiki.freepascal.org/Memory_Management#Ownership_Model
:)
Паскаль так же дыряв как и си, может как кресты. До раста ему крайне далеко
Вообще-то это не правда.
> До раста ему крайне далекоЕстественно, ведь в паскале нету unsafe и токсичного общества.
А ещё работа с память один в один как си. Так зачем нужен второй си, со странным синтаксисом?
Ага, ага. И работа со строками и указатель может указывать на любой тип как в си. Rtfm :)
Если говорить про Free Pascal, то в нём можно так же удобно работать с низкоуровневыми данными как в Си, и в то же время в нём есть средства для надёжной работы с высокоуровневыми данными (чего нет в Си). Во Free Pascal'е три вида указателей:
1. Небезопасные ( вида var x: ^T1 ). Они эквивалентны Си-шным указателям и предназначены для работы с низкоуровневой информацией (байты, маш. слова) и системными вызовами, для них нет проверки типизации и разрешена арифметика.
2. Безопасные указатели ( вида var x: T1 , где T1 - класс ). Для них компилятор проверяет типизацию, наличие инициализации, для них запрещены арифметика и приведение типа. Эти указатели используют для работы с объектами и построения динамических структур данных типа списков.
3. Интеллектуальные указатели (вида var x: T1 , где T1 - интерфейс). Это контролируемые указатели на подсчёте ссылок на объект. Они автоматически уничтожают объект когда его никто не использует).Это только маленькая часть отличий Free Pascal'я от Си.
> может как крестыно ведь LLVM написан на них, и раст его использует потому что своего компилятора в ассемблер и своего ассемблера у раста нет.
> но ведь LLVM написан на них, и раст его использует потому что
> своего компилятора в ассемблер и своего ассемблера у раста нет.Ты хотел показать, что ты не знаешь как работает LLVM - это понятно.
А вот сказать-то что хотел?
Я как один из авторов бекенда LLVM-RISCV наверно все-таки знаю как работает LLVM и уж точно знают побольше тебя. А сказать я хотел, что если (как ты говоришь) кресты дырявые, то дырявый и твой раст потому что раст не имеет ни компилятора, ни ассемблера. Все что он умеет это преобразовывать код на расте в LLVM-IR, а дальше это всё уже компилируется "дырявым" софтором на С++ в ассемблер -> бинарный код. Дак вот если в этом софте бага с переполнением, use-after-free и т.п., то и твой код на расте получится дырявым.
> Я как один из авторов бекенда LLVM-RISCVЯ тебе конечно верю
Разве могут быть сомненья
В интернете Анонимы
Только правду говорят!> что если (как ты говоришь) кресты дырявые,
Ага, а они дырявые.
> то дырявый и твой раст
Д - Логика (с)
> Дак вот если в этом софте бага с переполнением, use-after-free и т.п., то и твой код на расте получится дырявым.
С чего вдруг?
Может просто процесс компиляции крашнеся, или для уязвимости нужно самому заниматься компиляцией.
Раст выступает в роли дополнительного слоя защиты от врожденных багов недоязычков.
Но раз ты спец в llvm, то для тебя будет легко найти пример уязвимости, которая просочилась в получаемый бинарник.ps и да, к сожалению llvm таки дырявый.
"В итоге в кодовой базе LLVM удалось выявить 12 новых проблем, из которых 8 были вызваны ошибками, приводящими к повреждению памяти. 6 выявленных уязвимостей приводили к переполнению буфера, 2 к обращению к уже освобождённой памяти, 3 - к разыменованию нулевых уязазателей и 1 к чтению из области вне выделенного буфера."И это с учетом кучи тестов, фаззинга и тд.
opennet.ru/opennews/art.shtml?num=60707
>> компилятора в ассемблер и своего ассемблера
> Я как один из авторов бекенда LLVM-RISCV наверно все-таки знаю как работает
> LLVM и уж точно знают побольше тебя.Т.е. как "один из авторов бэкэнда" - ты даже не задумывался, почему это llvm-as и прочие llc - вынесены в tools (т.е. опциональны и не задействованны в компиляторе расте[1], как впрочем AFAIK нет и "компилирования в ассемблер" в том же GCC)?
Но ты продолжай, продолжай ...> что если (как ты говоришь) кресты дырявые, то дырявый и твой
> раст потому что раст не имеет ни компилятора, ни ассемблера. Все
> что он умеет это преобразовывать код на расте в LLVM-IR, а
> дальше это всё уже компилируется "дырявым" софтором на С++ в ассемблер
> -> бинарный код. Дак вот если в этом софте бага с
> переполнением, use-after-free и т.п., то и твой код на расте получится
> дырявым.А не, лучше б не продолжал. *рукалицо.жпг*
Так вот, дорогой "автор" - если в "этом софте" (т.е. LLVM) бага с переполнением, то она так и останется в "этом софте".
Потому что "бага" для "переноса" use-after-free/переполнения и т.д. должна быть в самом алгоритме кодогенерации - чтобы _генерировать_ дырявый код. Такие баги (кодогенерации) тоже бывают в компиляторах, однако они обычно намного реже непосредственно тех самых вышеупомянутых "багов в софте".
А просто "use-after-free" и прочая "испорченная" память в компиляторе - рискует сгенерировать тебе просто дефектный бинарник.
[1]
https://users.rust-lang.org/t/llvm-and-llc-binaries-missing-...
> Llvm-* and llc binaries missing from rustc build
> What should I do to have these llvm-* binaries also get built as part of the compiler build process?Это к "компилятора в ассемблер и своего ассемблера у раста нет" и "компилируется "дырявым" софтором на С++ в ассемблер -> бинарный код."
угу, без llvm-as ...Так чего именно ты там (со)автор - КоКа?
Читать всем! Про Java, Go, Rust. Раздел "Сравнение в реальных проектах":
https://www.cyberforum.ru/blogs/2408864/10292.html
И вот это до полной кучи тогда уж: https://yager.io/programming/go.html
Поднаброшу. Я вот долго думал, разбираясь в Rust и пытаясь его приспособить для своих производственно-промышленных задач. Да, всё получается, где сложно, где сразу, но получается. Но что-то гложет и что-то смущает донельзя. И понял. Если Си меня заставляет управлять вручную выделением и освобождением областей памяти, то Rust меня заставляет управлять вручную владением и временем жизни объектов. Просто одну абстракцию ("куча") заменили на другую. Что бы не говорили, но в 75% случаев использующих сложные структуры данных, приходится делать всё это руками.
Не буду опускаться до критики синтаксиса, всех этих <'&> иероглифов, потому как их и в Си++ натянули порядочно. В этом смысле отличий уже нет. Даже в Ada местами тоже натянули иероглифов.
Да, дополню, в качестве пояснения. Конечно, ошибки работы с динамической памятью встречаются, поиск и исправление требуют времени и глубокого понимания, как что работает. Но это десятая часть всех ошибок. Основные ошибки связаны с математикой: неправильное преобразование значений (которые есть физические величины), выход за область допустимых значений, алгоритмические ошибки. И вот тут, в плане возможности организации контроля на этапе компиляции, вне конкуренции язык Ada с его расширяемой системой типов и контрактов.
> управлять вручную владением и временем жизни объектовВы или не понимаете, о чём пишете, или осознанно искажаете смысл. Rust принуждает вас следить за владением и временем жизни. Но это принуждение осуществляется автоматически, а не вручную.
> Конечно, ошибки работы с динамической памятью встречаются, поиск и исправление требуют времени и глубокого понимания, как что работает. Но это десятая часть всех ошибок.
Такие фирмы, как Майкрософт и Гугл, утверждают, что таких ошибок примерно 70%, а не 10% как вы здесь утверждаете. Понятно, что в вашем конкретном случае (предположу, что-то не слишком сложное, до нескольких тысяч строк кода), может быть и такая статистика. Но ваш случай не показателен.
> неправильное преобразование значений (которые есть физические величины), выход за область допустимых значений <skipped>
Эти ошибки также контролируются компилятором Rust.
> Rust принуждает вас следить за владением и временем жизни.Именно об этом я и написал. Это не хорошо и не плохо, это просто другая абстракция. Ну не получается в Rust "всё автоматически". Из "автоматически" только то, что оно не скомпилируется. А вот как надо написать, чтобы скомпилировалось - извольте шевелить извилинами. Как и везде, как и в случае классической кучи. Только там упадёт на этапе выполнения/тестов.
> Понятно, что в вашем конкретном случае (предположу, что-то не слишком сложное, до нескольких тысяч строк кода)
в моём случае промышленная SCADA, на 70% написанная на Ada. Я не майкрософт и не гугл. У меня чисто прикладные, производственные задачи.
> Эти ошибки также контролируются компилятором Rust.
области допустимых значений и контракты в Rust строго говоря это не часть языка, не система расширения типов (как в Ada), а надстройка, то, что в C++ реализовывалось бы специализированными классами-контейнерами.
Rust, на уровне языка, фактически старается предотвратить 2 типа ошибок: использование неинициализированной памяти и использование уже освобождённой памяти. Ладно, пусть это будет треть ошибок, в целом "по больнице". Всё остальное там - это библиотеки.
Вообще, я зарёкся спрашивать что-то на форумах по Rust. Что не спросить, по делу, один ответ - "сам дурак". Где вас таких выращивают, в каком заповеднике? Вы изо всех утюгов вещаете про то, что все эти проблемы "решаются автоматически, такой чудесный язык". Люди начинают его изучать, сталкиваются с реальностью, начинают задавать вопросы. В том числе и неудобные! И получают в ответ, сходу, обвинения, оскорбления и агрессию.
Не поделитесь информацией про Аду?
Мне интересно:
- GUI на Аде написан?
- используется ли в коде на Аде динамическое создание и освобождение памяти? используются ли пулы памяти? используются ли интеллектуальные указатели?
Используется GtkAda.
Используются специализации Storage_Pools, но в целом модули стараются распределить память при инициализации и потом просто работать. Перераспределение памяти будет только при какой-либо реконфигурации. Реализация пулов в основном блочная, чтобы исключить фрагментацию.
Ссылочные типы с подсчётом ссылок и прочим, в том числе для обнаружения "повисших" групп объектов, которые ссылаются друг на друга, но их никто не использует, используются в графовых алгоритмах, это уже часть высокоуровневый модели данных системы.
Я же в основном по цифровой обработке сигналов и драйверам протоколов обмена.
Спасибо за информацию. А компилятор - FSF GNAT ? К нему претензий нет?
AdaCore GNAT Pro + SAS... Сертификация, панимаешь...
А вообще система начиналась на Rational Apex Ada.
>Ссылочные типы с подсчётом ссылок и прочим, в том числе для обнаружения "повисших" групп объектов, которые ссылаются друг на друга, но их никто не использует, используются в графовых алгоритмах, это уже часть высокоуровневый модели данных системы.То есть там мало того, что есть сборщик мусора, так ещё и счётчик ссылок зачем-то воткнули?
>но в целом модули стараются распределить память при инициализации и потом просто работатьРасскажите, как вы с таким подходом парсер будете делать
В языке Ада нет интеллектуальных указателей, но для GNAT они реализуются в библиотеке.
Делать сборщик мусора или нет - спецификация Ады про это ничего не говорит, это зависит от разработчика компилятора.Парсеры стандартных форматов есть готовые в виде библиотек. А если какой-то свой - видимо резервируют память в пуле с запасом.
> То есть там мало того, что есть сборщик мусора, так ещё и счётчик ссылок зачем-то воткнули?В Аде есть много разных сборщиков мусора. Но использовать их не обязательно. Мало того, один проект может использовать один тип сборщика мусора, а другой проект - другой, а третий - вообще его не использовать. Мало того, какой аллокатор хотите, такой и используйте.
Есть даже такая экзотика: какой либо конвертер выделяет память для работы по мере необходимости, а потом всё скопом освобождается, когда конвертация закончена. Просто потому, что во время работы освобождать нечего. Такой процесс не использует ни сборщик мусора, ни умные указатели. Не нужно это ему.Большинство модулей использует блочное выделение и освобождение памяти. Это просто быстрее, не возникает фрагментации кучи, и отлично подходит к специфике предметной области.
По моему какие-то варианты сборщика мусора используют модули, заточенные под всякий Web. Но я ими не занимаюсь, и, если честно, в них не разбирался.
И да, в .NET, например, если у вас есть кольцевые ссылки, то сбощик мусора скажей "ой" и память потечёт...
> Расскажите, как вы с таким подходом парсер будете делать
Есть реализации парсеров XML, JSON, CBOR которые вообще не используют динамическую память.
И, ужас какой, для ПЛК у нас тоже есть софт на Аде.
> Именно об этом я и написал. Это не хорошо и не плохо, это просто другая абстракция. Ну не получается в Rust "всё автоматически". Из "автоматически" только то, что оно не скомпилируется. А вот как надо написать, чтобы скомпилировалось - извольте шевелить извилинами. Как и везде, как и в случае классической кучи. Только там упадёт на этапе выполнения/тестов.Вы написали примерно следующее. В Си я должен следить за памятью вручную. Не отслежу - ну и ладно, в лучшем случае выхватим сегфолт. В худшем - получим испорченные данные.
В Rust за владением и временем жизни следит компилятор, не вы. Если вы ошиблись, вам дадут по рукам тут же. Вы правда до сих пор не чувствуете разницы между Си и Раст?> области допустимых значений и контракты в Rust строго говоря это не часть языка, не система расширения типов (как в Ada), а надстройка
Какая разница, как это реализовано, если это работает? Или вы полагаете, что в другом компиляторе этого может и не быть?
> Rust, на уровне языка, фактически старается предотвратить 2 типа ошибок: использование неинициализированной памяти и использование уже освобождённой памяти.
А также на уровне компилятора выход за пределы диапазона значений, выход за пределы массива, попытки присвоения значений немутабельным переменным, попытки разыменовывать сырые указатели (в режиме safe). Может ещё что забыл.
> Ладно, пусть это будет треть ошибок, в целом "по больнице".
Это 70% ошибок, если верить отчётам Гугла и Майкрософт.
> Вообще, я зарёкся спрашивать что-то на форумах по Rust. Что не спросить, по делу, один ответ - "сам дурак".
А что конкретно вы спросили по делу? Сами же написали: "Ещё наброшу". Или уже забыли?
> Где вас таких выращивают, в каком заповеднике?
А вас где? Сам же накинул, а теперь удивляется, что ему как-то не так отвечают.
> И получают в ответ, сходу, обвинения, оскорбления и агрессию.
Где были оскорбления или агрессия? Можете процитировать?
Про оскорбления и агрессию это не вам. Это вообще констатация факта взаимоотношений в сообществе. "Ещё наброшу" это предвосхищение реакции на критику языка, так сказать.> В Rust за владением и временем жизни следит компилятор, не вы. Если вы ошиблись, вам дадут по рукам тут же. Вы правда до сих пор не чувствуете разницы между Си и Раст?
Разница несомненно есть. Но в случае программирования критических систем на Си есть ещё статический анализатор, который даст по рукам точно так же. У вас просто не пропустят исходник мимо него, даже в тестовую среду. Эта проблема не новая и решается не только в Rust. Просто решается разными способами.
И, компилятор Rust, в случае сложных структур, часто не справляется и просто бракует всё останавливая сборку, и приходится расставлять ему хинты, то есть, управлять руками. Ну руками, так руками, не хелловорды пишем. Главное, чтобы работало, сами же ж говорите. Есть подход - программист управляет и направляет компилятор, указывая отношения владения и времени жизни объектов в коде. Есть такое? Есть.> Какая разница, как это реализовано, если это работает? Или вы полагаете, что в другом компиляторе этого может и не быть?
Я про подмену понятий авторами языка. Это раздражает.
Я не говорю, что Rust плохой язык. Но, как и у любого языка, особенно молодого, в дизайне есть слабые места. И вместо их исправления я наблюдаю, что вокруг выстраивается куча костылей. И это печально! Я реально начал в него вникать несколько лет назад, рассчитывая, что наконец-то, придумано что-то принципиально лучшее! И мирился с недостатками, думая, что язык развивается, всё это исправят. Но сейчас вижу, что только усугубляют. Впрочем, я не профессор компьютерных наук, у меня нет опыта Вирта, Таненбаума, Дейкстры. Хотя судя по критике Rust со стороны науки, мне это не кажется.
Я вот не хочу, чтобы такие хорошие идеи испортили до абсурда.> А также на уровне компилятора выход за пределы диапазона значений, выход за пределы массива, попытки присвоения значений немутабельным переменным, попытки разыменовывать сырые указатели (в режиме safe). Может ещё что забыл.
Ну мутабельность это ещё та придумка... которая мне лично не нравится, но это уже вкусовщина. Есть константы, а есть переменные. А "константные переменные" это, извините, оксюморон. Придумали себе проблему и героически её решают.
Описание диапазонов значений в Rust это, извините, кастрат, по сравнению с тем, что есть в Ada. Откат назад. Проверки контрактов нет. Но ладно, это рантайм, а Раста зеро-рантайм, типа... Ошибки индексов вы все на этапе компиляции не поймаете. Поймаются только те, где размер известен на этапе компиляции. А это также ловится статическим анализатором в любых других языках.
А что делать с проверкой допустимости результатов вычислений в рантайме? А не завезли. В Ada есть, а в новый и прогрессивный Rust не завезли.
"Сырые" указатели это вообще следствие модели Раста. Странно было бы, если бы такой проверки не было.> Это 70% ошибок, если верить отчётам Гугла и Майкрософт.
FAANG - это не весь мир программирования. И даже не его бОльшая часть, вместе взятые.
Если, на этих галерах, индусам следить за malloc/free это сродни достижению нирваны, то это их персональные проблемы.Напомнить, как ESA взорвала сверхтяжёлую ракету-носитель? Там была чисто алгоритмическая ошибка, которая ничем кроме глаз и мозгов не поймается.
В мире промышленности эти "лучшие практики разработки от FAANG" практически не нашли применения. И это к счастью. Тут конкуренты пилят SCADA по этим практиками, в том числе и с использованием Rust, на микросервисах, с Kubernetes и прочим и прочим... Реально, становится страшно.
> Про оскорбления и агрессию это не вам. Это вообще констатация факта взаимоотношений в сообществе.По моим наблюдениям - в любом сообществе.
Например вимеры против емаксеров. Или споры по поводу системмд/вейланд/лучший дистрибутив ever...> Разница несомненно есть. Но в случае программирования критических систем на Си есть ещё статический анализатор, который даст по рукам точно так же.
Не даст.
Вот целая куча дыреней в OpenSSL/LibreSSL www.opennet.ru/opennews/art.shtml?num=58622
чтение из области вне границ буфера, Use-after-free, двойное освобождение памяти, некорректное разыменование указателя, разыменование указателя NULL (x2)...
ну и еще одна логическая проблема, которая решается нормальными типами в нормальных языках.
При этом ворнинги включены, оба проекта обмазаны санитайзерами по самое немогу - и memory, и thread, и еще куча других github.com/openssl/openssl/actions/runs/4124496105 Там даже фаззинг какой-то есть.> И, компилятор Rust, в случае сложных структур, часто не справляется и просто бракует всё останавливая сборку, и приходится расставлять ему хинты, то есть, управлять руками.
Расставлять хинты, это указывать типы?
Я бы сказал что это просто хорошая манера программирования.> Есть подход - программист управляет и направляет компилятор, указывая отношения владения и времени жизни объектов в коде.
> Есть такое? Есть.Ну так для того лайфтаймы и были сделаны, чтобы ими управлять компилятором.
> Я про подмену понятий авторами языка. Это раздражает.
Что-то я не очень понял, что именно подменили авторы языка.
> Описание диапазонов значений в Rust это, извините, кастрат, по сравнению с тем, что есть в Ada. Откат назад. Проверки контрактов нет. Но ладно, это рантайм, а Раста зеро-рантайм, типа...
Ага, именно проверки во время компиляции это одна из фич.
Проверки контрактов могут добавить в будущем, если конечно будет спрос.
Все сразу сделать невозможно)> Ошибки индексов вы все на этапе компиляции не поймаете. Поймаются только те, где размер известен на этапе компиляции.
Но если у нас есть итератор или слайс, то можно проверку сделать один раз, а потом быть уверенным что за массив не выйдешь.
> А это также ловится статическим анализатором в любых других языках.
Как я написал выше - не ловится.
Если бы ловилось, то в расте не было бы нужды.
И всякие TRAP-C и Safe C++ не придумывали.> А что делать с проверкой допустимости результатов вычислений в рантайме? А не завезли. В Ada есть, а в новый и прогрессивный Rust не завезли.
Хм.. Ну так пишите на АДА.
В раст много чего не завезли, например GC.> Если, на этих галерах, индусам следить за malloc/free это сродни достижению нирваны, то это их персональные проблемы.
Хаха, а кто тогда пишет овнокод в ядре линукс?
www.cvedetails.com/vendor/33/Linux.html
Memory Corruption на первом месте с огромнейшим отрывом.
Overflow на почетном втором.> Напомнить, как ESA взорвала сверхтяжёлую ракету-носитель? Там была чисто алгоритмическая ошибка, которая ничем кроме глаз и мозгов не поймается.
Если ты про Ариан5 - то там был Overflow 16-битного инта)
Более того, еще были грубейшие нарушения процессов: код взяли с ариан4 и даже не перетестировали, в модуле присутствовали переменные которые "были не защищенные" потому что разработчики подумали что "ситуация переполнения не возможна впринципе" и тд.> В мире промышленности эти "лучшие практики разработки от FAANG" практически не нашли применения.
Зато если почитать про "индустриальный код тойоты", то волосы встают дыбом)
> Но в случае программирования критических систем на Си есть ещё статический анализатор, который даст по рукам точно так же.Не даст в некоторых случаях. И таких случаев, как показывает практика, довольно много.
> У вас просто не пропустят исходник мимо него, даже в тестовую среду. Эта проблема не новая и решается не только в Rust. Просто решается разными способами.
Согласен, что проблему в принципе можно решить. Разница только будет в цене решения. В случае с Си такая цена будет намного-намного выше, чем в случае с Rust.
> Есть подход - программист управляет и направляет компилятор, указывая отношения владения и времени жизни объектов в коде.
Если продолжить предложенную вами логическую цепочку рассуждений, то написание любой программы на любом ЯП - это управление и направление компилятора (интерпретатора). Не правда ли? Но будет ли это означать, что ЯП1 равен по функциональности ЯП2? Очевидно, что нет, не будет. Но вы зачем-то пытаетесь уравнять Си и Раст. Зачем?
> Я про подмену понятий авторами языка. Это раздражает.
Не могли бы вы указать ссылку на официальную документацию, где бы осуществлялась такая подмена понятий?
> Я не говорю, что Rust плохой язык. Но, как и у любого языка, особенно молодого, в дизайне есть слабые места.
Такие места есть в любом абсолютно ЯП. Хоть в молодом, хоть в старом. Мы живём не в идеальном мире. Однако замечу, что Раст по сравнению с некоторыми уже давно существующими ЯП - это значительный рывок в деле программостроения.
> И вместо их исправления я наблюдаю, что вокруг выстраивается куча костылей. И это печально!
Чтобы не быть голословным, пожалуйста, приводите примеры.
> Хотя судя по критике Rust со стороны науки, мне это не кажется.
Я бы хотел узнать больше об этой научной критике. Можете поделиться ссылками?
> Ну мутабельность это ещё та придумка... которая мне лично не нравится, но это уже вкусовщина.
Нет, мутабельность не имеет отношения к вкусовщине.
> Есть константы, а есть переменные. А "константные переменные" это, извините, оксюморон. Придумали себе проблему и героически её решают.
Если вы чего-то не знаете, не понимаете, это не значит, что это оксюморон. Значения констант должны быть известны на момент компиляции. Значения немутабельных переменных фиксированы, но могут быть получены в процессе работы программы. Кроме того, область видимости переменных может быть локальной, в отличие от констант, которые всегда глобальны. Переменные могут быть переопределены (shadowing).
> Описание диапазонов значений в Rust это, извините, кастрат, по сравнению с тем, что есть в Ada. Откат назад.
В чём это выражается на практике?
> Проверки контрактов нет. Но ладно, это рантайм, а Раста зеро-рантайм, типа...
В Rust механизм безопасности типов и проверка заимствования (borrow checker) выполняют схожие функции. Кроме того, есть assert! и debug_assert!
Ещё одним методом является модель владения. Также есть Trait bounds (where T: SomeTrait) — они ограничивают использование типов и обеспечивают их соответствие определенным условиям.
Ну и есть сторонние крейты для контрактного программирования, например pre и ensures.То есть, Rust защищает код на уровне системы типов и компилятора, а проверка контрактов частично реализуется через assert, условия типов и строгую систему владения.
> Ошибки индексов вы все на этапе компиляции не поймаете. Поймаются только те, где размер известен на этапе компиляции.
Это верно. Но в Си и такого нет.
> А это также ловится статическим анализатором в любых других языках.
Если его, анализатор, не забывать применять. Да?
> А что делать с проверкой допустимости результатов вычислений в рантайме? А не завезли.
Это не совсем так. В Rust есть:
1. Проверка переполнения арифметических операций (в режиме debug). В release можно использовать checked_add, wrapping_add, overflowing_add и saturating_add.
2. Проверка выхода за границы массива во время выполнения.
3. Активно используются Result и Option.
4. Есть библиотеки, такие как validify. Хотя это и не стандартная библиотека, но её уже "завезли".> FAANG - это не весь мир программирования. И даже не его бОльшая часть, вместе взятые.
Ок. Но ваше мнение в данном случае не идёт ни в какое сравнение с этими вот.
> Если, на этих галерах, индусам следить за malloc/free это сродни достижению нирваны, то это их персональные проблемы.
Это не только на этих галерах такие проблемы. Это в мире программистов на Си такие проблемы.
> Напомнить, как ESA взорвала сверхтяжёлую ракету-носитель? Там была чисто алгоритмическая ошибка, которая ничем кроме глаз и мозгов не поймается.
Да, факапы случаются. Но мы до сих пор говорили об определённом классе ошибок, а не вообще обо всех, которые встречаются в любом ЯП. Не понимаю, зачем вы пытаетесь с одной тему на другую перепрыгнуть.
> В мире промышленности эти "лучшие практики разработки от FAANG" практически не нашли применения. И это к счастью.
В мире промышленности это объяснимо тяжёлыми последствиями от возможных ошибок. Поэтому софт для мира промышленности стоит не в пример дороже, чем в мире обычных потребителей.
>Но в случае программирования критических систем на Си есть ещё статический анализатор, который даст по рукам точно так же. У вас просто не пропустят исходник мимо него, даже в тестовую средуКоторый в подавляющем количестве мест попросту отсутствет. Это мы сейчас молчим про его способность находить ошибки
>Впрочем, я не профессор компьютерных наук, у меня нет опыта Вирта, Таненбаума, ДейкстрыЭто тот самый Вирт, который то добавлял оператор FOR, то убирал? А можно без Вирта?
>Есть константы, а есть переменные. А "константные переменные" это, извините, оксюморонСразу видно Ыксперда. Константы, они везде константы. Как пи, например. А неизменяемые переменные очень нужны, например, для многопоточности. Вы же не можете сделать пользовательский ввод констатной?
>А что делать с проверкой допустимости результатов вычислений в рантайме? А не завезли. В Ada естьЛично я за что-то вроде ATS. А если в аде нет зависимых типов, то ада не нужна. Ибо вышло у вас недопустимое значение, что теперь, падать?
> В Rust за владением и временем жизни следит компиляторСлова достойные юного пионэра, который примерно на 1-2% изучил язык и думает, что, мол, вот она, золотая пилюля. Но чуть позже будет разочарование. Вроде даже научный термин есть этому.
Пример, как можно испортить ЯП политикой и флажкизмом
Программирую для Solana, из-за этого был вынужден изучать Rust. Честно говоря это боль, особенно то сообщество людей, которое образовалось вокруг языка. Взрослые вроде мужчины, а ставят пони и мультяшных персонажей себе на аватарки, используют детский сленг в общении и не знают САМЫХ основ computer science, но готовы раздавать советы об ошибках компилятора и почему правильно так, а не иначе.