into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016.

О том и речь. Одиночки запросто могут клепать свои pet-project-ы на чем угодно. Коллективы, которые работают на проектами с внешними требованиями, бюджетами и дедлайнами в несколько иной ситуации. И если коллектив успешно решает свои задачи с помощью современного C++, то продать ему Rust сложно.

О том и речь. Одиночки запросто могут клепать свои pet-project-ы на чем угодно.

Конечно. Но именно с них всё и начинается (и речь не столько о pet projects, сколько о one man show).

И если коллектив успешно решает свои задачи с помощью современного C++, то продать ему Rust сложно.

Да. Но, судя по /r/rust, это возможно уже сейчас.

В случае исключения раскручивается стек с очисткой ресурсов до точки, где можно что-то предпринять. Если такой точки в программе нет, тогда уже можно и упасть. А если есть, то можно, например, отрицательный ответ сгенерировать или повторить операцию с другим набором параметров. Тут уже от прикладной задачи зависит.

Я вижу, надо пояснять. Ловля эксепшенов бывает двух типов, один - это когда ловится конкретное исключение в конкретном месте потому что создание этого исключения - штатная, ожидаемая ситуация. Раст в таком случае использует Result и о возможных ошибках сообщает прототип функции. Есть другие ошибки, которые «всё, туши свет, сливай воду», их конкретно никто никогда не ловит, они либо роняют приложение, либо ловятся каким-нибудь «catch(Throweble)» вокруг высокоуровневой функции типа «обработка запроса», и не делают ничего вменяемого, просто сообщают «не шмогла» и переходят к следующему запросу.

Так вот, для вторых случаев у раста уже есть «барьер» в виде потоков + экспериментируют с дополнительными возможностями добавить барьер без создания потока. Сейчас паника разворачивается до границы потока. Так что если проект настолько серьёзен, что нужно отключать OOM киллер в настройках ядра и обрабатывать ошибку нехватки памяти, то врубить режим паники через unwind и вынести обработку запроса в поток - не такая уж и сложная задача.

Проблему для нового человека составляют не такие вот серьёзные непредвиденные ошибки, а всякая мелочь типа НеНайденаИконкаДляКнопкиЭксепшен, потому что уволившийся 5 лет назад программист когда-то решил, что именно таким способом удобнее сообщать об отсутствии картинки, о чём вообще-то написано в 3000 строке в файле «\\Storage\Development\Documents\SuperSoft2000\...\Readme.txt» и вообще, мог бы спросить.

Благодарствую за очередную простыню потока сознания. Но ни на один вопрос вы не ответили.

Так вот, для вторых случаев у раста уже есть «барьер» в виде потоков

Очень плохой барьер.

экспериментируют с дополнительными возможностями добавить барьер без создания потока. Сейчас паника разворачивается до границы потока.

IIRC, catch_unwind уже стабилизирован.

IIRC, catch_unwind уже стабилизирован.

Пару версий уже как стабилизировали это api

Но ни на один вопрос вы не ответили.

Хорошо, объясню проще: Не существует и не может существовать языка программирования, на котором можно было бы решать широкий круг задач, который при этом бы отлавливал все ошибки на этапе компиляции. Тем не менее любой язык программирования, даже ассемблер, спасает от какого-то класса ошибок. Раст в этом плане один из передовых языков, меньше информации приходится на документацию или устные договорённости, больше на проверяемый код. И дальше остаётся 2 вопроса: 1) согласны ли вы, что некоторые особенности раста (лайфтаймы, явное указание на возможность нулевого указателя, борроу чекер, явный возврат ошибки) позволяют избежать существенного класса неожиданностей при работе с малознакомым кодом? 2) согласны ли вы, что решение половины проблем - это лучше, чем не решение вообще?

Если ответы «да», то непонятно что вы тут делаете. Если хотя бы один ответ «нет», тогда уж напишите прямо, будет хотя бы понятно к чему это всё.

Вас куда-то не туда уносит. Вы выдвинули список претензий к C++. Среди них:

Всякая пурга типа «после того как сделал А, нужно сделать Б»
какая функция ... может исключение бросить

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

