Сравнение Rust и С++ на примерах

[AxisPod]

Вся память на стеке? Язык для программ уровня Hello World? Даже без кучи? Без сборщика мусора? Ну и зачем такое счастье? Дальше лучше, говорим про С++, юзаем корявую функцию из C, при этом аналог из C++ куда удобнее, но нет же, нельзя ведь его привести, не выгодно для статьи (если что я про printf, даже и не помню когда юзал).

Ну и за корявый код вините не язык, а руки разработчика, тонкости он должен знать.

[fuCtor]

Из текста:

Если же память выделена в куче — то указатель на неё (Box) ведёт себя точно так же, как и обычная переменная на стеке (удаляется при выходе из зоны видимости). Для совместного использования данных есть подсчёт ссылок (std::rc::Rc) и сборщик мусора (std::gc::Gc), оба реализованы как сторонние классы (Вы можете написать свои).

[amlet]

Я так понимаю, в примерах printf никакого отношения к обсуждаемой проблеме не имеет и используется только вывода результата. Использование стримов — это конечно хорошо, но неужели это тут так принципиально?

[Googolplex]

Вы читали статью вообще? В Rust есть и куча, и сборщики мусора (ну сейчас там в стандартной библиотеке не полноценный GC, а подсчёт ссылок, но это дело желания и умения — написать нормальный GC). При этом все эти механизмы безопасны в принципе. А в C++ ничего не мешает вам, например, взять указатель во внутренности unique_ptr. Я уже не говорю про более сложные случаи, связанные с многопоточностью.

[amlet]

я правильно понимаю, что GC в нём по-умолчанию включён?

P.S. Никто кстати не желает забабахать подобное сравнение про D?

[Googolplex]

Если в D отключить сборщик мусора, то стандартная библиотека перестанет нормально функционировать. Кроме того, если вам стандартная библиотека и не нужна, то, отключая GC, вы возвращаетесь в мир проблем C++, так хорошо описанный автором статьи.

В Rust изначально заложена возможность писать безопасные программы без сборщиков мусора и других автоматических систем управления памятью.

[boblenin]

Если так, то слабо верится, что разработчики языка смогут его оперативно поддерживать.

[NCrashed]

Никто кстати не желает забабахать подобное сравнение про D?

Сохранил первичную структуру поста. habrahabr.ru/post/225507/
Сравнение получается не сильно честным, примеры подобраны под сильный статический анализатор, встроенный в Rust, а D в этой области слабее.

[kvark]

Спасибо, это было великолепно!
Пора объявлять неделю языков программирования на Хабре. Небойсь, и Swift объявится ;)

[gshep]

После того, как Мейерс выступил на ДиКонф 2014, появилась вот такая интерпретация его выступления:
he-the-great.livejournal.com/52333.html

[Googolplex]

Очень странно, что вы увидели в Rust CoffeeScript'овый синтаксис. В Rust используются стандартные для C блоки для выделения кода, например. Да он вообще не похож на CoffeeScript!

А насчёт плюшек — тут можно спорить. Например, лично мне не нравятся строковые миксины, пусть они и офигенно мощные. А в Rust есть нормальные синтаксические гигиеничные макросы (и возможность создания полноценных процедурных макросов, как в Scala, например).

[Googolplex]

Ну схожесть разве что в стрелках в функциях и в statement as expression. Но последним обладают многие языки, та же Scala например.

И Rust, и D, и GO мощные и современные языки, которые лишены многих недостатков C++. Поэтому, думаю, что можно спокойно выбирать язык с тем синтаксисом, который больше нравится.

Полностью согласен.

[potan]

Регионов в D нет. В системном программировании они будут очень полезны.

[amlet]

> Размышления на тему того, как обратная совместимость мешает C++ достичь звёзд…

А ведь автор в чём-то прав. Вот например такие абсолютно неочевидные хрени буквально рвут мозг (особенно когда первый раз с этим сталкиваешься):

habrahabr.ru/post/68796/

А для чего это? Правильно, для обратной совместимости со старыми C программами (привет из 80-х).

[Googolplex]

Спасибо за статью!

