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

Reference counting недетерминирован, внезапно.

И снизошло растаманам откровение, и простили они GC.

GC зло! GC зло! GC зло! GC зло! GC зло! Только карандаши — шариковые ручки не работают в космосе! Шариковые ручки — зло! Шариковые ручки — зло! Шариковые ручки — зло!

^ |

Так было на самом деле, в любом раст-треде.

Спокойной ночи, и пусть Вам приснится ОС на Rust, без единого CVE и дедлока.

Увы, но такой статистики не имею, впрочем как и вы. Так что не аргумент.

language:Go stars:>100 - 2,407

language:Rust stars:>100 - 303

Да. Преимущество. Но у языков разница релиза в 3-и года.

GC зло! GC зло! GC зло! GC зло! GC зло! Только карандаши — шариковые ручки не работают в космосе!

Этот растохейтер порвался, несите следующего.

Главное — верить.

Главное — верить.

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

Спокойной ночи

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

Да и вам удача пригодится — нужно же будет разбросать unsafe по коду (oh, the irony!), чтобы в benchmarkgame не сливать хотя бы по time:

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lan...

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

Сливать кому, обиженный вы наш?

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

Ну, в моём случае правильный ответ «все», но я решил ограничиться более слабым утверждением, так как я видел только 2х и они работали вместе, возможно, один другого покусал. Хэш таблицы они, конечно же, не пишут, они пользуются старым добрым std::map.

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

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

Вы спорьте не со мной, а с проклятой реальностью, в которой GSL - это библиотечка, первые опубликованная в августе прошлого года и, следовательно, не являющаяся частью ни многострадального C++11, ни 14. То же относится и к core guidelines (вы, почему-то упорно путаете эти понятия).

Да, вся эта пурга - это попытка сделать C++ подтяжку, чтоб стал похожим на rust. Если уж хотите вести холивар - говорите, что core guidelines - это такой «rust 2.0» и создана она как работа над ошибками в расте. Эта версия хотя бы истории не противоречит.

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

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

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

Хаскель - это такая мечта программиста, типа я буду говорить что делать, а шайтанмашина сама решит как это делать. А потом он идёт на собеседование и потенциальный руководитель первым же заданием просит написать какую-нибудь простейшую хрень типа суммы элементов списка и полученный код жрёт тонну памяти потому что соискатель не добавил восклицательный знак. Потом выясняется, что известные примеры типа квиксорта в 3 строчки и решета эратосфена - это обман, они в принципе не являются реализациями данных алгоритмнов, а настоящее решето на хаскеле намного сложнее и непонятнее реализации на императивном языке.

Увы, но такой статистики не имею, впрочем как и вы.

Я бы так не сказал, просто она менее наглядная. От февраля 2016-го: http://redmonk.com/sogrady/2016/02/19/language-rankings-1-16/

По этой статистике Rust в 3-и раза менее популярен чем Go. Не далеко от правды. Я писал, что 2-а.

Ну, в моём случае правильный ответ «все», но я решил ограничиться более слабым утверждением, так как я видел только 2х

«Многие пишут свои умные указатели», «я видел только 2x»

facepalm.jpg

Да, вся эта пурга - это попытка сделать C++ подтяжку, чтоб стал похожим на rust. Если уж хотите вести холивар - говорите, что core guidelines - это такой «rust 2.0» и создана она как работа над ошибками в расте. Эта версия хотя бы истории не противоречит.

Вы когда-нибудь слышали про «после — не значит в следствии»?

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

Правда? И много вы таких проектов видели? Каков был их объем? И не было ли так, что для таких проектов C++ перестал быть хорошим выбором еще в 90-х?

Продолжай, мне всё равно. Тем более, всё это уже было на ЛОРе. Может ты это даже из какого-то моего давнего наезда на haskell почерпнул.

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

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

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

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

О, в кое-каких - будет. Поверь мне.

Менять во время обхода - завязываться на реализацию (ничего не сломается) => нарушение инкапсуляции

Такое ощущение, что фанаты Rust-а искренне надеются, что Rust компенсирует им отсутствие мозга.

deque< unique_ptr< task > > tasks = get_initial_task_list();
while( !tasks.empty() ) {
  for( auto it = begin(tasks); it != tasks.end(); ) {
    if( it->completed() )
      it = tasks.erase(it);
    else {
      if( it->needs_split() )
        tasks.emplace_back( it->split() );
      ++it;
    }
  }
}

«Многие пишут свои умные указатели», «я видел только 2x»

Вы не заметили, что уже на протяжении 3 сообщений минимум методично сливаетесь? По делу ни одного довода, только «мальчик, сколько тебе лет» и «а вот ты написал ..., а теперь докажи» и «ну это не 100% доказательство».

Вы можете не верить, но С++ доживает свой век. Новые фичи добавляются с большим запозданием, и реализованы криво, так как должны быть совместимыми со старым кодом, новые проекты предпочитают начинать на других языках. Всё что остаётся - молиться на старый код, который на modern C++ не похож вообще ни разу. Новые программисты изначально учатся на какой-нибудь питон и джаву, старые программисты пишут код как писали в начале 90х.

Правда? И много вы таких проектов видели? Каков был их объем?

Вы бы перестали огрызаться и вместо классического «а ты кто такой» взяли бы да привели контрпример.

Вы не заметили, что уже на протяжении 3 сообщений минимум методично сливаетесь?

Я заметил, что вы так и не смогли ответить на вопросы, которые вам были заданы (into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016. (комментарий)). Но вот херни наговорили изрядно.

Вы можете не верить, но С++ доживает свой век.

С++ будет доживать свой век не меньше, чем Cobol.

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

