Уже все почти забыли о Расте, а вот он опять всплыл.

Why I’m dropping Rust

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))). Няшненько.

Прощай Rust

Здравствуйте, Слава, Вы писали:

С>Здравствуйте, 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>Вообще, мне бы лично хватили сборки мусора по умолчанию, и возможности от нее отказаться в данном конкретном месте, сказав волшебное слово, с целью выиграть эффективность ценой потери безопасности в том небольшом слое кода, где это имеет смысл.

D's @nogc?

Здравствуйте, 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>Кто-то любит копипастить "почему" и обзывать чужие утверждения "ничем не подкрепленными" и "спорными" ничем не подкрепляя свои высказывания...

Ну так они и были ничем не подкреплены, да и сейчас в общем то тоже, или ты считаешь что фраза "из-за свое ограниченности" полностью раскрывает тему?

Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, VTT, Вы писали:

CK>

CK>let mut guard = lock(mutex);
CK>let vec = access(&mut guard);
CK>vec.clear();
CK>

Это к чему?
Лучше бы привели пример как безопасно и без лишнего оверхеда получить несколько ссылок на изменяемый объект (а еще лучше передать (получить) через границы языка или в разные потоки) и не расстроить 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>Здравствуйте, chaotic-kotik, Вы писали:

CK>>Здравствуйте, VTT, Вы писали:

CK>>

CK>>let mut guard = lock(mutex);
CK>>let vec = access(&mut guard);
CK>>vec.clear();
CK>>

VTT>Это к чему?


Это к "передать (получить) через границы языка или в разные потоки) и не расстроить 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>Видимо да.

Sounds passive-agressive to me.

Здравствуйте, 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) макросы используются во всю.
Ну это не показатель. И у меня есть большие сомнения, что макросы в этих языках во всю используются от хорошей жизни.