Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 96

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

Ну и за корявый код вините не язык, а руки разработчика, тонкости он должен знать.
Всего голосов 41: ↑3 и ↓38-35
Из текста:
Если же память выделена в куче — то указатель на неё (Box) ведёт себя точно так же, как и обычная переменная на стеке (удаляется при выходе из зоны видимости). Для совместного использования данных есть подсчёт ссылок (std::rc::Rc) и сборщик мусора (std::gc::Gc), оба реализованы как сторонние классы (Вы можете написать свои).
Всего голосов 7: ↑7 и ↓0+7
Я так понимаю, в примерах printf никакого отношения к обсуждаемой проблеме не имеет и используется только вывода результата. Использование стримов — это конечно хорошо, но неужели это тут так принципиально?
Всего голосов 5: ↑5 и ↓0+5
Вы читали статью вообще? В Rust есть и куча, и сборщики мусора (ну сейчас там в стандартной библиотеке не полноценный GC, а подсчёт ссылок, но это дело желания и умения — написать нормальный GC). При этом все эти механизмы безопасны в принципе. А в C++ ничего не мешает вам, например, взять указатель во внутренности unique_ptr. Я уже не говорю про более сложные случаи, связанные с многопоточностью.
Всего голосов 5: ↑5 и ↓0+5
НЛО прилетело и опубликовало эту надпись здесь
я правильно понимаю, что GC в нём по-умолчанию включён?

P.S. Никто кстати не желает забабахать подобное сравнение про D?
Всего голосов 4: ↑4 и ↓0+4
НЛО прилетело и опубликовало эту надпись здесь
Если в D отключить сборщик мусора, то стандартная библиотека перестанет нормально функционировать. Кроме того, если вам стандартная библиотека и не нужна, то, отключая GC, вы возвращаетесь в мир проблем C++, так хорошо описанный автором статьи.

В Rust изначально заложена возможность писать безопасные программы без сборщиков мусора и других автоматических систем управления памятью.
Всего голосов 6: ↑6 и ↓0+6
Если так, то слабо верится, что разработчики языка смогут его оперативно поддерживать.
Комментарий пока не оценивали0
Никто кстати не желает забабахать подобное сравнение про D?


Сохранил первичную структуру поста. habrahabr.ru/post/225507/
Сравнение получается не сильно честным, примеры подобраны под сильный статический анализатор, встроенный в Rust, а D в этой области слабее.
Всего голосов 6: ↑6 и ↓0+6
Спасибо, это было великолепно!
Пора объявлять неделю языков программирования на Хабре. Небойсь, и Swift объявится ;)
Всего голосов 4: ↑3 и ↓1+2
После того, как Мейерс выступил на ДиКонф 2014, появилась вот такая интерпретация его выступления:
he-the-great.livejournal.com/52333.html
Комментарий пока не оценивали0
Очень странно, что вы увидели в Rust CoffeeScript'овый синтаксис. В Rust используются стандартные для C блоки для выделения кода, например. Да он вообще не похож на CoffeeScript!

А насчёт плюшек — тут можно спорить. Например, лично мне не нравятся строковые миксины, пусть они и офигенно мощные. А в Rust есть нормальные синтаксические гигиеничные макросы (и возможность создания полноценных процедурных макросов, как в Scala, например).
Всего голосов 7: ↑7 и ↓0+7
НЛО прилетело и опубликовало эту надпись здесь
Ну схожесть разве что в стрелках в функциях и в statement as expression. Но последним обладают многие языки, та же Scala например.
И Rust, и D, и GO мощные и современные языки, которые лишены многих недостатков C++. Поэтому, думаю, что можно спокойно выбирать язык с тем синтаксисом, который больше нравится.

Полностью согласен.
Всего голосов 2: ↑2 и ↓0+2
Регионов в D нет. В системном программировании они будут очень полезны.
Всего голосов 1: ↑1 и ↓0+1
> Размышления на тему того, как обратная совместимость мешает C++ достичь звёзд…

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

habrahabr.ru/post/68796/

А для чего это? Правильно, для обратной совместимости со старыми C программами (привет из 80-х).
Всего голосов 4: ↑4 и ↓0+4
Спасибо за статью!

