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

move semantic

Тут в соседней теме обсуждали какая она полезная и «безопасная».

rvalue references

Я их до сих пор не понимаю. Но как они помогают от ошибок - не ясно.

variable & variadic templates

Еще раз. Я о безопасности, а не о фичах.

range-for, lambda

Сахар.

smart-pointers в стандартной библиотеке

Их использование опционально, в отличии от раста.

Ну вы же говорили, что STL вам не нравится.

Так да, он убог. rust std намного лучше, из-за более предсказуемого поведения.

несколько не ваше

Я то тут при чём. Каким бы modern не был бы С++, он всё равно не такой современный как rust.

И тормозить он не будет.

Но в разы медленней он будет точно. Бенчей полно в сети.

Если на мне нужны полный async io и 100500 нитей - разницы между Go и Rust не будет.

Язык можно менять эволюционно.

Хедеры выкинут - тогда заживём.

технологии

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

В rust же static из коробки многопоточный. i32 вам не дадут использовать в потоке. Как и все объекты без реализации Send/Sync. И всё в этом духе. То есть неверный код даже не скомпилируется.

То что у Rust нет аналога OpenMP не имеет отношения к языку. Биндинги к OpenCL и CUDA есть.

Был тезис:

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

Нет. Тезис был другим: «по возможностям безопасной многопоточности Си++ до Rust как до Луны». Поскольку ни в одной из приведенных «технологий» нет средств безопасности, сравнимых с Rust, на этом можно было бы и закончить.

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

На сравнение двух _языков_ (Си++ и Rust) были приведены 1 библиотека (TBB) и комплекс из языка и технологии (CUDA). К собственно языковым средствам относится только OpenMP.

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

Никак. Он и не должен был что-то опровергать.

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

Реальность такая, что многие программисты до сих пор собственную реализацию shared pointer пишут. Чисто по привычке. Сам видел.

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

Хмм.. GSL - это Guidelines support library. Т.е. тупо набор тайпдефов аля owned<T*> = T*.

Сами гайдлайны называются «c++ core guidelines» и да, они включают больше чем просто лайфтаймы. Они включают owned<T*>, вот этот самый not_null<T*> и много других вещей, которые позаимствовали из раста. Кстати, эти самые гайдлайны лежат на гитхабе, первый коммит чуть больше года назад, т.е. уже после релиза раста, так что никаких сомнений на тему является ли cppcg попыткой догнать раст быть не может.

Не то чтоб вопрос первенства был так важен, просто не надо сочинять про «накопившиеся за годы использования».

Затем, что он есть уже 30 лет.

Полностью с вами согласен, пора отправлять на покой. Для сравнения: коболу 30 стукнуло в 89м, бейсику в 94м, паскалю в 2000м. Конечно, есть ещё старичок C, но так как он является просто портабельным ассемблером, ему позволительно жить дольше, в этой области мало что нового можно изобрести.

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

И пусть оно будет. И пусть куча программистов зарабатывают на поддержке кода. Просто старый софт под современный C++ портировать будут нечасто, а для новых проектов разумнее брать что-то более современное. Я, извините меня, уже в 2000х как-то сидел на поддержке/развитии проекта на C/X11/Motif и как-то даже мыслей не было предложить портировать это на C++/QT какие-нибудь. Возможно и сейчас какой-нибудь несчастный сидит и страдает на этом проекте. 90%+ от вашего «столько сделано» представляют собой примерно такие же проекты.

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

grep по коду. Есть unsafe? Иди переговнокоживать без unsafe. Всё. Проблема решена.

Тезис был другим: «по возможностям безопасной многопоточности Си++ до Rust как до Луны».

Это случай так называемого вранья.

На сравнение двух _языков_

Сравнивать языки в вакууме — дело не мальчика, но мужа. Незаменимо в любом реальном проекте.

Ладно, подыграю: в С++ есть ещё Cilk+, чисто языковое средство для того же, не либа.

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