Для Go можно написать анализатор аналогичный тому что входит в стандарт компилятора Rust(ownership, lifetime analysis).

Дык, анализатор полагается, в том числе, на явно указанные лайфтаймы в коде. К которым много претензий в плане «читаемости». Если такие аннотации в Go добавить, то это тоже даром не пройдёт. Аналогично с дженериками.

популярности хотя бы как у явы

Ну-ну.

Какой в жопу лайфтайм анализис в языке с GC?

В Rust есть GC, но используется он реже.

всякие руби, гоу, питон и прочий геморрой тоже

На этом «геморрое» пишут не так уж мало и работу найти более чем реально. Да чего уж там, и на большей экзотике реально. Если к этому душа лежит, то чего ещё надо?

Или просто талантливые программисты как Fabrice Bellard.

И какому языку он помог «утвердиться»?

Дык, анализатор полагается, в том числе, на явно указанные лайфтаймы в коде.

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

К которым много претензий в плане «читаемости».

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

Ну нет. Паника — это abort(3).

Растовая паника?.. А ничего, что её можно перехватить?

Встроенным backtrace.

Т.е. пусть падает, а мы потом увидим, откуда именно упало?

Ну это всяко лучше segfault. За одно у нас и объекты почистятся, ибо, как уже написали выше, panic в расте вызывает деструкторы.

Просто покажите, чем Rust лучше в этих двух случаях.

Про исключения в общем-то всё рассказано уже.

Про последовательность действий... ну вот, например, создание итератора коллекции, чтение из него, уничтожение итератора и изменение коллекции - это 4 операции, которые не могут совершаться в произвольном порядке. Захват мутекса, доступ к объекту и освобождение мутекса - тоже. Разделение вектора на слайсы, создание кучи потоков для обработки, доступ к слайсам в потоках, завершение потоков и доступ к вектору. Контроль над выполнением правильности последовательностей вовсю работает на RAII + borrow checker'е.

В Rust есть GC, но используется он реже.

В таком случае, GC есть и в С++ и вообще (почти) везде.

За одно у нас и объекты почистятся, ибо, как уже написали выше, panic в расте вызывает деструкторы.

Чтобы объекты чистились, а ресурсы возвращались, нужно писать в том же духе, что и в C++ или в D при обеспечении exception safety. Тоже самое, только в профиль. Так что претензия по поводу исключений, которые в C++ якобы непонятно откуда ждать, выдает скорее неумение их готовить. Следовательно, и в Rust-е в коде никакой panic safety у подобных мастеров не будет.

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

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

GC в Go очень расслабляет, код лёгкий и воздушный

GC, конечно, снимает часть «нагрузки», но у меня несколько другое впечатление благодаря обработке ошибок. И для игровой логики можно что-то «ещё более лёгкое» (типа луа) взять.

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

Про исключения в общем-то всё рассказано уже.

Простите, но ничего не сказано. Про то, что в Rust-е можно использовать АлгТД для возврата ошибок не прибегая к panic-ам, давно известно. Поэтому я просил рассказать, как быть при наличии panic-ов. Они в Rust-е не могут вылететь откуда угодно? Или на них можно просто забить?

ну вот, например, создание итератора коллекции, чтение из него, уничтожение итератора и изменение коллекции - это 4 операции, которые не могут совершаться в произвольном порядке.

?

По остальным пунктам такие же вопросы. Такое ощущение, что про современный C++ вам Рабинович по телефону напел.

Но так пишут единицы, в то время, как в расте это поведение по умолчанию.

Во-первых, не единицы.

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

Rust-у пока везет в этом плане в том, что посредственностей в нем пока еще не так много. А когда туда ломанутся толпы индусов и бывших железячников, вопросы panic safety могут оказаться отнюдь не праздными.

Я ошибся, Rust может точно определять когда убирать память при компиляции. Меня ввёл в заблуждение пост в сети где кто-то объяснял что такое GC и упоминал в неоднозначном контексте Rust. Так и отложилось в памяти, как будто в Rust есть ситуации когда надо всё таки проверять HEAP.

По остальным пунктам такие же вопросы.

Ну в С++ можно в процессе обхода вектора изменить его размер и компилятор никак не даст по рукам.

