Опубликован релиз языка программирования Rust 1.89, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63697
Почему вы пишете в первом абзаце: предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime 😵💫Как будто это что-то уникальное…😐 В C++ тоже есть такие возможности, так что не стоит делать из этого сенсацию.😉
Это для местных хейтеров. Там есть персонажи, думающие, что в расте есть сборщик мусора. Вот их сразу и срезают. Та же фигня с постоянным абзацем, что rust не является обязательной зависимостью при сборке ядра linux.
> Там есть персонажи, думающие, что в расте есть сборщик мусораА как жи Arc<_>???))?? хыыы
Это не сборщик мусора, это автоматический подсчет ссылок
Тут есть скоморохи, которые на полном серьезе утверждают, что подсчет ссылок - это то же самое, что и сборщик мусора в Java и Python. И что RAII - это тоже подсчет ссылок (когда их максимум 1), и, соответственно, он тоже является сборкой мусора.Ты на Опеннете, друг, тут порой и не такой боед прочтешь...
Вообще то RAII - это тоже про подсчет ссылок, хотя сборщик мусора тут совершенно не причем.
> Вообще то RAII - это тоже про подсчет ссылокО, ты из тех самых экспертов? Ну так аргементы-то приведи своему утверждению.
Ну ты же себя Ыкспертом считаешь, чем же другие хуже?А если серьезно, то будет подсчет ссылок при RAII или нет, зависит от типа ресурса.
Если ресурс не является ссылкой, тогда никаких (всегда 1 ссылка) не будет, так как ресурс не ссылка **по определению**. Однако создание ссылочного ресурса (например, с shared_ptr) реализует подсчет ссылок автоматически, но как вырожденный случай, счетчик ссылок действительно может быть установлен в единицу, но это не означает, что подсчет ссылок отсутствует вовсе.
Я подозревал, что в ответе будет невнятная каша, но чтобы настолько... 🤦 Сперва у нас:> RAII - это тоже про подсчет ссылок
Теперь вдруг:
> Если ресурс не является ссылкой, тогда никаких (всегда 1 ссылка) не будет, так как ресурс не ссылка **по определению*
Т.е. ресурс не является ссылкой, но 1 ссылка есть, но ресурс не ссылка! 😂
> Однако создание ссылочного ресурса (например, с shared_ptr) реализует подсчет ссылок автоматически
Создание ресурса реализует подсчет ссылок. 🤣 А это создание может мне реализовать игру с корованами?
Жги еще!
> И что RAII - это тоже подсчет ссылок <...> и, соответственно, он тоже является сборкой мусора.Ну так ткните их в определения. GC работает в рантайме, а RAII отрабатывает на этапе компиляции.
В этом и проблема, что чёткого общепринятого определения не существует. Поэтому в разных сообществах принято за GC считать разное. В сообществе языка D, например, принято сборщиком мусора считать счётчики ссылок.На мой вопрос "что же это за сборщик мусора, который не может определить и дропнуть зацикленный в себя связный список "A -> B -> C -> A" если он уже ниоткуда не доступен - выдаются какие-то странные ответы.
У сообщества Rust ответ гениальный. Утечка памяти из-за циклических ссылок является "безопасной", просто нужно писать программы правильно :-)https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
> Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak). Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust.
> утечка памяти из-за циклических ссылок является "безопасной"Вообще они правы.
Это безопасно в рамках выбранной модели безопасности, т.к. утечка не повреждает память и максимум что случить - аппу грохнет OOM Killer. Сейчас без GC невозможно бороться с утечками, а отсутствие GC - осознанный выбор.Поэтому они не пытаются решить неразрешимую задачу, но стараются облегчить жизнь.
Это не "нерешаемая задача", а "нерешаемая задача для модели управления памятью в Rust", которая прибита гвоздями к реализации, что согласитесь не одно и тоже.DDOS, это один из способов атаки на систему, и говорить, что в самом безопасном языке программирования мы игнорируем целый класс атак, потому что "это безопасно в рамках выбранной модели безопасности", просто нужно писать программы без ошибок, то точно так же можно сказать и про С/С++.
В модели ручного управления памятью в С/С++, отсутствует автоматическая проверка границ переполнения буфера ради обеспечения максимальной производительности. Если требуется безопасное управление памятью, нужно использовать сильные и слабые указатели и облегчить себе жизнь.
> Это не "нерешаемая задача", а "нерешаемая задача для модели управления памятью в
> Rust", которая прибита гвоздями к реализации, что согласитесь не одно и тоже.Это нерешаемая задача при ручном управлении памятью. Аналогично она не решена в си, с++, паскаль и других. Даже в ада не решена. Если вы считаете иначе - покажите пример такого языка.
> DDOS, это один из способов атаки на систему
Да, но DDOS безопаснее чем получение контроля над системой.
> в самом безопасном языке программирования мы игнорируем целый класс атак
Аж жЫр с монитора потек)) Вообще в расте игнорируются еще и логические ошибки. Просто потому, что на данный момент нет способа с ними автоматически бороться кроме как формальной верификацией. Часть ошибок можно обойти развитой системой типов раста, но в общем проблема не решена.
> В модели ручного управления памятью в С/С++, отсутствует автоматическая проверка границ
> переполнения буфераТак дело не в переполнении буфера, а последствиях этого действия.
В расте при выходе за границы массива будет паника и приложение таки упадет, правда с адекватным трейсом. А в сишечке - все что угодно вплоть до исполнения кода.> ради обеспечения максимальной производительности
В расте для этого есть итераторы, а борровинг будет гарантировать что массив не мутируют с соседнего потока.
Так не си, с++, паскаль, ада и другие языки не утверждают, что они самые классные и безопасные и нужно писать только на них, а весь остальной код выкинуть.Контроль циклических ссылок не обязательно должен быть завязан на язык программирования, например для С++ существуют варианты решения этой проблемы с помощью плагина для компилятора.
> Аж жЫр с монитора потек))
Проверь стул, может быть и он тоже намок )))
> Просто потому, что на данный момент нет способа с ними автоматически бороться кроме как формальной верификацией. Часть ошибок можно обойти развитой системой типов раста, но в общем проблема не решена.
Вот в том то и дело, что у Rust отсутствует формальная верификация безопасности для используемой системы типов (невозможно с помощью статического анализатора кода доказать корректность использования динамически выделяемых ссылок на структуры с редактируемыми внутренними ссылками).
> Так дело не в переполнении буфера, а последствиях этого действия.
Так используйте безопасные структуры данных, чтобы не было последствий. Зачем для этого менять весь стек разработки, если все это можно решить на уровне линтера и статического анализатора?
> они самые классные и безопасные и нужно писать только на них,
> а весь остальной код выкинуть.Ну так раст и безопаснее чем с и с++, даже без детектирования утечек.
И их как раз нужно выкинуть, а пользоваться безопасными языками))> например для С++ существуют варианты решения этой проблемы с помощью плагина
> для компилятора.Так это же не часть языка. При чем тут плагины?
> отсутствует формальная верификация безопасности для используемой системы типов (невозможно с помощью статического анализатора
> кода доказать корректность использования динамически выделяемых ссылок на структуры с
> редактируемыми внутренними ссылками).Прости, а где она есть? Ваши набросы просто смешны.
> Зачем для этого менять весь стек разработки, если все это можно решить на уровне
> линтера и статического анализатора?Да ну? А почему это до сих пор не сделано?
Почему практически в каждой сишной CVE проблема с типикал проблемами с память?
Может потому что "линтера и статического анализатора" недостаточно?))Вот сейчас плюсовики зашевелились на счет safe-c++. Потому что жим-жим))
> Вот сейчас плюсовики зашевелились на счет safe-c++. Потому что жим-жимНе нужно пересказывать свои фантазии насчет жим-жим :-)
safe-c++ никогда не был С++, это попытка перетащить бредовые идеи Rust в С++ синтаксис с нарушением обратной совместимости с фактическим это созданием нового диалекта языка - монстра. Поэтому ничего удивительного, что комитет по стандартизации отверг это предложение.
Memory leaks are memory safe. Это известный вывод из определения той безопасности, которую раст стремится обеспечить. Но непонятно как это относится к обсуждаемому вопросу касательно GC.
К GC это действительно не имеет никакого отношения. Но речь пошла уже не только об очистке мусора, а о безопасной работы с памятью в целом и не только на Rust.
> В этом и проблема, что чёткого общепринятого определения не существует. Поэтому в
> разных сообществах принято за GC считать разное. В сообществе языка D,
> например, принято сборщиком мусора считать счётчики ссылок.Я думаю, что в данных вопросах надо смотреть прежде всего на академические источники, а не на какие-то там сообщества. Посему базисом на сегодняшний день следует считать Garbage Collection Handbook за авторством Джонса-Хоскинга-Мосса. Там уже которое издание выходит, актуализируя вопросы сборки мусора. Сначала в 96м была книга, потом в 12м, и на сегодня самая актуальная версия -- 16го года.
Вот выдержка оттуда [1]:
Мусор -- это более не живущий объект, чьё пространство ещё не было возвращено [программе].
Сборка мусора -- это автоматический подход к управлению памятью, который возвращает память, занимаемую объектами, которые более не используются программой.
Сборщик мусора -- это системный компонент [программы], занимающийся сборкой мусора.Таким образом, RAII например не является сборкой мусора, поскольку данный подход отрабатывает в compile time и освобождает память объекта при выходе из окружения, в котором он использовался, и следовательно объект не успевает стать мусором.
А растовые RC и ARC не является сборщиками мусора, потому что они не являются системными компонентами программы, а подключаются разработчиком по необходимости для ограниченного количества объектов, за которыми требуется более глубокий контроль. Если бы это было не так, то банальный free в сях тоже пришлось бы рассматривать как сборщик мусора, что естественно чушь.
> На мой вопрос "что же это за сборщик мусора, который не может
> определить и дропнуть зацикленный в себя связный список "A -> B
> -> C -> A" если он уже ниоткуда не доступен -
> выдаются какие-то странные ответы.Ну дык, вот такой вот сборщик. Видишь ли, когда мы говорим о сборщиках, мы всегда понимаем, что это трейдофф между производительностью и разрастанием кучи. Когда Коллинз и Маккарти в 1960м озаботились этим вопросом, Маккарти (который кстати и является автором термина, см [2], стр 27) написал трассировочный сборщик, и таких проблем у него не было, да; а вот Коллинз создал ARC. И за следующие несколько десятилетий оба подхода стали использоваться в сборщиках мусора совместно, потому что ARC при некоторых хаках может работать довольно быстро, плюс он всяко быстрее, чем трассировочные алгоритмы, а значит он позволяет существенно сократить им поле работы до их запуска. Ну то бишь потому что оба способа предполагают разный трейдофф.
На самом деле ARC имеет куда больше проблем, чем циклы, и требует большого количества хаков, чтобы эти проблемы не становились слишком существенными. Так, например, он добавляет оверхед при передаче ссылки -- всякий раз, когда ты ссылку на объект передаёшь, тебе нужно инкрементить reference counter в куче. И так для всего. К тому же количество ссылок на объект может потенциально достигать количества объектов в куче, что приводит тебя к тому, что слот для каунтера тебе потребуется держать очень большой, а это -- ещё большее разрастание кучи. В общем, наивный подход тут не подходит, и к ARC-у нужны разнообразные примочки, чтобы он не добавлял слишком много оверхеда.
Суть таких примочек как правило сводится к отсрочке освобождения памяти тем или иным способом. И появляется дополнительный поток, который следит на регулярной основе за ссылками, производя рекламацию в положенное время.
Что касается циклов... Я понимаю твоё смущение, но оно по итогу формулируется следующим образом: "как алгоритм может являться частью сборки мусора, если он не освобождает всю память". Но обрати внимание, что про "всю" память речи в определениях не идёт. Да, у алгоритма есть ограничения, и они вот такие. Большую часть памяти он освобождает, но для освобождения остальных -- нужно что-то ещё. Так что тут как с сями -- нужен ручной контроль, но просто не за освобождением, а лишь за тем, чтобы циклов не создавать. Ну или твоя программа будет течь. Впрочем, в случае с Rust, течь не сильно, поскольку ты ж не всё помечаешь в Arc, а только небольшое количество объектов. Так что в целом, подход не так уж плох.
[1] https://github.com/sauravomar/ebooks/blob/master/The%20...
[2] https://www-formal.stanford.edu/jmc/recursive.pdfPS: фанбои-растоманы, учитесь, пока я жив ^^^ =)
RAII это аналог сборщика мусора т.к. деструкторы объектов на стеке автоматически вызываются при выходе оных из области видимости функции
Это не совсем аналог.GC никак не привязан к области видимости. Это отдельная функциональность не связанная с кодом программы. Но и про RAII нельзя говорить, что он работает "только во время компиляции". RAII может быть и во время выполнения (например, ресурс с shared_ptr, который можно скопировать или передать как аргумент в функцию), ведь у него подсчет ссылок всегда идет в рантайме.
> Это не сборщик мусора, это автоматический подсчет ссылокВоу-воу! Нифига себе заявы! =)
"Это не сборщик мусора, это просто один из алгоритмов сборки мусора"! =)
Ребят, не переопределяйте термины ради красивого словца. Если у вас есть подсчёт ссылок, значит у вас таки есть базовый GC.
То, что он базовый, и потому легковесный -- не отменяет того факта, что это всё-таки GC. ))
Сборщик мусора это механизм, который может использовать в т.ч. и информацию о количестве ссылок. А может и не использовать. Зависит от самого сборщика и принципов его работы.Говоря, что подсчёт ссылок и есть сборщик мусора ты расписываешься в неспособности строить даже базовые логические цепочки.
Дорогой, ARС -- это GC по определению. Тут не о чем спорить.PS: Я не участвую в холиворе за или против Rust. Я сейчас говорю исключительно за терминологию.
UPD: вечер! =)Короче, какое дело. Я тут из любопытства таки почитал про этот ваш растовый ARC подробнее, и изрядно удивился тому, что оказывается это не Automatic Reference Counter, а Atomic Reference Counter, и он вообще говоря работает несколько иначе, нежели обычный ARC: оказывается, он работает не для всего, а лишь для тех сущностей, за которыми разработчик сказал следить явно, не является обязательной частью рантайма, и скорее ведёт себя как модуль для управления памятью в многопоточном приложении. Такие дела.
Почему его называли ARC при этом, а не как-то иначе -- это конечно вопрос-вопрос, ну да ладно: всё-таки чужой монастырь. Тем не менее, в свете этого, я склонен согласиться с господами растоманами, что это не GC.
Однако, местным комментаторам хотелось бы сказать, что вы удивительно плохо аргументируете свои позиции, особенно с учётом того, что у вас переопределены общеупотребительные аббревиатуры. Простое указание на описанные мною факты -- могло бы сразу прояснить вопрос, да и было бы куда полезнее, чем вой про то, что все вокруг идиоты. =)
> Почему его называли ARC при этом, а не как-то иначе -- это конечно вопрос-вопрос, ну да ладно: всё-таки чужой монастырь. Тем не менее, в свете этого, я склонен согласиться с господами растоманами, что это не GC.Есть Rc<T> (T-с-подсчётом-ссылок), а есть Arc<T> (T-с-атомарным-подсчётом-ссылок)
Первый компилятор запрещает передавать между потоками (Потому что подсчёт не атомарный, а значит при передаче между потоками может быть data race), а второй можно, если T можно передавать между потоками
> Однако, местным комментаторам хотелось бы сказать, что вы удивительно плохо аргументируете
> свои позиции, особенно с учётом того, что у вас переопределены общеупотребительные
> аббревиатуры. Простое указание на описанные мною факты -- могло бы сразу
> прояснить вопрос, да и было бы куда полезнее, чем вой про
> то, что все вокруг идиоты. =)Да-да. "Не я дебил, что полез спорить не понимая предмета спора, а мне плохо объяснили, про что я спорить полез. Сами виноваты, в общем".
Как люди должны были догадаться, что ты что-то там не понял? Раз начал спорить, значит понимаешь о чём речь, либо трепло, а треплу что-то объяснять смысла нет.
> Как люди должны были догадаться, что ты что-то там не понял? Раз начал спорить, значит понимаешь о чём речь, либо трепло, а треплу что-то объяснять смысла нет.А: Это не двигатель, это просто коленвал.
Б: Как это просто коленвал, но без двигателя? Коленвал -- это часть двигателя.
А: Двигатель -- это просто механизм, вращающий вал. Он может использовать коленвал, а может и не использовать. Говоря, что наличие коленвала подразумевает наличие двигателя, ты расписываешься в том, что дypак.
Б: Ладно, я посмотрел и вижу, что вы к коленвалу педали прикрутили. Окей, я согласен, что это не двигатель. Но о том, что вы используете коленвал так -- надо предупреждать.
А: Раз рот открыл -- значит должен был знать. А раз не знал -- значит дypак! А дypакy что-то объяснять смысла нет!Прекрасная иллюстрация, Вы не находите? =)
Ты вот сейчас серьёзно приводишь в пример, где коленвал = двигатель и что-то доказать хочешь этим (помимо собственных сомнительных когнитивных сбособностей)? Часть механизма - это механизм? Вот прям ваще серьёзно? Может у тебя и печень - это человек? И процессор - это компьютер? Расплодились наркоманы чёртовы...
Понимаю Ваше затруднение, дорогой товарищ. Увы, но нам придётся принять тот факт, что не всем дано строить "базовые логические цепочки"! ;)
> Дорогой, ARС -- это GC по определению.Какое-то неправильное определение GC получается, раз такой "GC" не умеет самостоятельно определять и дропать замкнутый внутрь себя связный список "A -> B -> C -> A" если он стал более ниоткуда недоступен.
>> Дорогой, ARС -- это GC по определению.
> Какое-то неправильное определение GC получается, раз такой "GC" не умеет самостоятельно
> определять и дропать замкнутый внутрь себя связный список "A -> B
> -> C -> A" если он стал более ниоткуда недоступен.см #334, я там раскрыл это
Дорогой, если у тебя есть определение, которое заставляет называть одну вещь другой вещью, то либо определение говно, либо ты им не умеешь пользоваться.
А зачем их считать, если не секрет?
> А зачем их считать, если не секрет?Зачем-зачем. Чтобы мусор собрать, естественно, ибо для чего ещё может быть нужен ARC? =)
> Там есть персонажи, думающие, что в расте есть сборщик мусора.В расте и рантайма нет.
>> Там есть персонажи, думающие, что в расте есть сборщик мусора.
> В расте и рантайма нет.Ну как бэ да, нету. Минимальный рантайм там примерно в тех же объемах, как и в GCC
> GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp.Правда, это не останавливает местных Воителей от повторения чуши (видимо, по принципу "мы все так говорим, а значит это правда!").
а чушь в чем ?
они же не утверждают, что "вот руст с рантаймом, а божественный цэ - без".
факт в том, что рантайм есть.
> факт в том, что рантайм есть.И этот "факт" основывается на "мы все так говорим, а значит это правда!" -- на колу мочало, начинай сначала!
> тех же объемах, как и в GCC
> GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp.Причем тут язык Си? Это самодеятельность gcc при оптимизации, и не мешает собирать ядро линукс.
Банальныйй цикл for в rust - это вызов next у итератора. Это точно не про отсутствующий рантайм.
>> тех же объемах, как и в GCC
>> GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp.
> Причем тут язык Си? Это самодеятельность gcc при оптимизации, и не мешает
> собирать ядро линукс.И где там язык Си упоминался?
Сам придумал, сам опроверг.> Банальныйй цикл for в rust - это вызов next у итератора. Это точно не про отсутствующий рантайм.
О, теперь итератры стали "рантаймом" ...
Ну и да, че там за for было?
https://rust.godbolt.org/z/YKEs1EoMn
pub fn main() {
for n in 1..101 {
square(n)
}main:
push rbx
mov edi, 1
.LBB2_1:
lea ebx, [rdi + 1]
call example::square::h9a0e2fa1b9513288
mov edi, ebx
cmp ebx, 101
jne .LBB2_1
pop rbx
ret
> Сам придумал, сам опроверг.Аргумент с GCC придумал ты. Причем тут баги в оптимизаторе gcc.
> О, теперь итератры стали "рантаймом"
В расте нет рантайма.
По определению сообщества опеннет.> Ну и да, че там за for было?
> https://rust.godbolt.org/z/YKEs1EoMnСтарательно прописывал ключи оптимизации чтобы не видеть вызовы метотдов итератора и много чего из "отсутствующего рантайма"?
И ссылка на официальный документ
https://doc.rust-lang.org/reference/expressions/loop-expr.ht...
A for expression is a syntactic construct for looping over elements provided by an implementation of std::iter::IntoIterator.
> Старательно прописывал ключи оптимизации чтобы не видеть вызовы метотдов итератора и много чего из "отсутствующего рантайма"?Скажи спасибо "дырявому" llvm, что может оптимизировать вот это https://rust.godbolt.org/z/Gva3P6T7j (твой пример без ключей оптмизиации, чтобы увидеть "отсутствующий рантайм")
> Скажи спасибо "дырявому" llvm, что может оптимизировать вот это https://rust.godbolt.org/z/Gva3P6T7j
> (твой пример без ключей оптмизиации, чтобы увидеть "отсутствующий рантайм")Т.е. ты старательно убрал оптимизацию, получил дебаг-сборку-по-умолчанию и гордо киваешь на "лишнее" в генерированном бинарнике?
Кстати, ты опять придумал-приписал-мне про что-то "дырявый llvm", попутно метанизировав небольшой водоем. Потому что код оптимизируется еще до этого:
https://play.rust-lang.org/?version=nightly&mode=release&edi... (SHOW LLVM-IR)
bb3: ; preds = %start, %bb3
%iter.sroa.0.02 = phi i32 [ 1, %start ], [ %_9.0, %bb3 ]
%_9.0 = add nuw nsw i32 %iter.sroa.0.02, 1
; call playground::square
tail call fastcc void @_ZN10playground6square17haf375fd7efae74b5E(i32 noundef %iter.sroa.0.02)
%exitcond.not = icmp eq i32 %_9.0, 101
br i1 %exitcond.not, label %bb4, label %bb3В общем, скажу спасибо за демонстрацию "квалификации" классического опеннетного Воена Супротив Раста. Ты случайно не автор https://veresov.pro/rustmustdie/ ?
> Потому что код оптимизируется еще до этого:Ты уверен, что это до промежуточных оптимизаций, которые делаются посредством llvm?
Например, при генерации mir - вызовы итератора видны
Извини, онлайн-инстанс с этой возможностью я тебе поднимать не буду:
https://doc.rust-lang.org/rustc/codegen-options/index.html
> When combined with -O --emit llvm-ir, it can be used to see the optimized LLVM IR emitted by rustc before any optimizations are applied by LLVM.
% rustc -O -C no-prepopulate-passes --emit llvm-ir loop.rs
define internal void @_ZN4loop4main17h5179398e685bdaa7E() unnamed_addr #0 {
start:
%iter = alloca [4 x i8], align 4
%_2 = alloca [8 x i8], align 4
call void @llvm.lifetime.start.p0(i64 4, ptr %iter)
store i32 1, ptr %iter, align 4
br label %bb1
bb1: ; preds = %bb7, %start
call void @llvm.lifetime.start.p0(i64 8, ptr %_2)
%_6 = load i32, ptr %iter, align 4, !noundef !4
%_4 = icmp slt i32 %_6, 101
br i1 %_4, label %bb3, label %bb4
bb4: ; preds = %bb1
call void @llvm.lifetime.end.p0(i64 8, ptr %_2)
call void @llvm.lifetime.end.p0(i64 4, ptr %iter)
ret void
bb3: ; preds = %bb1
%_5 = load i32, ptr %iter, align 4, !noundef !4
%0 = call { i32, i1 } @llvm.sadd.with.overflow.i32(i32 %_5, i32 1)
%_9.0 = extractvalue { i32, i1 } %0, 0
%_9.1 = extractvalue { i32, i1 } %0, 1
%1 = call i1 @llvm.expect.i1(i1 %_9.1, i1 false)
br i1 %1, label %bb5, label %bb7
bb7: ; preds = %bb3
store i32 %_9.0, ptr %iter, align 4
%2 = getelementptr inbounds i8, ptr %_2, i64 4
store i32 %_5, ptr %2, align 4
store i32 1, ptr %_2, align 4
%3 = getelementptr inbounds i8, ptr %_2, i64 4
%n = load i32, ptr %3, align 4, !noundef !4
; call loop::square
call void @_ZN4loop6square17h2c210414671ffe58E(i32 noundef %n)
call void @llvm.lifetime.end.p0(i64 8, ptr %_2)
br label %bb1
Т.е. тот самый "рантайм итератора" на самом деле
%_6 = load i32, ptr %iter, align 4, !noundef !4
%_4 = icmp slt i32 %_6, 101
br i1 %_4, label %bb3, label %bb4
...
%_5 = load i32, ptr %iter, align 4, !noundef !4
%0 = call { i32, i1 } @llvm.sadd.with.overflow.i32(i32 %_5, i32 1)
> % rustc -O -C no-prepopulate-passes --emit llvm-ir loop.rsЮление продолжается. "Незаметно" поменял оптимизацию на '-O'.
Если вернуться к исходной оптимизации '-C opt-level=s' (оптимизация по размеру). Ты же смотрел этот выхлоп, но промолчал.
То внезапно llvm-ir-код сильно раздувается вызовами методов итератора. При этом асм-код после всех оптимизаций не отличается от оптимизации '-O'.С чего бы вдруг промежуточный код очень сильно раздувается при оптимизации по размеру? И это сильно подрывает доверие к "чистоте" оптимизатора руст. В общем, мне такой цирк не нравится. Признаю свое поражение. Успехов в войне.
>> % rustc -O -C no-prepopulate-passes --emit llvm-ir loop.rs
> Юление продолжается. "Незаметно" поменял оптимизацию на '-O'.
> Если вернуться к исходной оптимизации '-C opt-level=s' (оптимизация по размеру).
> остальное бла-бла поскипано.Начнем с того, что "исходная" на play.rust как раз -O и там нельзя (или я не понял как) задавать свои флаги, "оптимизация по размеру" была как раз для того, чтобы компилятор туда не напихал еще чего нибудь ... и пожалуй на этом и закончим, потому что ничего внятного (даже определения "рантайма") от тебя все равно не будет.
Будет опять вариация "нисчитаица, там рантайм! Если собрать в дебаг-сборку без оптимизаций, то его сразу видно" и куча фантазий на тему и "по мотивам" ...
>> Сам придумал, сам опроверг.
> Аргумент с GCC придумал ты. Причем тут баги в оптимизаторе gcc.Аргумент я не придумал, он есть - требование к freestanding. Те же самые требования есть и у шланга. А вот что это "баги" - лишь твоя фантазия.
>> О, теперь итератры стали "рантаймом"
> В расте нет рантайма.
> По определению сообщества опеннет.Ну сообщество какое-то определение предоставить не может, лишь невнятное обобщенное мямлянье, по "логике" которого и у сишечки, в реальности -- "всегда есть рантайм".
>> Ну и да, че там за for было?
>> https://rust.godbolt.org/z/YKEs1EoMn
> Старательно прописывал ключи оптимизации чтобы не видеть вызовы метотдов итератора и много чего из "отсутствующего рантайма"?Старательно убрал ключи оптимизации для тыканья носом опеннетчиков -- чтобы оно вообще не оптимизировало все там нафиг.
> И ссылка на официальный документ
> https://doc.rust-lang.org/reference/expressions/loop-expr.ht...
> A for expression is a syntactic construct for looping over elements provided
> by an implementation of std::iter::IntoIterator.Еще бы ты прочитал тот "официальный" документ, заметил бы, что это Trait, т.е. интерфейс/абстракция.
> Аргумент я не придумал, он есть - требование к freestanding.Это требование gcc.
В freestanding для Си не входит реализация <string.h>
Вызовы mem* - это следствие работы оптимизатора.До сих пор висит незакрытый баг 2013г. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Оптимизатор, если видит код (вручную написанный), похожий на реализацию memset, memcpy и тд, заменяет этот код на вызов встроенной реализации. При этом не помогают ни -ffreestanding, ни -fno-builtin. Помогает запрет оптимизации подобного кода -fno-tree-loop-distribute-patterns.> Еще бы ты прочитал тот "официальный" документ, заметил бы, что это Trait, т.е. интерфейс/абстракция.
И кто реализует этот интерфейс/абстракцию последовательности чисел 1..10?
1..10 - это языковая конструкция, которая генерирует реализацию интерфейса "итератор". Это тот самый код с вызовами методов итератора, который ты пытаешься спрятать оптимизацией (спасибо llvm). Без оптимизатора в rust резко становиться видным "отсутствующий рантайм".
>> Аргумент я не придумал, он есть - требование к freestanding.
> Это требование gcc.
> В freestanding для Си не входит реализация <string.h>
> Вызовы mem* - это следствие работы оптимизатора.Пошел юлеж вида "Чисто в теории этого нету! Вот!".
А практическая реализация тех самых, используемых в реальности для freestanding компилеров -- опеннетным теоретикам, конечно же не интересна.
> И кто реализует этот интерфейс/абстракцию последовательности чисел 1..10?Каждый тип, в том числе и примитивный, что "немножечко" систематичнее хаков реализации циклов в самом компиляторе (ну или вообще отсутствия итераторов), не?
> 1..10 - это языковая конструкция, которая генерирует реализацию интерфейса "итератор".
> Это тот самый код с вызовами методов итератора, который ты пытаешься
> спрятать оптимизацией (спасибо llvm). Без оптимизатора в rust резко становиться видным "отсутствующий рантайм".Это тот самый код с хайнтами "инлайн" и реализацией для последовательностей в примитивных типах вида:
https://doc.rust-lang.org/src/core/iter/range.rs.html#201
#[inline]unsafe fn forward_unchecked(start: Self, n: usize) -> Self {
// SAFETY: the caller has to guarantee that `start + n` doesn't overflow.
unsafe { start.unchecked_add(n as Self) }
}
который и превращается (причем, совсем без llvm, во что тебя уже ткнули носом выше) в
.LBB2_1:
lea ebx, [rdi + 1]
mov edi, ebx
...
cmp ebx, 101
jne .LBB2_1
так что и тут унылая демагогия и попытки натягивания совы (дебагсборки) на глобус - никак не влияют на реальность генерируемого кода.
> Пошел юлежНа себя посмотри "кексперт по расту".
До моего сообщения ты даже не знал семантику цикла for. Когда теба носом ткнули, что это всего лишь декорация над iterator.next() и для банального цикла над _примитивными_ целыми числами, генерится "отсутствующий рантайм" из вызовов методов неизвестной глубины.
> #[inline]
> ...
> который и превращается (причем, совсем без llvm, во что тебя уже ткнули носом выше) вТы не показал, что это оптимизируется без llvm. Ты показал просто промежуточный код, который вполне может быть после (некоторых) оптимизаций llvm. LLVM не запрещает делать оптимизации над llvm-ir (пошагово, разные оптимизации).
Зачем ты рандомно тыкаешь на исходники, которые тем более показывают глубину безопасТности "отстутствующего" рантама со своими unsafe на каждой строчке?
> На себя посмотри "кексперт по расту".
> До моего сообщения ты даже не знал семантику цикла for. Когда теба
> носом ткнули, что это всего лишь декорация над iterator.next() и дляКрутые и забористые фантазии. Правда, если проскроллить вверх, то можно прочесть что ты свою "мудрость" наваял сразу и одним комментом, типа "доказательства рантайма": "Банальныйй цикл for в rust - это вызов next у итератора. Это точно не про отсутствующий рантайм.".
Хотя внятно обосновать это ты не смог.> банального цикла над _примитивными_ целыми числами, генерится "отсутствующий рантайм"
> из вызовов методов неизвестной глубины.Опять пошли буйные фантазии, теперь о "глубинах" и "банальных циклах" (хотя это на самом деле итератор дипазана чисел). Правда, фантазии не бьются с реальностью (в которой вместо вызовов подставляется конкретная реализация для конкретного типа), но тем хуже для реальности, да?
> Зачем ты рандомно тыкаешь на исходники, которые тем более показывают глубину безопасТности "отстутствующего" рантама со своими unsafe на каждой строчке?Какой Воен да без спрыга на "unsafe" ...
Рандомно, говоришь?
Кексперд, ты те две строчки кода-то читал? Это и есть кусок реализации "банального цикла" для диапазона чисел, только не в виде "хака" на уровне компилятора, а в/на уровне самого ЯП, причем как побочка: для каждого типа данных и на любой вкус и цвет и с любыми ограничениями-проверками платформы (по той же ссылке там и реализация для Char, ага).
Вот конкретно для диапазона чисел
forward_unchecked(start: Self, n: usize) -> Self {
start.unchecked_add(n as Self)
т.е. i=i+_размер_шага_,
И все "глубины вызовов" на самом деле блок
impl<T: TrustedStep> RangeIteratorImpl for ops::Range<T> {#[inline]
fn spec_next(&mut self) -> Option<T> {
if self.start < self.end {
let old = self.start;
// SAFETY: just checked precondition
self.start = unsafe { Step::forward_unchecked(old, 1) };
Some(old)
} else {
None
}
}
который прекрасно оптимизируется - а чего б не, если это лишь набор примитивных операций над нативным типом данных.
Компиляторы, внезапно, уже лет цать как не "смущаются" от стат. вызовов методов хоть десятикратной вложенности, поэтому смысл экономии на спичках - доступен лишь некоторым, особо одаренным опеннетчикам (что-то где-то краем уха слышавшим, остальное додумавшим и дофантазировавшим в меру своего разумения).
>[оверквотинг удален]
> main:
> push
> rbx
> mov
> edi, 1
> .LBB2_1:
> lea
> ebx, [rdi + 1]
> call
> example::square::h9a0e2fa1b9513288...
>
Т.е. в dead code elimination эта штука не умеет? Оок! Сишный компилер вообще сделал бы чуть ли не гольный ret. Потому что...
1) Side effects у всего этого просто нет.
2) Вычисленное значение нигде и никак не используется.
> Т.е. в dead code elimination эта штука не умеет? Оок! Сишный компилер
> вообще сделал бы чуть ли не гольный ret. Потому что...
> 1) Side effects у всего этого просто нет.
> 2) Вычисленное значение нигде и никак не используется.Т.е. ты опять влез в обсуждение, даже не утрудившись пройти по ссылке (там "оптимизатор" выставлен в режим "size", чтобы не анроллил цикл нафиг) и почитать весь код? Оок!
Как раз сайд эффект вида
#[inline(never)]
fn square(num: i32) {
println!("{:?}", num * num);
}
там для того самого - чтобы показал, во что превращается цикл, без инлайна и прочего.
Выкинь принт, и оно тебе выдаст ассемблерный листинг
main:
ret
>Это для местных хейтеров. Там есть персонажи, думающие, что в расте есть сборщик мусорапричем тут эмоции к факту того что в расте есть *статический* гц? да внезапно статический garbage collector - тоже garbage collector
> в расте есть *статический* гцЭто не сборщик, это контролёр: если находит мусор, то программа не соберёться. И растоманы воюют с этим контролёрем: приходится прятать травку, ой, мусор более изощереннными методами, чтобы контролёр не нашёл. Так как без ... мусора полезных программ не существует (unsafe).
В новостях про GCC и LLVM вы так не пишете. 🤥
Но ведь tokio не в базе раста...
Когда ничего уникального нет приходится писать это в расчете на то что простачки поведутся.
ну вот 8% а говорили не нужен, в следующий ответ будет уже 16%
А через выпуск - 32% ?
💯
Дойдёте до 128% - разбудите.
146%
Спасибо за новый мем. Теперь если не хочется его называть, можно использовать 8%. На чем написана ... ой ... переписана программа? - На 8% же.
> Спасибо за новый мем. Теперь если не хочется его называть, можно использовать 8%. На чем написана ... ой ... переписана программа? - На 8% же.Плохой мем.
Придется циферки каждый год добалять."На 8% же"
--- вы находитесь здесь
"На 10% же"
"На том без чего не получается собрать ядро"
Когда там фурифокс перепишут на раст 100%?
> Когда там фурифокс перепишут на раст 100%?А собирались?
У ФФ 25% JavaScript и 15% HTML.
На что ты собрался их менять?
На Rust!!!
У них деньги на 12% закончаться такими темпами. Их спасёт только если МС их купит и сделает нормальный вариант Раста (нет).
> У них деньги на 12% закончаться
> деньги ... закончаться
> закончатьсяhttps://rustfoundation.org/members/
Ты, наверное, думал, что Rust до сих пор сидит на шее у Mozilla?
MS всё устраивает, она - платиновый спонсор.
Меня не устраивает синтаксис, какой то ассемблер. Сделайте Си подобный и я тогда начну читать его доки.
Да продолжай не читать, это всех устраивает.
тоже пытался читать этот туториал (доками назвать это вебдванольное недоразумение язык не поворачивается) - вывернуло от синтаксиса через пять минут
Просто ты любитель, профессионального разработчика редко когда смущают такие мелочи как синтаксис.
я таки профессионал, в отличие от тебя
Я с МС сто лет работаю и знаю зачем они становятся спонсорами.
Можете рассказать?
план гейтса
> ну вот 8% а говорили не нужен, в следующий ответ будет уже 16%Тащите WD40 - пригодится! А то все ржавеет и скрипит :)
> OsString::leakАхаха! Выкуисте, хейтеры Си! В вашем "безопасном" Расте даже специальные методы сделали, чтобы память текла. 🤣
Утечка памяти это нормально, они сами так пишут в растбуке))
Это они из плюсов взяли. Утечка ресурсов в неизвестном направлении по неизвестным причинам нежелательна только в си, где с этим можно бороться.
Ага, в расте есть специальный метод, позволяющий сделать строку с лайфтаймом ’static - которая будет существовать "всю жизнь программы".
И если ты потеряешь ссылку, то "внезапно" будет утечка.
Чтобы программер сразу знал об опасности, написали прямо в название.А в СИшке?
Достаточно сделать
int *ptr = (int *)malloc(sizeof(int));
и забыть сделать free - получи подарок)
А ты не делай. Лучше иди вон утечки в icu исправь.
Си морально устаревает, а конструкция его сложна для самих же сишников - постоянно у них проблемы с памятью.
Даже правительство США призывает отказаться от небезопасных языков.
> Опциональная поддержка Rust реализована в APT, QEMU (virtiofsd), ядре Linux и Mesa, а также ожидается в LibreOffice.А что будут делать те доблесные воины, которые на полном серьезе утверждали, что не допустят появления Раста на своих системах (типа будут пересобирать ядро и продолжать сидеть на старой сишной librsvg)?
Ну, в смысле, как быть, когда на Линуксе софта и так с гулькин нос - но даже в эти остатки пролезут метастазы Раста?
> А что будут делать те доблесные воины, которые на полном серьезе утверждалиКак это что?
Будут точно продолжать также утверждать!
Так тут есть куча народу, которые сидят на всяких ненужных бздях.
Плюс с(л|р)аководы и прочие маргиналы.Какое-то время они даже будут работать.
Я бы попросил! Я на illumos!
Будут пользоваться DragonflyBSD.
> не допустят появления Раста на своих системахЭти воины успокоятся, когда gccrs будет достаточно для сборки ядра или firefox. C++ в gcc в очень редких случаях отключают (для совсем уж embedded роутеров). Ну вот примерно также и с rust будет.
А тонна llvm примерно одинаковых версий, размазанных по всей системе, уже задолбала, если честно.
> Эти воины успокоятся, когда gccrs будет достаточно для сборки ядра или firefox.
> C++ в gcc в очень редких случаях отключают (для совсем уж
> embedded роутеров). Ну вот примерно также и с rust будет.Я себе ядра без всякого хруста билдую. Потому что на хрусте на данный момент там - полтора недопиленных драйвера. И зачем мне какой-то портитип драйвера нвидий "на 400 строк" в реальном кернеле? Вот чтобы что? Не, реально работать с видяхой ЭТО ессно не способно пока.
А мозилла с хрустом свое servo делала, делала, делала и ... уволила разработчииков, и проект на мороз выпихнула. И вот цать лет спустя оно даже пару страничек открывать вроде смогло. Правда все равно никому нахрен не упавшее.
Хороший язык! Этакий «трёхколёсный велосипед», который не даст неискушённому программисту упасть. Ну а для ассов IT как был, так и остаётся - Си.
> для ассов IT как был, так и остаётся - Си.Это называется "Си главного мозга". Особенно грустно на это смотреть, когда открываешь некий стандарт или спецификацию, а там описания структур в сишном стиле с этим уродским unsigned long int. Лечение комплексное, с принудительной изоляцией.
> Ну а для ассов IT как был, так и остаётся - Си.Ладно Линус, тоже необычно мягко для себя отзывающийся о Rust, так даже Грег Кроа-Хантер говорит, что Rust - дельная вещь для борьбы с ошибками, на Опеннете даже новость была. Если уж он, со столькими годами в ядре, не ас IT, то я уж не знаю кто для вас ас
pub fn all_false<const LEN: usize>() -> [bool; LEN] { [false; _] }Когда я вижу примеры программ, то не понимаю как Rust смог стать хоть соль–нибудь популярным. Вырвиглазно вырвиглазие какое–то.
> pub fn all_false<const LEN: usize>() -> [bool; LEN] { [false; _] }А что не понятно то? Какая-то подводная лодка публично облает выхлопом какую-то баржу. Видите, закорючками нарисовано.
> универсальное приложение на языке Rustrust-gpu - сила. Именно этот подход надо было продвигать в Bevy, а не ещё один яп WGSL. Но там у Карта свои тараканы.
> Представлен проект tmux-rs, развивающий клон мультиплексора терминала tmux (консольный оконный менеджер), переписанный с Си на Rust.типикал раст
Ещё более типикал тут вот что: "This project is alpha quality and has many known bugs. It's written in almost entirely unsafe Rust. Don't use it yet unless you're willing to deal with frequent crashes".
> has many known bugs. It's written in almost entirely unsafe RustДа как так-то!
> Отмечается, что в ветке Debian Unstable (Sid) около 8% src-пакетов в репозитории main связаны сборочными зависимостями как минимум с одним пакетом "librust-*"Спорный тезис. Скорее всего были учтены все or-зависимости, где предоставлялась альтернатива между c- и rust-утилитами, а потом прошли по дереву зависимостей дальше, и о чудо, у rust-утилит в зависимостях обнаружился librust-*. Вряд ли без подобных махинаций в подсчётах можно было бы получить 8%.
> Вряд ли без подобных махинаций в подсчётах можно было бы получить 8%.А в чем собственно махинация?
Раст-зависимость есть? Есть
С ней собрать можно? МожноВ чем тогда некорректность утверждения "связаны сборочными зависимостями как минимум с одним пакетом"?
Заодно это еще и знак что сишные or-зависимости можно деприкейтить.
> А в чем собственно махинация?Это стадия отрицания, прямо как в свое время "Линус не допустит Раста в ядре". Скоро будет принятие. 🥲
> А в чем собственно махинация?А в том, что...
> С ней собрать можно? Можно
...фактически пакеты собирались скорее всего без этих зависимостей...
> Заодно это еще и знак что сишные or-зависимости можно деприкейтить.
...и нет никаких гарантий, что при удалении сишных зависимостей они спокойно соберутся.
Искренне Ваш, Капитан Очевидность.
> ...фактически пакеты собирались скорее всего без этих зависимостей...
> ...и нет никаких гарантий, что при удалении сишных зависимостей они спокойно соберутся.Невероятно круто.
Но все равно, как это противоречит "связаны сборочными зависимостями как минимум с одним пакетом"?
> Но все равно, как это противоречит "связаны сборочными зависимостями как минимум с одним пакетом"?Формально -- не противоречит =)
А тезис спорный потому, что добавить в depends-ы вместо "x" какой-нибудь "x | x-rs" -- это тебе не мешки ворочать, и потому многие справедливо расценят заявления о 8%-й зависимости от rust-утилит как очковтирательство.
Стоит ли напоминать, что именно из-за таких вот вбросов rust-сообщество и заслужило себе дурную репутацию? Язык-то неплохой, но пиар просто жуть. )
в заголовке там аж "целый до^ц дебиан на 8 процентов зависит от раста".
я вообще подумала, что это о базовой системе.
а о пакетиках рассуждать.. это глупость та еще.
сегодня хаперленд добавили, завтра - выуинули - уже 7%. какая к черту разница, зачем это в заголовке и зачем это в принципе кто-то считал.
не хотят эти счетоводы долю цэ в пакетиках посчитать ?
лол, заголовок поменляи
Чёто конечно фанаты раста подсдулись. Да и развития у языка как такового нет.
Фанаты раста один раз написали безопасно и отдыхают. А дыряшечники в офисах по 16 часов дебажат свои границы буферов, вот почему их так много на опеннете и зависает.
> Фанаты раста один раз написали безопасно и отдыхаютА что они написали-то?) Последнее крупное событие было, что "драйвер на расте вот-вот почти уже совсем готов для реальной работы в ядре".
> А что они написали-то?)О, рад что ты спросил! (с)
Ты с каким смарфоном ходишь? Если не айфон - то в андроиде уже миллионы строк на расте.
Клоудфларя, майкрософт, AWS - они тоже используют раст.
uutils в Ubuntu (один из самых крутых дистрибутивов, который даже ставят на суперкомпы из топ500 и "ноуты с завода").Вчерашняя новость про "Релиз Mesa 25.2" в которой дыряшечный Clover выкинули и заменили на раст версию.
И это без упоминания всяких COSMIC, Niri, alacritty, regrep, fish и прочих.
> uutilsТак это не написали, а с Си переписали, что растовщики обычно и делают, с этого надо было начинать.
> с этого надо было начинать.Так с этого и начали)) И заодно избавились от гнураковой лицухи.
А теперь эти uutils добавляют в убунточку. Пока еще опционально))
Там оттестят, допишут недостающее, добавят пару несовместимостей с оригиналом...
ну и вы поняли))
> переписалиТут уточнение: "недопереписали".
> написалиу тебя 15 ошибок в слове "переписывают"
Я могу понять, что корпорациям и бизнесу раст, теоретически, удобнее и приятнее использовать может быть - потенциально меньше ошибок.Но программистам-то он чем может быть интересен?
Ведь самый смак программирования это как раз таки "небезопасное" программирование, где за написанный код отвечаешь целиком лишь сам программист. А это - Assm, C и с натяжкой C++.Подозреваю, что этим программистам в целом программирование не очень интересно, и они предпочитают, когда за них думает машина.
> Я могу понять, что корпорациям и бизнесу раст, теоретически, удобнее и приятнее использовать может быть - потенциально меньше ошибок.Пользователям, кстати, тоже - мне было не очень приятно услышать, что в моем браузере есть дыра, и уже существует эксплойт по взлому через открытие картинки на сайте.
> Но программистам-то он чем может быть интересен?
Скорость разработки. Уверенность в надежности своей программы.
Деньги в конце-концов: корпам нужно -> корпы платят.> Ведь самый смак программирования это как раз таки "небезопасное" программирование, где
> за написанный код отвечаешь целиком лишь сам программист. А это - Assm, C и с натяжкой C++.Это те, которые любят сидеть ночами и дебажить рандомный SIGABRT или порчу памяти?
Извини клуб BDSMщиков двумя этажами ниже (с)> Подозреваю, что этим программистам в целом программирование не очень интересно, и они предпочитают, когда за них думает машина.
Чего ты тогда не пишешь в чистых машинных кодах)?
И не считаешь на бумажке, вместо калькулятора.
Да и от автоматизации (скрипты и прочее) тоже стоит отказаться.И вообще - программирование, это и есть "когда за тебя думает машина"))
>Чего ты тогда не пишешь в чистых машинных кодах)?На ассме для души пишу периодически. Приятно.
А вообще ты сейчас бытаешься до абсурда довести мною сказанное.
Писать более менее комфортно на машинных кодах можно, разве что, 16-битное что-то под ДОС.
Всё, что выше, - унылая возня с форматом исполняемых файлов, которую, как раз таки, приятнее спустить на ассемблер и линкер.Да и дело ведь ещё не только в автоматизации, но и в сокрытии от тебя, как от программиста, низкоуровневых деталей.
Например, если пишешь для x86 на С, то единственный твой способ проверять на оверфлоу интов - монструозные конструкции из if-стейтментов. На чистом ассме x86 ты это можешь проверить одной инструкцией. На арме также, кстати. На риск процах, вот, тоже как на си надо извращаться.
Или ещё, например, написать функцию, которая принимает параметры через другие регистры, отличные от того как принято в соглашении о вызовах.
> На ассме для души пишу периодически. Приятно.
> А вообще ты сейчас бытаешься до абсурда довести мною сказанное.Хм... без обид, но я подумал, что это ты пытаешься довести до абсурда)
> Да и дело ведь ещё не только в автоматизации, но и в сокрытии от тебя, как от программиста, низкоуровневых деталей.
Ты пытаешься сделать 2 вещи:
1. натянуть свои привычки на всех программистов
2.попытаться продвинуть тезис что "Программисту" должны быть интересны какие-то низкоуровневые детали.Я ожидаю, что ты ответишь "Настоящему программисту они должны быть интересны".
Поэтому забегая вперед спрошу, ты реально знаешь как на низкому уровне работают все процессоры, под которые ты пишешь? Все особенности, errata для разных поколений и ревизий и тд?> Например, если пишешь для x86 на С, то единственный твой способ проверять на оверфлоу интов - монструозные конструкции из if-стейтментов.
Поэтому никто и не проверяется.
Но.. можно писать на расте и тоже не проверять! Зато кол-во CVE и бесполезных часов с дебагом бедет существенно меньше.> Или ещё, например, написать функцию, которая принимает параметры через другие регистры, отличные от того как принято в соглашении о вызовах.
Это типа инструкция, как отстрелить себе ногу?
Программисты бывают разные.
Кто-то хочет все контролировать, кого-то волнует конечный результат: готовая игра, научный алгоритм (привет питон!) или веб-страничка.
Грести всех под одну гребенку не очень конструктивно.
>попытаться продвинуть тезис что "Программисту" должны быть интересны какие-то низкоуровневые детали.Раст - язык системного программирования. Разве нет?
>Я ожидаю, что ты ответишь "Настоящему программисту они должны быть интересны".
Если пишешь системный код - да. Если нет - нет. Для веб-странички не нужно. Ну, разве что поверхностно, чтобы сильно много памяти не жрало.
>Поэтому забегая вперед спрошу, ты реально знаешь как на низкому уровне работают все процессоры, под которые ты пишешь? Все особенности, errata для разных поколений и ревизий и тд?
Естественно, всего не знаю, но стараюсь разобраться.
> Например, если пишешь для x86 на С, то единственный твой способ проверять на оверфлоу интов - монструозные конструкции из if-стейтментовОчевидно - ты не знаешь СИ.
Просвяти. Иных способов не знаю.
1. Опция есть для компилятора -fsanitize=undefined
2. Built-in Functions to Perform Arithmetic with Overflow Checking ( https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... )
> этим программистам в целом программирование не очень интересноВ этом и смысл! Действительно, на расте программировать не интересно и даже муторно, поэтому это можно делать только за деньги, свободные этим заниматься не будут. Корпорасты проталкивают раст, чтобы переписать на нём всё базовое СПО и таким образом выдавить свободных и взять открытые проекты под свой контроль. Вот такой у них план. Как говорится, "без шума и пыли".
> и таким образом выдавить свободныхА где эти свободные?
Вы не могли бы показать их вклад?
Напр. в ядро линукса?
Которое вот прям самое что ни на есть базовое СПО.
> А где эти свободные?Здесь, на Опеннете!
> Вы не могли бы показать их вклад?
Ну вот же он, в виде комментариев против Раста и гегемонии проклятых корпорастов!
> Напр. в ядро линукса?
В это гнездо корпорастов не один уважающий себя свободный не полезет! 😤 Только комментарии в Опеннете, сори.
> Здесь, на Опеннете!Вот оно чё, Михалыч! Спасибо что открыли глаза)
> Ну вот же он, в виде комментариев против Раста и гегемонии проклятых корпорастов!
Потрясающий, просто невероятнейший вклад в развитие ядра, линукса и СПО в целом.
Мне просто стыдно, что усомнился в деятельности свободных. Посыпаю голову пеплом.
> Корпорасты проталкивают раст, чтобы переписать на нём всё базовое СПО и таким образом выдавить свободных и взять открытые проекты под свой контрольАхаха! Ядро Линкс на 99.9% писалось сугубо "корпорастами" еще тогда, когда Раста на слуху не было. Какие "свободные", лол?
Почитай вот на досуге статистику, чтобы розовые очки наконец-то спали:
> Ахаха! Ядро Линкс на 99.9% писалось сугубо "корпорастами"Ну и что? Написали и написали, они действовали в рамках философии и по правилам СПО, предоставляя свой код и никак не нарушая экосистему. Но сейчас им в голову вдарило, будто за этот вклад у них есть какие-то права на открытые проекты, и они решили перестроить экосистему СПО в своих интересах, вот в чём отличие того, что было, от того, что сейчас.
> Ну и что? Написали и написали, они действовали в рамках философии и по правилам СПО,"правила"?
А можно их где-то почитать))?> будто за этот вклад у них есть какие-то права на открытые проекты,
У них нет прав и не может быть.
У них есть сами проекты. А, точнее, они и есть проекты)
Выкинь корпов из ядра и получишь ХУРД.> и они решили перестроить экосистему СПО в своих интересах,
Не просто решили, а вполне успешно перестраивают, несмотря на визги от васянов
> вот в чём отличие того, что было, от того, что сейчас.
LOL, ибм когда вкладывалась в ядро она сразу собиралась делать деньги.
Мелкомягкие чуть позже поняли, что лучше возглавить и направлять, а не-мамонты пусть работают.
> У них нет прав и не может бытьВот это здравая мысль! Так что ничего у них не получится, сообщество уже детектировало их поползновения по захвату свободных проектов с помощью ржавчины и скоро выроботает антиген, корпорасты останутся с носом! Будут сами корпеть над ничетаемым и мозгодробильным растовщическим кодом) Ржавые шестерёнки никогна нормально не завертятся!
>> У них нет прав и не может быть
> Вот это здравая мысль!Конечно, у них не может быть прав тк они и есть проект.
Это как рассказывать что у тела должны быть права шевелить пальцами> Так что ничего у них не получится,
Системд, вейланд, раст....
Уже получается)> сообщество уже детектировало их поползновения по захвату свободных проектов с помощью ржавчины и скоро выроботает антиген, корпорасты останутся с носом!
Судя по слогу ты троллишь. Надеюсь.
Пока сообщество выдает невнятные визги и сглатывает))
Причина тряски?))> выроботает
> ничетаемым
> никогнаЧел, успокойся, а то у тебя уже проверка архфаграфии отвалилась.
Не нужно принимать это так близко к сердцу.Ну вытеснят корпорасты васяно6оmжей, ну захватят они СПО проекты.
Будете сидеть на всякой маргинальщине вроле слаки, побираться на всяких форума в даркнете и кодом обмениваться.Не стоит оно того, чтобы так нервы себе портить. Они очень плохо восстанавливаются.
Лучше выйди на улицу, потрогай траву, посмотри на всех этих счастливых людей, которые живут и любят, даже не зная что такое спо и линукс.
> Причина тряски?))Ну некоторые вообще-то ещё и работают и пишут на опеннет урывками, а не целый день по методичке за зарплату)
> Ну некоторые вообще-то ещё и работают и пишут на опеннет урывками, а
> не целый день по методичке за зарплату)Ахаха! Т.е. ты еще и в рабочее время сюда раст хейтить приходишь!
Казалось бы, дно было достигнуто, но тут ты его пробил еще глубже.
Смотри чтобы тебя не уволили))> а не целый день по методичке за зарплату)
Или у кого-то отпуск))
> Действительно, на расте программировать не интересно и даже муторноRust - мультипарадигменный язык, на нём можно программировать даже в стиле дыряшки.
В случае с Си альтернативного подходу к программированию нет.
> Я могу понять, что корпорациям и бизнесу раст, теоретически, удобнее и приятнее использовать может быть
> Но программистам-то он чем может быть интересен?Программистам он интересен тем, что надо что-то жрать, ведь деньги на жратву программист получает сугубо от работы на те самые корпорации и бизнес.
Вакансий по расту в данный момент решительно меньше вакансий на С и C++. Иногда можно и на ассме найти что-то.
А плюсовикам опытным и платят весьма неплохо.
> Вакансий по расту в данный момент решительно меньше вакансийА при чем тут "данный момент"? Видишь ли, некоторые смотрят чуть дальше своего носа и планируют профессиональное будущее наперед.
Как высокомерно.Видишь ли, мой юнный друг, "данный момент" в рамках языков программирования, исчиляется десятками лет. Учитывая, что речь о языках, очень плотно проникших в инфраструктуру, то речь где-то о 5-6 десятках.
Переписывание грепа и судо на расте это никак не изменит.
И даже переписывание ядра на расте это сильно не изменит.
> Видишь ли, мой юнный друг, "данный момент" в рамках языков программирования, исчиляется десятками лет. Учитывая, что речь о языках, очень плотно проникших в инфраструктуру, то речь где-то о 5-6 десятках.Так для раста десяток лет уже прошел.
Плюс сейчас все происходит быстрее.
Ты посмотри, когда представле голанг и как быстро он вошел в индустрию.
Достаточно одной-дух крупных компаний, чтобы начали появляться вакансии -> начали появлять учебники и курсы -> язык уже прочно внедрен.> Переписывание грепа и судо на расте это никак не изменит.
> И даже переписывание ядра на расте это сильно не изменит."не изменит" - это твое мнение, оно настолько очень ценное, ну прям ваще.
То что сейчас Mesa уже не собирается без ржавого это разве не изменение?
То что у гугла в AOSP миллионы строк кода у миллионов юзеров это не изменение?Рим строился не за один день, так и тут.
Вангую взрывной рост кол-ва проектов, в ближайшие лет 5.
Если не будет 🍄 вoйны)
> данный момент" в рамках языков программирования, исчиляется десятками лет. Учитывая, что речь о языках, очень плотно проникших в инфраструктуру, то речь где-то о 5-6 десятках.Правильно. В каких годах вышли C и C++ ты, надеюсь, знаешь? Посчитай, сколько десятков уже набралось :)
Плюс, не вся разработка ПО - это выгребание легаси конюшен.
Я так и не понял, как твои слова противоречат моему аргументу о профессиональном будущем. Позоже, у тебя какая-то стадия отрицания уже 😂
>Посчитай, сколько десятков уже набралось :)Я ещё там кое-что писал про языки, которые плотно пролезли в инфраструктуру. Перепрочитай.
И попробуй посчитай кол-во проектов, написанных на тех же плюсах.
Не сможешь все их пересчитать, потому что их дохренища. Ещё долго не вымрут.>Плюс, не вся разработка ПО - это выгребание легаси конюшен.
Большая часть разработки - это как раз таки легаси. Сколько времени уходит на запуск проекта, и сколько на его поддержание?
> Ещё долго не вымрут.Я тебе еще раз повторяю: вопрос не "когда?", а "что потом?".
> Не сможешь все их пересчитать, потому что их дохренища. Ещё долго не вымрут
> Большая часть разработки - это как раз таки легасиЯ вот одного не пойму: если ты так уверен, что плюсовое легаси всех прокормят даже через 20-30 лет, то чего ты так трясешься от Раста?
Казалось бы, настоящим программстам фиолетово: ну, платили деньги за плюсы - теперь будут платить за Раст (предметные области-то те же). А вот твои слова выглядят как попытки самоуспокоения и отрицания.
Изначальный мой пост - вопрос, зачем раст нужен программистам, если то же самое можно делать на уже существующих языках программирования, которые с нами останутся ещё надолго.
Изучение нового языка, привычка к нему и связанными с ним тулзами - это ведь время. Время, которое можно потратить на укрепление уже существующий знаний, например.И не надо играть в диванного психотерапевта и искать тряску и отрицание в сообщениях собеседника. Так делают только малолетние дурачки с двачей.
> Изначальный мой пост - вопрос, зачем раст нужен программистам, если то же
> самое можно делать на уже существующих языках программированиРазве?
Код на расте получается менее дырявым, отваливается куча ошибок по памяти.
Т.е "то же самое" это не совсем правда.> которые с нами останутся ещё надолго.
Которые уже старается не использовать крупные компании.
> Изучение нового языка, привычка к нему и связанными с ним тулзами - это ведь время.
Конечно. Но программистам нужно развиваться.
Думаю такие же аргументы были, когда появился С++.> Время, которое можно потратить на укрепление уже существующий знаний, например.
Можно.
Но есть шанс что "профессиональный настройщик карбюраторов для жигулей" в один не-прекрасный день обнаруживает себя на обочине жизни и смотрит как поезд прогресса уходит вдаль.
> Изначальный мой пост - вопрос, зачем раст нужен программистам, если то же
> самое можно делать на уже существующих языках программирования,В том то и дело что нельзя. За 40+ не научились писать недырявые сишные программы.
С с++ ситуация лучше, но не слишком. И у них в коммитете как раз сейчас сраз про safe-c++.
А мир за это время успел сильно измениться.> которые с нами останутся ещё надолго.
А вот "на сколько сильно" зависит от конкурентов. Сделаем все чтобы сократить этот срок)
> Изучение нового языка, привычка к нему и связанными с ним тулзами -
> это ведь время. Время, которое можно потратить на укрепление уже существующий
> знаний, например.Люди уже 30+ улучшают. И что, сильно помолго?))
> вопрос, зачем раст нужен программистам, если то же самое можно делать на уже существующих языках программированияВозможно, у программистов (в часности, на C++) есть некий опыт, из-за которого они будут не согласны с таким утверждением? Этого ты не допускаешь?
И, возможно, непонятным для тебя вещам есть другие объяснения кроме как "они просто дураки"?
> И не надо играть в диванного психотерапевта и искать тряску и отрицание в сообщениях собеседника
А мне их и не надо искать - они есть суть твоих сообщений.
>Возможно, у программистов (в часности, на C++) есть некий опыт, из-за которого они будут не согласны с таким утверждением? Этого ты не допускаешь?
>И, возможно, непонятным для тебя вещам есть другие объяснения кроме как "они просто дураки"?Так, может быть, я для этого и задался этим вопросом, нет?
Разумный ответ, правда, из всей этой нити, был только от одного юзера - в самом начале.А по поводу того, что недырявые программы на С и С++ не научились писать за это время - глупости. Не, если, конечно, смотреть только на опенсорс, то да, действительно, видимо не научились. Просто софт опенсорсом не заканчивается.
> Так, может быть, я для этого и задался этим вопросом, нет?Не разводи цирк, пожалуйста. Ты не "задавался вопросом", а через риторический вопрос заявил, что Раст не нужен т.к. в других языках (C++) можно делать все то же самое.
Да, я именно так и считаю. Но это не значит, что я не поглядываю в сторону раста. Поглядываю.
Просто, не хочу изучать технологию, только из-за её маркетинга. Обычно-то технологии "побеждают" не потому, что их хорошо рекламируют, а потому что они удобны и полезны.
Хотя, конечно, есть и контр-примеры.Поэтому и интересует мнение других программистов.
Правда, этим программистам почему-то интереснее натягивать сову на глобус, преувеличивать и обвинять друг дружку в тряске.
> А по поводу того, что недырявые программы на С и С++ не научились писать за это время - глупости. Не, если, конечно, смотреть только на опенсорс, то да, действительно, видимо не научились. Просто софт опенсорсом не заканчивается.Звучит не убедительно.
В качестве контраргумента приведу
opennet.ru/opennews/art.shtml?num=62110"Сетевое хранилище Synology DiskStation DS1823xs+. 4 успешных взлома c использованием уязвимостей, связанных с некорректной обработкой аргументов, записью за пределы выделенного буфера..."
"Принтер Canon imageCLASS MF656Cdw. Три успешных взлома c использованием уязвимостей, связанных с переполнением стека."
"Камера видеонаблюдения Lorex 2K WiFi. 5 успешных взломов c использованием уязвимостей, связанных с переполнением буфера и разыменованием указателя."Думаешь там был опенсорсный код)?
А ведь есть еще автомобили - opennet.ru/opennews/art.shtml?num=62614
Там тоже не весело.
> Вакансий по расту в данный момент решительно меньше вакансий на С и C++.А вот на жабаскрипте и ПХП вакансий просто море)
Я это рассматриваю как большой плюс - мало конкуренции, те кому нужны раст программеры готовы платить выше чем по рынку.
> А плюсовикам опытным и платят весьма неплохо.
Любому опытному платят хорошо, даже сварщику.
Но через пару-тройку лет у меня уже будет +2-3 года к опыту написания на расте, а у тех кро решит вкатиться - нет)
Как думаешь кому предложат большую вилку зарплаты?ps именно по этому я стараюсь отговаривать людей писать на расте и вообще пробовать.
и тут мне на помощь приходят аргументы растохейтеров)
> Но через пару-тройку лет у меня уже будет +2-3 года к опыту написания на расте, а у тех кро решит вкатиться - нет)
> Как думаешь кому предложат большую вилку зарплаты?Тому у кого будет опыт работы на языках, которые будут использоваться через 2-3 года. Раст тихо плачет в сторонке.
> Тому у кого будет опыт работы на языках, которые будут использоваться через 2-3 года.Т.е не "дырявые ЯП" против которых выступает правительство США?
> Раст тихо плачет в сторонке.
От смеха)
>А вот на жабаскрипте и ПХП вакансий просто море)Некоректно сравнивать пхп и раст. Совершенно разные языки для разных задач.
В остальном - удачи.
>Но через пару-тройку лет у меня уже будет +2-3 года к опыту написания на расте, а у тех кро >решит вкатиться - нет)
>Как думаешь кому предложат большую вилку зарплаты?тому, кто всё это время тренировал ответы на бихэвиорал вопросы.
а технологии всегда вторичны, можешь алго задачки решать на разных языках.
конторы, которые требуют знания конкретных библиотек и языков платят мало, это первый признак жмотов.
ты лжёшь с первого предложения, дальнейшие манипуляции читать нет смысла
> Но программистам-то он чем может быть интересен?Деньгами, которые «корпорации и бизнес» платят за разработку. Но это про любой язык правда. Что там программист делает под одеялом^W^Wу себя на локалхосте интересно только самому программисту и его кошке. Программирование ради программирования оставьте олимпиадникам. Люди взрослые и прагматичные пишут на том, за что платят.
> интересно только самому программисту и его кошке.На счет последней есть огромные сомнения.
А вот чтобы раб хорошо зарабатывал на премиум корм... вот в этом заинтересованность точно есть.> Программирование ради программирования оставьте олимпиадникам.
Да ладно, нормальное хобби, не хуже многих других.
Ты городишь несусветную чушь - будто все корпорасты разом решили "давайте испортим жизнь прогерам и выберем самый бестолковый и непопулярный язык!". Коропорация ПЕРВАЯ кто заинтересован в самом массовом И УДОБНОМ языке, на который найдётся не меньше сотни вакансий даже в Гваделупе. Раст в этом плане - обочечная лошадь, которую пинают, суют во все соревнования, но она всё равно приходит последней. КТО будет вваливать бабки в заведомое корыто??
Перестань, единственная мечта корпораций всегда была чтобы софт писать могли дворники и повара, а не платить стотыщ специалистам. Взять тот же Кобол и иже с ними. Каждый язык, что появляется, сулит корпам это, в надежде продаться и уехать отдыхать на Гаваи на гонорар.
> Изначальный мой пост - вопрос, зачем раст нужен программистам, если то же
> самое можно делать на уже существующих языках программированияПрограммисты - народ подневольный, на чём прикажут - на том и пишут.
А если посмотреть глобально - любой язык программирования связан с финансовыми интересами какой-либо компании. Если говорить конкретно про Rust, то эта компания, в первую очередь, - Google. Деньги она делает на услугах, сопутствующих Rust'у. Как до этого она делала (и сейчас тоже) деньги на Go.
>>за написанный код отвечаешь целиком лишь сам программист. А это - Assm, CАга, это сейчас, воюя в комментариях, вы так говорите. А когда баг в программе превращается в повреждённое оборудование, в убытки в десятки тысяч долларов или массовый взлом с кражей данных, вас хвать за жoпу, так сразу: "кхм.. пук... ну понимаете... софта без багов не бывает... а 70% багов по статистике это небезопасная работа с памятью..." и прочие отмазки, всё валите на свой любимый язычок, пытаясь убедить, что баги - это нормально. Сколько программистов в мире садятся в тюрьму за свои бэкдоры? Да всех случаев за всё время можно по пальцам пересчитать, ибо а натуре хрен ваши намеренные бекдоры для судебной экспертизы выглядят как "случайные баги"
>Отмечается, что в ветке Debian Unstable (Sid) около 8% src-пакетов в репозитории main связаны сборочными зависимостями как минимум с одним пакетом "librust-*".Это абсолютно ужасно. Cargo - это помойка. Достаточно одной из из зависимостей быть скомпрометированной - и у нас абсолютно все пакеты окажутся инфицированы вирусом. И будет так: есть 2 стула. На одном ты бутстрапишь всю экосистему с древнейших версий (потому что современные потребуют зависимости, неинфицированных версий которых у тебя нет). А на другом просто терпишь малварь всю оставшуюся жизнь. Неплохой выбор кстати: ты и так будешь терпеть малварь, так как АНБ будет ломать всех и вся очень успешно, так как у них есть доступ к нецензурированной GPT-5, а тебе фиг.
Оставлю маленький коммент. На будущее.Когда-то в 2010ых в одной большой стране собрался один конгресс, да и поднял вопрос о хакерстве и уязвимостях. Долго ли, коротко ли, захотели они принять закон о криминальной ответственности за дыры в софте. Однако, здравый смысл, всё же, победил. Но в одно зловещее агентство было направлено поручение о разработке инициативы по затыканию этих самых дыр к следующему обсуждению этого вопроса через 10, 20 лет...
И вот, откуда ни возьмись - всплывает из мутных глубин (тех же примерно, что и бтц) инициатива по созданию нового ЯП, который бы не давал криворуким писунам писать криворукий код, с UB и дырами. Вскоре мир услышал слово "Раст". Сперва - тихо, затем громче. Потому что иниицатива была бы пустой, если бы не подразумевала принуждения. И понеслись потоки безумия. По началу, конечно, устои бородатых программистов было не сломить. Но в соседнем отделе предложили дёрнуть раскрашенный в неопределённые цвета рычажок, и вскоре - модные громкие меньшинства, необезображенные наличием критического мышления молодчики, тянущиеся к нетрадиционным экспериментам студенты, не совсем безвозмездные блоггеры и прочая б@гемная публика начала раздувать огонёк из гнилушек в пламя, которое начало жечь пятки не самым независимым программистам и держателей дистрибутивов. Хайп, вэйп, вайп. И немножко давления. И вот - уже оно в ядре.
И на носу 2030ый и новый съезд заинтересованных. Ошибки ведь нельзя запретить? Да нет, это в прошлом.
Не переживай, Rust это всего лишь маркетинговый ЯП, который случайно поймал хайпе на теме безопасности, но не имеющий под собой ни теоретической основы, ни ключевых преимуществ, которые бы нельзя было реализовать на других языках.Тот же самый С++ с помощью профилей превращается в точно такой же безопасный ЯП для работы с памятью, но с сохранением обратной совместимости и без необходимости переписывать на новом гламурном языке мегатонны кода.
Это тоже на будущее :-)
Случайностей в таких масштабах не бывает...> Это тоже на будущее :-)
Это не на будущее, и не на настоящее. Это навсегда! 8)
> Это не на будущее, и не на настоящее. Это навсегда! 8)Даже сталь ржавеет, что уж говорить об IT… Rust - это предсмертный язык уходящей эпохи традиционных архитектур компьютеров фон Неймана. Будущее - это кванты и нейросети, это будут совсем другие технологии и методы программирования.
Надеюсь, что нет.
Место детерминированным алгоритмам останется всегда.
> Случайностей в таких масштабах не бывает...это называется маркетинг, загугли на досуге
> Rust это всего лишь маркетинговый ЯПЯ знаю о процедурных, объектно-ориентированных, функциональных, мультипарадигменных языках программирования. Что означает этот новояз?
> который случайно поймал хайпе на теме безопасности
И больше десяти лет это всё как бы случайно длится? Причём "хайп" подхватили конторы-лидеры планеты по разработке ПО? 🤦♂️
> но не имеющий под собой ни теоретической основы, ни ключевых преимуществ, которые бы нельзя было реализовать на других языках
До Rust подобных языков не было, чтобы всё было под одной крышей - и абстракции с околонулевой стоимостью, и безопасная работа с памятью, и поддержка афинных типов, и обеспечение совместимости за счёт редакций даже при ломании некоторых языковых конструкций, и удобнейшая инфраструктура. А так, чисто теоретически, конечно, можно создать язык, ни в чём не уступающий Rust.
> Тот же самый С++ с помощью профилей превращается в точно такой же безопасный ЯП для работы с памятью
Почему же до сих пор не превратился в точно такой же? Почему до сих пор в коде на C++ находятся банальнейшие ошибки по работе с памятью? Снова программисты не те?
> Я знаю о процедурных ...Поздравляю, теперь вы знаете, что язык программирования еще может не иметь каких либо фундаментальных преимуществ перед другими, но позиционировать себя таковым.
> Причём "хайп" подхватили конторы-лидеры планеты по разработке ПО?
Ориентация на вопросы безопасности, это один из этапов развития любой технологии на определенном этапе своего развития. Поэтому не льстите себе, отнюдь не Rust является причиной хайпа.
> До Rust подобных языков не было ...
Я уже писал, что ничего уникального в этом нет и все это присутствует или реализуется в других языках. На Rust десять лет (точнее 5-7 лет) никто не обращал особого внимания по обозначенным выше причинам (что все это есть в других языках), и только после поднятия вопросов безопасности обратили на него внимание из-за маркетинговой шумихи и истеричного сообщества.
> Почему же до сих пор не превратился в точно такой же?
Потому что требуется обеспечение обратной совместимости с ранее написанным кодом (сейчас планируется добавить фичи безопасности в С++26 стандарт). Ведь никто в здравом уме не будет переписывать работающие исходники из-за того, что разработчики языка столкнувшись с очередной проблемой решили сломать обратную совместимость для поддержки новой фичи в языке или библиотеке.
> Тот же самый С++ с помощью профилей превращается в точно такой же безопасный ЯП для работы с памятьюНе превращается. Без вменяемой, _compile-time_ move-семантики он никогда не станет таким же безопасным ЯП для работы с памятью. Без лайфтамов в декларациях он может достичь того же уровня безопасности только уходя от локального анализа кода к анализу всего call tree для каждой функции, но проблема останова будет бить по яйцам за такое.
Потенциально возможно затолкать в C++ и лайфтаймы, и вменяемую move семантику, но тогда код на этом C++ станет несовместим с кодом на любом другом C++. То есть даже стандартную библиотеку C++ тебе придётся использовать, заворачивая в unsafe, и самостоятельно доказывая те гарантии, которые по задумке должен доказывать твой профиль.
Паника Страуструпа и его хаотические метания с профилями не смогут сделать из Rust из C++. Он туфтой занимается. C++ превращается в legacy язык, его нишу разъедают со всех сторон Rust и Go, и Страуструпу следовало бы не биться в истерике, а принять складывающуюся реальность, и заняться полировкой существующего C++. Можно было бы попробовать в interoperability, скажем стандартизовать ABI для C++.
> но проблема останова будет бить по яйцам за такое.Она бьет по яйцам только в концепции Rust, так как основана на идее "контроля заимствования", которая как раз и требует анализа всего стека вызовов при переходе владения. Но кто сказал, что это единственно верная концепция безопасного управления памятью?
> Потенциально возможно затолкать в C++ и лайфтаймы ...
Зачем делать Rust из С++? Изначально требуется внятно описать саму концепцию безопасного управления, и только после этого можно делать какие-либо изменения в семантике или добавлять новые атрибуты.
> ... не смогут сделать из Rust из C++
И слава богу, так как концепция управления памятью в Rust не полная (она не может гарантировать безопасную работу с памятью в некоторых сценариях), а раз нет возможности обойтись без unsafe кода, то сперва нужно доработать теорию и только потом переходить к её реализации в одном из основных языков программирования.
> кто сказал, что это единственно верная концепция безопасного управления памятью?Я тебе раскрою секрет: статические гарантии безопасного управления памятью -- это проблема останова. Раст эту проблему обходит на кривой, ограничивая класс программ, которые можно написать на safe-подмножестве языка.
> Изначально требуется внятно описать саму концепцию безопасного управления
Ну опиши мне эту концепцию, как её задумал Страуструп.
> сперва нужно доработать теорию и только потом переходить к её реализации в одном из основных языков программирования.
Ты не доработаешь её, потому что проблема останова. Я готов допустить, что можно иначе ограничить класс программ, которые возможно написать на языке, и получить возможность на этом классе доказывать безопасность статически. Но для общего случая ты ничего не докажешь. А это значит, что какую бы концепцию ты не напридумывал бы совместно со Страуструпом, тебе придётся подпирать её либо костылём unsafe, либо костылём рантайм проверок, либо и тем и другим. Последний вариант наиболее вероятен.
> Оставлю маленький коммент. На будущее.Типа предсказателем себя возомнил? Хочешь переплюнуть Вангу?
Если хочешь, то давай сформулируй нам на будущее критерий, фальсифицирующий твоё предсказание. Вот допустим гипотетически, что Rust - это не заговор, но популярность его продолжит расти ещё лет 20, до уровня когда 30% кода в дебиане будет на расте. При таких допущениях, по каким признакам мы сможем определить, что Rust это не заговор?
Спорим, что у тебя нет таких признаков? Твоё предсказание сформулировано в лучших традициях теорий заговоров, оно нефальсифицируемо. Что бы не произошло, любое вообразоимое и невообразимое событие можно объяснить в рамках твоей теории заговора.
Так что Вангу тебе не переплюнуть, у той хотя бы стиль был своеобразный, но у тебя никакой оригинальности, обычный заговоротеоретик, коих в интернете миллиарды.
Вообще-то это апологеты Rust не горят желанием представлять доказательства своего величия, тогда как я написал всего про два факта:1. У Rust отсутствует внятно сформулированная теоретическая основа безопасной работы с памятью, т.е. хотя бы банальный список выполняемых проверок в компиляторе, которые обеспечивают "доказательную безопасность". Их нет, и кстати их и быть не может, так как изначальная концепция не покрывает некоторые алгоритмы работы с памятью в безопасном режиме (т.е. без использования unsafe).
Именно поэтому разработчикам приходится придумывать новые библиотечные классы, так как их пришлось добавлять для реализации новых сценариев работы, которые вылезли уже после выхода языка и отсутствовали в изначальной концепции. Либо вообще признаваться, что "это сделать невозможно, поэтому мы не будет считать такое поведение ошибкой" (https://doc.rust-lang.org/book/ch15-06-reference-cycles.html)
2. С чего вы решили, что Rust является единственным ЯП, который озаботился безопасной работой с памятью? Java и даже Ada так или иначе пытались решать данные вопросы. У С++ так же есть подвижки в этом направлении.
Поэтому тут нет никакой теории заговора против Rust. Его разработчики молодцы, что подняли идею безопасности на первый план, но они забыли про множество других вопросов (удобство, обратная совместимость и пр.)
> 1. У Rust отсутствует внятно сформулированная теоретическая основа безопасной работы с
> памятьюЭто не так.
"Crust: A bounded verifier for Rust" alastairreid.github.io/RelatedWork/papers/toman:ase:2015/
"Stacked Borrows: An Aliasing Model for Rust" plv.mpi-sws.org/rustbelt/stacked-borrows/paper.pdf
"Leveraging Rust types for modular specification and verification"
alastairreid.github.io/RelatedWork/papers/astrauskas:oopsla:2019/Плюс часть идей были взяты из Cyclone
"Region-Based Memory Management in Cyclone" cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf
"Safe Manual Memory Management in Cyclone" cs.umd.edu/projects/PL/cyclone/scp.pdf
https://rustc-dev-guide.rust-lang.org/appendix/bibliography....> хотя бы банальный список выполняемых проверок в компиляторе, которые
> обеспечивают "доказательную безопасность".Вообще-то правила "доступа" к памяти четко определены.
Each value in Rust has an owner.
There can only be one owner at a time.
When the owner goes out of scope, the value will be dropped.At any given time, you can have either one mutable reference or any number of immutable references.
References must always be valid.> Их нет, и кстати их и быть не может, так как изначальная концепция
> не покрывает некоторые алгоритмы работы с
> памятью в безопасном режиме (т.е. без использования unsafe).Примеры в студию.
> Либо вообще признаваться, что "это сделать невозможно, поэтому мы не будет считать такое поведение ошибкой" (https://doc.rust-lang.org/book/ch15-06-reference-cycles.html)
В этом нет ничего постыдного. Назовите другой ЯП без GC с решенной проблемой Reference Cycles. Да и оно укладывается в модель безопасности раста - утечки не портят память.
> Java и даже Ada
JAVA вообще мимо, с ее то жирнючим рантаймом. А под Ada наверное имеется в виду Ada Spark, безопасное подмножество Ada.
> так или иначе пытались решать данные вопросы.
И как? Хорошо получилось? Теперь нас окружают сплошные безопасные программы :) ?
> У С++ так же есть подвижки в этом направлении.
Угу, комитет раскололся на два враждующих лагеря))
> но они забыли про множество других вопросов (удобство, обратная совместимость и пр.)
Как раз раст уделяет огромного внимание удобству и обратной совместимости.
Идея с edition оказалась просто шикарной. Она позволяет как легко добавлять новое в mainline, так и оставаться стабильной в рамках edition и выбрасывать неудачные решения между ними.Это все позволило расту получить сертификацию для автомотив, медицины и других критиченых областей применения.
> Это не так ...Я видел эти документы, а вы сами их читали? В них приводится доказательства с учетом некоторых ограничениях корректной реализации некоторых библиотечных функций, в том числе и реализация unsafe кода.
Но это не описание концепции, это доказательство реализации, причем с некоторыми допущениями и ограничениями.
> There can only be one owner at a time...
> At any given time, you can have either one mutable reference ...
> Примеры в студиюВот это как раз и есть описание самой концепции безопасного управления памятью, но проверку который невозможно реализовать статически из-за фундаментальных ограничений некоторых сценариев использования (циклические ссылки, изменение данных в двух потоках и т.д.) Как раз в этом и состоит проблема Rust, что он замахнулся на все возможные сценарии, безопасность некоторых реализовать не в состоянии, после чего начинает юлить "это проверить невозможно, поэтому мы считаем это безопасным"
> Поэтому тут нет никакой теории заговора против RustТы точно не перепутал пост, на который отвечаешь? И тред прочитал? Чот не похоже, больше выглядит, будто ты решил поговорить со своими собственными тараканами.
> Оставлю маленький коммент. На будущее.Чёрт, красиво! =)
> принять закон о криминальной ответственности за дыры в софте
Это ж насколько расстрельной будет должность CEO компании, которая возьмётся разрабатывать софт после того, как данный закон будет принят? Инуяша, ну вряд ли всё настолько плохо.
> Ошибки ведь нельзя запретить? Да нет, это в прошлом.
Если подумать, скорее всего мы все были бы не против такого расклада?
У меня вопрос серьёзный: для Rust'а есть анализатор памяти, наподобие AddressSanitizer или valgrind?
ThreadSanitizer?
Как при программировании на Rust'е ловят ошибки многопоточности и утечки памяти?
Они дают честное слово :-)
Если ты серьезно, то можешь почитать тут
rustc-dev-guide.rust-lang.org/sanitizers.htmlЕсть
AddressSanitizer
ControlFlowIntegrity
Hardware-assisted AddressSanitizer
KernelControlFlowIntegrity LLVM
LeakSanitizer
MemorySanitizer
ThreadSanitizer
Ok.
> Как при программировании на Rust'е ловят ошибки многопоточностиЕсли речь про data race - то Rust тебя защищает от data race, если ты сам не будешь что-то делать через unsafe. Miri однако может даже в случае unsafe сказать где ты передаёшь между потоками что-то, что безопасно передавать между потоками нельзя, и аналогично с другими уязвимостями с unsafe.
Race conditions по определению автоматически не поймать
Утечки памяти - всё тот же valgrind
> Race conditions по определению автоматически не пойматьНет такого определения, просто модель управления памятью Rust такого не умеет, точно так же как в Rust не решается проблема и с утечками памяти при циклических ссылках.
>> Race conditions по определению автоматически не поймать
> Нет такого определения, просто модель управления памятью Rust такого не умеетRace conditions не про управление памятью, не путать с data race
https://stackoverflow.com/questions/11276259/are-data-races-...
Race condition может даже в однопоточной программе возникнуть
все приведенные вами примеры по ссылке только для многопоточных приложений
> все приведенные вами примеры по ссылке только для многопоточных приложенийНу почему же
На stackoverflow в качестве примера дедлок предлагают например (Тоже подвид race condition)
В Rust есть async-await, асинхронный код можно исполнять в одном потоке (e.g https://docs.rs/tokio/latest/tokio/runtime/#current-thread-s...), и есть асинхронные мьютексы которыми ты точно так же можешь поймать дедлок
> Race conditions по определению автоматически не пойматьЛожь.
---
Safe Rust guarantees an absence of data races, which are defined as:
two or more threads concurrently accessing a location of memory
one or more of them is a write
one or more of them is unsynchronizedA data race has Undefined Behavior, and is therefore impossible to perform in Safe Rust.
---
Тогда уж цитируйте полностью> However Rust does not prevent general race conditions.
>
> This is mathematically impossible in situations where you do not control the scheduler, which is true for the normal OS environment. ...
Серьезный ответ - если разобраться, то Раст это как если к плюсам прикрутить ан.ьный анализатор, который тебе программировать не даёт.
> Раст это как если к плюсам прикрутить [вырежем сентенции неосиляторов] анализатор, который тебе программировать не даёт.и делаем поправку - "... который тебе НЕПРАВИЛЬНО программировать не даёт". А правильно - даёт.
Но только через жопу.
Джентльменам верят на слово.
США уже призвало всех отказаться от небезопасных языков!
А количество rust кода в ядре только увеличится! Не нравится - форкайте)))
ты не так понял: оно призвало использовать только раст. без этого отказываться от свободных языков смысла нет, нужен тотальный вендорлок
>> ты не так понял: оно призвало использовать только растВсе он правильно понял. Они ещё и Go рекламируют, ну и платформы: js, java, .net
> ты не так понял: оно призвало использовать только раст.какое наглое вранье?
> C#, Go, Java, Python, Rust, and Swiftдумаешь рк забаннил все ссылки?
media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF
и ты у нас тоже из непонятливых
Ах, питон забыл. Как же без него? Хотя я лично вот не понимаю. Я юы сказал это недосказанность. Они ещё и старье рекламируют, но совсем по другим причинам и тем не менее у этих языков все же везде есть фанаты - Fortran, Cobol. Хотя вот есть то что они не рекламируют, но ничуть не хуже - тот же Haskell.
> Для размещения библиотек поддерживается репозиторий crates.io.Это же небезопасно, а вдруг там трояна разместят? Кто модерирует содержимое пакетов?
Это вам не AppStore, по этому вряд-ли кто то будет на линукс использовать серьёзный софт. Конечно кто-то может обходя васянское ПО с блэкдорами поставить платёжный терминал или банковский софт... Но разраб не будет соберать своё ПО на 100500 дистрибутивов, он сделает только на Mac и Win. Остальное сделают Васи - а блэкдор это монетизация))))
cargo предоставляет возможность установить троян без crates.io
[dependencies]
horselib = { version = "1.13", git = "https://git.sr.ht/trojan/horse.git", branch = "totally-legit" }В случае, если исходник с трояном есть локально, собрать зависимость тоже можно:
[dependencies]
horselib = { path = "/usr/src/malware/horse", version = "1.13" }
> В случае, если исходник с трояном есть локально, собрать зависимость тоже можно:И только амазон, гугл и майкрософт трояны не раздают. А в их ToS, AUP и EULA вообще-то написано немного другое и их неихло бы порой почитывать. Для понимания кто там трояны раздает и вообще.
> [dependencies]
> horselib = { path = "/usr/src/malware/horse", version = "1.13" }Это все прекрасно но
1) crates.io сделан персональный фавор относительно других -> вендорлок
2) по дефолту куча проектов юзает crates io с его вендорлоком на ту троицу.Т.е. в целом откровенно подмятый корпами проект с характерным эксперименсом вида "так и быть, можете облобызать нам ботинки, мы сегодня добрые".
> Это все прекрасно но
> 1) crates.io сделан персональный фавор относительно других -> вендорлокОй, а у дебиана сделан персональный фавор для реп дебиана!
Да, другие можно подключить, но это все равно вендерлок!> 2) по дефолту куча проектов юзает crates io с его вендорлоком на ту троицу.
Проекты используют то, что им удобно.
Если вы белка-истеричка, то кнопочка fork находится вооон там.
Кликайте, делайте свои зависимости и сами их мейнтейньте.> Т.е. в целом откровенно подмятый корпами проект с характерным эксперименсом вида "так
> и быть, можете облобызать нам ботинки, мы сегодня добрые".У тебя странные фантазии. Можете тебе стоит сходить к психиатру?
Используйте Mos.Hub. На платформе доступен публичный каталог готовых решений. Каждое из них проходит несколько стадий проверки на безопасность, так что пользователи могут быть уверены в том, что ПО не содержит уязвимостей и не нанесет вреда при внедрении. Любой участник сообщества Mos.Hub может переиспользовать решения из каталога, участвовать в развитии или выложить в общий доступ свой opensource проект.
решений чего? кто задачку задавал? уравнений?
ты зря загон сообществом называешь
Например СУБД libmdbx там лежит, про которую недавно писали https://www.opennet.dev/opennews/art.shtml?num=63653
> Например СУБД libmdbx там лежит, про которую недавно писали https://www.opennet.dev/opennews/art.shtml?num=63653
> https://hub.mos.ru/leo/libmdbxВот чему-то такому там самое место. Сообщество из автора этой штуки довольно спорное как по мне. И иметь дело с такими сообществами лишний раз - нафиг нужно, имхо.
в случае, если проверка на бэкдоры не проходит, ввиду их отсутствия - их добавляют?
> Это же небезопасно, а вдруг там трояна разместят? Кто модерирует содержимое пакетов?А кто модерирует коммиты в сишные либы, типа ХЗ.
Или кто смотрит, чтобы на сайте кернел.огр не было бекдоров?
Почему в ядре 10 лет жил бекдор от NSA?
Похоже, люди стали понимать, зачем создавался запутанный язык, и почему его так активно продвигают.
> Похоже, люди стали понимать, зачем создавался запутанный язык, и почему его так активно продвигают.Запутанный?
Ты про тот, который будет тебе в выхлопе копилятора подсказки кидать и по рукам бить?
Или про то где a+b это undefined behavior, он вышли за границы буфера, подарим атакующему рут?В гугле расту учат ГОшников. ГОшников, Карл!
И они его за 3-4 месяца осваивают.
А сколько нужно учить СИ или читать 2000 страниц стандарта С++?
> А сколько нужно учить СИЕго не нужно учить. На нем нужно думать. Если не можете, это не для вас.
> Его не нужно учить. На нем нужно думать. Если не можете, это не для вас.О, не, на C думать противопоказано. Особенно если ты пишешь на C. Язык C например, в большинстве ситуаций, не позволяет описать разницу между указателем и массивом, потому что массив и есть указатель. Поэтому при написании программ на C надо думать на чём-то другом, как правило люди выбирают ассемблер и думают на нём. Если же ты думаешь на C, то это временно, с практикой пройдёт.
>А сколько нужно учить СИ или читать 2000 страниц стандарта С++?Во первых не смешивай 2 разных языка. Си можно выичить за неделю. Си плюс-плюс за год. Весь Си плюс-плюс никогда не сможешь выучить.
> Во первых не смешивай 2 разных языка.Вам "или" между Си и С++ ни на что не намекает? Если бы я хотел их смешать, то написал бы как некоторые кексперты "С/С++"
> Си можно выичить за неделю.
Вот прям все 190+ UB (gist.github.com/Earnestly/7c903f481ff9d29a3dd1) можно выучить на неделю?)) Да вы просто гений!
> Весь Си плюс-плюс никогда не сможешь выучить.
Вот тот и оно.
>прям все 190+ UBUndefined behavior sanitizer всё знает ...
> Си можно выичить за неделю.Нельзя. Не, то есть, если под "выучить" ты понимаешь способность пройти тест с вариантами ответов, то да, можно. Но такому знанию цена ноль. За полгода можно выучить C, если за плечами есть знание другого языка, причём вполне практическое знание, которое позволяет писать грамотный код. Но не за месяц, и тем более не за неделю.
>Почему в ядре 10 лет жил бекдор от NSA?От того, что из названия этого бекдора убрали слово "NSA", он из ядра не исчез.
Вот-вот. Им главное завязать на себя побольше ПО. А там ...
а там реклама и подписка
И компилятор в облака.
Скорее бы, а то слушать как кулеры напрягаются и hdd шуршит надоело ещё двадцать лет тому назад.
Вопрос такой. Компилятор до сих пор с закрытым исходным кодом?
А ещё такой вопрос - локальный сервер пакетов cargo можно какой поднять? И пакеты только для rust годятся или для чего угодно?
Cargo работает только с Rust-крейтами. Локальный сервер ...? Зеркало? Зачем? Можно просто локальный репозитарий. На crates.io есть программка которая скачивает самые популярные крейты. А можно и не скачивать , а устанавливать крейты из linux-дистрибутива, например, Debian или Ред ОС
> А ещё такой вопрос - локальный сервер пакетов cargo можно какой поднять?Быстрый ответ - да, можно.
Подробный тут - там дофига возможностей (локальный/глобальный, зеркала и тд)
doc.rust-lang.org/cargo/reference/specifying-dependencies.html> И пакеты только для rust годятся или для чего угодно?
что значит "чего угодно"?))
если ты имеешь в виду сидную либу или видос рикки рола, то нет - так нельзя))
А я правильно понимаю, что если условно zlib написан на Rust, то все использующие его пакеты согласно этой статистике считались бы "завязанными на Rust"?
Всё верно, причём там "или" зависимости.
Не парьтесь, там просто каждый крейт собирается отдельным пакетом, и вот эта "великая статистика" обусловлена тем что там librust-* пакетов примерно как python-* пакетов будет.
Да, их там штук 200 будет (может и больше)
Вот что интересно - а сколько кода на Rust в винде и маке? Есть ли там все эти отчетности про 8 процентов?
Надо взять самый первый проект на расте: это фурифокс. Вот сколько там %% на расте - это верхний предел для больших проектов.
Про Мак не знаю. Про Винду в начале этого года выступал кто-то из топ-менеджеров MS, говорил, что Rust используется на всю катушку, и, как будто, все довольны (программисты, менеджеры). Сколько в процентах кода на Rust в Windows не знаю.https://www.techtarget.com/searchenterprisedesktop/answer/Do...
https://www.theregister.com/2023/04/27/microsoft_windows_rust/
Вот оно как. Спасибо за информацию, почитал с интересом. Стало быть - и винда в сторону Rust движется.
Мозила тоже двигалась. А это родоначальник всё-таки.
А всех недовольных увольняют.