Безопаснее Haskell c STM (deadlock-free memory model) и, прямо скажем, куда более богатой системой типов и изоляцией стейта? Или Erlang с наиболее честной на рынке моделью вытесняющей многопоточности и встроенным OLP для конкуррентности? Быстрее и удобнее thrust на числодробилках? Готовый в данный момент, а не в светлом будущем?

Для меня символ раста — это стековерфлоу внутри деаллоктора из прошлого треда. И Rust _принуждает_ к этой практике своей «безопасностью».

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

grep по коду. Есть unsafe?

Зачем же так примитивно? Достаточно #![forbid(unsafe_code)]

Тезис был другим: «по возможностям безопасной многопоточности Си++ до Rust как до Луны».

Это случай так называемого вранья.

Читай внимательнее.

Ладно, подыграю: в С++ есть ещё Cilk+, чисто языковое средство для того же, не либа.

Это уже четвертая «технология», убийства которой ты ожидаешь от Rust, или ты начал писать список хотелок с чистого листа?

Безопаснее Haskell c STM (deadlock-free memory model) и, прямо скажем, куда более богатой системой типов и изоляцией стейта?

Без понятия. Но если ты предлагаешь использовать Хаскель вместо Rust... удачи. Если нет, то зачем ты вообще вспомнил Хаскель.

Для меня символ раста — это стековерфлоу внутри деаллоктора

Подход не мальчика, но мужа.

Тут в соседней теме обсуждали какая она полезная и «безопасная».

На LOR-е обсуждают много херни и здесь офигенное количество ыкспертов.

Я их до сих пор не понимаю. Но как они помогают от ошибок - не ясно.
Еще раз. Я о безопасности, а не о фичах.

Да как бы вам объяснить, чтобы не обидеть. Ну вот допустим, нам нужно было создать вектор с какими-то полиморфными значениями и вернуть его наружу. Сейчас это можно сделать, например, так:

auto make_vector() {
  vector< unique_ptr<Base> > r;
  r.reserve(some_size);
  ...
  return r;
}
...
auto vec = make_vector();
for(const auto & b : vec)
  ...

В C++03 пришлось бы делать гораздо больше телодвижений. Больше шансов ошибиться, особенно при сопровождении, когда какие-то типы где-то меняются.

Их использование опционально, в отличии от раста.

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

rust std намного лучше, из-за более предсказуемого поведения.

Например?

Но в разы медленней он будет точно.

В вычислительных может быть. На каком-нибудь IO сильно сомневаюсь.

Реальность такая, что многие программисты до сих пор собственную реализацию shared pointer пишут. Чисто по привычке. Сам видел.

Прям многие? Может они следом еще и свои streams пишут, и вектора, и хеш-таблицы?

Не то чтоб вопрос первенства был так важен, просто не надо сочинять про «накопившиеся за годы использования».

Простите, вам сколько лет, если вы в GSL видите не зафиксированные в конце-концов в одной библиотеке best practices, а попытку угнаться за Rust-ом?

90%+ от вашего «столько сделано» представляют собой примерно такие же проекты.

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

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

Ну то есть вектор будет перемещён, а не скопирован. Я правильно понял? Возврат auto - это вроде как уже С++14. До него я еще не дорос. Хотя с уходом в раст - особо и не нужно.

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

Например?

Увы, но много примеров привести не могу, именно потому, что я не использую std. Любимый tailgunner'ом пример с UB в option уже хорош. Use after move вообще прекрасен и прочие прелести. std, построенный на эксплуатировании этих возможностей меня не устраивает.

Что бы не быть голословным, в Rust, если я вызову unwrap у Option с None, я получу не сегфолт/UB, а красивое сообщение, после чего прога завершится с вызовом всех деструкторов. Заодно я могу получить backtrace.

На каком-нибудь IO сильно сомневаюсь.

А при чём тут IO и язык?

Это уже четвертая «технология», убийства которой ты ожидаешь от Rust, или ты начал писать список хотелок с чистого листа?