Я бы ещё добавил, наверное, сравнение с С++ными примитивами для управления памятью — unique_ptr, shared_ptr и прочее, и указанием, почему всё-таки они не панацея. Потому что это довольно справедливая претензия — в современном С++ код через сырые указатели стараются не писать.

[Googolplex]

Вот здесь один из авторов языка (фактически, современную систему с &/&mut указателями и borrow checker'ом заложил именно он) рассказывает, как именно обеспечивается безопасность работы с памятью в Rust, и какого класса ошибки исключаются. Очень интересный доклад, интересующимся советую посмотреть.

Это первая из ссылок-источников в посте, просто хочу обратить на неё внимание.

[Dor1s]

Дошел до места, где автор сравнивает память, выделенную через new, с памятью на стеке. Дальше не читал.
Прежде чем писать о языке программирования, разберитесь в нем. Не надо заниматься распространением безграмотности, пожалуйста :)

[kvark]

А можно конкретнее? Я сравнил память из кучи и на стеке с точки зрения её управления в Rust. Может, если я плохо выразился, попробуйте Вы объяснить лучше.

[DancingOnWater]

1) Монстрообразные сообщения об ошибках это не проблема языка это проблема gcc. В clang-сообщение уже более понятно. Итого как плюс язык пункт номер 1 выбывает
2)Битые указатели на стековые переменные — это то, от чего программист на С++ избавляется очень быстро (Может ошибиться раз или два, но третей подобной ошибки он не допустит). Нужен подсчет ссылок — shaerd_ptr
3) Обращение к удаленной памяти отлавливается Valgrind и статическими анализаторами на раз-два.
4) Не полное перечисление в свитче — gcc и clang это отслеживают.
5) Многопоточность. Решается введением shared_ptr

[Halt]

По поводу (1) еще раз дам ссылку, которую уже постил ранее: blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

P.S.: Касательно самого утверждения можно поспорить. Автор отмечает особенности языка, который вылавливает подобные ошибки на лексическом уровне. Это все таки более круто, поскольку не накладывает на программиста дополнительных неявных или слабо формализованных ограничений.

[DancingOnWater]

Посмотрел на синтаксис Rust, вот так сразу из записи я не могу определить ошибку => все упирается в сообщение компилятора.

И да, я не понял к чему ссылка: в целях ознакомления или аргумент в споре? Если последнее, то тогда в каком?

[Halt]

к чему ссылка

Целях ознакомления; в подтверждение вашего пункта 1.

из записи я не могу определить ошибку => все упирается в сообщение компилятора.

Это то же самое, что утверждать что в С++ const не нужен, мол, из записи я не могу определить ошибку, приходится читать сообщения компилятора. Под лексическим уровнем я понимаю то, что компилятор обладает достаточной информацией, чтобы проводить анализ того, что в других языках остается «за кадром», в сознании программиста.

Например, в C++ мы вынуждены сознательно контролировать вопросы синхронизации ресурсов в многопоточном приложении. Тут компилятор ничего не подскажет. Говорить что программист сам дурак и программа должна быть написана так чтобы все было очевидно тоже нельзя, по скольку ошибки обычно возникают не при проектировании а при рефакторинге и изменении чужого кода.

Даже зная тонкости, я был бы не против, если компилятор сможет отлавливать противоречия и в подобных местах.

[DancingOnWater]

А кто говорит что что-то не нужно, просто это не киллер-фича. Вот ошибки с многопоточностью — это да.

[amosk]

5) Многопоточность. Решается введением shared_ptr

Как?

[DancingOnWater]

Ну что-то типа того:

class Resource {
shared_ptr value;
public:
Resource(): {}
~Resource() }
int *acquire() {
return atomic_load(&value);
}
};

Но в Qt это сделано более удобно

[amosk]

Спасибо, направление понятно:
Инициализировать через atomic_compare_exchange_strong_explicit, а читать через atomic_load

Правда надо признать, shared_ptr тут не нужен. Можно обойтись простым указателем :)

[mayorovp]