Я бы ещё добавил, наверное, сравнение с С++ными примитивами для управления памятью — unique_ptr, shared_ptr и прочее, и указанием, почему всё-таки они не панацея. Потому что это довольно справедливая претензия — в современном С++ код через сырые указатели стараются не писать.
Всего голосов 2: ↑2 и ↓0+2
Вот здесь один из авторов языка (фактически, современную систему с &/&mut указателями и borrow checker'ом заложил именно он) рассказывает, как именно обеспечивается безопасность работы с памятью в Rust, и какого класса ошибки исключаются. Очень интересный доклад, интересующимся советую посмотреть.

Это первая из ссылок-источников в посте, просто хочу обратить на неё внимание.
Комментарий пока не оценивали0
Дошел до места, где автор сравнивает память, выделенную через new, с памятью на стеке. Дальше не читал.
Прежде чем писать о языке программирования, разберитесь в нем. Не надо заниматься распространением безграмотности, пожалуйста :)
Всего голосов 13: ↑10 и ↓3+7
А можно конкретнее? Я сравнил память из кучи и на стеке с точки зрения её управления в Rust. Может, если я плохо выразился, попробуйте Вы объяснить лучше.
Всего голосов 2: ↑2 и ↓0+2
1) Монстрообразные сообщения об ошибках это не проблема языка это проблема gcc. В clang-сообщение уже более понятно. Итого как плюс язык пункт номер 1 выбывает
2)Битые указатели на стековые переменные — это то, от чего программист на С++ избавляется очень быстро (Может ошибиться раз или два, но третей подобной ошибки он не допустит). Нужен подсчет ссылок — shaerd_ptr
3) Обращение к удаленной памяти отлавливается Valgrind и статическими анализаторами на раз-два.
4) Не полное перечисление в свитче — gcc и clang это отслеживают.
5) Многопоточность. Решается введением shared_ptr
Всего голосов 8: ↑7 и ↓1+6
По поводу (1) еще раз дам ссылку, которую уже постил ранее: blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

P.S.: Касательно самого утверждения можно поспорить. Автор отмечает особенности языка, который вылавливает подобные ошибки на лексическом уровне. Это все таки более круто, поскольку не накладывает на программиста дополнительных неявных или слабо формализованных ограничений.
Всего голосов 1: ↑1 и ↓0+1
Посмотрел на синтаксис Rust, вот так сразу из записи я не могу определить ошибку => все упирается в сообщение компилятора.

И да, я не понял к чему ссылка: в целях ознакомления или аргумент в споре? Если последнее, то тогда в каком?
Комментарий пока не оценивали0
к чему ссылка
Целях ознакомления; в подтверждение вашего пункта 1.

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

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

Даже зная тонкости, я был бы не против, если компилятор сможет отлавливать противоречия и в подобных местах.
Комментарий пока не оценивали0
А кто говорит что что-то не нужно, просто это не киллер-фича. Вот ошибки с многопоточностью — это да.
Комментарий пока не оценивали0
5) Многопоточность. Решается введением shared_ptr

Как?
Всего голосов 2: ↑2 и ↓0+2
Ну что-то типа того:

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

Но в Qt это сделано более удобно
Всего голосов 1: ↑1 и ↓0+1
Спасибо, направление понятно:
Инициализировать через atomic_compare_exchange_strong_explicit, а читать через atomic_load