По сравнению с тем, как развивался C++ до 2011-го года, сейчас все просто в шоколаде.

новые проекты предпочитают начинать на других языках.

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

Всё что остаётся - молиться на старый код, который на modern C++ не похож вообще ни разу.

Может кто-то молится, не знаю. Знаю примеры, когда кодовую базу немаленького объема и возрастом более 10-15 лет тихо и спокойно дорабатывают, плавно переводя на новый C++.

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

Это нормально. Не всем нужно погружаться в околосистемное программирование или middleware.

старые программисты пишут код как писали в начале 90х.

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

Вы бы перестали огрызаться и вместо классического «а ты кто такой» взяли бы да привели контрпример.

Контрпример чего? Где ваш пример, на который вы мне рекомендуете привести контрпример?

Вот, кстати, и пример программиста, пишущего по канонам 90х.

В 90-х были unique_ptr и emplace?

Я же помню, какое определение системы типизации Вы тут выдавали с надутым видом. Предлагаете после этого обсуждать /не/ банальности с Вами? Знаете, как-то было такое дело: дали мартышке пенсне...

Покажите, как это будет выглядеть по канонам 2010-х.

Я же помню, какое определение системы типизации Вы тут выдавали

Напомни.

с надутым видом

Ты лучше хорошему учись. Не можешь учиться хорошему - хотя бы не учись плохому.

Ещё неизвестно, что окажется запутаннее - няшка борроучекер с лайфтаймами, или изобилие «похожих, но чуть-чуть разных» value categories в последних C++1z. Лично мне вот при первом варианте удерживать всё в голове как-то проще.

Вот, кстати, и пример программиста, пишущего по канонам 90х.

Может, по канонам 60-х сразу? Там же структуры данных, и - эти - алгоритмы)))

https://play.rust-lang.org/?gist=4413c694e6db2e6c6e0315f98939d81f&version...

Может даже и быстрее будет из-за того, что список одним куском.

Точнее вот так: https://play.rust-lang.org/?gist=be372a924b13c6673a7c44a5498da89e&version...

А needs_split() встроено прямо в Rust?)

Я так понимаю, что вы сделали какую-то другую задачу. Нужно идти по списку задач снова и снова до тех пор, пока они не закончатся. Те задачи, которые завершились, нужно удалять. Если задача не завершилась и нуждается в расщеплении, то в конец списка нужно поставить новую задачу.

needs_split() это артефакт недостаточно мощной системы типов в C++.

Достаточно вызывать эту функцию в цикле. Я пропустил внешний while(!...is_empty()).

Когда раст научится хотя-бы перегружать операторы, тогда и поговорим про системы типов)

https://doc.rust-lang.org/std/ops/

Перегрузка операторов — синтаксический сахар. Каким боком тут система типов?

Когда раст научится хотя-бы перегружать операторы, тогда и поговорим про системы типов)

Rust умеет перегружать операторы. Что ты там хотел сказать про систему типов? Говори.

Не говорите о чём не знаете, пожалуйста. Вышел Rust 1.8

Каким боком это относится к needs_split()?

Это к перегрузке операторов. А насчет needs_split, наводящий вопрос: что будет если вызвать split(), когда needs_split() == false?

Ничего подобного. Это элемент Command-Query Separation Principle. needs_split — это query, не изменяющий объект. split — это command, модифицирующий объект. Кроме того, для task::split может быть определено предусловие (true == this->needs_split()).

Так что, если беретесь показать аналог, по показывайте его с использованием того же API. А то ведь и исходный пример можно переписать с использованием boost::optional или std::optional (из C++17):

deque< unique_ptr< task > > tasks = get_initial_task_list();
while( !tasks.empty() ) {
  for( auto it = begin(tasks); it != tasks.end(); ) {
    if( it->completed() )
      it = tasks.erase(it);
    else {
      if( auto child = it->split() )
        tasks.emplace_back( move(*child) );
      ++it;
    }
  }
}

Автор ответил)

Это элемент Command-Query Separation Principle.

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

Стабильного ABI у С++ нет (впрочем как и у Раста), так что использовать тот же интерфейс особого смысла нет.

Можно и кальку с вашего решения сделать, c usize вместо итератора.

https://play.rust-lang.org/?gist=49e1c87c14b49b20a0ee919b37b30efa&version...

Заменить «стабильное ABI» на «стандартное ABI»

Стандартный ABI у Си++ есть.

Бинарный интерфейс, совместимый с С? Это и Раста есть.

У тебя точно так же контракт проверяется во время выполнения if'ом, только ещё и код менее самодокументирован, и нельзя узнать у task needs_split() или !needs_split().

Нет. Стандартный C++ ABI.

https://gcc.gnu.org/onlinedocs/libstdc /manual/abi.html

http://mentorembedded.github.com/cxx-abi/abi.html

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

Ну вот и понятен стал твой уровень, лалка. RVO в этом случае будет. RVO, который был ещё в Borland Turbo C++ 3.0. Любой нормальный компилятор именно это сделает сегодня.

У современного C++ есть преимущества, в том числе связанные с безопасностью. Но в сравнении с Rust они блекнут.

Контракт НЕ проверяется во время выполнения. Во время выполнения проверяется только порождает ли задача новую задачу. Option<Box<Task>> гарантирует, что порожденную задачу можно получить только если она действительно есть.

только ещё и код менее самодокументирован

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

Очевидные вещи не видите.

и нельзя узнать у task needs_split() или !needs_split()

В предложенном eao197 коде не было никаких указаний, что needs_split() нужна для чего-то ещё кроме контроля предусловия для split().

Но, никто не мешает добавить needs_split() к трейту Task, и оставить split() как есть.