Для совместного использования данных есть подсчёт ссылок (std::rc::Rc) и сборщик мусора (std::gc::Gc), оба реализованы как сторонние классы (Вы можете написать свои).Как написать свои классы без операции «удаления памяти»? Эта операция в языке есть, просто вы не нашли ее.

[mayorovp]

Извиняюсь, закрывающий тег уехал, поздно заметил.

Для совместного использования данных есть подсчёт ссылок (std::rc::Rc) и сборщик мусора (std::gc::Gc), оба реализованы как сторонние классы (Вы можете написать свои).

Как написать свои классы без операции «удаления памяти»? Эта операция в языке есть, просто вы не нашли ее.

[kvark]

Реализация Rc и Gc содержит небезопасный код для управления памятью. В области безопасного кода операции «удаления» нет, именно это имелось ввиду.

[JIghtuse]

Какой-то чувак сейчас пишет серию статей на схожую тему, Rust для программистов на C++. featherweightmusings.blogspot.com/

[professor_kuvalda]

По-моему, гораздо проще изучить грабли С++, чем все эти новомодные языки: Julia, D, Rust, Swift (потом наверняка ещё что-нибудь придумают).

[Halt]

Когда-то так думали и труъ программисты, не признававшие ничего выше ассемблера. Особенно во время, когда компиляторы действительно генерировали код хуже человека.

[Gorthauer87]

Если бы в Rust'е еще синтаксис был более человеческим, а не эти кучи закорючек и сокращений в стиле Perl.

[aTwice]

Во-во. Долго вникал в смысл 'a' в этой строке:

fn bar<'a>(p: &'a int) -> &'a int {

А еще на лямбда-синтаксис [](){} ругаются.

[gridem]

Можно просто писать: []{}

[Googolplex]

Как ни странно, в этом желании разработчики вас поддерживают. Поэтому в языке закорючек стало гораздо меньше по сравнению с первой версией языка, как и сокращений. Например, ещё в начале года owned pointer записывался как ~T, например:

struct A {
    x: ~int
}

теперь вместо тильды используется Box<T>, который, собственно, в статье используется. А в прошлом году из языка удалили @, который обозначал как раз указатель за сборщиком мусора.

А больше в языке ничего сверхкраткого с закорючками нет.

[kvark]

Вас смутили области видимости. Если есть едеи, как описать их более человечно — делитесь ;)

[tgz]

Всеми силами надеюсь что Rust будет годнотой и избавит мир от цпп кода.

[aTwice]

Что мешает использовать Go?

[kvark]

Не хочу возобновлять священные войны, но Go не подходит для системного программирования, так что это не конкурент C++ и Rust. Этой темы мы уже касались в комментариях моей прошлой статьи.

[Googolplex]

Вы не сможете написать на Go, например, прошивку для микроконтроллера — рантайм слишком большой и ресурсоёмкий, а на Rust — вполне, если отключить его рантайм. В Go рантайм отключить хоть и можно, но бесполезно — вся безопасность работы с памятью, обеспеченная сборщиком мусора, потеряется. В Go также нет сырых указателей, которые очень важны для работы с железом. Да, там есть unsafe.Pointer, но работа с ними вызывает адскую боль. Это одно из объяснений.

[tgz]

Система типов и управление памятью.

[Hertz]

Пример про потоки совсем за уши притянут, Вы намеренно написали не thread-safe код, конечно он может проинициализировпть память несколько раз, это обычный race condition.

[kvark]

Вот от такого «обычного» race condition и спасает нас компилятор Rust. Повторюсь, смысл не в том, что на С++/asm нельзя написать хорошо, а в том, что на Rust вы обязаны написать хорошо, а иначе оно не соберётся. Многопоточность — лишь частный случай, но без неё картина была бы неполной.

[Chaos_Optima]

Я честно говоря ожидал другую статью, например о возможностях Rust'a которые сильно бы облегчали разработку по сравнению с С++
А то что в этой статье, так это примеры того как Rust защищает программиста от ошибок которые он и так не должен допускать (если это конечно нормальный программист).
Т.к. все примеры ошибок имхо высосаны из пальца, их допускают либо новички которые только только перешли на С++, либо криворукие которым не дано.