Правда надо признать, shared_ptr тут не нужен. Можно обойтись простым указателем :)
Всего голосов 1: ↑1 и ↓0+1
Для совместного использования данных есть подсчёт ссылок (std::rc::Rc) и сборщик мусора (std::gc::Gc), оба реализованы как сторонние классы (Вы можете написать свои).Как написать свои классы без операции «удаления памяти»? Эта операция в языке есть, просто вы не нашли ее.
Комментарий пока не оценивали0
Извиняюсь, закрывающий тег уехал, поздно заметил.
Для совместного использования данных есть подсчёт ссылок (std::rc::Rc) и сборщик мусора (std::gc::Gc), оба реализованы как сторонние классы (Вы можете написать свои).
Как написать свои классы без операции «удаления памяти»? Эта операция в языке есть, просто вы не нашли ее.
Комментарий пока не оценивали0
Реализация Rc и Gc содержит небезопасный код для управления памятью. В области безопасного кода операции «удаления» нет, именно это имелось ввиду.
Комментарий пока не оценивали0
Когда-то так думали и труъ программисты, не признававшие ничего выше ассемблера. Особенно во время, когда компиляторы действительно генерировали код хуже человека.
Всего голосов 4: ↑4 и ↓0+4
Если бы в Rust'е еще синтаксис был более человеческим, а не эти кучи закорючек и сокращений в стиле Perl.
Всего голосов 15: ↑15 и ↓0+15
Во-во. Долго вникал в смысл 'a' в этой строке:
fn bar<'a>(p: &'a int) -> &'a int {

А еще на лямбда-синтаксис [](){} ругаются.
Всего голосов 4: ↑4 и ↓0+4
Можно просто писать: []{}
Комментарий пока не оценивали0
Как ни странно, в этом желании разработчики вас поддерживают. Поэтому в языке закорючек стало гораздо меньше по сравнению с первой версией языка, как и сокращений. Например, ещё в начале года owned pointer записывался как ~T, например:
struct A {
    x: ~int
}

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

А больше в языке ничего сверхкраткого с закорючками нет.
Всего голосов 3: ↑3 и ↓0+3
Вас смутили области видимости. Если есть едеи, как описать их более человечно — делитесь ;)
Комментарий пока не оценивали0
Всеми силами надеюсь что Rust будет годнотой и избавит мир от цпп кода.
Всего голосов 12: ↑7 и ↓5+2
Что мешает использовать Go?
Всего голосов 4: ↑0 и ↓4-4
Не хочу возобновлять священные войны, но Go не подходит для системного программирования, так что это не конкурент C++ и Rust. Этой темы мы уже касались в комментариях моей прошлой статьи.
Всего голосов 7: ↑7 и ↓0+7
Вы не сможете написать на Go, например, прошивку для микроконтроллера — рантайм слишком большой и ресурсоёмкий, а на Rust — вполне, если отключить его рантайм. В Go рантайм отключить хоть и можно, но бесполезно — вся безопасность работы с памятью, обеспеченная сборщиком мусора, потеряется. В Go также нет сырых указателей, которые очень важны для работы с железом. Да, там есть unsafe.Pointer, но работа с ними вызывает адскую боль. Это одно из объяснений.
Всего голосов 6: ↑6 и ↓0+6
Система типов и управление памятью.
Всего голосов 1: ↑1 и ↓0+1
Пример про потоки совсем за уши притянут, Вы намеренно написали не thread-safe код, конечно он может проинициализировпть память несколько раз, это обычный race condition.
Комментарий пока не оценивали0
Вот от такого «обычного» race condition и спасает нас компилятор Rust. Повторюсь, смысл не в том, что на С++/asm нельзя написать хорошо, а в том, что на Rust вы обязаны написать хорошо, а иначе оно не соберётся. Многопоточность — лишь частный случай, но без неё картина была бы неполной.
Всего голосов 4: ↑4 и ↓0+4
Я честно говоря ожидал другую статью, например о возможностях Rust'a которые сильно бы облегчали разработку по сравнению с С++
А то что в этой статье, так это примеры того как Rust защищает программиста от ошибок которые он и так не должен допускать (если это конечно нормальный программист).
Т.к. все примеры ошибок имхо высосаны из пальца, их допускают либо новички которые только только перешли на С++, либо криворукие которым не дано.

Напишите пожалуйста нормальную статью, потому что как мне кажется Rust достоин большего внимания, чем просто подгузник для программиста.
Всего голосов 8: ↑6 и ↓2+4
Я честно говоря ожидал другую статью, например о возможностях Rust'a которые сильно бы облегчали разработку по сравнению с С++

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