Вопрос в том, насколько часто это случается именно при обходе контейнера?

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

Гораздо чаще случается ситуация, когда есть вектор, а в различных частях программы разбросаны ссылки на элементы этого вектора. В один прекрасный момент кто-то модифицирует вектор и ссылки протухают.

Но это не то, о чем говорил хрюндель.

Во-первых, не единицы.

Смотря на софт в моей уютненькой генте - я бы так не сказал.

Уязвимости и сегфолты на каждом шагу. И как раз раст решает все эти проблемы. Ибо вместо «у меня прога упала» можно отправить backtrace.

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

Да. И именно нелюбимый многими, «фашисткий» компилятор запрещает 95% процентов проблем от индусо-кода.

Вопрос в том, насколько часто это случается именно при обходе контейнера?

Не знаю.

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

Ну почему? Да, придётся более явно намерения показать, но как по мне это наоборот хорошо. Ну и в данном контексте это скорее побочный бонус от ссылочной семантики в расте, чем специальная фича.

В один прекрасный момент кто-то модифицирует вектор и ссылки протухают.

И от этого раст тоже защитит. Ага, ценой дополнительных ограничений.

Смотря на софт в моей уютненькой генте - я бы так не сказал.

И много там софта на современном C++?

И именно нелюбимый многими, «фашисткий» компилятор запрещает 95% процентов проблем от индусо-кода.

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

SIGABRT тоже можно перехватить.

$ curl rust-lang.org/en-US/documentation.html | grep -ic 'Code of Conduct'
1

Rust: language for pussies.

И много там софта на современном C++?

Что за «современный C++»? Если не считать фич/сахара языка, типа лямбд и auto - ничего не поменялось. Просто больше классов из boost'a утянули.

Я же говорю не о вкусовщине, а о реальных примерах. В rust тупо нельзя сделать 95% ошибок С/С++. Даже integer overflow в дебаге отлавливается. Совсем красота.

Про многопоточность я вообще молчу. С++ до раста как до луны.

У вас в генте глючный софт написан на C++? Или на C с glib и GTK?

Что за «современный C++»?

C++14.

типа лямбд и auto - ничего не поменялось

Ну да, ну да. Расскажите мне еще ваших интересных сказок.

В rust тупо нельзя сделать 95% ошибок С/С++

Предлагаю разделять C и C++. В C++ запросто можно использовать not_null<T> и не иметь проблем, которые есть в чистом C.

Если у кого-то не хватает опыта писать именно на C++, то да, Rust поможет.

Про многопоточность я вообще молчу. С++ до раста как до луны.

Уже появился убийца OpenMP/TBB/CUDA(которая ближе к C++, чем к чему бы то ни было)?

И, конечно же, с защитой от гонок, дедлоков и прочей дряни? Продано!Дайте две!

У вас в генте глючный софт написан на C++? Или на C с glib и GTK?

На всём подряд. По большей части C++, ибо Qt.

C++14.

Ну и что в нём такого революционного? Такого, что упростило отлов типовых ошибок, о которых мы говорим. Сахар есть, да.

Не поймите меня не правильно, я и сам пишу на плюсах. Но я не вижу в С++14 удобств уровня Rust.

Расскажите мне еще ваших интересных сказок.

Я задал конкретный вопрос.

Если у кого-то не хватает опыта писать именно на C++

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

OpenMP

Костыль, используемый 2.5 проектами

TBB

Видел его только в OpenCv.

CUDA

Узконишевая проприетарщина.

защитой от гонок, дедлоков и прочей дряни?

Ознакомитесь с докой. Большая часть проблем отловится на уровне компиляции.

Простите, но ничего не сказано. Про то, что в Rust-е можно использовать АлгТД для возврата ошибок не прибегая к panic-ам, давно известно. Поэтому я просил рассказать, как быть при наличии panic-ов. Они в Rust-е не могут вылететь откуда угодно? Или на них можно просто забить?

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

Но если важны именно паники - тоже в общем-то всё рассказали, либо падаем, либо ставим барьер. Большего как-то и хотеть нельзя.

По остальным пунктам такие же вопросы. Такое ощущение, что про современный C++ вам Рабинович по телефону напел.

