Здравствуйте, _VW_, Вы писали:
_VW>Здравствуйте, AlexRK, Вы писали:
_VW>>>то есть, это ограничение руста?
ARK>>Это ограничение существующей экосистемы руста, но не самого руста, как языка программирования.
_VW>насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
Судя по ответу Стива Клабника здесь, в ближайшее время ничего менять не собираются:
"Yes, in general, the standard library assumes that you can't really handle OOM. Using libcore and custom allocators, you could implement whatever behavior you'd like, but you'd still need to re-implement this kind of thing on top of it."
С другой стороны, сейчас ведется работа над "placement box" (ознакомиться можно здесь), что приведет к появлению поддержки сторонних аллокаторов. Но, опять же, никаких потенциальных возвратов ошибок вроде как не предвидится, плюс нельзя будет использовать свой аллокатор для существующих коллекций, как я понял.
Так что, в ближайшие год-два точно, единственный способ обрабатывать ситуации нехватки памяти можно будет только реализуя собственные менеджеры памяти и переписывая требуемые структуры данных для них.
From my experience, I found it awfully difficult to understand how to work with borrowing and lifetimes.
ARK>А это — нет. Возможность попроще говнокодить (и потенциально допускать ошибки) ставится выше создания гарантированно корректного кода. ARK>Это не говорит о том, что у Rust нет преимуществ.
По опыту — С++ код, активно использующий семантику перемещения и уникальные указатели бывает иногда довольно сложно понять. Обычно в приложении есть два с половиной объекта, время жизни которых имеет значение, остальное же может быть отдано на откуп GC или еще какому-нибудь механизму. Rust же, наоборот, делает шаг назад от языков с автоматическим управлением временем жизни объектов, но при этом не дает никаких особенных преимуществ по сравнению с С++, с которым он на одном уровне по когнитивной нагрузке, но только без тулинга/библиотек/книг/статей/конференций/программистов.
В>"Yes, in general, the standard library assumes that you can't really handle OOM. Using libcore and custom allocators, you could implement whatever behavior you'd like, but you'd still need to re-implement this kind of thing on top of it."
Да уж, булшит про невозможность обработки OOM на уровне рантайма это сильно. Далеко не всегда ООМ нельзя обработать. Часто это возможно и даже требуется делать.
Здравствуйте, Васильич, Вы писали:
В>Так что, в ближайшие год-два точно, единственный способ обрабатывать ситуации нехватки памяти можно будет только реализуя собственные менеджеры памяти и переписывая требуемые структуры данных для них.
насколько это серьезное ограничение эко-системы? чем плохо отсуствие возможности отловить ошибку OOM?
Здравствуйте, Васильич, Вы писали:
В>Исходники стандартной библиотеки просто кишат unsafe'ами
То есть это утверждение предыдущего оратора
KP>>* быстрый код в общем случае не уступающий C/C++;
не соответствует действительности, сравнимой производительности без unsafe не получится?
Здравствуйте, _VW_, Вы писали:
_VW>насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
Ну, я не супер-знаток растовой экосистемы, но полагаю, что преодоление данного ограничения будет означать переписывание неприемлемо большого количества кода.
From my experience, I found it awfully difficult to understand how to work with borrowing and lifetimes.
ARK>>А это — нет. Возможность попроще говнокодить (и потенциально допускать ошибки) ставится выше создания гарантированно корректного кода. ARK>>Это не говорит о том, что у Rust нет преимуществ.
EL>По опыту — С++ код, активно использующий семантику перемещения и уникальные указатели бывает иногда довольно сложно понять.
Возможно, причина заключается не в том, что "код активно использует семантику перемещения и уникальные указатели", а в том, что это "С++ код, активно использующий семантику перемещения и уникальные указатели". С++ не проектировался с учетом семантики перемещения и не _требует_ ее. Но это только моя гипотеза.
EL>Обычно в приложении есть два с половиной объекта, время жизни которых имеет значение, остальное же может быть отдано на откуп GC или еще какому-нибудь механизму. Rust же, наоборот, делает шаг назад от языков с автоматическим управлением временем жизни объектов, но при этом не дает никаких особенных преимуществ по сравнению с С++, с которым он на одном уровне по когнитивной нагрузке, но только без тулинга/библиотек/книг/статей/конференций/программистов.
Про тулинг/библиотеки/книги/статьи/конференции — это без вопросов, тут С++ на световые годы впереди. Насчет всего остального не уверен.
Здравствуйте, ELazin, Вы писали:
KP>>быстрый код в общем случае не уступающий C/C++; KP>>гарантии корректной работы с памятью.
EL>одно исключает другое
В случае раста есть некоторые накладные расходы на проверки, но в общем случае это утверждение неверно. Статически можно проверять все, даже выход за границы массивов, но сейчас это мейнстримом не является.
Здравствуйте, ELazin, Вы писали:
EL>одно исключает другое
Не противоречит при условии обеспечения гарантий на этапе компиляции. Надо признать, гарантии безопасной работы с памятью не везде и не всегда, можно и в рантайме в панику вылететь при попытке захватить ссылку на объект, но в общем случае ситуация с безопасной работой с памятью ощутимо лучше чем в C++.
Здравствуйте, _VW_, Вы писали:
_VW>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
Ансельм Кентерберийский еще в 1078 году сформулировал онтологический аргумент явного преимущества Раста перед С++17: Раст уже существует, уже реален, а С++17 еще нет.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, _VW_, Вы писали:
_VW>>насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
ARK>Ну, я не супер-знаток растовой экосистемы, но полагаю, что преодоление данного ограничения будет означать переписывание неприемлемо большого количества кода.о
я не про это. а про то, как часто его может нужно будет преодолевать.
Здравствуйте, _VW_, Вы писали:
ARK>>Ну, я не супер-знаток растовой экосистемы, но полагаю, что преодоление данного ограничения будет означать переписывание неприемлемо большого количества кода.о
_VW>я не про это. а про то, как часто его может нужно будет преодолевать.
А... получается, этот вопрос к расту вообще не относится. Как часто вообще надо обрабатывать OOM? Фиг знает. В системах с ограниченными ресурсами это, скорее всего, общее место. Но я в этом не копенгаген.
Здравствуйте, Васильич, Вы писали:
> Гарантии безопасной работы с памятью, большей частью на этапе компиляции;
В>C++ имеет похожие возможности в некоторых областях, но при этом не дает никаких гарантий.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, _VW_, Вы писали:
_VW>>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
KP>Есть и плюсы и минусы. В целом, для небольшой и сильной команды он предпочтительнее. Для большой и/или слабой команды лучше взять C++, а еще лучше Java или C#
Здравствуйте, _VW_, Вы писали:
_VW>насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
Здравствуйте, kaa.python, Вы писали:
KP>Основные плюшки: KP>
...
быстрый код в общем случае не уступающий C/C++;
На данный момент это миф. Хотя возможно когда-нибудь в будущем это станет реальностью, т.к. никаких фундаментальных препятствий Rust не имеет (в отличие от того же Java/C#). Однако для этого требуется ещё не один год активной работы над компилятором.
KP>Почему бы я его не взял для большой/слабой команды: KP>
...
Нет нормально работающей IDE;
Да, это существенная проблема. Но на мой взгляд есть ещё и гораздо более серьёзная: непонятно какие собственно бонусы принесёт язык (ну кроме небольшого синтаксического сахара), в случае перехода на него с C++ (а в особенности если взглянуть на будущий стандарт).
ARK>В случае раста есть некоторые накладные расходы на проверки, но в общем случае это утверждение неверно. Статически можно проверять все, даже выход за границы массивов, но сейчас это мейнстримом не является.
KP>Не противоречит при условии обеспечения гарантий на этапе компиляции. Надо признать, гарантии безопасной работы с памятью не везде и не всегда, можно и в рантайме в панику вылететь при попытке захватить ссылку на объект, но в общем случае ситуация с безопасной работой с памятью ощутимо лучше чем в C++.
Ощутимо лучше чем? В современном С++ не принято использовать голые указатели и Си-стиль. Помимо этого для С++ есть соответствующий тулинг (ASan). Ну и свойство memory safety, оно не composable, если у тебя есть unsafe код, который портит память, то уронить приложение можно и в safe блоке. Memory safe приложение должно состоять только из safe кода, что в случае раста явно не выполняется, так что все эти гарантии — ничего не стоят.
Здравствуйте, ELazin, Вы писали:
EL>Ощутимо лучше чем? В современном С++ не принято использовать голые указатели и Си-стиль. Помимо этого для С++ есть соответствующий тулинг (ASan). Ну и свойство memory safety, оно не composable, если у тебя есть unsafe код, который портит память, то уронить приложение можно и в safe блоке. Memory safe приложение должно состоять только из safe кода, что в случае раста явно не выполняется, так что все эти гарантии — ничего не стоят.
"Не принято" и "запрещено везде, кроме unsafe блоков" — таки разные вещи.
Наличие явно выделенных небольших unsafe блоков лучше, чем один громадный unsafe блок в С++. Ну и есть подозрение, что типичное приложение не будет нуждаться в unsafe.