Нет, но Вы же придрались, что я, дескать, перечислил библиотеки, а не фичи самого языка — потому «не считается» — пришлось исправляться, добавлять фичи именно языка.

Если нет, то зачем ты вообще вспомнил Хаскель.

Как я говорю, я подыграю, и закрою глаза на подмену изначального тезиса. В конце концов, если не прощать собеседнику лёгкого огородно-поливального камуфляжа, на ЛОРе и делать нечего. /Допустим/, Rust обыгрывает C++ по безопасности многопоточного кода. Но тут уж многие языки дадут гадким крестам фору. Почему бы не выбрать что-то другое, более «взрослое»? Альтернатив немало.

Но если ты предлагаешь использовать Хаскель вместо Rust...

Какой же в Haskell фатальный недостаток, позвольте узнать?

Подход не мальчика, но мужа.

Подход не кочетка, но страуса.

P.S. Вообще, идея, что некая магическая система типов позволит сделать многопоточный код безопасным легко и совершенно без потери производительности (#zerocostabstractions, ага) — это классическая триада «быстро, качественно, эффективно».

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

Ну то есть вектор будет перемещён, а не скопирован.

В старом C++ мы либо рисковали просесть по производительности за счет копирования результирующего значения, либо нужно было использовать out-параметр. А out-параметры — это и больше кода, и чревато ошибками.

Да, безопаснее, но не решение.

Так я же не сравнивал безопасность C++14 с безопасностью Rust-а. Сравнивается безопасность C++14 с безопасностью C++03.

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

Увы, но много примеров привести не могу, именно потому, что я не использую std.

Жаль. Пока только какие-то городские легенды.

А при чём тут IO и язык?

При том, что для этого Go и создавался.

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

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

Когда ты говоришь, что подыграешь, ты делаешь это исключительно для себя.

Какой же в Haskell фатальный недостаток, позвольте узнать?

Зависит от области применения. Для системного программирования - толстый рантайм и непредсказуемость из-за ленивости.

Для меня символ раста — это стековерфлоу внутри деаллоктора

Подход не мальчика, но мужа.

Подход не кочетка, но страуса.

Ну или так.

Вообще, идея, что некая магическая система типов позволит сделать многопоточный код безопасным легко и совершенно без потери производительности (#zerocostabstractions, ага) — это классическая триада «быстро, качественно, эффективно».

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

Процитируй, где в TAPL говориться об этом запрете.

Почему бы не выбрать что-то другое, более «взрослое»?

[KO]Потому, что безопасная многопоточность без GC только у Rust. [/KO]

Какой же в Haskell фатальный недостаток, позвольте узнать?

Сходите, посмотрите бенчмарки.

Сравнивается безопасность C++14 с безопасностью C++03.

Я вижу. А я сравнивал С++ с Rust.

Поймите в чем фишка: смена языка должна быть оправдана.

Прекрасно понимаю и агитирую писать Новые проекты на расте.

Пока только какие-то городские легенды.

Как так? UB уже перестал существовать?

При том, что для этого Go и создавался.

Я конечно профан, но фишка Go под названием Green threads никак не вяжется с IO. Или вы про межпоточный IO, а не дисковую подсистему? Тогда каюсь.

Но тогда Rust тоже создавался для aio, это один из его постулатов.

А я сравнивал С++ с Rust.

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

агитирую писать Новые проекты на расте.

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

UB уже перестал существовать?

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

Или вы про межпоточный IO, а не дисковую подсистему?

Я про разнообразные сетевые сервисы, под которые Go и создавался. И где go-роутины сильно облегчают жизнь разработчику.

P.S. s/эффективно/дёшево/

Зависит от области применения.

Уже что-то.

Для системного программирования - толстый рантайм

В нынешние времена под системным программированием могут подразумевать что угодно. Нужно уточнение.

и непредсказуемость из-за ленивости

Неужто новая версия методички? Обычно же он непредсказуем из-за GC!

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

Процитируй, где в TAPL говориться об этом запрете.

*должно быть* очевидно любому, *прочитавшему* TAPL хотя бы до введения

Ну что я могу тут поделать...

Потому, что безопасная многопоточность без GC только у Rust.

Без GC

Ну и зачем нужна такая безопасность?

Бенчмарки у хаскеля как раз более чем нормальные. И выразительность шикарная. И система типов великолепная. И средства для работы с потоками удобные.

В нынешние времена под системным программированием могут подразумевать что угодно. Нужно уточнение.

https://en.wikipedia.org/wiki/System_programming

и непредсказуемость из-за ленивости

Неужто новая версия методички?

Опыт использования DARCS.

Обычно же он непредсказуем из-за GC!

А предсказуемый сборщик мусора в Хаскель не завезли? Окей, тогда еще и сборка мусора.

*должно быть*

Похоже, оно должно тебе лично.

Пытался освоить язык и просто не понял его. Сначала было подумал, вот не могу осилить его, мозгов не хватает, но вскоре уловил себя на мысли, что язык просто намерено запутанный, как-будто умышлено ставили цель сделать его максимально «не таким как все». В конечном итоге я стал ловить себя на мысли, что мне откровенно гадят в мозг.

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

выбросить все

Зачем же всё выбрасывать? Нужна вам новая прога/либа - пишите её на расте. Неужели обязательно писать её на плюсах? Да, либ пока мало, но это временная проблема.

сетевые сервисы

В этой области Go безусловно прекрасен.

Ну и зачем нужна такая безопасность?

Там, где некогда ждать пока GC почухается.

Бенчмарки у хаскеля как раз более чем нормальные.

Для своей ниши - да. Для системщины - не очень.

Нужна вам новая прога/либа - пишите её на расте.

Дык абсолютно новая и не нужна. Нужно что-то поверх имеющегося. Или такое же, но чуть-чуть другое.

Неужели обязательно писать её на плюсах?

Вся инфраструктура давно готова и налажена. Плюс язык каждые три года становится заметно лучше и удобнее.

Да, либ пока мало, но это временная проблема.

Это если Rust-у повезет хотя бы в половину от того, как повезло Go.

Похоже, оно должно тебе лично.

Ещё одна уступка. Допустим, я Вашу эрудицию сейчас недооцениваю. Так какая же ключевая мысль доносится до читателя в этом введении?

Опыт использования DARCS.

У меня такого опыта нет, но в «интернетах пишут», что проблема DARCS в основном в экспоненциальных алгоритмах, разве нет?

У меня же есть опыт использования анализатора гигабайтных pcap-трейсов на этом языке, который почему-то не течёт.

https://en.wikipedia.org/wiki/System_programming

Я про это и говорю. Широкая больно область.

язык просто намерено запутанный

Самообман как он есть. Вы хоть с чего переучивались?

не таким как все

То есть C/C++/C#/Java/D вы никогда не видели? Про маргинальщину, от которой он почерпнул идеи, вообще молчу.

Вся инфраструктура давно готова и налажена.

Это хорошо. Увы, но у меня противоположное мнение.

Это если Rust-у повезет хотя бы в половину от того, как повезло Go.

Ну половину популярности Go он уже имеет.

Там, где некогда ждать пока GC почухается.

Erlang используют в soft-realtime системах больше лет, чем многим пользователям Rust. Алгоритмов GC много, есть и детерминированные.

Ни и главное. *Ты* вот сам-то что за system-level hard-realtime low-latency софт-то пилишь?

P.S. Прошу прощения, посыпаюсь пеплом: всё-таки первая глава, а не введение. Это большая разница!

Ну половину популярности Go он уже имеет.

Списки вакансий и спрос на готовых Rust-программистов отлично это подтверждает.

Erlang используют

Мало ли что используют. Люди вон и десктоп софт готовы на JS писать. Но это не значит, что это хорошо.

У Rust есть ниша, которая совпадает с моими интересами. Поэтому я его и выбрал.

Я вангую, что Rust вытеснит C/C++ из нишы: переписать узкое место в *скриптовый язык*, чтобы было быстрее. Модулей для python и node.js уже прилично. Проще налабать на rust, чем долбаться с сишкой. Ну и прочие низкоуровневые либы и высокопроизводительный прикладной софт. Всякие там кодеки аудио/видео, шрифтовые движки, etc.

*Ты* вот сам-то что за system-level hard-realtime low-latency софт-то пилишь?

От того, что я не пишу в этих областях, GC становится быстрее?

Языку полтора года. Чего еще ожидать? Я про количество проектов и сообщество.

А предсказуемый сборщик мусора в Хаскель не завезли?

Как Вы доказали в недавней дискуссии с библиотеками для многопоточности, главное — не то, что уже работает и протестировано, а *потенциал языка*! Потенциально haskell куда более детерменирован, чем Rust с его смартпоинтерами, ибо время освобождения смартпоинтера зависит от внешних условий, а детерминированному гц достаточно только стек просканировать один раз, и затем он может, например, параллельно работать.

Мало ли что используют.

Вот это аргумент! O___~

Наповал.

От того, что я не пишу в этих областях

...мне сразу вспоминается термин «карго-культ». ^____~

Как Вы доказали в недавней дискуссии с библиотеками для многопоточности, главное — не то, что уже работает и протестировано, а *потенциал языка*!

Интересно, ты TAPL тоже так творчески читал?

Потенциально haskell куда более детерменирован,

То есть предсказуемого сборщика мусора всё же не завезли. Окей.

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

Время освобождения Box<T> зависит от внешних условий? Ты Rust даже на картинках не видел.

Сходите, посмотрите бенчмарки.

Будешь смеяться, но я именно так для себя haskell и открыл. По произведению выразительность*быстродействие лучше ничего-то и нет.

выразительность

Когда это перестало быть вкусовщиной?

Вот это аргумент!

Получше ваших.

Интересно, ты TAPL тоже так творчески читал?

«Всё мне ясно стало теперь!» (с)

Время освобождения Box<T> зависит от внешних условий?

Не Box, а Rc, кажется. См. прошлый тред, пример, где Rc падает в стековерфлоу.

Ты Rust даже на картинках не видел.

Леверье тоже никогда Нептун на картинках не видел.

То есть предсказуемого сборщика мусора всё же не завезли. Окей.

То есть убийцы CUDA/OpenMP/TBB/Cilk+ всё же не завезли. Окей.

Я про количество проектов и сообщество.

О, да! http://githut.info/

А ведь есть еще и закрытые коммерческие проекты.

Rust с его смартпоинтерами, ибо время освобождения смартпоинтера зависит от внешних условий

Время освобождения Box<T> зависит от внешних условий?

Не Box, а Rc, кажется.

Reference counting недетерминирован, внезапно. Но это не единственный смартпойнтер Rust.

Ты Rust даже на картинках не видел.

Леверье тоже никогда Нептун на картинках не видел.

Вопрос о том, видел ли ты Rust вживую, даже не стоит.

То есть предсказуемого сборщика мусора всё же не завезли. Окей.

То есть убийцы CUDA/OpenMP/TBB/Cilk+ всё же не завезли

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

Вы шутите?

Last update: 2014

Но это не единственный смартпойнтер Rust.

Но, предполагаю, единственный, который можно как-то соотнести по мощности с GC?

Более того - убийцу CUDA в Rust даже не планируют завозить.

Как же так-то! Многопоточность *в опасности*!

Ну так покажите, что за последние 2 года что-то для Rust-а изменилось. Это же так просто.

соотнести

Соотносить ARC и GC вообще смысла мало.

это не единственный смартпойнтер Rust.

Но, предполагаю, единственный, который можно как-то соотнести по мощности с GC?

Расскажи мне о методике «соотнесения по мощности».

Более того - убийцу CUDA в Rust даже не планируют завозить.

Как же так-то!

Как-то так.

Многопоточность *в опасности*!

Не волнуйся, с ней всё нормально.