Нет никакого «современного C++» в природе, это вас кто-то обманул. Реальный проект будет писаться людьми, которые изучали C++ по книгам 98го года. Но даже если б и был, и даже если бы кто-то потрудился нарушить все славные традиции и оформить в виде правильных RAII паттернов, толку было бы ноль: ну был бы у вас, например, мутекс как в расте, чтоб нельзя было получить указатель на данные в обход блокировки, один хрен этот указатель вы отдали бы в какую-то функцию, оттуда через цепочку вызовов он попал бы в другую функцию, автор которой мог и не догадываться, что полученный им параметр нельзя никуда сохранить, и привет, у вас ссылка на данные за незалоченным мутексом.

Уверяю вас, Бьярн Страуструп знает свой язык не хуже вас, и коль скоро он рекламирует C++ Core Guidelines, являющийся по сути подобием лайфтаймовой нотации раста, значит эта проблема существует и без явной поддержки со стороны языка её не решить. Ну а коль скоро всё равно нужно язык менять, зачем нужен недораст без паттернматчинга, ADT и с кучей устаревших решений, который и так не быстро компилируется, а ещё нужно анализатор запускать, чтоб убедиться в соответствии коре гайдлайнам, если есть нормальный раст?

Ясно.

убийца OpenMP/TBB/CUDA

Смешались в кучу кони, люди.

Ну и что в нём такого революционного?

rvalue references, universal references, move semantic, variable & variadic templates, decltype/declval, range-for, auto (в том числе и для вывода типа результата функции), lambda, smart-pointers в стандартной библиотеке, typeid, type_traits...

я и сам пишу на плюсах

Ну вы же говорили, что STL вам не нравится. Так что вас можно заподозрить в том, что C++ и modern C++ — это несколько не ваше.

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

Я вам больше скажу, эти же 100 студентов напишут на Go более стабильный код, чем на расте. И тормозить он не будет. И с многопоточностью там все в порядке. Так что если ориентироваться на студентов, то там и Rust в глубоком пролете.

Развёрнутый аргумент, пожалуйста.

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

Какая из них, по Вашему мнению, НЕ имеет отношения к C++ и многопоточности?

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

Вас в сторону уносит. В контексте беседы итератор приведён как пример принуждения пользователя типа к правильному порядку действий. Авторы решили, что для безопасности изменение контейнера не должно производиться одновременно с существованием итераторов/слайсов/указателей на него и сделали так. Таким образом, если вы пишете некую подсистему со сложным контрактом, вы можете воспользоваться borrow checker'ом чтоб заставить вызывающую сторону его соблюдать.

Нет никакого «современного C++» в природе, это вас кто-то обманул.

Вы вообще программированием занимаетесь или на форумах трындите? А то вокруг меня реальность несколько другая.

и коль скоро он рекламирует C++ Core Guidelines, являющийся по сути подобием лайфтаймовой нотации раста, значит эта проблема существует и без явной поддержки со стороны языка её не решить

Лайфтаймы в GSL — это только часть GSL. Сам GSL — это сконцентрированный набор рекомендаций, накопившихся за годы использования C++.

Ну а коль скоро всё равно нужно язык менять

Язык можно менять эволюционно. Что и происходит со всеми успешными и долгоживущими языками.

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

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

Таким образом, если вы пишете некую подсистему со сложным контрактом, вы можете воспользоваться borrow checker'ом чтоб заставить вызывающую сторону его соблюдать.

Покажите пример.

Какая из них, по Вашему мнению, НЕ имеет отношения к C++ и многопоточности?

По моему мнению, ни один язык не сможет стать убийцей всех трех технологий.

Был тезис:

[в плане многопоточности] С++ до раста как до луны.

Было высказано сомнение, в подтверждение которого были приведены связанные с многопоточностью довольно «взрослые» (прошу прощения за кальку с английского) технологии, которые есть в арсенале C++ программиста. CUDA, как всегда, тут несколько особняком, но в любом случае, к C++ она ближе и синтаксически, и инфраструктурно (см. напр. thrust).

Так каким же образом Ваш выпад к моей личности это опровергает?