Меня всегда заявляют такие высказывания. Как будто бы эти люди, которые криворукие, они где-то там, в другом мире, а мы работаем только с высшим сословием. Константин, приходилось ли Вам работать с большим С++ проектом? Мне — да, и я с горечью спешу Вас огорчить, что ошибки такого рода (простые, аналогично примерам из статьи) повсеместны. Они приносят уйму головной боли, проедают наше время и деньги на исправление.
Всего голосов 6: ↑5 и ↓1+4
Простите, заявляют забавляют
Комментарий пока не оценивали0
> Главная возможность — защита от самопрострела ноги, и о ней я более-менее рассказал тут на примерах. Поверьте, оно сильно облегчает разработку ;)
То что я увидел я бы не назвал защитой от самострела, т.к. примеры, реально очень сильно надуманны.

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

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

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

Плохому программисту не язык мешает.
Всего голосов 7: ↑5 и ↓2+3
Чем раньше обнаруживается ошибка, тем меньше на нее тратится времени и денег. Ваш К. О.
Комментарий пока не оценивали0
Так никто об этом и не спорит, я лишь говорю что примеры в статье надуманны, автор также это признаёт ниже. Мне очень импонирует Rust и хотелось бы прочитать статью про реально полезные фишки этого языка которые делают его привлекательнее С++, а не то что он способен предотвращать банальные ошибки.
Всего голосов 1: ↑1 и ↓0+1
Способность предотвращать банальные ошибки — это и есть реально полезная фишка. Не вызвать деструкторы вручную. Еще есть сопоставление с образцом, но об этом уже моветон упоминать. По большому счету, это все, по сравнению с C++11/14. Я не понимаю, чего вы ждете, кнопку «сделать все как я хочу и без багов»?
Всего голосов 3: ↑3 и ↓0+3
Правда в том, что «проблемы как с программистами так и с менеджментом» есть везде. Проекты на С++, над которыми я работал (и работаю) профессионально, просто кишат велосипедами(свои умные указатели и контейнеры), голыми указателями, они не покрыты тестами и не проверяются статическими анализаторами. STL стараются избегать за милю, хотя это уже отдельная история… Эти проекты огромны (~35Mb собранный в release исполняемый файл), над ними работает туча людей, и ошибки появляются и исправляются постоянно.

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

>Плохому программисту не язык мешает.
При правильном выборе инструмента (языка), плохих программистов становится заметно меньше.
Всего голосов 3: ↑2 и ↓1+1
Часто отказ от c++ standard library обоснован, например в геймдеве, посмотрите, например, на ea stl. А другие команды пишут свои велосипеды.
Вот например нужен мне lock-free hashmap для игры, где мне его взять? Вероятнее всего написать самому.
Комментарий пока не оценивали0
--защита от самопрострела ноги

для этого уже есть C++/CLI

когда новичек вырастет до профи он будет использовать STL + юнит тесты и самопристрелы будут теоритически невозможны
Комментарий пока не оценивали0
Однако C++/CLI — это уже совсем другая история. На нём каши не сваришь ОС не напишешь…

А по поводу STL + unit tests, как уже говорилось, некоторые серьёзные проекты не используют их (игры!), так что дело не в квалификации. Да и самострелы не уходят «теоретически» — смотрите пример с итератором.
Всего голосов 1: ↑1 и ↓0+1
>которые он и так не должен допускать (если это конечно нормальный программист)
Нормальный программист как нормальный человек просто обязан допускать ошибки. Без ошибок человек не человек.
Всего голосов 3: ↑3 и ↓0+3
Все-таки самая большая проблема в cpp и c это отсутствие модулей, остальное вполне лечится новыми стандартами.
Всего голосов 4: ↑3 и ↓1+2
Если я не ошибаюсь, модули Бъярн тоже хочет вылечить новым стандартом. Он об этом говорил на Lang-NEXT.
Комментарий пока не оценивали0
используйте своё воображение, чтобы оценить масштабы угрозы в реальном мире

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

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