Напишите пожалуйста нормальную статью, потому что как мне кажется Rust достоин большего внимания, чем просто подгузник для программиста.

[kvark]

Я честно говоря ожидал другую статью, например о возможностях Rust'a которые сильно бы облегчали разработку по сравнению с С++

Главная возможность — защита от самопрострела ноги, и о ней я более-менее рассказал тут на примерах. Поверьте, оно сильно облегчает разработку ;)

их допускают либо новички которые только только перешли на С++, либо криворукие которым не дано.

Меня всегда заявляют такие высказывания. Как будто бы эти люди, которые криворукие, они где-то там, в другом мире, а мы работаем только с высшим сословием. Константин, приходилось ли Вам работать с большим С++ проектом? Мне — да, и я с горечью спешу Вас огорчить, что ошибки такого рода (простые, аналогично примерам из статьи) повсеместны. Они приносят уйму головной боли, проедают наше время и деньги на исправление.

[kvark]

Простите, заявляют забавляют

[Chaos_Optima]

> Главная возможность — защита от самопрострела ноги, и о ней я более-менее рассказал тут на примерах. Поверьте, оно сильно облегчает разработку ;)
То что я увидел я бы не назвал защитой от самострела, т.к. примеры, реально очень сильно надуманны.

> Константин, приходилось ли Вам работать с большим С++ проектом?
О да, не просто с большим, с гигантским.

> Мне — да, и я с горечью спешу Вас огорчить, что ошибки такого рода (простые, аналогично примерам из статьи) повсеместны. Они приносят уйму головной боли, проедают наше время и деньги на исправление.

Тогда давайте и я вас огорчу, подобные ошибки в 90% случаев отсеиваются варнингами, тестами, элементарным запуском на проверку, и ревью кода перед коммитом, не говоря уже об анализаторах, а если у вас в проекте допускаются подобные ошибки (; после for или возврат указателя на локальную переменную), и они каким-то образом проходят в репозиторий, то это означает что у вас проблемы как с программистами так и с менеджментом, сочувствую.

Плохому программисту не язык мешает.

[leventov]

Чем раньше обнаруживается ошибка, тем меньше на нее тратится времени и денег. Ваш К. О.

[Chaos_Optima]

Так никто об этом и не спорит, я лишь говорю что примеры в статье надуманны, автор также это признаёт ниже. Мне очень импонирует Rust и хотелось бы прочитать статью про реально полезные фишки этого языка которые делают его привлекательнее С++, а не то что он способен предотвращать банальные ошибки.

[leventov]

Способность предотвращать банальные ошибки — это и есть реально полезная фишка. Не вызвать деструкторы вручную. Еще есть сопоставление с образцом, но об этом уже моветон упоминать. По большому счету, это все, по сравнению с C++11/14. Я не понимаю, чего вы ждете, кнопку «сделать все как я хочу и без багов»?

[kvark]

Правда в том, что «проблемы как с программистами так и с менеджментом» есть везде. Проекты на С++, над которыми я работал (и работаю) профессионально, просто кишат велосипедами(свои умные указатели и контейнеры), голыми указателями, они не покрыты тестами и не проверяются статическими анализаторами. STL стараются избегать за милю, хотя это уже отдельная история… Эти проекты огромны (~35Mb собранный в release исполняемый файл), над ними работает туча людей, и ошибки появляются и исправляются постоянно.

Я знаю, что можно писать грамотно, использовать стандартные умные указатели и контейнеры (и в том же духе), но реальность такова, что свобода выбора этих инструментов и лёгкий доступ к самострелам играют злую шутку над разработчиками. Даже в Вашей неподтверждённой статистике 10% оставшихся ошибок могут занять больше времени и денег на исправление, чем написание и первичная отладка самого кода, содержащего их.

>Плохому программисту не язык мешает.
При правильном выборе инструмента (языка), плохих программистов становится заметно меньше.

[Hertz]

Часто отказ от c++ standard library обоснован, например в геймдеве, посмотрите, например, на ea stl. А другие команды пишут свои велосипеды.
Вот например нужен мне lock-free hashmap для игры, где мне его взять? Вероятнее всего написать самому.

[kvark]

Однако C++/CLI — это уже совсем другая история. На нём каши не сваришь ОС не напишешь…

А по поводу STL + unit tests, как уже говорилось, некоторые серьёзные проекты не используют их (игры!), так что дело не в квалификации. Да и самострелы не уходят «теоретически» — смотрите пример с итератором.

[kosmos89]

>которые он и так не должен допускать (если это конечно нормальный программист)
Нормальный программист как нормальный человек просто обязан допускать ошибки. Без ошибок человек не человек.

[Gorthauer87]

Все-таки самая большая проблема в cpp и c это отсутствие модулей, остальное вполне лечится новыми стандартами.

[kvark]

Если я не ошибаюсь, модули Бъярн тоже хочет вылечить новым стандартом. Он об этом говорил на Lang-NEXT.

[dimoclus]

используйте своё воображение, чтобы оценить масштабы угрозы в реальном мире

Почему-то меня не покидает ощущение, что в реальном мире у Rust найдутся свои грабли, для обхода которых будут делать еще один новый язык.

Может настало время принять очевидное: разработчик програмного обеспечения должен обладать высокой квалификацией и опытом хождения по граблям, в противном случае никакие языки программирования не спасут от кривого падучего кода?

[Googolplex]

Поскольку Rust — системный язык, там есть «задний ход» в небезопасный низкоуровневый мир — unsafe, где возможны небезопасные операции, вроде разыменования сырых указателей. Если программист будет пользоваться этими блоками направо и налево, он получит фактически C, где возможно всё, в том числе расстрелять себе ноги урановыми медведями.

Но сам язык сделан так (и на это сильный упор в его документации), что эти блоки нужно использовать только тогда, когда это реально необходимо (взаимодействие с C, например, или реализация высокоуровневых абстракций вроде Rc). Вне этих блоков ошибки, связанные с неправильной работой с памятью, исключены (с поправкой на возможные ошибки компилятора и баги в библиотеках). Поэтому, хоть языки и не могут в принципе спасти от кривого кода, они очень сильно могут облегчить когнитивную нагрузку и исключить наиболее распространённые ошибка. Если бы это было не так — мы бы до сих пор писали бы на ассемблере.

[kvark]

This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember, all I'm offering is the truth – nothing more.

Реальный мир для Rust наступает с каждым днём. Пока не видно и намёка на то, что реализованная модель безопасности работает плохо. Выясняются детали, полируются интерфесы, добавляются возможности, а в целом — по Ленину:

Верной дорогой идете, товарищи!

[DancingOnWater]

Тоже самое говорили про D, вот только порт Qt не обновляется с декабря… Меня это как-то резко напрягло

[kvark]

Я бы не отказался почитать на Хабре полноценный обзор D. Где язык находится сейчас, есть ли список живых проектов, как на D сказывается влияние Андрея Александреску, и насколько эффективно его применяют в Facebook (и зачем)?

[NCrashed]

Идеал недостижим, это не означает, что не надо к нему двигаться. Заметили часто встречающиеся грабли — исправили, обратили внимание на следующие (которые могут появиться и из-за такого исправления). Вся полезность высокоуровневых языков очевидна при сравнении, например, асма и тех же плюсов.

Однако высокую квалификацию никто не отменял, без нее и грабли не классифицируешь и не уберешь их с дороги, чтобы другим больше не мешались.

[vt4a2h]

В качестве примеров приведены банальные вещи. Хотя бы полгода промышленного программирования и будет очень сложно сделать ошибку во всех приведенных фрагментах кода. Конечно же от случайностей никто не застрахован, но cppcheck и valgrind всегда в помощь.
Хотелось бы сказать кое-что о сообщениях об ошибках (ваш пример из статьи):

gcc

/usr/include/c++/4.8/bits/stl_algo.h:160: ошибка: no match for 'operator==' (operand types are 'std::vector<int>' and 'const int')
    if (*__first == __val)
                 ^

clang

