Здравствуйте, VTT, Вы писали:
VTT>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна.
Даже движок браузера пишут. Похоже, что вполне жизнеспособно.
VTT>Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами.
Сложные правила разделяемого владения объектами не нужны.
VTT>Заявления про безопасность раста — брехня.
По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание а) наличия возможностей по сокращению количества исключений времени выполнения; б) отсутствие возможностей легко отстрелить себе яйца.
Здравствуйте, AlexRK, Вы писали:
ARK>Даже движок браузера пишут. Похоже, что вполне жизнеспособно.
Если мне не изменяет память, то была одна-единственная заметка, что где-то в мозиле его начали задействовать.
ARK>Сложные правила разделяемого владения объектами не нужны.
Ну как не нужны? Вон в статье из первого поста человек приводит пример с виджетами.
Причем это достаточно простой пример, если бы он вздумал запилить какие-нибудь RustForms, то был бы вообще ад.
ARK>По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание ARK>а) наличия возможностей по сокращению количества исключений времени выполнения;
Не понял, в расте же нет исключений (по мне это тоже скорее недостаток), а макрос try! просто прячет проверку результата и резкий выход из метода. ARK>б) отсутствие возможностей легко отстрелить себе яйца.
Ну допустим таких возможностей в нем действительно поменьше, чем в С/С++, но уж никак не меньше чем в каком-нибудь C#.
Скорее еще какие-нибудь расто-специфические добавляются.
В плане безопасности я бы поставил раст где-нибудь на уровень пониже go.
Причем в первую очередь из-за наличия растущей стандартной библиотеки для неискушенных кодеров (постоянно дергать из него с-шные интерфейсы мало бы кто осилил).
А как пример безопасного языка я бы привел ada/spark, с верификацией и без динамического выделения памяти.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
ARK>>Даже движок браузера пишут. Похоже, что вполне жизнеспособно. VTT>Если мне не изменяет память, то была одна-единственная заметка, что где-то в мозиле его начали задействовать.
Тем не менее. А уж среди любительских поделок есть даже примитивная операционная система.
ARK>>Сложные правила разделяемого владения объектами не нужны. VTT>Ну как не нужны? Вон в статье из первого поста человек приводит пример с виджетами.
Ну вот так не нужны. ИМХО, эта вот практика — совать ссылки на родителей в детей — порочна до мозга костей. И очень правильно Раст такой говнокод запрещает.
ARK>>а) наличия возможностей по сокращению количества исключений времени выполнения; VTT>Не понял, в расте же нет исключений (по мне это тоже скорее недостаток), а макрос try! просто прячет проверку результата и резкий выход из метода.
Под исключениями здесь я имел в виду не языковые конструкции, а просто ошибки времени исполнения, которые есть везде. Соответственно, чем больше возможностей уберечься от них, тем лучше.
ARK>>б) отсутствие возможностей легко отстрелить себе яйца. VTT>Ну допустим таких возможностей в нем действительно поменьше, чем в С/С++, но уж никак не меньше чем в каком-нибудь C#.
Гораздо меньше, чем в C#, хотя бы за счет отсутствия NPE и рефлексии.
VTT>Скорее еще какие-нибудь расто-специфические добавляются.
Трудно сказать. Лично я таких не знаю, хотя может что-то и есть.
VTT>В плане безопасности я бы поставил раст где-нибудь на уровень пониже go.
Ээээ.... Крайне оригинальное мнение.
VTT>Причем в первую очередь из-за наличия растущей стандартной библиотеки для неискушенных кодеров (постоянно дергать из него с-шные интерфейсы мало бы кто осилил).
Не понял, как это понижает безопасность. По-моему, совершенно наоборот.
VTT>А как пример безопасного языка я бы привел ada/spark, с верификацией и без динамического выделения памяти.
В простой Аде есть динамическое выделение памяти. Впрочем согласен, SPARK, безусловно, один из самых безопасных языков. Только он совершенно не мейнстримовый и даже не "около". Среди мейнстрима и около — круче Раста нет пока никого.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Я согласен. Но за safety всегда приходится чем-то платить. Я готов к тому что мои парсеры входных данных будут выглядеть так себе, зато гарантированно не смогут уронить приложение.
Непонятно, что хуже, когда "парсер входных данных" честно роняет программу, наевшись плюшек, или когда он лишь делает вид, что работает, но данные парсит неправильно. А когда код выглядит так себе, шансы, что он работает некорректно (пусть и без сегфолтов) очень сильно возрастают.
Здравствуйте, AlexRK, Вы писали:
VTT>>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна.
ARK>Даже движок браузера пишут. Похоже, что вполне жизнеспособно.
По большому счету, это пока единственная более-менее серьезная программа, написанная на этом языке. Да и та пока не написана. Даже компилятор евонный написан в основном не на нем.
ARK>По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание а) наличия возможностей по сокращению количества исключений времени выполнения; б) отсутствие возможностей легко отстрелить себе яйца.
Rust вряд ли безопаснее или мейнстримовей, чем Go.
Здравствуйте, VTT, Вы писали:
ARK>>Даже движок браузера пишут. Похоже, что вполне жизнеспособно. VTT>Если мне не изменяет память, то была одна-единственная заметка, что где-то в мозиле его начали задействовать.
Его, собственно, мозила и продвигает. Мне кажется, у них пороху не хватит втащить в мейнстрим новый язык.
Здравствуйте, Pzz, Вы писали:
ARK>>Даже движок браузера пишут. Похоже, что вполне жизнеспособно. Pzz>Даже компилятор евонный написан в основном не на нем.
Компилятор Раста примерно полностью написан на самом Расте.
ARK>>По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание а) наличия возможностей по сокращению количества исключений времени выполнения; б) отсутствие возможностей легко отстрелить себе яйца. Pzz>Rust вряд ли безопаснее или мейнстримовей, чем Go.
Go менйстримовей, Rust безопаснее — количество мест, где все может упасть, ограничено сравнительно небольшим количеством случаев (ну и явными unsafe блоками).
Здравствуйте, AlexRK, Вы писали:
ARK>>>Даже движок браузера пишут. Похоже, что вполне жизнеспособно. Pzz>>Даже компилятор евонный написан в основном не на нем.
ARK>Компилятор Раста примерно полностью написан на самом Расте.
Насколько я понимаю, на расте написан только парсер, а кодогенератор используется от LLVM (написанный на C++)
ARK>>>По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание а) наличия возможностей по сокращению количества исключений времени выполнения; б) отсутствие возможностей легко отстрелить себе яйца. Pzz>>Rust вряд ли безопаснее или мейнстримовей, чем Go.
ARK>Go менйстримовей, Rust безопаснее — количество мест, где все может упасть, ограничено сравнительно небольшим количеством случаев (ну и явными unsafe блоками).
По большому счету, проблема не в том, упадет ли программа. Если именно упадет — туда и дорога. Реальная проблема — это когда программа, наевшись плюшек, может сделать такое, чего делать не должна.
Программа на go может упасть. Но вот buffer overflow или доступ к неинициализированной/невыделенной памяти на go без unsafe не сделаешь. А unsafe там как-то не очень-то и нужен.
Здравствуйте, AlexRK, Вы писали:
ARK>Go менйстримовей, Rust безопаснее — количество мест, где все может упасть, ограничено сравнительно небольшим количеством случаев (ну и явными unsafe блоками).
Go безопасней, потому что там GC. Но это уже язык из другой лиги. Те, кого устраивает GC, не будут смотреть на Rust. А те, кто смотрит на Rust, не будут смотреть на языки с GC. Rust конкурирует с C, C++, Objective C, Swift.
Здравствуйте, uncommon, Вы писали:
U>TL;DR: Раст — это постоянная борьба с borrow-checker'ом, плюс трудность выражения конструкций, которые очень легко описываются в других языках (C++, C#). Что делает написание таких вещей, как GUI очень даже нетрививальной задачей.
Исправленный TL;DR: некто потыкался в Rust, попытался натянуть на него ООП, не нашёл в документации std::rc::Weak, пожаловался, что всё сложно, и ушёл.
Здравствуйте, VTT, Вы писали:
VTT>Ничего особого в плане безопасности, кроме запрета на множество ссылок на изменяемый объект, раст в общем-то не предлагает. VTT>Зато использования (прямого или косвенного) unsafe блоков в нем избежать практически невозможно. VTT>Кроме того, эти заявления по факту исходят в основном от самих разработчиков языка и пока что являются чисто голословными.
Случай так называемого вранья. Кроме отсутствия data race conditions, Rust обеспечивает невозможность разыменования висячих указателей и нулевых ссылок, соответственно и гарантирует отсутствие двойного освобождения памяти.
В моей программе (графика на D3D12, около 6000 строк) unsafe используется только для FFI. ДОБАВЛЕНИЕ: к хорошему быстро привыкаешь, и когда программа валится с сегфолтом вместо того, чтобы записать в лог сообщение об ошибке (в 95% процентах случаев потому что писатели графических драйверов не предусмотрели какой-то вариант использования API, и один случай был по моей вине: отсутствие ограничения типов COM-интерфейсов, передаваемых в функции, в сгенерированных биндингах к WinAPI (уже исправлено)), это очень раздражает и совершенно не добавляет тёплых чувств к С++, на котором эти самые драйвера написаны. Валить это на программистов, как обычно делается, не вижу смысла. Программисты в NVidia, Microsoft, AMD и Intel наверняка не менее опытны чем я. Кстати, вчера отправил эту самую программку в Microsoft как тест-кейс для поиска багов в GPU-based validation и Microsoft Basic Render Driver.
Компиляторы, обеспечивающие математически-доказанное соответствие спецификации, можно пересчитать по пальцам одной руки. Так что в этом отношении Раст не выделяется. Могу добавить, что в разработке системы типов Rust участвует группа математиков, см. http://plv.mpi-sws.org/rustbelt/
Вот смотрю я на этот код и вижу, что всё же Rust существенно более многословен (ну естественно речь не о количестве байт кода или длине ключевых слов, а о количестве сущностей и операций), чем его более древние конкуренты по нише. Понятно, что эта многословность является ценой за некоторые автоматические гарантии, которые в других языках ложатся на программиста. Весь вопрос в том, адекватна ли эта цена получаемым преимуществам...
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, VTT, Вы писали:
ARK>>>Сложные правила разделяемого владения объектами не нужны. VTT>>Ну как не нужны? Вон в статье из первого поста человек приводит пример с виджетами.
ARK>Ну вот так не нужны. ИМХО, эта вот практика — совать ссылки на родителей в детей — порочна до мозга костей. И очень правильно Раст такой говнокод запрещает.
Чем это она порочна?
А что вы скажите на счет произвольного графа, где все ноды могут как угодно ссылаться друг на друга?
Ну или вот совсем простой пример:
{
TLogger logger;
TWorker worker(logger); // сохроняет ссылку на logger
TJob job(logger); // тоже сохроняет ссылку на logger
worker.Do(job); // что-то делаем, дергая logger в процессе
...
} // выходим из области видимости, все разрушается
Тут на логгер одновременно ссылаются сразу два других объекта, но никаких дополнительных телодвижений не требуется.
В расте же, на такие тривиальные случаи придется городить указатели с подсчетом ссылок или что похуже. (как в том Ералаше, про мальчика с двумя билетами и проездным :D)
Мне кажется, что недоделка раста заключается в отождествлении передачи ссылки на изменяемый объект и передачи владения этим объектом.
Это конечно здорово упрощает жизнь разработчиков компилятора, но с точки зрения разработки эффективного кода только вставляет палки в колеса.
Не помню названия, но был какой-то проект надстройки для C++, где borrower был реализован потолковее.
Там вроде для обозначения владения объектом добавлялся специальный compile-time токен (разрушить объект мог только владелец токена).
А компилятор следил, чтобы время жизни указателей на этот объект не превышало время жизни объекта.
При этом владение токеном могло быть и косвенным, в примерах кажется была даже реализация xor linked list.
ARK>Не понял, как это понижает безопасность. По-моему, совершенно наоборот.
Я тоже имел ввиду, что повышает. Иначе я бы расположил его даже ниже простого С по безопасности.
ARK>Впрочем согласен, SPARK, безусловно, один из самых безопасных языков. Только он совершенно не мейнстримовый и даже не "около". Среди мейнстрима и около — круче Раста нет пока никого.
Скорее он просто не особо нужен для майнстримных приложений.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
ARK>>Ну вот так не нужны. ИМХО, эта вот практика — совать ссылки на родителей в детей — порочна до мозга костей. И очень правильно Раст такой говнокод запрещает. VTT>Чем это она порочна?
Увеличивает связность системы там, где этого можно избежать.
VTT>А что вы скажите на счет произвольного графа, где все ноды могут как угодно ссылаться друг на друга?
Слишком общий вопрос. Если ответить в таком же общем ключе — лучше всего избегать таких графов (ИМХО, конечно же).
VTT>Ну или вот совсем простой пример: VTT>Тут на логгер одновременно ссылаются сразу два других объекта, но никаких дополнительных телодвижений не требуется.
А потом один из объектов внезапно станет более долгоживущим и сохранит в себе ссылку на убитый логгер.
VTT>В расте же, на такие тривиальные случаи придется городить указатели с подсчетом ссылок или что похуже. (как в том Ералаше, про мальчика с двумя билетами и проездным :D)
Ну, обычно переписать что-то "в лоб" на языке с другой идеологией нельзя. Надо изначально думать иначе.
VTT>Мне кажется, что недоделка раста заключается в отождествлении передачи ссылки на изменяемый объект и передачи владения этим объектом.
А мне наоборот кажется, что это очень верный путь. Алиасинг (множественные ссылки на один объект) пора уже потихоньку начинать искоренять.
VTT>Это конечно здорово упрощает жизнь разработчиков компилятора, но с точки зрения разработки эффективного кода только вставляет палки в колеса.
Код с алиасингом не более эффективен, он более запутан и более просто пишется (но не обязательно более просто читается).
VTT>Не помню названия, но был какой-то проект надстройки для C++, где borrower был реализован потолковее. VTT>Там вроде для обозначения владения объектом добавлялся специальный compile-time токен (разрушить объект мог только владелец токена). VTT>А компилятор следил, чтобы время жизни указателей на этот объект не превышало время жизни объекта. VTT>При этом владение токеном могло быть и косвенным, в примерах кажется была даже реализация xor linked list.
В С++ невозможно достичь никаких гарантий, поэтому все чекеры для него бесполезны куда менее полезны, чем для строгих языков. Если же оставить это за скобками и говорить о самой идее. В принципе вариант неплохой, напоминает принцип сборки мусора, только во время компиляции. Если хочется иметь много ссылок на один объект, то это, наверное, лучший вариант. Но лично мне, как я выше уже писал, нравится и кажется более правильным принцип "один объект — одна ссылка".
ARK>>Не понял, как это понижает безопасность. По-моему, совершенно наоборот. VTT>Я тоже имел ввиду, что повышает. Иначе я бы расположил его даже ниже простого С по безопасности.
А что такое "безопасность" в вашем понимании вообще?
Если понимать под безопасностью то, что я написал в начале, то Go/C# (про голый С это было круто) не являются более безопасными, чем Rust, т.к. в них ошибки могут генерироваться куда бОльшим количеством конструкций — одно только разыменование нулевого указателя это мегатонны спящих багов. В Расте причиной паники может быть нехватка памяти, переполнение стека, арифметическое переполнение, выход за границы массива, _явный_ unwrap (видимый в коде) и искусственно созданная паника (вроде ничего не забыл).
Потенциально язык ну очень хороший с великолепными идеями. На практике, необходимость написать "first_child.borrow().any().downcast_ref::<TaggedBase>().unwrap().tag" вместо "first_child.tag" несколько охлаждает пыл. Я просто представляю себе проект полный вот такими конструкциями и не могу понять, хочу ли я видеть такое каждый день
Здравствуйте, kaa.python, Вы писали:
KP>Потенциально язык ну очень хороший с великолепными идеями. На практике, необходимость написать "first_child.borrow().any().downcast_ref::<TaggedBase>().unwrap().tag" вместо "first_child.tag" несколько охлаждает пыл. Я просто представляю себе проект полный вот такими конструкциями и не могу понять, хочу ли я видеть такое каждый день
Эта штука написана на коленке за полчаса. Если делать нормальную библиотеку, то обращение к полям виджета будет выглядеть проще, например так:
let first_tagged = as_tagged(&first_child).unwrap();
println!("First tag: {:?}", first_tagged.tag());
Здравствуйте, AlexRK, Вы писали:
VTT>>Тут на логгер одновременно ссылаются сразу два других объекта, но никаких дополнительных телодвижений не требуется.
ARK>А потом один из объектов внезапно станет более долгоживущим и сохранит в себе ссылку на убитый логгер. ARK>Ну, обычно переписать что-то "в лоб" на языке с другой идеологией нельзя. Надо изначально думать иначе.
С какой другой идеологией? borrow checker и умные указители по сути являются чем-то вроде enforced RAII.
Пример "другой" идеологии — это например отказ от динамического выделения памяти и рекурсии (все распределяется в compile-time), или наоборот, отказ от освобождения выделенной памяти, но ограничение срока жизни программы.
Как это иначе? Всегда использовать shared_ptr / weak_ptr (или аналогичные конструкции в раст) вместо передачи обычной ссылки?
Допустим, аккуратно переписав тот кусок с логгером с использованием RC указателей мы избавились от проблемы висячей ссылки на убитый логгер.
Но может вылезти совершенно другая, вызванная внезапным незапланированным удлинением срока жизни этого логгера.
Например, следующий созданный экземпляр логгера не сможет открыть файл или подключится к сборщику логов.
Я вообще хочу сказать, что контролировать удаление объекта после всех ссылок на него — это еще не все.
Контролировать жизненный цикл — вот что сложно.
Даже просто удалить объект после всех ссылок на него может быть недостаточно, иногда приходится реализовывать специальные сценарии освобождения объектов, когда ссылающиеся на него объекты прекращают это делать в строгом порядке.
Умные указатели и бдительный borrow checker совсем не панацея, а в сложных сценариях (прежде всего с пересечением границы языков) — бесполезные.
ARK>А мне наоборот кажется, что это очень верный путь. Алиасинг (множественные ссылки на один объект) пора уже потихоньку начинать искоренять. ARK>Код с алиасингом не более эффективен, он более запутан и более просто пишется (но не обязательно более просто читается).
Какое-то странное утверждение, эффективный код просто обязан иметь множественные ссылки на один объект, особенно если он по размеру значительно больше ссылки или представляет собой ресурс.
А если вы про сложности, вызванные алиасингом в смысле неспособности компилятора определять осуществляется ли доступ к одному и тому же участку / пересекающимся участкам памяти, — так механизм работы с ссылками (те более с повышенной строгостью, как в раст) как раз должен помогать их преодолевать.
ARK>А что такое "безопасность" в вашем понимании вообще? ARK>Если понимать под безопасностью то, что я написал в начале, то Go/C# (про голый С это было круто) не являются более безопасными, чем Rust, т.к. в них ошибки могут генерироваться куда бОльшим количеством конструкций — одно только разыменование нулевого указателя это мегатонны спящих багов. В Расте причиной паники может быть нехватка памяти, переполнение стека, арифметическое переполнение, выход за границы массива, _явный_ unwrap (видимый в коде) и искусственно созданная паника (вроде ничего не забыл).
Под безопасностью я подразумеваю скорее способность программы демонстрировать заданное поведение.
В этом смысле например разыменование нулевого указателя (в рантайме) само по себе не обязательно является проблемой безопасности, так как поведение приложения (аварийное завершение) в данном случае определено.
Хотя и может подразумевать наличие дефекта в приложении, который потенциально создает угрозу безопасности.
А вот UB при разыменовании нулевого указателя в коде C++ — это как раз дырища в безопасности, так как теряется контроль.
Если бы в расте не пилили усердно стандартную библиотеку, то уверения создателей раста в безопасности их языка в купе с необходимостью на каждый чих дергать голые С-шные методы образовывали бы гремучую смесь. Ну и вообще молодо-зелено.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>С какой другой идеологией? borrow checker и умные указители по сути являются чем-то вроде enforced RAII.
С идеологией "один объект — одна мутабельная ссылка".
VTT>Как это иначе? Всегда использовать shared_ptr / weak_ptr (или аналогичные конструкции в раст) вместо передачи обычной ссылки?
Иначе — это, например, отказаться от ссылок на родителя.
VTT>Я вообще хочу сказать, что контролировать удаление объекта после всех ссылок на него — это еще не все. VTT>Контролировать жизненный цикл — вот что сложно.
Верно, и в Расте жизненный цикл виден куда лучше, чем в языках с неконтролируемым алиасингом.
VTT>Умные указатели и бдительный borrow checker совсем не панацея, а в сложных сценариях (прежде всего с пересечением границы языков) — бесполезные.
Не панацея, но лучше, чем полный хаос.
VTT>Какое-то странное утверждение, эффективный код просто обязан иметь множественные ссылки на один объект, особенно если он по размеру значительно больше ссылки или представляет собой ресурс.
ИМХО, совершенно не обязан, ссылками можно и нужно обмениваться, а не прикапывать у себя.
VTT>Под безопасностью я подразумеваю скорее способность программы демонстрировать заданное поведение. VTT>В этом смысле например разыменование нулевого указателя (в рантайме) само по себе не обязательно является проблемой безопасности, так как поведение приложения (аварийное завершение) в данном случае определено. VTT>Хотя и может подразумевать наличие дефекта в приложении, который потенциально создает угрозу безопасности. VTT>А вот UB при разыменовании нулевого указателя в коде C++ — это как раз дырища в безопасности, так как теряется контроль.
Любое разыменование нулевого указателя является потенциальной угрозой безопасности (а формально доказать обратное очень сложно, если вообще возможно). Взрыв Ариана-5 произошел из-за вполне себе рядового исключения, а вовсе не из-за UB. Так что и UB, и исключения в плане угрозы безопасности эквивалентны. Мы не имеем права сказать, что одна программа безопаснее другой, если в первой есть только исключения, а во второй есть и исключения, и UB. Программа безопаснее _только_ в том случае, если количество в ней любых ошибок на одну строку кода (хоть исключений, хоть UB) _меньше_, чем в другой программе. (Это, конечно, если брать просто различие "UB или исключение", без подробной классификации типов ошибок.)
Здравствуйте, AlexRK, Вы писали:
ARK>С идеологией "один объект — одна мутабельная ссылка".
Ну ссылка-то может и доступна только одна, но это "одномоментно".
Я бы не сказал, что раст прямо ограничивает распространение ссылок, он просто не дает их раздавать без "безопасного" rc указателя.
Скорее даже раст провоцирует чрезмерное использование этих указателей.
ARK>Иначе — это, например, отказаться от ссылок на родителя.
И как в таком случае будет выглядеть иерархия виджетов, хотя бы примерно?
Информация о том, кто чей родитель должна же где-то храниться и быть доступна этим виджетам, чтобы обеспечить возможность прохождения событий (вызовов методов) вверх и вниз по иерархии.
ARK>Верно, и в Расте жизненный цикл виден куда лучше, чем в языках с неконтролируемым алиасингом.
Допустим, с элементарыми сценариями владения все действительно замечательно.
Но как только начали раздавать ссылки, то все становится не так радужно.
Во-первых правило "одной мутабельной ссылки" для rc указателей работает только в рантайме.
Если ресурс уже сдох или им владеет кто-то еще, то будет panic.
Это вроде как безопасней чем разыменование нулевых указателей, но и вредно, так как контроль все равно лежит исключительно на разработчиках (которым они явно пренебрегают).
Россыпи unwrap в расте похожи на настоящий антипаттерн.
Во-вторых неявное копирование (или его отсутствие) в расте — это тихий ужас.
Проявляется и при обычных вызовах методов типа foo(value) — нет никакой возможности определить, перемещается ли объект, или копируется.
И во всяких хитрых вызовах, которые могут неявно сделать copy on write, типа make_mut.
ARK>ИМХО, совершенно не обязан, ссылками можно и нужно обмениваться, а не прикапывать у себя.
Чтобы обмениваться с кем-то ссылками, придется держать ссылки на тех, с кем хочется обмениваться.
И если постоянно обмениваться ссылками, то это как раз усложнит управление жизненным циклом.
ARK>Любое разыменование нулевого указателя является потенциальной угрозой безопасности (а формально доказать обратное очень сложно, если вообще возможно). Взрыв Ариана-5 произошел из-за вполне себе рядового исключения, а вовсе не из-за UB. Так что и UB, и исключения в плане угрозы безопасности эквивалентны. Мы не имеем права сказать, что одна программа безопаснее другой, если в первой есть только исключения, а во второй есть и исключения, и UB. Программа безопаснее _только_ в том случае, если количество в ней любых ошибок на одну строку кода (хоть исключений, хоть UB) _меньше_, чем в другой программе. (Это, конечно, если брать просто различие "UB или исключение", без подробной классификации типов ошибок.)
Ну вот не надо винить одно исключение (причем вроде как корректно выброшенное) во взрыве ариан.
Взрыв произошел из-за целой цепочки программных, технических и организационных недоработок, которые наложились друг на друга в роковой последовательности.
Вообще приравнивать исключение (читай языковой механизм) к неконтролируемому рандому UB — это нонсенс.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