Но сам язык сделан так (и на это сильный упор в его документации), что эти блоки нужно использовать только тогда, когда это реально необходимо (взаимодействие с C, например, или реализация высокоуровневых абстракций вроде Rc). Вне этих блоков ошибки, связанные с неправильной работой с памятью, исключены (с поправкой на возможные ошибки компилятора и баги в библиотеках). Поэтому, хоть языки и не могут в принципе спасти от кривого кода, они очень сильно могут облегчить когнитивную нагрузку и исключить наиболее распространённые ошибка. Если бы это было не так — мы бы до сих пор писали бы на ассемблере.
Всего голосов 3: ↑3 и ↓0+3
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 наступает с каждым днём. Пока не видно и намёка на то, что реализованная модель безопасности работает плохо. Выясняются детали, полируются интерфесы, добавляются возможности, а в целом — по Ленину:
Верной дорогой идете, товарищи!
Всего голосов 2: ↑2 и ↓0+2
Тоже самое говорили про D, вот только порт Qt не обновляется с декабря… Меня это как-то резко напрягло
Комментарий пока не оценивали0
Я бы не отказался почитать на Хабре полноценный обзор D. Где язык находится сейчас, есть ли список живых проектов, как на D сказывается влияние Андрея Александреску, и насколько эффективно его применяют в Facebook (и зачем)?
Всего голосов 1: ↑1 и ↓0+1
Идеал недостижим, это не означает, что не надо к нему двигаться. Заметили часто встречающиеся грабли — исправили, обратили внимание на следующие (которые могут появиться и из-за такого исправления). Вся полезность высокоуровневых языков очевидна при сравнении, например, асма и тех же плюсов.

Однако высокую квалификацию никто не отменял, без нее и грабли не классифицируешь и не уберешь их с дороги, чтобы другим больше не мешались.
Всего голосов 1: ↑1 и ↓0+1
В качестве примеров приведены банальные вещи. Хотя бы полгода промышленного программирования и будет очень сложно сделать ошибку во всех приведенных фрагментах кода. Конечно же от случайностей никто не застрахован, но 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);
Всего голосов 1: ↑1 и ↓0+1
Примеры действительно банальны, и я это не скрываю. Зато их можно целиком взять и отдать Вашему компилятору, в том числе и online. Если Вы хотите погрузиться глубже в матрицу, посмотрите или почитайте выступление Niko Matsakis.

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

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

На Windows есть AppVerifier.
Всего голосов 1: ↑1 и ↓0+1
Не понимаю, почему комментаторы из лагеря C++ реагируют так, как будто их лично задевает, что Раст как язык лучше, чем плюсы. Ну лучше он, лучше. За собственную профессиональную ценность можете не беспокоиться, проектов на плюсах еще вашим внукам хватит (к сожалению).
Всего голосов 9: ↑6 и ↓3+3
Кажется, мои статьи дёргают за живое, заставляют некоторых людей выйти из своей пещеры. Пещеры иллюзии того, что нужно выбирать между надёжностью и производительностью, и что С++ занимает локальный оптимум в плане второго. Rust нарушает эти неписаные правила, и чтобы осознать это, нужно согласиться принять красную таблетку, а не синюю.
Всего голосов 1: ↑1 и ↓0+1
А потом бегать как белка в колесе за изменениями синтаксиса и стандартной библиотеки. Ржавчина еще весьма нестабильна. D в этом смысле уже чуть повзрослее.
Всего голосов 3: ↑3 и ↓0+3
А я вот не понимаю, почему вы считаете, что нас это задевает?
Всего голосов 6: ↑4 и ↓2+2
Не вы конкретно, но аж 5 комментаторов выше в разной форме сослались на «прямоту рук», требуемую для разработки на плюсах, в чем читается "kvark, ну раз ниасилил плюсы, не мозоль тут нам глаза".
Всего голосов 4: ↑3 и ↓1+2
Блин, да сколько ж вас в придуманном мире живет?

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

Всего голосов 4: ↑2 и ↓20
Это не экспертное мнение, а завуалированный переход на личности. Повторюсь, к вам это не относится, ваши комментарии строго по делу.
Комментарий пока не оценивали0
Я не то подразумевал, я говорил что статья несёт в себе очень мало полезной информации. А не то, что Rust уг, C++ forever. Rust мне самому крайне интересен.
Комментарий пока не оценивали0
Шаблоны в Rust проверяются на корректность до их инстанцирования...