/usr/include/c++/4.8/bits/stl_algo.h:160: ошибка: invalid operands to binary expression ('std::vector<int, std::allocator<int> >' and 'int')
          if (*__first == __val)
              ~~~~~~~~ ^  ~~~~~

Да, сообщение об ошибке сильно длиннее, но я привел первую значащую строчку. По мне так это ни чем не хуже того что говорит нам Rust.
Кстати, если уж переписать код вашего примера на C++11, то он будет выглядеть не так уж и страшно:

    int a;
    std::vector<std::vector<int>> v;
    auto it = std::find(begin(v), end(v), a);

[kvark]

Примеры действительно банальны, и я это не скрываю. Зато их можно целиком взять и отдать Вашему компилятору, в том числе и online. Если Вы хотите погрузиться глубже в матрицу, посмотрите или почитайте выступление Niko Matsakis.

> Конечно же от случайностей никто не застрахован, но cppcheck и valgrind всегда в помощь.
Valgrind не доступен на Windows, а cppcheck не ловит все ошибки. В целом и то и другое я, несомненно, считаю необходимым для любого С++ проекта.

Clang действительно даёт более красивые сообщения об ошибках, лучше предупреждает об угрозах, и достоен внимания. В конце концов, Clang, как и Rust (как и Swift), работает на LLVM.

[Paul]

Valgrind не доступен на Windows

На Windows есть AppVerifier.

[leventov]

Не понимаю, почему комментаторы из лагеря C++ реагируют так, как будто их лично задевает, что Раст как язык лучше, чем плюсы. Ну лучше он, лучше. За собственную профессиональную ценность можете не беспокоиться, проектов на плюсах еще вашим внукам хватит (к сожалению).

[kvark]

Кажется, мои статьи дёргают за живое, заставляют некоторых людей выйти из своей пещеры. Пещеры иллюзии того, что нужно выбирать между надёжностью и производительностью, и что С++ занимает локальный оптимум в плане второго. Rust нарушает эти неписаные правила, и чтобы осознать это, нужно согласиться принять красную таблетку, а не синюю.

[Gorthauer87]

А потом бегать как белка в колесе за изменениями синтаксиса и стандартной библиотеки. Ржавчина еще весьма нестабильна. D в этом смысле уже чуть повзрослее.

[DancingOnWater]

А я вот не понимаю, почему вы считаете, что нас это задевает?

[leventov]

Не вы конкретно, но аж 5 комментаторов выше в разной форме сослались на «прямоту рук», требуемую для разработки на плюсах, в чем читается "kvark, ну раз ниасилил плюсы, не мозоль тут нам глаза".

[DancingOnWater]

Блин, да сколько ж вас в придуманном мире живет?

Цитирую автора: «однако мне будет интересно почитать Ваше экспертное мнение в комментариях. „

[leventov]

Это не экспертное мнение, а завуалированный переход на личности. Повторюсь, к вам это не относится, ваши комментарии строго по делу.

[Chaos_Optima]

Я не то подразумевал, я говорил что статья несёт в себе очень мало полезной информации. А не то, что Rust уг, C++ forever. Rust мне самому крайне интересен.

[wander]

Шаблоны в Rust проверяются на корректность до их инстанцирования...

В С++ тоже. Это называется two-phase name lookup. Не смотря на то, что Visual Studio не поддерживает его, он все еще остается требованием стандарта.
womble.decadent.org.uk/c++/template-faq.html#two-phase

[kvark]

Спасибо, это ценное дополнение. Однако всё, что связано с аргументами шаблона, проверяется только на второй фазе (при инстацировании), так что смысл сравнения остаётся прежним.

[Gorthauer87]

Вот ежели наконец родят концепты, то можно будет все проверять как следует.

[wander]

Я не спорю с тем, что диагностика в С++ может проигрывать другим языкам. Однако это

всё, что связано с аргументами шаблона, проверяется только на второй фазе

не совсем так. Скажем, частично проверка аргументов производится при специализации, и в некоторых других случаях.

template <typename T1, typename T2>
struct A
{
};
template <typename T1>
struct A<T1, 2>
{
};

