TL;DR: Раст — это постоянная борьба с borrow-checker'ом, плюс трудность выражения конструкций, которые очень легко описываются в других языках (C++, C#). Что делает написание таких вещей, как GUI очень даже нетрививальной задачей.
Мне особо понравилась конструкция Vec<Rc<RefCell<T>>>. Это, типа, идиоматическая запись в Расте коллекции объектов с раздельным владением. А элементы вектора создавать так: Rc::new(RefCell::new(WidgetObj::new(1))). Няшненько.
Здравствуйте, uncommon, Вы писали:
U>TL;DR: Раст — это постоянная борьба с borrow-checker'ом, плюс трудность выражения конструкций, которые очень легко описываются в других языках (C++, C#). Что делает написание таких вещей, как GUI очень даже нетрививальной задачей.
U>Мне особо понравилась конструкция Vec<Rc<RefCell<T>>>. Это, типа, идиоматическая запись в Расте коллекции объектов с раздельным владением. А элементы вектора создавать так: Rc::new(RefCell::new(WidgetObj::new(1))). Няшненько.
Ну да, быренько чего-то наговнякать уже не получается. Для того и делали.
Здравствуйте, uncommon, Вы писали:
U>Уже все почти забыли о Расте, а вот он опять всплыл.
Я не забыл! Время от времени ставлю свежую версию, собираюсь попробовать, а тут бац, новая версия выходит, и так по кругу.
U>Why I’m dropping Rust
U>TL;DR: Раст — это постоянная борьба с borrow-checker'ом, плюс трудность выражения конструкций, которые очень легко описываются в других языках (C++, C#). Что делает написание таких вещей, как GUI очень даже нетрививальной задачей.
На реддите автору дали справку, что он дурак и зря пытался ООПшные привычки тащить в полуфункциональный язык. Не осилил просто правильный подход.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не путай макросы C++ и гигиеничные макросы типа Lisp/Nemerle.
Я их не путаю. Детали реализации макросов, будь то просто подстановка текста, как в препроцессоре С, или более изощренные средства, не столь важны.
EP>В диалектах Lisp'а (например Clojure) макросы используются во всю.
Ну это не показатель. И у меня есть большие сомнения, что макросы в этих языках во всю используются от хорошей жизни.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, AlexRK, Вы писали:
ARK>Даже движок браузера пишут. Похоже, что вполне жизнеспособно.
Если мне не изменяет память, то была одна-единственная заметка, что где-то в мозиле его начали задействовать.
ARK>Сложные правила разделяемого владения объектами не нужны.
Ну как не нужны? Вон в статье из первого поста человек приводит пример с виджетами.
Причем это достаточно простой пример, если бы он вздумал запилить какие-нибудь RustForms, то был бы вообще ад.
ARK>По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание ARK>а) наличия возможностей по сокращению количества исключений времени выполнения;
Не понял, в расте же нет исключений (по мне это тоже скорее недостаток), а макрос try! просто прячет проверку результата и резкий выход из метода. ARK>б) отсутствие возможностей легко отстрелить себе яйца.
Ну допустим таких возможностей в нем действительно поменьше, чем в С/С++, но уж никак не меньше чем в каком-нибудь C#.
Скорее еще какие-нибудь расто-специфические добавляются.
В плане безопасности я бы поставил раст где-нибудь на уровень пониже go.
Причем в первую очередь из-за наличия растущей стандартной библиотеки для неискушенных кодеров (постоянно дергать из него с-шные интерфейсы мало бы кто осилил).
А как пример безопасного языка я бы привел ada/spark, с верификацией и без динамического выделения памяти.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
EP>>Да. Причём "короче" может быть качественным понятием, а не количественным. EP>>Например генерация автомата из императивного по форме кода а-ля stackless await. VTT>А где пример-то?
Например computation expression в Nemerle:
https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro
The C# await/async implementation and the Nemerle asynchronous programming approach have much in common, but with a big difference: await/async requires language support, but asynchronous programming in Nemerle is implemented with monads, which are part of the standard library, not the language itself.
VTT>>>Не ошибиться в копипасте? EP>>Да, этого мало? VTT>Ну опять же, укорачивать и прятать копипасту за макросами не должно быть самоцелью.
Вполне достойная самоцель. Многие языковые фичи только и делают что уменьшают boilerplate
VTT>Допустим, некоторые случаи действительно не получится сделать более толковыми языковыми средствами.
Не надо допускать — это объективный факт. Есть реальный спрос на мета/макро-прогарммирование — C++, D, Rust, Nemerle, Lisp (веб-программирование на Clojure), T4, и даже со всех углов слышны воодушевлённые придыхания о Roslyn'е от, казалось бы, программистов корпоративных систем и прочих опердней.
VTT>Но если таких случаев выходит многовато — то это скорее говорит об ущербности языка.
Так и есть — макросы очевидно не от хорошей жизни появляются — любой язык общего назначения в чём-то ущербен. И рано или поздно натыкаешься на эту ущербность. В идеальном языке не было бы никакой необходимости в макросах — в нём уже были бы средства для выражения любой проблемы на языке предметной области.
И лучше иметь возможность обойти эту ущербность библиотечными средствами, а не ждать пока введут новую фичу в язык, её реализуют на всех требуемых компиляторах, и они через несколько апдейтов систем дойдут до конечных программистов приложений. Программистам библиотек ещё хуже — для расширения клиентской базы приходится использовать старые компиляторы.
VTT>А если таких случаев выходит немного — то это недостаточная причина прикручивать макросы. VTT>Даже в многострадальном с++ с его архаичным препроцессором практически единственная ситуация, где использование порождающих макросов еще как-то оправдано — когда надо в одном месте заиметь имя типа / метода и аналогичный текстовый литерал.
Да ладно, зачем тогда по-твоему появились штуки типа Boost.Preprocessor? В нём фичи типа циклов реализованы огромными усилиями, вопреки архаичности препроцессора.
Конкретный пример использования — BOOST_FUSION_DEFINE_STRUCT — описываешь структуру один раз, и автоматом получаешь любой возможный обход, в том числе для вполне земной сериализации.
Также можно использовать для генерации тех же автоматов из императивного кода, но в таких случаях уже серьёзно не хватает возможностей препроцессора.
EP>>Это разруливается namespace'ами. EP>>Да и например в Lisp вызов макроса по форме аналогичен вызову функции, так что тут пересечения с будущими возможными фичами не больше чем в случае с обычными функциями. VTT>Какой ужас...
В чём ужас?
EP>>Могу назвать реально полезные фичи в новых версиях всех mainstream языков. Наличие же плохих фич не говорит о том что на расширение в полезных направлениях нет спроса. VTT>Вообще говоря, фичи могут быть и хорошими, но при этом избыточными.
Для обсуждаемой темы — не суть важно. В языках постоянно не хватает каких-либо хороших фич, макросы и прочее метапрограммирование позволяют на порядки сократить барьер их реализации — с изменения компиляторов до написания библиотеки в рамках текущей версии языка.
Здравствуйте, 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());
Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна.
Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами.
Заявления про безопасность раста — брехня.
Другая отталкивающая особенность языка — это макросы.
Просто наглый способ прятать крякозябры.
Причем отделаться от него практически невозможно.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, VTT, Вы писали:
VTT>>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна. CK>почему?
На практике часто требуется одновременно иметь более одной ссылки на изменяемый объект.
VTT>>Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами. CK>почему?
Из-за своей ограниченности.
VTT>>Заявления про безопасность раста — брехня. CK>почему?
Ничего особого в плане безопасности, кроме запрета на множество ссылок на изменяемый объект, раст в общем-то не предлагает.
Зато использования (прямого или косвенного) unsafe блоков в нем избежать практически невозможно.
Кроме того, эти заявления по факту исходят в основном от самих разработчиков языка и пока что являются чисто голословными.
VTT>>Другая отталкивающая особенность языка — это макросы. CK>почему?
Ненужность макросов, как некого встроенного способа для кодогенерации в обход других языковых механизмов, всем известна.
Причем она была осознана достаточно давно, например такое было явно запрещено еще в Steelman language requirements.
В большинстве современных языков, таких как go, D, C#, Java, Haskell, макросы отсутствуют.
Там, где макросы живут по историческим причинам (прежде всего в C/C++), их использование рекомендуется ограничить.
VTT>>Просто наглый способ прятать крякозябры. CK>ето как?
Ето использовать макросы.
VTT>>Причем отделаться от него практически невозможно. CK>ты о чем вообще?
О наглом способе прятать крякозябры.
CK>в общем, кто-то тут любит писать ничем не подкрепленные и спорные утверждения, вместо того чтобы сесть и разобраться как следует, а потом обстоятельно написать, почему
Кто-то любит копипастить "почему" и обзывать чужие утверждения "ничем не подкрепленными" и "спорными" ничем не подкрепляя свои высказывания...
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>На практике часто требуется одновременно иметь более одной ссылки на изменяемый объект.
let mut guard = lock(mutex);
let vec = access(&mut guard);
vec.clear();
VTT>>>Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами. CK>>почему? VTT>Из-за своей ограниченности.
"сложные правила разделяемого владения объектами" — как по мне звучит как источник головной боли, Rust как раз и создан для того чтобы такие вещи можно было явным образом выразить в коде, иначе все это работает как-то, но в коде никак не выражено (хорошо если в комментарии описано). В общем, не убедительно. О какой ограниченности идет речь — не ясно.
VTT>Ничего особого в плане безопасности, кроме запрета на множество ссылок на изменяемый объект, раст в общем-то не предлагает. VTT>Зато использования (прямого или косвенного) unsafe блоков в нем избежать практически невозможно. VTT>Кроме того, эти заявления по факту исходят в основном от самих разработчиков языка и пока что являются чисто голословными.
Я вижу как Rust устраняет источник нескольких потенциальных уязвимостей за счет использования borrow checker-а. Ес-но, так как там возможно использование unsafe, возможны и дыры, однако, по крайней мере, эти потенциально опасные места явным образом помечены ключевым словом unsafe. Если приложение, написанное на Rust сегфолтится, значит причина точно в одном из этих unsafe блоков. Это значительно лучше чем ситуация "весь код это один большой unsafe блок".
VTT>Ненужность макросов, как некого встроенного способа для кодогенерации в обход других языковых механизмов, всем известна. VTT>Причем она была осознана достаточно давно, например такое было явно запрещено еще в Steelman language requirements. VTT>В большинстве современных языков, таких как go, D, C#, Java, Haskell, макросы отсутствуют. VTT>Там, где макросы живут по историческим причинам (прежде всего в C/C++), их использование рекомендуется ограничить.
В D макросы отсутствуют, зато есть CTFE + string mixins. В C# и Java народ активно юзает рефлексию для того, чего можно добиться макросами (надо ли говорить что это все происходит в рантайме). В Rust реализованы гигеенические макросы, так что типичных для си-макросов проблем там нет, при этом Rust позволяет делать на макросах вот такое: http://diesel.rs/
VTT>Кто-то любит копипастить "почему" и обзывать чужие утверждения "ничем не подкрепленными" и "спорными" ничем не подкрепляя свои высказывания...
Ну так они и были ничем не подкреплены, да и сейчас в общем то тоже, или ты считаешь что фраза "из-за свое ограниченности" полностью раскрывает тему?
Это к чему?
Лучше бы привели пример как безопасно и без лишнего оверхеда получить несколько ссылок на изменяемый объект (а еще лучше передать (получить) через границы языка или в разные потоки) и не расстроить borrow checker.
CK>"сложные правила разделяемого владения объектами" — как по мне звучит как источник головной боли, Rust как раз и создан для того чтобы такие вещи можно было явным образом выразить в коде, иначе все это работает как-то, но в коде никак не выражено (хорошо если в комментарии описано). В общем, не убедительно. О какой ограниченности идет речь — не ясно.
Вот в том-то и проблема, что раст никаким образом не позволяет описывать в коде эти сложные правила, кроме borrow checker ничего не предусматривается.
Вариант "сразу идеально переписать все на раст" не рассматривается, работать надо сейчас и с уже существующими библиотеками и системными api.
Да и "безопасный" код написанный на расте может обернуться неприемлемым оверхедом (Vec<Rc<RefCell<T>>> — это еще цветочки).
CK>Ес-но, так как там возможно использование unsafe, возможны и дыры, однако, по крайней мере, эти потенциально опасные места явным образом помечены ключевым словом unsafe. Если приложение, написанное на Rust сегфолтится, значит причина точно в одном из этих unsafe блоков. Это значительно лучше чем ситуация "весь код это один большой unsafe блок".
Даже один блок unsafe сразу переводит весь код в unsafe, т.е. прерывает цепочку накладываемых на код ограничений.
А использование unsafe (хотя бы косвенное через стандартную библиотеку) в расте неизбежно.
CK>В C# и Java народ активно юзает рефлексию для того, чего можно добиться макросами (надо ли говорить что это все происходит в рантайме).
А пацаны-то не знают
CK>В Rust реализованы гигеенические макросы, так что типичных для си-макросов проблем там нет, при этом Rust позволяет делать на макросах вот такое: http://diesel.rs/
Как раз возможность делать "такое" и есть проблема макросов.
CK>Ну так они и были ничем не подкреплены, да и сейчас в общем то тоже, или ты считаешь что фраза "из-за свое ограниченности" полностью раскрывает тему?
Видимо да.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>>>Другая отталкивающая особенность языка — это макросы. CK>>почему? VTT>Ненужность макросов, как некого встроенного способа для кодогенерации в обход других языковых механизмов, всем известна. VTT>Причем она была осознана достаточно давно, например такое было явно запрещено еще в Steelman language requirements. VTT>В большинстве современных языков, таких как go, D, C#, Java, Haskell, макросы отсутствуют. VTT>Там, где макросы живут по историческим причинам (прежде всего в C/C++), их использование рекомендуется ограничить.
Не путай макросы C++ и гигиеничные макросы типа Lisp/Nemerle. В диалектах Lisp'а (например Clojure) макросы используются во всю.
Вот смотрю я на этот код и вижу, что всё же Rust существенно более многословен (ну естественно речь не о количестве байт кода или длине ключевых слов, а о количестве сущностей и операций), чем его более древние конкуренты по нише. Понятно, что эта многословность является ценой за некоторые автоматические гарантии, которые в других языках ложатся на программиста. Весь вопрос в том, адекватна ли эта цена получаемым преимуществам...
Потенциально язык ну очень хороший с великолепными идеями. На практике, необходимость написать "first_child.borrow().any().downcast_ref::<TaggedBase>().unwrap().tag" вместо "first_child.tag" несколько охлаждает пыл. Я просто представляю себе проект полный вот такими конструкциями и не могу понять, хочу ли я видеть такое каждый день
Здравствуйте, VTT, Вы писали:
EP>>Не путай макросы C++ и гигиеничные макросы типа Lisp/Nemerle. VTT>Я их не путаю. Детали реализации макросов, будь то просто подстановка текста, как в препроцессоре С, или более изощренные средства, не столь важны.
Таким образом C++ templates и C# generics — тоже макросы, только более изощренные. Сейчас представить каждое без соответствующего — врядли представляется возможным (например я бы не стал писать на C# без generics, а то время когда это делал — вспоминаю просто с ужасом). При чём в большинстве языков — проблема обобщения так или иначе решается (это намек в сторону Java и D).
В C++ — наряду вместе с шаблонами ходят парой и текстовые макросы, при чём, сомневаюсь, что без последних жизнь реально возможна (как минимум это способ параметризировать код при вызове компилятора). В C# кстати такое тоже есть, хотя и более ограниченно, и кстати тоже вполне используется.
Получается, что:
VTT> Ненужность макросов, как некого встроенного способа для кодогенерации в обход других языковых механизмов, всем известна.
Звучит как минимум странно. Мне вот известно, что "макросы" очень нужны, при чём — чем они изощреннее — тем лучше.
Здравствуйте, VTT, Вы писали:
EP>>Ты же говоришь так, как будто для всех use-case'ов макросов есть альтернативы не уступающие по характеристикам. VTT>А какие у них есть характеристики? Короче записать?
Да. Причём "короче" может быть качественным понятием, а не количественным. Например генерация автомата из императивного по форме кода а-ля stackless await.
VTT>Не ошибиться в копипасте?
Да, этого мало?
EP>>Языки постоянно расширяются, в них добавляются новые реально полезные и необходимые фичи. Макросы позволяют реализовывать необходимые фичи как только появится потребность, не дожидаясь новой версии языка (есть конечно границы, но макросы существенно расширяют горизонт). VTT>Давать пользователям возможность самим расширять синтаксис, мимикрируя конструкции, которые в будущем могут в похожей форме прийти в язык — крайне недальновидное решение.
Это разруливается namespace'ами.
Да и например в Lisp вызов макроса по форме аналогичен вызову функции, так что тут пересечения с будущими возможными фичами не больше чем в случае с обычными функциями.
EP>>Если бы было так как ты говоришь, мол достаточно гранулировать и рефакторить "надлежащим образом" — то в языки и не добавлялись бы новые фичи VTT>К сожалению, чаще всего "фичи" добавляются просто в стремлении быть "данамично развивающимся языком", а не из рациональных соображений. VTT>Во многих языках даже наоборот, скорее пора выкидывать фичи.
Могу назвать реально полезные фичи в новых версиях всех mainstream языков. Наличие же плохих фич не говорит о том что на расширение в полезных направлениях нет спроса.
Здравствуйте, uncommon, Вы писали:
U>Уже все почти забыли о Расте, а вот он опять всплыл.
U>Why I’m dropping Rust
U>TL;DR: Раст — это постоянная борьба с borrow-checker'ом, плюс трудность выражения конструкций, которые очень легко описываются в других языках (C++, C#). Что делает написание таких вещей, как GUI очень даже нетрививальной задачей.
U>Мне особо понравилась конструкция Vec<Rc<RefCell<T>>>. Это, типа, идиоматическая запись в Расте коллекции объектов с раздельным владением. А элементы вектора создавать так: Rc::new(RefCell::new(WidgetObj::new(1))). Няшненько.
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще, мне бы лично хватили сборки мусора по умолчанию, и возможности от нее отказаться в данном конкретном месте, сказав волшебное слово, с целью выиграть эффективность ценой потери безопасности в том небольшом слое кода, где это имеет смысл.
Здравствуйте, D. Mon, Вы писали:
DM>На реддите автору дали справку, что он дурак и зря пытался ООПшные привычки тащить в полуфункциональный язык. Не осилил просто правильный подход.
Да тут даже не в функциональщине дело, он там пытается с trait-ом сделать что-то очень странное и удивляется тому, что так нельзя. Для программиста на Java или С# это не менее странно выглядит.
Здравствуйте, VTT, Вы писали:
VTT>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна.
Даже движок браузера пишут. Похоже, что вполне жизнеспособно.
VTT>Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами.
Сложные правила разделяемого владения объектами не нужны.
VTT>Заявления про безопасность раста — брехня.
По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание а) наличия возможностей по сокращению количества исключений времени выполнения; б) отсутствие возможностей легко отстрелить себе яйца.
Здравствуйте, VTT, Вы писали:
ARK>>Даже движок браузера пишут. Похоже, что вполне жизнеспособно. VTT>Если мне не изменяет память, то была одна-единственная заметка, что где-то в мозиле его начали задействовать.
Тем не менее. А уж среди любительских поделок есть даже примитивная операционная система.
ARK>>Сложные правила разделяемого владения объектами не нужны. VTT>Ну как не нужны? Вон в статье из первого поста человек приводит пример с виджетами.
Ну вот так не нужны. ИМХО, эта вот практика — совать ссылки на родителей в детей — порочна до мозга костей. И очень правильно Раст такой говнокод запрещает.
ARK>>а) наличия возможностей по сокращению количества исключений времени выполнения; VTT>Не понял, в расте же нет исключений (по мне это тоже скорее недостаток), а макрос try! просто прячет проверку результата и резкий выход из метода.
Под исключениями здесь я имел в виду не языковые конструкции, а просто ошибки времени исполнения, которые есть везде. Соответственно, чем больше возможностей уберечься от них, тем лучше.
ARK>>б) отсутствие возможностей легко отстрелить себе яйца. VTT>Ну допустим таких возможностей в нем действительно поменьше, чем в С/С++, но уж никак не меньше чем в каком-нибудь C#.
Гораздо меньше, чем в C#, хотя бы за счет отсутствия NPE и рефлексии.
VTT>Скорее еще какие-нибудь расто-специфические добавляются.
Трудно сказать. Лично я таких не знаю, хотя может что-то и есть.
VTT>В плане безопасности я бы поставил раст где-нибудь на уровень пониже go.
Ээээ.... Крайне оригинальное мнение.
VTT>Причем в первую очередь из-за наличия растущей стандартной библиотеки для неискушенных кодеров (постоянно дергать из него с-шные интерфейсы мало бы кто осилил).
Не понял, как это понижает безопасность. По-моему, совершенно наоборот.
VTT>А как пример безопасного языка я бы привел ada/spark, с верификацией и без динамического выделения памяти.
В простой Аде есть динамическое выделение памяти. Впрочем согласен, SPARK, безусловно, один из самых безопасных языков. Только он совершенно не мейнстримовый и даже не "около". Среди мейнстрима и около — круче Раста нет пока никого.
Здравствуйте, Pzz, Вы писали:
ARK>>Даже движок браузера пишут. Похоже, что вполне жизнеспособно. Pzz>Даже компилятор евонный написан в основном не на нем.
Компилятор Раста примерно полностью написан на самом Расте.
ARK>>По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание а) наличия возможностей по сокращению количества исключений времени выполнения; б) отсутствие возможностей легко отстрелить себе яйца. Pzz>Rust вряд ли безопаснее или мейнстримовей, чем Go.
Go менйстримовей, Rust безопаснее — количество мест, где все может упасть, ограничено сравнительно небольшим количеством случаев (ну и явными unsafe блоками).
Здравствуйте, 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/
Здравствуйте, 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 (видимый в коде) и искусственно созданная паника (вроде ничего не забыл).
Здравствуйте, 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 — это нонсенс.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
ARK>>Иначе — это, например, отказаться от ссылок на родителя. VTT>И как в таком случае будет выглядеть иерархия виджетов, хотя бы примерно? VTT>Информация о том, кто чей родитель должна же где-то храниться и быть доступна этим виджетам, чтобы обеспечить возможность прохождения событий (вызовов методов) вверх и вниз по иерархии.
Просто без ссылки на родителя. Что-то сделали, выставили нужное состояние/флаги и все. Не надо родителя дергать, он сам решит, когда ему что делать. Вверх по иерархии вызывать не надо. Только вниз.
VTT>Во-первых правило "одной мутабельной ссылки" для rc указателей работает только в рантайме. VTT>Если ресурс уже сдох или им владеет кто-то еще, то будет panic. VTT>Это вроде как безопасней чем разыменование нулевых указателей, но и вредно, так как контроль все равно лежит исключительно на разработчиках (которым они явно пренебрегают).
Ну, это вроде как хак для злобных буратино. По крайней мере эти штуки можно найти простым поиском по тексту.
VTT>Россыпи unwrap в расте похожи на настоящий антипаттерн.
С этим соглашусь. Но я бы предпочел явные россыпи unwrap неявным залежам NPE или неявной порче памяти в С/C++.
VTT>Во-вторых неявное копирование (или его отсутствие) в расте — это тихий ужас. VTT>Проявляется и при обычных вызовах методов типа foo(value) — нет никакой возможности определить, перемещается ли объект, или копируется. VTT>И во всяких хитрых вызовах, которые могут неявно сделать copy on write, типа make_mut.
Я что-то немного утерял нить разговора. Ну предположим, и что? Разве в С++ или C# в этом плане ситуация лучше? По-моему, гораздо хуже. Вот например, это же прекрасно — https://stackoverflow.com/questions/32009694/why-implicit-conversion-of-bool-to-string-isnt-an-error. А раз так, то какой смысл это упоминать?
ARK>>ИМХО, совершенно не обязан, ссылками можно и нужно обмениваться, а не прикапывать у себя. VTT>Чтобы обмениваться с кем-то ссылками, придется держать ссылки на тех, с кем хочется обмениваться.
Эээ, это зачем? Вот есть метод, у него на входе ссылка и на выходе ссылка. Никого он не держит.
VTT>И если постоянно обмениваться ссылками, то это как раз усложнит управление жизненным циклом.
Этот тезис необходимо обосновать. Мне кажется наоборот — что жизненный цикл в таком случае упрощается. Впрочем, формальных доказательств этого у меня нет.
VTT>Ну вот не надо винить одно исключение (причем вроде как корректно выброшенное) во взрыве ариан. VTT>Взрыв произошел из-за целой цепочки программных, технических и организационных недоработок, которые наложились друг на друга в роковой последовательности.
Согласен, но тем не менее это иллюстрирует тот факт, что исключения могут быть весьма разрушительны.
Была бы ситуация лучше, если бы вместо исключений были явно торчащие из кода сигналы ошибок (с формально доказанной "сердцевиной")? Трудно сказать. Во всяком случае исключения скрыты и их не видно, что явно безопасности не прибавляет.
VTT>Вообще приравнивать исключение (читай языковой механизм) к неконтролируемому рандому UB — это нонсенс.
С точки зрения оценки риска возможного ущерба — разницы нет. И то, и то потенциально может привести к катастрофе (не обязательно взрыв ракеты, но и, например, утечка конфиденциальных данных). Лично я именно это подразумеваю под безопасностью, а совсем не обязательно порчу памяти.
Здравствуйте, VTT, Вы писали:
VTT>Зато использования (прямого или косвенного) unsafe блоков в нем избежать практически невозможно.
Во первых, чем это плохо? В языках без явных unsafe блоков точно так же присутствуют "небезопасные моменты" (и всякие UB), просто они ещё и не сразу видны. Как по мне, явный unsafe — это преимущество: им можно (нужно) уделять больше внимания на ревью и т.д.
Во вторых, невозможность избежать явного использования unsafe несколько преувеличена.
VTT>В большинстве современных языков, таких как go, D, C#, Java, Haskell, макросы отсутствуют.
В Go даже шаблонов/дженериков нет, так себе пример для подражания. Зато из коробки есть кодогенерация (go generate) — чем она принципиально отличается от макросов? Тем что работает через "комментарии" и отдельную тулзу?
В D имеются продвинутые шаблоны, миксины и прочее CTFE. Результат по разрушительности мощности не сильно отличается.
Про Template Haskell, я так понимаю, ты тоже не слышал?
Для C# есть Roslyn, да и Nemerle не просто так появился.
VTT>Там, где макросы живут по историческим причинам (прежде всего в C/C++), их использование рекомендуется ограничить.
Это разные макросы.
Здравствуйте, VTT, Вы писали:
DE>>Опять же, как нужно? Тупо писать больше мусорного кода? VTT>Ну собственно основная претензия к макросам и заключается в том, что они представляют собой способ прятать весь boilerpalte "под ковер". VTT>Извольте писать помощников, рефакторить и гранулировать код надлежащим образом.
Макросы в том числе помогают убрать тот boilerplate, который невозможно убрать/отрефакторить/etc другими средствами языка.
Ты же говоришь так, как будто для всех use-case'ов макросов есть альтернативы не уступающие по характеристикам.
Языки постоянно расширяются, в них добавляются новые реально полезные и необходимые фичи. Макросы позволяют реализовывать необходимые фичи как только появится потребность, не дожидаясь новой версии языка (есть конечно границы, но макросы существенно расширяют горизонт).
Если бы было так как ты говоришь, мол достаточно гранулировать и рефакторить "надлежащим образом" — то в языки и не добавлялись бы новые фичи
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Макросы в том числе помогают убрать тот boilerplate, который невозможно убрать/отрефакторить/etc другими средствами языка.
Они ничего не убирают, весь этот boilerplate так и остается там, где его оставили.
EP>Ты же говоришь так, как будто для всех use-case'ов макросов есть альтернативы не уступающие по характеристикам.
А какие у них есть характеристики? Короче записать? Не ошибиться в копипасте?
EP>Языки постоянно расширяются, в них добавляются новые реально полезные и необходимые фичи. Макросы позволяют реализовывать необходимые фичи как только появится потребность, не дожидаясь новой версии языка (есть конечно границы, но макросы существенно расширяют горизонт).
Давать пользователям возможность самим расширять синтаксис, мимикрируя конструкции, которые в будущем могут в похожей форме прийти в язык — крайне недальновидное решение.
Хотя для языков, прежде всего ориентированных на продуктивность — вполне обычное.
EP>Если бы было так как ты говоришь, мол достаточно гранулировать и рефакторить "надлежащим образом" — то в языки и не добавлялись бы новые фичи
К сожалению, чаще всего "фичи" добавляются просто в стремлении быть "данамично развивающимся языком", а не из рациональных соображений.
Во многих языках даже наоборот, скорее пора выкидывать фичи.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, uncommon, Вы писали:
U>>TL;DR: Раст — это постоянная борьба с borrow-checker'ом, плюс трудность выражения конструкций, которые очень легко описываются в других языках (C++, C#). Что делает написание таких вещей, как GUI очень даже нетрививальной задачей.
U>>Мне особо понравилась конструкция Vec<Rc<RefCell<T>>>. Это, типа, идиоматическая запись в Расте коллекции объектов с раздельным владением. А элементы вектора создавать так: Rc::new(RefCell::new(WidgetObj::new(1))). Няшненько.
С>Ну да, быренько чего-то наговнякать уже не получается. Для того и делали.
И наиг такой язык нужен? Теперь придётся "наговнякать" долго и изворотливо.
Напоминает анекдот про розетки. "...Теперь будут погибать самые одарённые."
При этом главная проблема уменьшения сложности не решена.
ps: Почему-то меня современные компиляторы настараживают. Попробуйте быстренько сделать мальенький консольный hello world на C++11, так чтоб можно было запустить например на winnt4.
Если на древнем delphi7 скомпилировать какйю-нибудь фигню, так она и win95, и на win10 запускается.
Если попробывать старый visual studio поставить на новый 64битую ось, то увидим интересные надписи вида, "имеются известные проблеммы с совместимостью" часть функций будет безбожно глюкать и не работать.
А так как почти всё собирается новыми модными компиляторами. То скоро по будет пускаться только на win10 и только в защищёных шифрованых контейнерах, которые поддерживаются только новыми процессорами. Которые срочно надо всем обновить.
Здравствуйте, VTT, Вы писали:
VTT>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна. VTT>Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами. VTT>Заявления про безопасность раста — брехня.
Вообще, мне бы лично хватили сборки мусора по умолчанию, и возможности от нее отказаться в данном конкретном месте, сказав волшебное слово, с целью выиграть эффективность ценой потери безопасности в том небольшом слое кода, где это имеет смысл.
Здравствуйте, so5team, Вы писали:
Pzz>>Вообще, мне бы лично хватили сборки мусора по умолчанию, и возможности от нее отказаться в данном конкретном месте, сказав волшебное слово, с целью выиграть эффективность ценой потери безопасности в том небольшом слое кода, где это имеет смысл.
S>D's @nogc?
Хм. Как-то не совсем, по-моему, логично делать это атрибутом всей функции, а не той переменной, которую мы хотим не показывать сборщику мусора.
Здравствуйте, Pzz, Вы писали:
S>>D's @nogc?
Pzz>Хм. Как-то не совсем, по-моему, логично делать это атрибутом всей функции, а не той переменной, которую мы хотим не показывать сборщику мусора.
Такой кейс, полагаю, решается с помощью GC.removeRoot.
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще, мне бы лично хватили сборки мусора по умолчанию, и возможности от нее отказаться в данном конкретном месте, сказав волшебное слово, с целью выиграть эффективность ценой потери безопасности в том небольшом слое кода, где это имеет смысл.
Здравствуйте, Pzz, Вы писали:
S>>D's @nogc?
Pzz>Хм. Как-то не совсем, по-моему, логично делать это атрибутом всей функции, а не той переменной, которую мы хотим не показывать сборщику мусора.
Все логично. @nogc говорит "я хочу быть уверенным, что в этом куске кода не случится вдруг сборка мусора". Что до отдельных переменных, то там еще проще, достаточно просто создавать объект не через new, а через любой другой аллокатор, не опирающийся на GC (от обычного сишного malloc() до наворотов https://dlang.org/phobos/std_experimental_allocator.html ).
Здравствуйте, VTT, Вы писали:
VTT>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна.
почему?
VTT>Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами.
почему?
VTT>Заявления про безопасность раста — брехня.
почему?
VTT>Другая отталкивающая особенность языка — это макросы.
почему?
VTT>Просто наглый способ прятать крякозябры.
ето как?
VTT>Причем отделаться от него практически невозможно.
ты о чем вообще?
в общем, кто-то тут любит писать ничем не подкрепленные и спорные утверждения, вместо того чтобы сесть и разобраться как следует, а потом обстоятельно написать, почему
я rust-ом не особо интересуюсь, однако подобный стиль обсуждения просто приводит к тому, что никакой дискуссии и плодотворного обсуждения тупо не получается, практически весть рсдн теперь такой, привычку подкреплять какими-то фактами и рассуждениями свои железные доводы здесь имеют человек десять, остальные делают так как ты, в некоторых юзергруппах и списках рассылки за это тупо банят, зато там уровень обсуждения очень хороший, что-то полезное всегда можно почерпнуть
Это к "передать (получить) через границы языка или в разные потоки) и не расстроить borrow checker"
VTT>Вот в том-то и проблема, что раст никаким образом не позволяет описывать в коде эти сложные правила, кроме borrow checker ничего не предусматривается. VTT>Вариант "сразу идеально переписать все на раст" не рассматривается, работать надо сейчас и с уже существующими библиотеками и системными api.
Системные api элементарно оборачиваются в unsafe блоки. Я не вижу тут проблем вообще. Самый оправданный вариант использования unsafe блоков в коде. Что ты имеешь ввиду под этими "сложными правилами" и как, по твоему, их следует выражать в коде?
VTT>Да и "безопасный" код написанный на расте может обернуться неприемлемым оверхедом (Vec<Rc<RefCell<T>>> — это еще цветочки).
Я согласен. Но за safety всегда приходится чем-то платить. Я готов к тому что мои парсеры входных данных будут выглядеть так себе, зато гарантированно не смогут уронить приложение.
VTT>Даже один блок unsafe сразу переводит весь код в unsafe, т.е. прерывает цепочку накладываемых на код ограничений. VTT>А использование unsafe (хотя бы косвенное через стандартную библиотеку) в расте неизбежно.
Косвенное не так страшно. На нем вообще циклические структуры данных плохо выражаются без unsafe. Однако unsafe есть везде. И в C# и в Java (привет netty), не в таком количестве конечно, но есть.
CK>>В C# и Java народ активно юзает рефлексию для того, чего можно добиться макросами (надо ли говорить что это все происходит в рантайме). VTT>
А пацаны-то не знают
Что они не знают? Например форматирование в C# использует рефлексию времени исполнения.
VTT>Как раз возможность делать "такое" и есть проблема макросов.
Но ведь никто не заставляет делать "такое". Это либо делается совершенно intentional (нужно доступ к базе организовать и все такое), либо не делается вообще. Вопрос философии и выбора.
CK>>Ну так они и были ничем не подкреплены, да и сейчас в общем то тоже, или ты считаешь что фраза "из-за свое ограниченности" полностью раскрывает тему? VTT>Видимо да.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Я согласен. Но за safety всегда приходится чем-то платить. Я готов к тому что мои парсеры входных данных будут выглядеть так себе, зато гарантированно не смогут уронить приложение.
Непонятно, что хуже, когда "парсер входных данных" честно роняет программу, наевшись плюшек, или когда он лишь делает вид, что работает, но данные парсит неправильно. А когда код выглядит так себе, шансы, что он работает некорректно (пусть и без сегфолтов) очень сильно возрастают.
Здравствуйте, AlexRK, Вы писали:
VTT>>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна.
ARK>Даже движок браузера пишут. Похоже, что вполне жизнеспособно.
По большому счету, это пока единственная более-менее серьезная программа, написанная на этом языке. Да и та пока не написана. Даже компилятор евонный написан в основном не на нем.
ARK>По моему мнению, Раст безопаснее любого другого мейнстримового или околоменстримового языка. Под безопасностью в данном контексте я понимаю сочетание а) наличия возможностей по сокращению количества исключений времени выполнения; б) отсутствие возможностей легко отстрелить себе яйца.
Rust вряд ли безопаснее или мейнстримовей, чем Go.
Здравствуйте, VTT, Вы писали:
ARK>>Даже движок браузера пишут. Похоже, что вполне жизнеспособно. VTT>Если мне не изменяет память, то была одна-единственная заметка, что где-то в мозиле его начали задействовать.
Его, собственно, мозила и продвигает. Мне кажется, у них пороху не хватит втащить в мейнстрим новый язык.
Здравствуйте, 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.
Здравствуйте, 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, безусловно, один из самых безопасных языков. Только он совершенно не мейнстримовый и даже не "около". Среди мейнстрима и около — круче Раста нет пока никого.
Скорее он просто не особо нужен для майнстримных приложений.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, 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>Другая отталкивающая особенность языка — это макросы. VTT>Просто наглый способ прятать крякозябры. VTT>Причем отделаться от него практически невозможно.
Честно говоря, не совсем понял претензию. Кто мешает запретить на уровне соглашений проекта макросы? Или мешают именно стандартные? Чем?
Опять же, как нужно? Тупо писать больше мусорного кода? Макросы в расте пусть и корявы, но всё-таки явно лучше сишных — хотя бы из-за наличия гигиены.
VTT>Вполне толково расписано.
Похоже мы читали разные тексты. Я увидел претензии в духе "почему я не могу обращаться в интерфейсе к данным наследников" и "не осилил найти стандартную функцию forget".
VTT>Заявления про безопасность раста — брехня.
Такие заявления — брехня.
Здравствуйте, VTT, Вы писали:
VTT>Даже один блок unsafe сразу переводит весь код в unsafe, т.е. прерывает цепочку накладываемых на код ограничений.
Ага, конечно. И джава ничуть не безопаснее С ведь где-то в глубине нативный код имеется.
Здравствуйте, fddima, Вы писали:
F> Таким образом C++ templates и C# generics — тоже макросы, только более изощренные. Сейчас представить каждое без соответствующего — врядли представляется возможным (например я бы не стал писать на C# без generics, а то время когда это делал — вспоминаю просто с ужасом). При чём в большинстве языков — проблема обобщения так или иначе решается (это намек в сторону Java и D). F> В C++ — наряду вместе с шаблонами ходят парой и текстовые макросы, при чём, сомневаюсь, что без последних жизнь реально возможна (как минимум это способ параметризировать код при вызове компилятора). В C# кстати такое тоже есть, хотя и более ограниченно, и кстати тоже вполне используется.
Не хило у вас все перемешано...
F>Мне вот известно, что "макросы" очень нужны, при чём — чем они изощреннее — тем лучше.
Пользуйтесь как можно больше.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, DarkEld3r, Вы писали:
DE>Честно говоря, не совсем понял претензию. Кто мешает запретить на уровне соглашений проекта макросы? Или мешают именно стандартные? Чем?
"Тут так принято". Это же не с/с++ где царит полнейший плюрализм.
DE>Опять же, как нужно? Тупо писать больше мусорного кода?
Ну собственно основная претензия к макросам и заключается в том, что они представляют собой способ прятать весь boilerpalte "под ковер".
Извольте писать помощников, рефакторить и гранулировать код надлежащим образом.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>Не хило у вас все перемешано...
Изложил все исключительно в вашей терминологии.
F>>Мне вот известно, что "макросы" очень нужны, при чём — чем они изощреннее — тем лучше. VTT>Пользуйтесь как можно больше. обобщения в виде generics, templates используются чуть менее чем везде где они доступны. Даже в C умудряются создавать общий код, но это реже и плата в рантайме понятна. Дурачка включать не надо.
Я был бы рад такому языку который бы мог компилировать мои мысли в понятные для других ЯП программы. Но таких пока не предвидится, так что все таки предпочитаю пользоваться тем немногим что есть.
Здравствуйте, VTT, Вы писали:
EP>>Макросы в том числе помогают убрать тот boilerplate, который невозможно убрать/отрефакторить/etc другими средствами языка. VTT>Они ничего не убирают, весь этот boilerplate так и остается там, где его оставили.
В каком смысле? Этот boilerplate не нужно писать руками.
С тем же успехом можно сказать что современные языки ничем не лучше ассемблера, так как в итоге всё равно в него компилируются
Здравствуйте, VTT, Вы писали:
VTT>Во-вторых неявное копирование (или его отсутствие) в расте — это тихий ужас. VTT>Проявляется и при обычных вызовах методов типа foo(value) — нет никакой возможности определить, перемещается ли объект, или копируется.
Хм... ну так предполагается, что трейт Copy реализовывается исключительно для типов для которых эта разница не имеет значения. Конечно, можно умышленно подложить грабли, но это претензия сродни тому, что можно сделать кривой конструктор копирования. Вот только в ситуации с конструктором его можно ещё и забыть сделать, а в расте надо наоборот сделать дополнительные неправильные действия. Как по мне, разница всё-таки есть.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Да. Причём "короче" может быть качественным понятием, а не количественным. EP>Например генерация автомата из императивного по форме кода а-ля stackless await.
А где пример-то?
VTT>>Не ошибиться в копипасте? EP>Да, этого мало?
Ну опять же, укорачивать и прятать копипасту за макросами не должно быть самоцелью.
Допустим, некоторые случаи действительно не получится сделать более толковыми языковыми средствами.
Но если таких случаев выходит многовато — то это скорее говорит об ущербности языка.
А если таких случаев выходит немного — то это недостаточная причина прикручивать макросы.
Даже в многострадальном с++ с его архаичным препроцессором практически единственная ситуация, где использование порождающих макросов еще как-то оправдано — когда надо в одном месте заиметь имя типа / метода и аналогичный текстовый литерал.
EP>Это разруливается namespace'ами. EP>Да и например в Lisp вызов макроса по форме аналогичен вызову функции, так что тут пересечения с будущими возможными фичами не больше чем в случае с обычными функциями.
Какой ужас...
EP>Могу назвать реально полезные фичи в новых версиях всех mainstream языков. Наличие же плохих фич не говорит о том что на расширение в полезных направлениях нет спроса.
Вообще говоря, фичи могут быть и хорошими, но при этом избыточными.
Это прежде всего относится к введению встроенных средств вместо (паралельно) аналогичных библиотечных и различному "укорочивающему" синтаксическому сахару. Например nullable типы в c#.
В mainstream языках можно смело начинать потихоньку избавляться от излишков.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Например computation expression в Nemerle: EP>
EP>https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro
EP>The C# await/async implementation and the Nemerle asynchronous programming approach have much in common, but with a big difference: await/async requires language support, but asynchronous programming in Nemerle is implemented with monads, which are part of the standard library, not the language itself.
Статья хардкорная, понять, где же там извлекают пользу из макросов (а ее там извлекают или просто монаидические Computation-Expression существуют в ввиде макросов?) мне не удалось.
Автор явно забыл, что слово "просто" надо использовать пореже.
Оффтопик:
Most likely everyone who has understood monads wrote an article about them.
эти "пониматели монад" чем-то смахивают на веганов
EP>Вполне достойная самоцель. Многие языковые фичи только и делают что уменьшают boilerplate
Речь шла о том, макросы в расте что как раз boilerplate не уменьшают, а только прячут.
VTT>>Допустим, некоторые случаи действительно не получится сделать более толковыми языковыми средствами.
EP>Не надо допускать — это объективный факт. Есть реальный спрос на мета/макро-прогарммирование — C++, D, Rust, Nemerle, Lisp (веб-программирование на Clojure), T4, и даже со всех углов слышны воодушевлённые придыхания о Roslyn'е от, казалось бы, программистов корпоративных систем и прочих опердней.
Не стоит смешивать мета-программирование, препроцессоры, всякую разную кодогенерацию и макросы.
EP>Так и есть — макросы очевидно не от хорошей жизни появляются — любой язык общего назначения в чём-то ущербен. И рано или поздно натыкаешься на эту ущербность. В идеальном языке не было бы никакой необходимости в макросах — в нём уже были бы средства для выражения любой проблемы на языке предметной области. EP>И лучше иметь возможность обойти эту ущербность библиотечными средствами, а не ждать пока введут новую фичу в язык, её реализуют на всех требуемых компиляторах, и они через несколько апдейтов систем дойдут до конечных программистов приложений. Программистам библиотек ещё хуже — для расширения клиентской базы приходится использовать старые компиляторы.
Вы о чем вообще? Я бы сказал, что макросы уже практически вымерли.
Причем потребность в них отпала наверное как раз от хорошей жизни.
VTT>>А если таких случаев выходит немного — то это недостаточная причина прикручивать макросы. VTT>>Даже в многострадальном с++ с его архаичным препроцессором практически единственная ситуация, где использование порождающих макросов еще как-то оправдано — когда надо в одном месте заиметь имя типа / метода и аналогичный текстовый литерал.
EP>Да ладно, зачем тогда по-твоему появились штуки типа Boost.Preprocessor? В нём фичи типа циклов реализованы огромными усилиями, вопреки архаичности препроцессора. EP>Конкретный пример использования — BOOST_FUSION_DEFINE_STRUCT — описываешь структуру один раз, и автоматом получаешь любой возможный обход, в том числе для вполне земной сериализации.
На макросах и целые мета-языки появились, но это совершенно не оправдывает использование макросов.
Boost.Preprocessor по большей части уже давно не нужен.
А фьюжн я и раньше не стал бы использовать. Внешний кодогенератор (как в qt например) для информации о типах (если уж без нее не обойтись) и то лучше.
Вообще-то я выше уже привел единственный кейс, где от макросов еще остается какой-то прок и который как раз покрывается в фьюжн.
EP>Также можно использовать для генерации тех же автоматов из императивного кода, но в таких случаях уже серьёзно не хватает возможностей препроцессора.
Зачем генерировать автоматы из императивного кода?
Чем вас не устраивают автоматы, написанные в императивной манере?
Почему нельзя обойтись без макросов?
EP>>>Это разруливается namespace'ами. EP>>>Да и например в Lisp вызов макроса по форме аналогичен вызову функции, так что тут пересечения с будущими возможными фичами не больше чем в случае с обычными функциями. VTT>>Какой ужас...
EP>В чём ужас?
В том, что лисп по сути уже давно воспринимается как какое-то маргинальное явление.
Достаточно странно приводить его как пример оправдания существования макросов.
Если уж хотелось привести такой пример — так можно было вспомнить ассемблеры какие-нибудь.
Вот там да, надо чтобы весь boilerplate был на месте, но записывался покороче. Без макросов никуда.
EP>В языках постоянно не хватает каких-либо хороших фич, макросы и прочее метапрограммирование позволяют на порядки сократить барьер их реализации — с изменения компиляторов до написания библиотеки в рамках текущей версии языка.
По мне, так во многих языках скорее избыток фич.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