В С++ тоже. Это называется two-phase name lookup. Не смотря на то, что Visual Studio не поддерживает его, он все еще остается требованием стандарта.
womble.decadent.org.uk/c++/template-faq.html#two-phase
Комментарий пока не оценивали0
Спасибо, это ценное дополнение. Однако всё, что связано с аргументами шаблона, проверяется только на второй фазе (при инстацировании), так что смысл сравнения остаётся прежним.
Комментарий пока не оценивали0
Вот ежели наконец родят концепты, то можно будет все проверять как следует.
Всего голосов 1: ↑1 и ↓0+1
Я не спорю с тем, что диагностика в С++ может проигрывать другим языкам. Однако это
всё, что связано с аргументами шаблона, проверяется только на второй фазе

не совсем так. Скажем, частично проверка аргументов производится при специализации, и в некоторых других случаях.
template <typename T1, typename T2>
struct A
{
};
template <typename T1>
struct A<T1, 2>
{
};

Ну да ладно, собственно это не важно. Rust хороший язык, надеюсь найдется время познакомиться с ним поближе.
Комментарий пока не оценивали0
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;
}

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

Главная опасность в указателях C++ заключается в их арифметике и reinterept_cast, но отказ от этого я уже прочувствовал на C# и мне провал по скорости и костылеписанию жутко не понравился
Всего голосов 1: ↑1 и ↓0+1
Я, кстати, сталкивался с ситуацией, когда программа, переписанная с обычных указателей на auto_ptr и еще что-то (программа не моя), потеряла 20% производительности. Правда падать перестала, что существенно важнее :-).
Всего голосов 2: ↑2 и ↓0+2
Да. Но Вы же не пишете все компоненты большой системы единолично. За себя Вы можете отвечать, а за соседа? А за человека, который работает вместе с Вами над Open Source проектом (Rust же в Mozilla изобретали)? Rust позволяет гарантировать безопасность в этих случаях. И это имеет качественные последствия. Например, Вам больше может быть не нужна аппаратная изоляция процессов (виртуальная память). Можно работать без неё, на более простых, дешёвых и экономичных процессорах. При этом с хорошим уровнем безопасности и с богатой функциональностью: http сервер от автора A не испортит данные графическому интерфейсу от автора B, которые друг друга в глаза не видели, и код у них закрытый. Актуально для интернета вещей.
Всего голосов 5: ↑5 и ↓0+5
Сто-стоп-стоп. Для интернет-вещей есть Java, C#, PHP. Область C\С++ — прикладное ПО, вычисления, высоконагрузочные проекты, системное ПО.
Всего голосов 2: ↑0 и ↓2-2
Вы правда не видите разницы между «интернетом вещей» и «интернет-вещами»?
Комментарий пока не оценивали0
По-моему первое в контексте беседы не имеет смысла. В интернете вещей процессы изолированны аппаратно изначально.
Всего голосов 1: ↑0 и ↓1-1
Вы отрицаете необходимость запуска нескольких процессов на одном устройстве?..
Комментарий пока не оценивали0
А в этом суть концепции?
Всего голосов 1: ↑0 и ↓1-1
Нет, концепция интернета вещей заключается не в однозадачности устройств.
Комментарий пока не оценивали0
Да, и из этого следует трудности интеграции всех этих устройств. Rust предлагает что-то для решения этой проблемы? — нет.
Всего голосов 1: ↑0 и ↓1-1
Простите, но вы читать умеете?
Rust позволяет гарантировать безопасность в этих случаях. И это имеет качественные последствия. Например, Вам больше может быть не нужна аппаратная изоляция процессов (виртуальная память). Можно работать без неё, на более простых, дешёвых и экономичных процессорах.

Все еще не ясна связь Rust и интернета вещей?
Комментарий пока не оценивали0
Знаете, я не могу вам ответить, меня распирает смех и горькие слезы.
Прошу, просветите меня, зачем виртуализация была нужна для интернета вещей до появления раст?
Всего голосов 1: ↑0 и ↓1-1
Добавлю, что rust ещё не готов для серьёзного использования. Язык сильно меняется, старый код, как правило, не собирается новой версией компилятора. Компилятор всё ещё нестабилен, несколько раз встречался с тем, что код падает на ровном месте в segfault.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr