Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
Здравствуйте, _VW_, Вы писали:
_VW>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17? _VW>Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
Здравствуйте, _VW_, Вы писали:
_VW>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17? _VW>Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
У Rust'а:
Продвинутая система модулей;
Гарантии безопасной работы с памятью, большей частью на этапе компиляции;
Гарантии корректной работы с памятью в многопоточных приложениях, тоже большей частью на этапе компиляции;
Паттерн-матчинг;
Алгебраические типы данных;
И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
C++ имеет похожие возможности в некоторых областях, но при этом не дает никаких гарантий.
Здравствуйте, Васильич, Вы писали:
В>Здравствуйте, _VW_, Вы писали:
_VW>>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17? _VW>>Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
В>У Rust'а: В>Продвинутая система модулей; В>Гарантии безопасной работы с памятью, большей частью на этапе компиляции; В>Гарантии корректной работы с памятью в многопоточных приложениях, тоже большей частью на этапе компиляции; В>Паттерн-матчинг; В>Алгебраические типы данных; В>И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
У C++ — удобные проверенные средства разработки и развитое сообщество.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Васильич, Вы писали:
В>>У Rust'а: В>>Продвинутая система модулей; В>>Гарантии безопасной работы с памятью, большей частью на этапе компиляции; В>>Гарантии корректной работы с памятью в многопоточных приложениях, тоже большей частью на этапе компиляции; В>>Паттерн-матчинг; В>>Алгебраические типы данных; В>>И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
TB>У C++ — удобные проверенные средства разработки и развитое сообщество.
Да, это правда. Хотя это больше не достоинство C++ как такового, а скорее его возраста.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, _VW_, Вы писали:
_VW>>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
ARK>Каким образом вы это поняли?
Здравствуйте, _VW_, Вы писали:
_VW>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
Есть и плюсы и минусы. В целом, для небольшой и сильной команды он предпочтительнее. Для большой и/или слабой команды лучше взять C++, а еще лучше Java или C#
_VW>Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
Основные плюшки:
простой, на много проще C++;
довольно хорошо продуманная модульность с управлением зависимостями из коробки (cargo);
очень хорошая поддержка разработки многопоточных приложений;
быстрый код в общем случае не уступающий C/C++;
гарантии корректной работы с памятью.
Почему бы я его не взял для большой/слабой команды:
Он сложнее Java/Python и его реально нужно учить. Концепция отличается от привычных C/C++/Java/Python;
Благодаря unsafe в нем крайне легко говнокодить в C/C++ стиле;
Нет нормально работающей IDE;
Язык заставляет довольно серьезно подходить к архитектуре. Исправление постфактум обойдутся основательно дороже чем в C/C++ и скорей всего (это теория) приведут к появлению кучи говнокода по средствам unsafe.
Здравствуйте, kaa.python, Вы писали:
KP>Основные плюшки: KP>
KP> простой, на много проще C++; KP> довольно хорошо продуманная модульность с управлением зависимостями из коробки (cargo); KP> очень хорошая поддержка разработки многопоточных приложений; KP> быстрый код в общем случае не уступающий C/C++; KP> гарантии корректной работы с памятью. KP>
KP>Почему бы я его не взял для большой/слабой команды:
KP>
KP> Он сложнее Java/Python и его реально нужно учить. Концепция отличается от привычных C/C++/Java/Python; KP> Благодаря unsafe в нем крайне легко говнокодить в C/C++ стиле; KP>
Это, кстати, одна из проблематичных областей для новичков. Исходники стандартной библиотеки просто кишат unsafe'ами, что может заставить новичков думать, что по другому просто нельзя, хотя понятно, что там они используются исключительно в целях оптимизации. Это усложняется тем, что стандартная библиотека и исходники компилятора являются пока что одним из основных мест, куда люди смотрят в процессе обучения.
С другой стороны, Rust пока притягивает в основном сильных программистов в силу своей сложности, которые пишут адекватный код, используя хорошие практики. К моменту "опопсения" языка будет хорошая база и для остальных.
KP>
KP> Нет нормально работающей IDE; KP> Язык заставляет довольно серьезно подходить к архитектуре. Исправление постфактум обойдутся основательно дороже чем в C/C++ и скорей всего (это теория) приведут к появлению кучи говнокода по средствам unsafe. KP>
Я бы, кстати, сказал, что с точки зрения архитектуры Rust ближе к C#/Java, чем к C++.
Это очень показательный пример, когда человек, привыкший к необдуманному кодингу, сталкивается с растом. Тут важно запомнить одно: сильнейшая сторона Rust'а в его строгости, он всегда начинает бить по рукам, когда программист теряет нить и начинает писать код от балды.
В примере выше код неконсистентен в типах, поэтому автору приходится прибегать к частому преобразованию типов. Вместо того, чтобы задуматься, почему у него r, g, b имеют тип u8 в структуре, но int в заголовке функции, он обвиняет Rust в излишнем кастинге. Это, кстати, сишная привычка по дефолту ставить int везде.
One of the reasons was that Rust couldn't deal with out-of-memory exceptions.
ARK>>ОК, это понять можно.
_VW>Во, это я хотел узнать. Что, как, почему и чем это грозит?
Чувак хочет обрабатывать нехватку памяти, а Rust ему не дает — все аллокации производятся неявно и в случае нехватки памяти делается аборт всего процесса. Хотя, как я понимаю, это больше ограничение существующих библиотек. Можно ведь и самому написать выделитель с проверкой результата. Но потом под него придется все остальное переписывать.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, _VW_, Вы писали:
ARK>>>
One of the reasons was that Rust couldn't deal with out-of-memory exceptions.
ARK>>>ОК, это понять можно.
_VW>>Во, это я хотел узнать. Что, как, почему и чем это грозит?
ARK>Чувак хочет обрабатывать нехватку памяти, а Rust ему не дает — все аллокации производятся неявно и в случае нехватки памяти делается аборт всего процесса. Хотя, как я понимаю, это больше ограничение существующих библиотек. Можно ведь и самому написать выделитель с проверкой результата. Но потом под него придется все остальное переписывать.
Здравствуйте, _VW_, Вы писали:
ARK>>Чувак хочет обрабатывать нехватку памяти, а Rust ему не дает — все аллокации производятся неявно и в случае нехватки памяти делается аборт всего процесса. Хотя, как я понимаю, это больше ограничение существующих библиотек. Можно ведь и самому написать выделитель с проверкой результата. Но потом под него придется все остальное переписывать.
_VW>то есть, это ограничение руста?
Это ограничение существующей экосистемы руста, но не самого руста, как языка программирования.
Здравствуйте, Zenden, Вы писали:
В>>И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
Z>Лолшто? этот вырвиглазный синтаксис вы называете приятным? Наверно вам и objective-c приятен
Синтаксис вполне нормален, очень близок к C/C++. У вас, возможно, просто другие персональные предпочтения.
Здравствуйте, AlexRK, Вы писали:
_VW>>то есть, это ограничение руста?
ARK>Это ограничение существующей экосистемы руста, но не самого руста, как языка программирования.
насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
В>У Rust'а: В>Продвинутая система модулей;
В С++ тоже скоро будет.
В>Гарантии безопасной работы с памятью, большей частью на этапе компиляции;
Это не совсем так. Помимо семантики владения, которую можно проверить (иногда) на этапе компиляции, есть еще и остальные операции с памятью, которые проверяются в рантайме (bounds checking) и которые имеют свою стоимость. Первое (ownership) в С++ вполне себе можно проверять во время компиляции, shared_ptr/unique_ptr в помощь. Операции с памятью тоже никто не заставляет выполнять без проверки выхода за границы (vector.at вместо []).
В>Гарантии корректной работы с памятью в многопоточных приложениях, тоже большей частью на этапе компиляции;
Баги в многопоточных программах data-race-ами не ограничиваются. Есть еще просто race-ы, от которых он не защищает. Головой, в конечном итоге, придется думать самостоятельно.
В>C++ имеет похожие возможности в некоторых областях, но при этом не дает никаких гарантий.
Что значит "не дает гарантий"? Какие гарантии дает язык? У С++ есть стандарт, поэтому я могу точно сказать как должен вести себя тот или иной фрагмент кода. Стандарт определяет некоторые вещи как UB (undefined behaviour), такие как разыменование нулевого указателя. Но это, КМК, вполне логично. Можно конечно попытаться скрыть от программиста неопределенное поведение максимально, но это, во первых, ограничит возможности оптимизатора, во вторых — язык станет слишком высокоуровневым, как Java или C#. В Java ведь тоже memory safety есть, только за счет GC.
