Можете поподробнее? Что должна делать ФС, чтобы при перечислении записей в каталоге не понадобилось никаких флагов? Или вы предлагаете отказаться от каталогов вообще и, соответсвенно, от ls и ее флагов?
Под локалаизцией я понимаю не только то, что код будет обернут в unsafe блок (как это вообще можно называть локализацией?). Локализация, это когда ваш unsafe код сведен к минимуму и не размазан по всему коду. Как Rust поможет автоматически вам решить эту задачу?
Если вы не решаете какую-то низкоуровневую задачу (написание ОС\аллокатора\структуры данных), то, скорее всего, unsafe вам вообще не понадобится.
Простите, но в системном программировании примерно такие задачи и решаются.
А вы прочитали комментарий? Там написано, про код используемый в реальных продуктах. Но да спасибо низачто, за то время пока вы ерничали я успел найти реальный код используемый в продакшене и написанный на Rust.
Эта ОС примитивный конкурентный код, где все защищено одним или несколькими несколькими глобальными локами (я даже не говорю про какие-то там lock-free, вопрос в элементарной конкуретности), а аллокатор памяти в этой ОС просто шутка. Этот код просто утрированный пример.
Серьезно, у меня некоторые студенты на 2-3 курсе писали более содержательный системный код, разве что я им не давал задания прикручивать к своему коду UI-чик, так как есть несколько более базовые задачи.
Но проблема не только в этом. То что этот код не начали использовать в реальных продуктах, значит, что одних гарантий безопасности Rust-а не достаточно (возможно пока), чтобы перейти на него для системной разработки. Я молчу о том, чтобы получить хоть какую-то статистику об ошибках и надежности года на Rust в реальных проектах. И именно поэтому я указал вам на то, что этот код никто кроме разработчиков для реальных задач не использует.
И нет, мне не нужен Unreal Engine, уж точно не как показатель применимости кода для системного программирования. Совершенно точно квантовые компьютеры не имеют никакого отношения к делу. И о пользовательской базе в 10 миллионов человек я не говорил. И я еще даже не упоминал про такие вещи как QNX и L4* (которые создавались, в том числе, с расчетом на безопасность). Если вы перестанете утрировать, а перейдете к объективным аргументам, то обсуждение будет гораздо полезнее.
Это просто несерьезно… Когда redox будет использоваться кем-то кроме его создателей и для чего-то кроме развлечений, тогда можно будет сказать, что Rust показал себя в мире системного программирования. Да и вообще называть исследовательской ОС, вся новизна которой в том, что она написана на Rust — слишком громко.
Даже элементарно, ребята в ядре используют топрный free-list алокатор с кучей ограниченной 256MB и эта константа забита в коде к тому же залоченный одним общим мьютексом. И это при том, что аллокация памяти довольно разнообразная на всякие интересные, быстрые и простые алгоритмы. Пожалуй перед тем как браться за ОС им стоит элементарно познакомиться с тем, что было сделано другими (серьезно, например, SLAB аллокаторы появились в SunOS, т. е. это не пипец какой bleeding edge, уж не говоря о том, что алгоритм там элементарный).
Но на самом деле системное программирование не ограничивается только ядром ОС и писать полноценную ОС для этого не обязательно.
Или вы этим комментарием хотели показать, что там нет unsafe? Там он есть, я это знаю наверняка.
Люди склонны ошибаться. В любом случае, мы переходим в область субъективных суждений: вряд ли, существует статистика как часто такие ошибки допускают. Могу снова предложить почитать статьи авторов PVS Studio и сделать поправку на то, что им попадает в руки код после ревью, прохождения тестов, а бывает, что и после других анализаторов.
И Rust это никак не исправляет, вводит новые сложности, которые устраняют возможность каких-то ошибок при определенных условиях, но на сколько эти ошибки влияют на качество проекта в целом, сколько новых ошибок будет из-за сложностей самого Rust-а — вопросы, которые остаются без ответа.
Кстати, отсутствие дата рейсов тоже гарантируется.
Только для ограниченного набора многопоточных примитивов. Потому как только вам нужно залезть в нетривиальный lock-free, реализовать SMR и тд, вам тут же приходиться использовать unsafe.
Посмотрел, перечислены штуки, которые можно сделать только в unsafe, что и требовалось доказать.
Да они unsafe и что дальше? Для системного программирования приходиться использовать unsafe, или вы предлагаете новичкам вообще никогда не лезть в системное программирование? В таком случае предлагаю не называть Rust языком для системного программирования.
Дык, умение «правильно дизайнить», в какой-то степени, зависит и от языка. В любом случае, начали мы с того, что опытный товаришь не сможет «продумать дизайн» за меня.
Я не говорил такого, я говорил, что Rust не сможет придумать за вас и вам все еще нужен опытный товарищь.
А после того, как вы перешли из разряда новичков, на сколько Rust вам упрощает жизнь и повышает качество вашего кода? Потому как, если мы говорим уже не о новичках, то и в C++ не новичкам не так чтобы очень часто приходится сталкиваться с проблемами с памятью, отчасти потому что эти темы довольно неплохо проработаны и есть средства борьбы с проблемами.
Так я об этом и говорю: более опытные разработчики пишут такие штуки, а менее опытные — используют. И в модулях последних unsafe можно и запретить. Получаем автоматический контроль за тем, чтобы небезопасные штуки не расползались по коду.
Если за вашей работой все время кто-то следит, то запрещать можно и в C++, разница в том, что компиялтор не может следить за этими запретами (если вы не напряглись и не стали использовать какую-то тулу, компиляторный плагин или еще что-нибудь, тут опять же довольно много используемых на практике вариантов). В этом разница есть, на сколько она существенна вопрос.
Могу только повторить аргумент об автоматической проверке. Можно идеально продумать/задизайнить, а потом кто-то воткнёт reinterpret_cast (или лучше — сишный каст) и на ревью обо пройдёт незамеченным. Или забудет проверить нулевой указатель и т.д. Всё это не имеет отношения к дизайну и отлавливается растом.
А слово unsafe какое-то магическое и оно никогда не пройдет на ревью незамеченным?
BTW, как вы себе представляете такой запрет? Компилятор будет спрашивать логин и пароль, если пользователь наовчиек, то одни флаги компиляции, если нет то другие? Потому как на ревью можно это проглядеть так же как и в любом другом языке.
Ответ всё тот же: зависит от проекта. Универсальных решений не бывает.
Абсолютно согласен и эту мысль пытаюсь донести до всех, кто считает, что может просто забыть про новые проекты на C и C++ и заменить их Rust-ом, потому что «безопасно».
Не совсем понимаю, если честно. Вообще, кривая освоения языка у раста не самая плавная, но С++ на «нормальном» (а не базовом) уровне освоить тоже не просто.
Дело не в кривой освоения языка, дело в дизайне. Разделении на сущности, распределении обязанностей в коде, и тд и тп — это дизайн.
Кстати, можно вообще сделать запрет unsafe кода и компилятор за этим будет следить, что тоже полезно в плане разделения зон ответственности.
Условно вы получите Java, там не супер часто используются нативные binding-ы (за исключением таковых в стандартной библиотеке), и вот вам безопасное окружение (при условии, что мы доверяеме JVM и стандартной библиотеке).
Но язык предназначенный для системного программирования, в частности, должен уметь решать задачи в которых без unsafe не обойтись (например, попробуйте на Rust написать динамический универасльный аллокатор памяти без unsafe). На сколько я понимаю Rust относит себя как раз к языкам для системного программирования.
Про литературу — это я опять же на вопрос о преимуществах языка отвечал, в общем случилось недопонимание.
Я задал вопрос о конкретных доводах в пользу безопасности Rust. На сколько реально улучшается качество кода при использовании Rust (я могу поверить, что если вы никогда не используете unsafe он достаточно безопасен для многих задач)? Потому что заявлений о безопасности Rust я слышал много (причем в виде Rust безопасен и точка), впрочем на сайте они прямым текстом пишут, что «Rust is totally a safe programming language» но только до тех пор пока вы не начнете использовать unsafe.
Но простите, есть класс задач, в которых приходится использовать unsafe и отсюда возникает вопрос, а на сколько же реально он «safe» в задачах системного программирования? Мое мнение такое, в задачах системного программирования, он безопасен ровно на столько, на сколько хорошо продуман и задизайнен ваш код. Но как не трудно заметить это же касается и C и C++, и на самом деле любого языка (хотя, справедливости ради, тут нужно вспомнить мнение одного товарища, что C++ ведет к реально плохим дизайнерским решениям).
Так вопрос тоже странный. Ведь «сделать жизнь лучше» можно очень по разному, совсем не только увеличением «безопасности и качества». Собственно, преимущества от языка и по моему мнению не исчерпываются дополнительными гарантиями. Если же всё-таки говорить о последних, то на мой взгляд, разница следующая: в С++ надо делать дополнительные телодвижения, чтобы получить безопасность, в расте — наоборот. Опять же, наступить на грабли UB сложнее.
Перефразирую. С учетом того, что есть классы ошибок с которыми Rust не поможет справиться, с учетом того, что есть средства для поиска ошибок работы с памятью для других языков, с учетом того, что Rust это новый язык с новыми сложностями. На сколько это оправдано начинать проект на Rust, чтобы повысить «безопасность»?
BTW, я посмотрел на список того, что считается UB в Rust, он не сильно то отличается от того, что считается UB, например, в C.
1. Не стоит всех, кто делает ошибки в коде называть идиотами. Все когда-то начинали, но это не значит, что все были идиотами.
2. Вы нигде (кроме первого комментария, где вы сказали, что в Rust unsafe четко локализован, с чего все и началось), а вот DarkEld3r, похоже, сомневается в этом.
3. Кроме указания на то, что локализация unsafe-ов магическим образом в коде не появится от того, что код будет написан на Rust я вам тоже не противоречил.
«Немного» не так. Есть ключевое отличие: в расте из коробки есть формальные метрики. И если я вижу unsafe, то начинаю смотреть на код внимательнее. Если unsafe слишком много — вполне себе повод отправить на переделку.
Согласен, Rust не даст вам опустить unsafe и если кто-то кроме вас смотрит код и он достаточно хорошо разбирается в дизайне, то этот кто-то сможет вам на это указать.
Но продумать дизайн кода, так что бы unsafe не распространялся он за вас не сможет. И в этом мой поинт — если вы умете это делать, вы сможете это сделать и в C++ и в Rust, если нет, то вы не сможете этого сделать ни там ни там.
А какая у меня аргументация? Да, я считаю, что у раста есть ряд преимуществ (как и недостатков, впрочем), но приводить их, в очередной раз, смысла не вижу. Просто сделал комментарий конкретно про unsafe и на эту тему готов поспорить.
Прошу прощения, я не посмотрел на ник и перепутал вас с другим оппонентом и о его аргументации (цитата была в комментарии выше) я и говорил.
Хочу сказать, что вопрос «какие у раста преимущества» провокационный. Вот как на это можно ответить? Если вкратце, то получатся сплошная агитация без фактов, если развёрнуто, то в комментарий можно не поместиться.
Я такого вопроса не задавал. Я спросил, каким образом наличие или отсутствие литературы относится к делу. А объективных доводов пользу безопасности Rust я все еще не могу увидеть, основные причины:
— я видел код написанный на Rust, при этом имеющий проблемы работы с памятью, т. е. Rust не делает магии — хороший инженер будет хорошо писать на Rust (С++/Java/Haskell), плохой везде будет писать плохо (несколько слишком суровое обобщение, но оно должно донести суть идеи)
— кроме проблем работы с памятью есть и другие проблемы связанные с дизайном, логикой внешними зависимостями и Rust тут не помошник
— для борьбы с проблемами неправильного использования памяти существует некоторое количество разнообразных автоматических средств (тоже самое относится к проблемам связанным с конкуретностью)
На сколько, с учетом всего этого, переход на Rust при прочих равных условиях сделает жизнь лучше? Если хоть какой-то способ показать, что Rust реально улучшает качество? Когда я задаю такие вопросы, то получаю вот такие странные ответы (это реальная цитата из моей переписки про Rust):
Мне субъективно приятней писать на расте, чем на C++, благодаря красивому и лаконичному синтаксису, крутой системе типов, единообразию кодовой базы, отсутствию неявных преобразований, аккуратности во всем (например, гигиеничные макросы), крутым современным фишкам вроде классного паттерн-матчинга, очень хорошей системе сборки, expression-ориентированности, шикарному выведению типов, наличию большого числа статических проверок, ну и ОЩУЩЕНИЮ безопасности.
т.к. точно также позволяет при определённом желании наговнокодить, потоптаться по памяти и сделать другие плохие вещи.
Да позволяет, но оценку этому я не давал. Указал только на одну конкретную возможность поговнокодить, за которой компилятор не следит (просто потому, что за дизайном кода компилятор не следит).
Более того, он с важей т.з. хуже т.к. накладывает дополнительные ограничения.
Он накладывает дополнительные ограничения, и я видел примеры задач которые на C прекрасно решаются без них. Но оценку, что Rust хуже или лучше (опять же безотносительно области применения) я не давал.
Также он хуже, поскольку про него меньше статей, best practices etc.
Я говорил, что их меньше, но я опять же не говорил, что это делает его хуже или лучше. Более того, замечу что разговор про наличие литературы начал не я, и даже задал вопрос, каким образом это имеет отношение к делу, на который впрочем ответа не получил.
Ещё вам, похоже, надоели евангелисты, кричащие на всех углах, как Rust безопасен.
Такого я не говорил, но это правда (причем нет разницы между евангелистами Rust, C++, Java и даже попадавшимся мне на глаза евангелистом языка Ассемблера), потому что они почему-то очень любят другим приписывать утверждения, которых они не делали.
Но главное пожалуй то, что для него гораздо меньше наработанного кода, библиотек и поддержки платформ.
Это правда, но я об этом не говорил, и уж тем более не мог сказать, что из-за этого Rust плохой.
Если я где-то ошибся, поправьте.
Поправил.
Ответьте мне пожалуйства на следущий вопрос — может быть я правда чего-то не знаю о Rust. Каким образом Rust позволяет локализовать unsafe блоки в коде и не допустить чтобы они разбредались по всей кодовой базе?
Этот вопрос появился не на пустом месте. Потому что, если ваша программа упала и все что вам показывает coredump это покарапченную память. То первыми кандидатами на проверку как раз будут unsafe блоки в Rust (и те части кода, в которых делаются небезопасные вещи в языках где нет unsafe). Если по всей кодовой базе у вас будет торчать unsafe, то при поиске ошибок толку от того, что есть разделение на safe и unsafe код не будет.
Мое утверждение заключается в том, что Rust не помогает это сделать, потому что это вопрос дизайна, а компилятор не следит за дизайном программы. И как пример я приводил моего студента, который, хоть и верил в безопасность Rust и то, что Rust позволит ему сделать код лучше, сделал такой очевидный дизайнерский просчет (в дполонение к другим ляпам).
Исходя из опыта переписки отмечу особенно: я не говорю, что такой проблемы не возникает в C++ (или каком-то другом языке), я не говорю, что эта проблема автоматически и безоговорочно делает Rust плохим и тд и тп. Мое утверждение, что такая проблема не решается запретами.
Почему нет? unsafe-блоки всё-таки будут явно выделены. Да, можно весь код в таком блоке написать, но и это имеется очевидное преимущество — сразу видно, что с кодом что-то не так. В плюсах какую-то хрень спрятать, в том числе случайно, проще.
Да можно, а можно и натыкать везде по коду unsafe-ов — все это можно. И от того, что вы используете Rust магическим образом ваше сознание не изменится, вы не станете лучшим инженером и не научитесь грамотно локализовывать опасные места в коде.
Замечу, что не любой C++ или C код делает грязные небезопасные трюки, а код, который так делает все еще можно локализовать в кодовой базе. Да этот код не будет помечен ключевым словом языка, но локализация такого кода — не задача компилятора, а задача инженера. Если вы умеете это делать вы сможете это сделать в C++, если вы не умеете этого делать, вы не сможете этого сделать и в Rust.
Ну давайте делать далеко идущие выводы по тому какой код написал один студент.
А каких выводах речь? Где я делал выводы? Я просто констатирую факт, что аргументация того студента и ваша аргументация идентичны, и его код, не смотря на все эти аргументы, содержал ошибки работы с памятью, ошибки дизайна (unsafe размазанный по коду) и кучу других ошибок.
Каких именно доводов? У языка есть хороший мануал, есть куча статей на эту тему — выводы сделать можно, если есть желание разбираться. Если нет, то о каких доводах можно говорить?
Да о каких выводах вы все говорите? У C++ тоже есть документация и есть статьи и еще больше чем про Rust. Куча этих статей о том как все делать правильно и тд и тп. Чем Rust в этом смысле отличается? Что вообще вы хотели сказать этим комментарием?
Меня удивляют аргуметы о наличии unsafe: ведь и в C# и в джаве можно сишный код дёргать и нарушить имеющиеся гарантии, но почему-то никто не орёт, что гарантии менеджед языков — миф.
Вы похоже забыли, о чем речь. Вы написали, что в коде на Rust все unsafe будут каким-то непонятным образом локализованы. На что я вам отметил, что факт того, что вы пишите на Rust не значит, что unsafe-ы каким-то магическим образом будут локализованы. Вы оспариваете это мое утверждение?
Обращу ваше внимание, что я не говорил, что иметь разделение на safe/unsafe в языке плохо, что программы вызывающие нативный код из managed языков безопасны и тд и тп. Это ваши слова, не мои — не нужно их мне приписывать.
Начну с конца. Любым инструментом можно как сделать хорошо, так и сделать отвратительно.
Ровно мои слова — Rust такой же инструмент и не надо ему приписывать мифические свойства, которых у него нет. В частности unsafe магическим образом не будет локализован в коде, только потому что вы пишите на Rust.
По поводу вашего студента — а вы уверены, что на С он бы написал лучше? У меня пока складывается впечатление, что он пытался «вбить молотком» своё решение, не сильно задумываясь о результате. И в С ему бы это удалось гораздо легче.
Касательно этого студента, конечно нет. Очевидно, что я бы не стал просить решать задание в двух экземплярах на Rust и на C. Но это лишь демонстрация того, что проблемы никуда не исчезнут магическим образом, потому что Rust.
Но отмечу, что Rust он выбрал добровольно и не сменил своего выбора даже после того, как выяснилось, что сборка bare-metal программ на Rust, который пвроде предназначен для системного программирования, почему-то нормально не описана в документации и вызывает головную боль.
Кроме того я имел возможность посмотреть на других студентов, которые добровольно выбрали C, хотя большими знатоками C или C++ (или вообще дизайна кода) большинство из них не назовешь.
По моему опять же сугубо личному опыту, Rust провоцирует писать более аккуратный код, более чётко выделять отдельные элементы, более тщательно продумывать, как будут обработаны те или иные нештатные ситуации. Именно из-за своих ограничений, которые не позволяют просто так создать, к примеру, иерархию объектов, которые в реальности ссылаются друг на друга «вверх», «вниз» и «вбок» совершенно произвольно.
Студент тоже мне пел такие песни, но результат показал, что это только песни. Моя мысль заключается в том, что не смотря на то, что некоторые люди заявляют о том, что Rust их на что-то там провоцирует, это не значит, что так и есть на самом деле. Я лично, все еще в ожидании хоть каких-нибудь конкретных доводов в пользу безопасности Rust (а не странных утверждений о том, что Rust провоцирует кого-то делать то, что он и так должен был делать).
1. То что они изначально предназначены для разделенного владения не значит, что они не могут решать других задач. Если вас волнует имя, то using вам в помощь, если же вас интересует функциональность, то shared_ptr и weak_ptr обладают нужной функциональностью (по крайней мере я не видел, чтобы кто-то показал обратное).
2. То что Бьерн, сказал, что ситуации когда дизайн программы требует использования shared_ptr из-за непонятного времени жизни программы должны быть сведены к минимуму (что несомненно правда), не значит, что мы не можем использовать shared_ptr/weak_ptr для отлова ошибок в коде.
Нужно слушать не только что кто-то там сказал, но еще и почему кто-то так сказал.
Вы предлагаете отлавливать dangling pointers — это это ошибочная ситуация, weak_ptr и shared_ptr позволяют ее отловить и являются стандартным средством языка. Так что сравнение как раз таки имеет смысл.
В статье описан, как раз один такой инструмент, со своими достоинствами и недостатками. мне кажется баланс достоинств и недостатков вполне приемлем: о)
Перфразирую, в стандратной библиотеке уже есть shared_ptr и weak_ptr, которые решают эту проблему. Ваше решение по сравнению с этим выигрывает в отсутствии динамических аллокаций (не известно сколько), проигрывает в алгоритмической сложности «освобождения» (не известно сколько). Я ничего не забыл?
Он локализован, если инженер пишуший код его локализовал. У меня был студент, который на курсе ОС решил писать ОС на Rust, тоже говорил, что Rust такой весь из себя безопасный и тд и тп. Но на практике что я видел, когда проверял его домашние задания:
— проблемы с памятью (с которыми Rust должен помогать по идее)
— unsafe размазанный по коду (с которым по идее должны помагать «правила хорошего тона» Rust-а)
— все те же алгоритмические и логические проблемы (к которым Rust напрямую, конечно, не имеет отношения, но код решающий аналогичную задачу на C был несколько компактнее и проще, ИМХО, именно Rust стал источником многих из этих проблем, как раз из-за переусложнения того, что должно быть простым).
Короче Rust может стать хорошим инструментом только в руках тех, кто умеет им пользоваться (удивительно, но как и любой другой инструмент, включая C++).
Кто-то пытается для развлечения, но в само ядро эти модули не войдут (по крайней мере не в ближайшем будущем), да и пользоваться Rust-ом просто не удобно в этом случае. Модуль ядра не работает в воздухе, ему нужно окружение — интерфейсы ядра, оборачивать все эти интферфейсы в Rust значит делать двойную работу (с учетом того, что внутри ядра не поддерживается стабильный API, я уже молчу про ABI).
В дополнение к этому идеология Rust («безопасность» через кучу ограничений), просто не согласуется с идеологией ядра Linux (не знаешь что делаешь — не суй свой нос). Да и касательно отлова проблем с памятью, в ядре Linux есть довольно хорошие средства нахождения таких проблем, Rust мало что к этому может добавить. Да и проблемы неправильного использования памяти, вероятно, самый простой класс проблем, с которыми приходится сталкиваться в ядре, но Rust не предлагает никакого решения для большинства из других проблем.
1. Советуют или нет использовать make_shared, а голову еще никто не отменял, об этой проблеме известно давно, а даже если бы не было известно, то не трудно догадаться — сюрприза тут нет.
2. Я не говорил, что с weak_ptr нет проблем, мой поинт в том, что вы неправы насчет «несравнимости» подхода с дополнительной динамической аллокацией и без нее.
3. Еще одно подтверждение, что правильный дизайн и голова — лучшие друзья инженера. Умные указатели не освобождают от обязанности понимать, что происходит в коде, в частности, знать кто какими объектами владеет и чем ограничено время жизни объектов, все остальное лишь помошники в этом (возможно даже очень хорошие), но не замена голове.
Простите, но в системном программировании примерно такие задачи и решаются.
Серьезно, у меня некоторые студенты на 2-3 курсе писали более содержательный системный код, разве что я им не давал задания прикручивать к своему коду UI-чик, так как есть несколько более базовые задачи.
Но проблема не только в этом. То что этот код не начали использовать в реальных продуктах, значит, что одних гарантий безопасности Rust-а не достаточно (возможно пока), чтобы перейти на него для системной разработки. Я молчу о том, чтобы получить хоть какую-то статистику об ошибках и надежности года на Rust в реальных проектах. И именно поэтому я указал вам на то, что этот код никто кроме разработчиков для реальных задач не использует.
И нет, мне не нужен Unreal Engine, уж точно не как показатель применимости кода для системного программирования. Совершенно точно квантовые компьютеры не имеют никакого отношения к делу. И о пользовательской базе в 10 миллионов человек я не говорил. И я еще даже не упоминал про такие вещи как QNX и L4* (которые создавались, в том числе, с расчетом на безопасность). Если вы перестанете утрировать, а перейдете к объективным аргументам, то обсуждение будет гораздо полезнее.
Даже элементарно, ребята в ядре используют топрный free-list алокатор с кучей ограниченной 256MB и эта константа забита в коде к тому же залоченный одним общим мьютексом. И это при том, что аллокация памяти довольно разнообразная на всякие интересные, быстрые и простые алгоритмы. Пожалуй перед тем как браться за ОС им стоит элементарно познакомиться с тем, что было сделано другими (серьезно, например, SLAB аллокаторы появились в SunOS, т. е. это не пипец какой bleeding edge, уж не говоря о том, что алгоритм там элементарный).
Но на самом деле системное программирование не ограничивается только ядром ОС и писать полноценную ОС для этого не обязательно.
Или вы этим комментарием хотели показать, что там нет unsafe? Там он есть, я это знаю наверняка.
Только для ограниченного набора многопоточных примитивов. Потому как только вам нужно залезть в нетривиальный lock-free, реализовать SMR и тд, вам тут же приходиться использовать unsafe.
Да они unsafe и что дальше? Для системного программирования приходиться использовать unsafe, или вы предлагаете новичкам вообще никогда не лезть в системное программирование? В таком случае предлагаю не называть Rust языком для системного программирования.
А после того, как вы перешли из разряда новичков, на сколько Rust вам упрощает жизнь и повышает качество вашего кода? Потому как, если мы говорим уже не о новичках, то и в C++ не новичкам не так чтобы очень часто приходится сталкиваться с проблемами с памятью, отчасти потому что эти темы довольно неплохо проработаны и есть средства борьбы с проблемами.
Если за вашей работой все время кто-то следит, то запрещать можно и в C++, разница в том, что компиялтор не может следить за этими запретами (если вы не напряглись и не стали использовать какую-то тулу, компиляторный плагин или еще что-нибудь, тут опять же довольно много используемых на практике вариантов). В этом разница есть, на сколько она существенна вопрос.
А слово unsafe какое-то магическое и оно никогда не пройдет на ревью незамеченным?
BTW, как вы себе представляете такой запрет? Компилятор будет спрашивать логин и пароль, если пользователь наовчиек, то одни флаги компиляции, если нет то другие? Потому как на ревью можно это проглядеть так же как и в любом другом языке.
Абсолютно согласен и эту мысль пытаюсь донести до всех, кто считает, что может просто забыть про новые проекты на C и C++ и заменить их Rust-ом, потому что «безопасно».
Смотрите https://doc.rust-lang.org/reference.html#behavior-considered-undefined
Условно вы получите Java, там не супер часто используются нативные binding-ы (за исключением таковых в стандартной библиотеке), и вот вам безопасное окружение (при условии, что мы доверяеме JVM и стандартной библиотеке).
Но язык предназначенный для системного программирования, в частности, должен уметь решать задачи в которых без unsafe не обойтись (например, попробуйте на Rust написать динамический универасльный аллокатор памяти без unsafe). На сколько я понимаю Rust относит себя как раз к языкам для системного программирования.
Я задал вопрос о конкретных доводах в пользу безопасности Rust. На сколько реально улучшается качество кода при использовании Rust (я могу поверить, что если вы никогда не используете unsafe он достаточно безопасен для многих задач)? Потому что заявлений о безопасности Rust я слышал много (причем в виде Rust безопасен и точка), впрочем на сайте они прямым текстом пишут, что «Rust is totally a safe programming language» но только до тех пор пока вы не начнете использовать unsafe.
Но простите, есть класс задач, в которых приходится использовать unsafe и отсюда возникает вопрос, а на сколько же реально он «safe» в задачах системного программирования? Мое мнение такое, в задачах системного программирования, он безопасен ровно на столько, на сколько хорошо продуман и задизайнен ваш код. Но как не трудно заметить это же касается и C и C++, и на самом деле любого языка (хотя, справедливости ради, тут нужно вспомнить мнение одного товарища, что C++ ведет к реально плохим дизайнерским решениям).
Перефразирую. С учетом того, что есть классы ошибок с которыми Rust не поможет справиться, с учетом того, что есть средства для поиска ошибок работы с памятью для других языков, с учетом того, что Rust это новый язык с новыми сложностями. На сколько это оправдано начинать проект на Rust, чтобы повысить «безопасность»?
BTW, я посмотрел на список того, что считается UB в Rust, он не сильно то отличается от того, что считается UB, например, в C.
2. Вы нигде (кроме первого комментария, где вы сказали, что в Rust unsafe четко локализован, с чего все и началось), а вот DarkEld3r, похоже, сомневается в этом.
3. Кроме указания на то, что локализация unsafe-ов магическим образом в коде не появится от того, что код будет написан на Rust я вам тоже не противоречил.
В ответ на ваш комментарий:
Правильно?
Но продумать дизайн кода, так что бы unsafe не распространялся он за вас не сможет. И в этом мой поинт — если вы умете это делать, вы сможете это сделать и в C++ и в Rust, если нет, то вы не сможете этого сделать ни там ни там.
Прошу прощения, я не посмотрел на ник и перепутал вас с другим оппонентом и о его аргументации (цитата была в комментарии выше) я и говорил.
Я такого вопроса не задавал. Я спросил, каким образом наличие или отсутствие литературы относится к делу. А объективных доводов пользу безопасности Rust я все еще не могу увидеть, основные причины:
— я видел код написанный на Rust, при этом имеющий проблемы работы с памятью, т. е. Rust не делает магии — хороший инженер будет хорошо писать на Rust (С++/Java/Haskell), плохой везде будет писать плохо (несколько слишком суровое обобщение, но оно должно донести суть идеи)
— кроме проблем работы с памятью есть и другие проблемы связанные с дизайном, логикой внешними зависимостями и Rust тут не помошник
— для борьбы с проблемами неправильного использования памяти существует некоторое количество разнообразных автоматических средств (тоже самое относится к проблемам связанным с конкуретностью)
На сколько, с учетом всего этого, переход на Rust при прочих равных условиях сделает жизнь лучше? Если хоть какой-то способ показать, что Rust реально улучшает качество? Когда я задаю такие вопросы, то получаю вот такие странные ответы (это реальная цитата из моей переписки про Rust):
Да позволяет, но оценку этому я не давал. Указал только на одну конкретную возможность поговнокодить, за которой компилятор не следит (просто потому, что за дизайном кода компилятор не следит).
Он накладывает дополнительные ограничения, и я видел примеры задач которые на C прекрасно решаются без них. Но оценку, что Rust хуже или лучше (опять же безотносительно области применения) я не давал.
Я говорил, что их меньше, но я опять же не говорил, что это делает его хуже или лучше. Более того, замечу что разговор про наличие литературы начал не я, и даже задал вопрос, каким образом это имеет отношение к делу, на который впрочем ответа не получил.
Такого я не говорил, но это правда (причем нет разницы между евангелистами Rust, C++, Java и даже попадавшимся мне на глаза евангелистом языка Ассемблера), потому что они почему-то очень любят другим приписывать утверждения, которых они не делали.
Это правда, но я об этом не говорил, и уж тем более не мог сказать, что из-за этого Rust плохой.
Поправил.
Ответьте мне пожалуйства на следущий вопрос — может быть я правда чего-то не знаю о Rust. Каким образом Rust позволяет локализовать unsafe блоки в коде и не допустить чтобы они разбредались по всей кодовой базе?
Этот вопрос появился не на пустом месте. Потому что, если ваша программа упала и все что вам показывает coredump это покарапченную память. То первыми кандидатами на проверку как раз будут unsafe блоки в Rust (и те части кода, в которых делаются небезопасные вещи в языках где нет unsafe). Если по всей кодовой базе у вас будет торчать unsafe, то при поиске ошибок толку от того, что есть разделение на safe и unsafe код не будет.
Мое утверждение заключается в том, что Rust не помогает это сделать, потому что это вопрос дизайна, а компилятор не следит за дизайном программы. И как пример я приводил моего студента, который, хоть и верил в безопасность Rust и то, что Rust позволит ему сделать код лучше, сделал такой очевидный дизайнерский просчет (в дполонение к другим ляпам).
Исходя из опыта переписки отмечу особенно: я не говорю, что такой проблемы не возникает в C++ (или каком-то другом языке), я не говорю, что эта проблема автоматически и безоговорочно делает Rust плохим и тд и тп. Мое утверждение, что такая проблема не решается запретами.
Замечу, что не любой C++ или C код делает грязные небезопасные трюки, а код, который так делает все еще можно локализовать в кодовой базе. Да этот код не будет помечен ключевым словом языка, но локализация такого кода — не задача компилятора, а задача инженера. Если вы умеете это делать вы сможете это сделать в C++, если вы не умеете этого делать, вы не сможете этого сделать и в Rust.
А каких выводах речь? Где я делал выводы? Я просто констатирую факт, что аргументация того студента и ваша аргументация идентичны, и его код, не смотря на все эти аргументы, содержал ошибки работы с памятью, ошибки дизайна (unsafe размазанный по коду) и кучу других ошибок.
Да о каких выводах вы все говорите? У C++ тоже есть документация и есть статьи и еще больше чем про Rust. Куча этих статей о том как все делать правильно и тд и тп. Чем Rust в этом смысле отличается? Что вообще вы хотели сказать этим комментарием?
Вы похоже забыли, о чем речь. Вы написали, что в коде на Rust все unsafe будут каким-то непонятным образом локализованы. На что я вам отметил, что факт того, что вы пишите на Rust не значит, что unsafe-ы каким-то магическим образом будут локализованы. Вы оспариваете это мое утверждение?
Обращу ваше внимание, что я не говорил, что иметь разделение на safe/unsafe в языке плохо, что программы вызывающие нативный код из managed языков безопасны и тд и тп. Это ваши слова, не мои — не нужно их мне приписывать.
Касательно этого студента, конечно нет. Очевидно, что я бы не стал просить решать задание в двух экземплярах на Rust и на C. Но это лишь демонстрация того, что проблемы никуда не исчезнут магическим образом, потому что Rust.
Но отмечу, что Rust он выбрал добровольно и не сменил своего выбора даже после того, как выяснилось, что сборка bare-metal программ на Rust, который пвроде предназначен для системного программирования, почему-то нормально не описана в документации и вызывает головную боль.
Кроме того я имел возможность посмотреть на других студентов, которые добровольно выбрали C, хотя большими знатоками C или C++ (или вообще дизайна кода) большинство из них не назовешь.
Студент тоже мне пел такие песни, но результат показал, что это только песни. Моя мысль заключается в том, что не смотря на то, что некоторые люди заявляют о том, что Rust их на что-то там провоцирует, это не значит, что так и есть на самом деле. Я лично, все еще в ожидании хоть каких-нибудь конкретных доводов в пользу безопасности Rust (а не странных утверждений о том, что Rust провоцирует кого-то делать то, что он и так должен был делать).
2. То что Бьерн, сказал, что ситуации когда дизайн программы требует использования shared_ptr из-за непонятного времени жизни программы должны быть сведены к минимуму (что несомненно правда), не значит, что мы не можем использовать shared_ptr/weak_ptr для отлова ошибок в коде.
Нужно слушать не только что кто-то там сказал, но еще и почему кто-то так сказал.
Вы предлагаете отлавливать dangling pointers — это это ошибочная ситуация, weak_ptr и shared_ptr позволяют ее отловить и являются стандартным средством языка. Так что сравнение как раз таки имеет смысл.
Перфразирую, в стандратной библиотеке уже есть shared_ptr и weak_ptr, которые решают эту проблему. Ваше решение по сравнению с этим выигрывает в отсутствии динамических аллокаций (не известно сколько), проигрывает в алгоритмической сложности «освобождения» (не известно сколько). Я ничего не забыл?
— проблемы с памятью (с которыми Rust должен помогать по идее)
— unsafe размазанный по коду (с которым по идее должны помагать «правила хорошего тона» Rust-а)
— все те же алгоритмические и логические проблемы (к которым Rust напрямую, конечно, не имеет отношения, но код решающий аналогичную задачу на C был несколько компактнее и проще, ИМХО, именно Rust стал источником многих из этих проблем, как раз из-за переусложнения того, что должно быть простым).
Короче Rust может стать хорошим инструментом только в руках тех, кто умеет им пользоваться (удивительно, но как и любой другой инструмент, включая C++).
В дополнение к этому идеология Rust («безопасность» через кучу ограничений), просто не согласуется с идеологией ядра Linux (не знаешь что делаешь — не суй свой нос). Да и касательно отлова проблем с памятью, в ядре Linux есть довольно хорошие средства нахождения таких проблем, Rust мало что к этому может добавить. Да и проблемы неправильного использования памяти, вероятно, самый простой класс проблем, с которыми приходится сталкиваться в ядре, но Rust не предлагает никакого решения для большинства из других проблем.
2. Я не говорил, что с weak_ptr нет проблем, мой поинт в том, что вы неправы насчет «несравнимости» подхода с дополнительной динамической аллокацией и без нее.
3. Еще одно подтверждение, что правильный дизайн и голова — лучшие друзья инженера. Умные указатели не освобождают от обязанности понимать, что происходит в коде, в частности, знать кто какими объектами владеет и чем ограничено время жизни объектов, все остальное лишь помошники в этом (возможно даже очень хорошие), но не замена голове.