Ну да ладно, собственно это не важно. Rust хороший язык, надеюсь найдется время познакомиться с ним поближе.

[wander]

Visual Studio не поддерживает

Поправлюсь, не поддерживала до версии 2012, насколько я могу судить. Однако все еще работает не корректно в некоторых случаях.

Например в таком

template<typename T>
struct Base
{
    template<typename U>
    struct InnerBase
    {};
};
template<typename T, typename U>
struct Derived : public Base<T>
{
    struct InnerDerived : public Base<T>::template InnerBase<U>
    {};
};

int main()
{
    Derived<int, int>::InnerDerived foo;
}

Сорри за оффтоп :)

[DancingOnWater]

Помедетировав над постом и комментариями автора пришел к выводу, что главный посыл автор, что Rust сообщает об ошибках на этапе компиляции.
Но приведенные примеры, строго говоря дики для плюсовика. Любой из нас нарвавшись на ошибки связанные с указателями пару раз понимает всю остроту этой бритвы и начинает пользоваться с осторожностью.
Единственно реально опасный случай может возникнуть с мнопоточностью, и то, только в ходе рефакторинга, в противном случае будет использован shared_ptr и атомические операции. Но честно, у меня не хватает воображения представить подобную ситуацию, т.е. ценность подобного предупреждения не велика.

Главная опасность в указателях C++ заключается в их арифметике и reinterept_cast, но отказ от этого я уже прочувствовал на C# и мне провал по скорости и костылеписанию жутко не понравился

[potan]

Я, кстати, сталкивался с ситуацией, когда программа, переписанная с обычных указателей на auto_ptr и еще что-то (программа не моя), потеряла 20% производительности. Правда падать перестала, что существенно важнее :-).

[mikhanoid]

Да. Но Вы же не пишете все компоненты большой системы единолично. За себя Вы можете отвечать, а за соседа? А за человека, который работает вместе с Вами над Open Source проектом (Rust же в Mozilla изобретали)? Rust позволяет гарантировать безопасность в этих случаях. И это имеет качественные последствия. Например, Вам больше может быть не нужна аппаратная изоляция процессов (виртуальная память). Можно работать без неё, на более простых, дешёвых и экономичных процессорах. При этом с хорошим уровнем безопасности и с богатой функциональностью: http сервер от автора A не испортит данные графическому интерфейсу от автора B, которые друг друга в глаза не видели, и код у них закрытый. Актуально для интернета вещей.

[DancingOnWater]

Сто-стоп-стоп. Для интернет-вещей есть Java, C#, PHP. Область C\С++ — прикладное ПО, вычисления, высоконагрузочные проекты, системное ПО.

[mayorovp]

Вы правда не видите разницы между «интернетом вещей» и «интернет-вещами»?

[DancingOnWater]

По-моему первое в контексте беседы не имеет смысла. В интернете вещей процессы изолированны аппаратно изначально.

[mayorovp]

Вы отрицаете необходимость запуска нескольких процессов на одном устройстве?..

[DancingOnWater]

А в этом суть концепции?

[mayorovp]

Нет, концепция интернета вещей заключается не в однозадачности устройств.

[DancingOnWater]

Да, и из этого следует трудности интеграции всех этих устройств. Rust предлагает что-то для решения этой проблемы? — нет.

[mayorovp]

Простите, но вы читать умеете?

Rust позволяет гарантировать безопасность в этих случаях. И это имеет качественные последствия. Например, Вам больше может быть не нужна аппаратная изоляция процессов (виртуальная память). Можно работать без неё, на более простых, дешёвых и экономичных процессорах.

Все еще не ясна связь Rust и интернета вещей?

[DancingOnWater]

Знаете, я не могу вам ответить, меня распирает смех и горькие слезы.
Прошу, просветите меня, зачем виртуализация была нужна для интернета вещей до появления раст?

[alexbers]

Добавлю, что rust ещё не готов для серьёзного использования. Язык сильно меняется, старый код, как правило, не собирается новой версией компилятора. Компилятор всё ещё нестабилен, несколько раз встречался с тем, что код падает на ровном месте в segfault.