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 очень даже нетрививальной задачей.
U>Мне особо понравилась конструкция 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))). Няшненько.
С>Ну да, быренько чего-то наговнякать уже не получается. Для того и делали.
И наиг такой язык нужен? Теперь придётся "наговнякать" долго и изворотливо.
Напоминает анекдот про розетки. "...Теперь будут погибать самые одарённые."
При этом главная проблема уменьшения сложности не решена.
ps: Почему-то меня современные компиляторы настараживают. Попробуйте быстренько сделать мальенький консольный hello world на C++11, так чтоб можно было запустить например на winnt4.
Если на древнем delphi7 скомпилировать какйю-нибудь фигню, так она и win95, и на win10 запускается.
Если попробывать старый visual studio поставить на новый 64битую ось, то увидим интересные надписи вида, "имеются известные проблеммы с совместимостью" часть функций будет безбожно глюкать и не работать.
А так как почти всё собирается новыми модными компиляторами. То скоро по будет пускаться только на win10 и только в защищёных шифрованых контейнерах, которые поддерживаются только новыми процессорами. Которые срочно надо всем обновить.
Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна.
Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами.
Заявления про безопасность раста — брехня.
Другая отталкивающая особенность языка — это макросы.
Просто наглый способ прятать крякозябры.
Причем отделаться от него практически невозможно.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна. VTT>Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами. VTT>Заявления про безопасность раста — брехня.
Вообще, мне бы лично хватили сборки мусора по умолчанию, и возможности от нее отказаться в данном конкретном месте, сказав волшебное слово, с целью выиграть эффективность ценой потери безопасности в том небольшом слое кода, где это имеет смысл.
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще, мне бы лично хватили сборки мусора по умолчанию, и возможности от нее отказаться в данном конкретном месте, сказав волшебное слово, с целью выиграть эффективность ценой потери безопасности в том небольшом слое кода, где это имеет смысл.
Здравствуйте, 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 ).
Здравствуйте, uncommon, Вы писали:
U>Уже все почти забыли о Расте, а вот он опять всплыл.
Я не забыл! Время от времени ставлю свежую версию, собираюсь попробовать, а тут бац, новая версия выходит, и так по кругу.
U>Why I’m dropping Rust
U>TL;DR: Раст — это постоянная борьба с borrow-checker'ом, плюс трудность выражения конструкций, которые очень легко описываются в других языках (C++, C#). Что делает написание таких вещей, как GUI очень даже нетрививальной задачей.
На реддите автору дали справку, что он дурак и зря пытался ООПшные привычки тащить в полуфункциональный язык. Не осилил просто правильный подход.
Здравствуйте, D. Mon, Вы писали:
DM>На реддите автору дали справку, что он дурак и зря пытался ООПшные привычки тащить в полуфункциональный язык. Не осилил просто правильный подход.
Да тут даже не в функциональщине дело, он там пытается с trait-ом сделать что-то очень странное и удивляется тому, что так нельзя. Для программиста на Java или С# это не менее странно выглядит.
Здравствуйте, VTT, Вы писали:
VTT>Концепция существования одной-единственной ссылки на изменяемый объект на практике не особо жизнеспособна.
почему?
VTT>Кроме того, она никоим образом не помогает организовывать взаимодействие со внешним кодом и разруливать сложные правила разделяемого владения объектами.
почему?
VTT>Заявления про безопасность раста — брехня.
почему?
VTT>Другая отталкивающая особенность языка — это макросы.
почему?
VTT>Просто наглый способ прятать крякозябры.
ето как?
VTT>Причем отделаться от него практически невозможно.
ты о чем вообще?
в общем, кто-то тут любит писать ничем не подкрепленные и спорные утверждения, вместо того чтобы сесть и разобраться как следует, а потом обстоятельно написать, почему
я rust-ом не особо интересуюсь, однако подобный стиль обсуждения просто приводит к тому, что никакой дискуссии и плодотворного обсуждения тупо не получается, практически весть рсдн теперь такой, привычку подкреплять какими-то фактами и рассуждениями свои железные доводы здесь имеют человек десять, остальные делают так как ты, в некоторых юзергруппах и списках рассылки за это тупо банят, зато там уровень обсуждения очень хороший, что-то полезное всегда можно почерпнуть
Здравствуйте, 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>Ну так они и были ничем не подкреплены, да и сейчас в общем то тоже, или ты считаешь что фраза "из-за свое ограниченности" полностью раскрывает тему?
Видимо да.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Это к "передать (получить) через границы языка или в разные потоки) и не расстроить 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>Видимо да.
Здравствуйте, VTT, Вы писали:
VTT>>>Другая отталкивающая особенность языка — это макросы. CK>>почему? VTT>Ненужность макросов, как некого встроенного способа для кодогенерации в обход других языковых механизмов, всем известна. VTT>Причем она была осознана достаточно давно, например такое было явно запрещено еще в Steelman language requirements. VTT>В большинстве современных языков, таких как go, D, C#, Java, Haskell, макросы отсутствуют. VTT>Там, где макросы живут по историческим причинам (прежде всего в C/C++), их использование рекомендуется ограничить.
Не путай макросы C++ и гигиеничные макросы типа Lisp/Nemerle. В диалектах Lisp'а (например Clojure) макросы используются во всю.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не путай макросы C++ и гигиеничные макросы типа Lisp/Nemerle.
Я их не путаю. Детали реализации макросов, будь то просто подстановка текста, как в препроцессоре С, или более изощренные средства, не столь важны.
EP>В диалектах Lisp'а (например Clojure) макросы используются во всю.
Ну это не показатель. И у меня есть большие сомнения, что макросы в этих языках во всю используются от хорошей жизни.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.