Параллельный код. Это (без иронии) замечательно, что в C++ можно написать так же удобно.
А вот про безопасность давайте поговорим отдельно. "В плюсах сделаете { } просто и в конце jthread сделает join()". А что будет, если не "сделать { }"? И что будет, если не "конце jthread сделает join()"? Потому, что в Rust это нельзя не сделать, код не скомпилируется. В обычные потоки (не scoped) нельзя передать не 'static объект (объект, который живет всю жизнь программы). И не в смысле пока жив main, но и после этого;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"?
Обработка ошибок через монады
"Обработка ошибок через монады есть и в плюсах" И надо поддерживать как обработку ошибок монадами, так и исключениями одновременно;
"Какие проблемы у монад я написал в первом комментарии" Да не то, чтобы написали, кроме "Это ужасный код ... все равно смотрится как каша". Дело ваше, чувство прекрасного у всех свое. Меня же больше интересует практическая сторона вопроса, чем эстетическая;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"?
Рефакторинг
"система типов в плюсах не слабее, чем в расте. Думаю с этим спорить бессмысленно". Не готов спорить, у меня нет достаточных компетенций в C++;
"Перечисления в плюсах это std::variant, паттерн матчинг это std::visit". То же самое, не готов спорить, но первый комментарий из первой ссылки из гугла, которую я открыл, с этим не согласен;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"?
Факты
"Слишком мало контекста". Ответы на все эти вопросы вы могли бы получить просто посмотрев выступление, из которого эти тезисы;
"Rust навязывает и заставляет писать правильный код, в отличии от большинства других языков". Ужас то какой, заставляет писать правильный код. Как жить то после такого;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"? Где хотя бы противоречие или несогласие, раз уж вы решили написать почти полторы тысячи символов по этому поводу?
Время компиляции
Видимо хоть в чем-то мы согласны, это уже неплохо;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"?
Сложность
"Rust сложным, насколько я понял по множеству статей, кажется людям, которые переходят с языков вроде python. И причины тут очевидны" Причины настолько очевидны, что их и указывать не надо? И, кстати, будем знакомы, я как раз начал изучать Rust после Python. И я считаю, что Rust - простой;
"Насчет Си - наверно под "маленький" имеются ввиду концепции в языке". Это ему не помогает, в C приходится думать о слишком большом количестве вещей и из-за этого никто не способен писать безопасный код на C и/или C++;
"Option<NotNull<Node<T>>>". Насколько я знаю, в стандартной билбиотеке плюсов код гораздо более нечитаем, тут же просто по переводу можно довольно точно понять, что происходит;
"если там всегда есть объект". Потому, что не всегда там есть объект;
"А если он есть не всегда, тогда зачем NotNull?". Чтобы нельзя было разыменовать нулевой указатель;
"А что вообще значит ситуация, когда Option == None". Что объекта там нет;
"Я под обработкой ошибок понимаю считай весь код, который есть в вашей версии, но нет в моей". Допустим, мне вообще не кажется это важным;
"Поэтому я и сказал, что мне не нравятся исключения в C++". Тогда я не понимаю примера в вашем первом комментарии. Вы не хотите писать "ужасный код" для обработки ошибок как значений и вам не нравятся исключения. Вы хотите жить в мире, где ошибок просто не существует? Я тоже был бы не против, только пока такого не предвидится;
"Наверняка и ваш код на Rust можно сделать более красивым". В данном случае можно т.к. filter_map_ok принимает замыкание, которое возвращает Option. Получилось вот так:
Мне по большому счету все равно. Код с and_then лучше тем, что ему не надо быть в функции, которая возвращает Option. Может быть когда стабилизируют try_blocks так будет удобнее во всех случаях. Для меня большой разницы нет, Option все равно придется как-то проверить и никакая магия не поможет избавиться от последнего map.
В итоге, вы написали очень много слов про C++. У меня в статье C++ упоминается 7 раз. 5 из них это цитаты (или перефразирование цитат) и еще 2 во вступлении. Так что я не очень понимаю, к чему эта гора текста про C++, про который я в статье не говорю? Кто ж виноват в том, что в статьях, из которых я брал тезисы, очень много сравнений с C++.
Я отвечал на пункты по мере прочтения и только в конце понял, что вы мне не противоречите нигде, кроме эстетической составляющей кода. На эту тему дискутировать я не хочу, мне в большой степени все равно, как оно выглядит. Пусть каждому нравится свой стиль кода, я не против.
Мне так не кажется, у меня отдельный абзац об этом в статье.
Раст значительно сложнее
Мне так не кажется, у меня отдельная часть статьи об этом.
писать статьи, в которые заложено сравнение и сопоставление двух языков, при этом бравируя, что одного из них вы не знаете, конечно не стоит
Если вы считаете, что где-то в моей статье есть фактическая ошибка напишите, пожалуйста, я с радостью её исправлю и пересмотрю свой взгляд на этот счет.
Выход за длину это как раз и есть выход за границу слайса и проблема ровно в том, что паники при этом нет, она возникает только при выходе за границу capacity.
на Rust в двое быстрее, чем этот же C++ проект заново на C++
Если вас не затруднит, подскажите, что же помешало тем же самым людям, переписывающим тот же самый код с C++ на C++ на второй и, особенно, на третий раз сделать это в 2 раза быстрее?
После прочтения, вам не показалось что язык тут играет второстепенную роль?
После переслушивания выступления нет, не показалось.
скорость переписывания с одного языка на другой
Именно из-за этого Ларс в самом начале и говорит:
There is nothing that makes people more angry on the internet than talking about benchmarks. Except, talking about developer productivity.
А еще он говорит, что на переписывание кода с C++ на Rust и на последующую поддержку кода после этого нужно как минимум в двое меньше людей.
P.s. Меня поражает то, насколько Rust сообщество на самом деле скромное и критичное даже к самому Rust'у. Вы просто посмотрите на то, что люди писали в комментариях под фотографией одного слайда (с как раз вырванной из контекста фразой про то, что в Rust продуктивность в 2 раза выше, чем в C++) из выступления (про видео и, соответственно, текст выступления написали позднее). Как минимум половина комментариев ровно про то же самое! "Как они измеряли продуктивность", "А может быть это просто были очень мотивированные писать на Rust разработчики", "А насколько честное это сравнение" и т.д. Я бы хотел увидеть еще еще одно такое сообщество, куда приходят с выступлением о том, что их любимый язык в 2 раза продуктивнее, чем другой, но вместо радости они относятся к этой информации очень подозрительно.
Да, пожалуй, говорить, что связные списки не нужны совсем - преувеличение. У них есть своя ниша - удаление или добавление элемента/ов туда, где прямо сейчас находится итератор. Во всех остальных случаях у него хуже производительность и это еще надо очень хорошо протестировать, чтобы понять, что это даст прибавку в скорости работы.
Мне кажется, что искать в дебаге производительный код несколько странно. Для этого и придуман релиз режим, чтобы при разработке можно было код быстро компилировать, а чтобы в релизе код быстро работал. При желании можно сделать свой профиль, в котором будут и оптимизации (какого-то уровня) и дебаг символы. Я так свой трассировщик оптимизировал.
И тут половина ваших фактов не имеет смысла, а остальная половина спорна
Можете привести примеры?
Это ужасный код
Красота в глазах смотрящего.
у вас кода их обработки больше
Мы, наверно, считаем "код для обработки ошибок" очень по-разному. Можете, пожалуйста, мне пальцем показать мне весь код, который как вы думаете отвечает за обработку ошибок. Я могу суммарно символов 10 указать.
Сравните с чистой логикой
Можете перечислить все возможные исключения, которые могут возникнуть в подобном коде на C++? Желательно всего кода, а не только той части, где нет ошибок и только опциональные значения.
Не вижу, что в этом плохого. Начиная от того, что мы и так доверяем огромному количеству людей, разработчики Rust тут точно даже не в первой сотне по значимости, заканчивая тем, что да, я доверяю чужим людям. И если это доверие нарушено я перестану и постараюсь переосмыслить то, чему у них доверял.
Используйте безопасные типы
Чтобы использовать безопасные типы надо знать, какие из типов безопасны, а у меня опыта нет.
Но я практически не увидел людей ссылающиеся на эти проблемы
Про эти проблемы я читал десятки раз и я не хочу делать свою статью трехтомником для того, чтобы в неё вошли все возможные плюсы, минусы и подводные камни Rust, сравнение со всеми возможными языками, состояние экосистемы во всех нишах и т.д. Если вас это интересует, я могу вам гарантировать, что при недолгом поиске вы это найдете.
Уж лучше диабет, чем расстройство нервной системы. Да и не думаю, что в статье о переходе Rust -> С++ есть большой смысл. Я гарантирую, что мой C++ код будет ужасен и состоять из UB процентов на 70. Только это не докажет, что Rust лучше (или C++ хуже), а только то, что я лично не умею писать код на C++. Что очень легко прочитать, как "Rust разработчики не умею писать код на C++", что в свою очередь можно прочитать, как "Rust разработчики не умею писать код". Это уже тут в комментариях происходит, что же будет в такой специализированной статье.
Вот обратное было бы интересно. Опытный C++ разработчик пишет некий сервис на C++. Потом N месяцев учит Rust и пишет аналогичный сервис на Rust. Там можно сравнить и код, и ощущения разработчика.Я бы такое почитал. Вообще такое сделал Google и результаты для C++ неутешительные.
разрабы, пишущие на расте, скорее всего не понимают, что там под капотом происходит
Так в этом и плюс Rust,ты можешь позволить себе не знать, что там происходит (и использовать Rust как Python 4) и при этом писать быстрый и корректный код.
Параллельный код. Это (без иронии) замечательно, что в C++ можно написать так же удобно.
А вот про безопасность давайте поговорим отдельно. "В плюсах сделаете { } просто и в конце jthread сделает join()". А что будет, если не "сделать { }"? И что будет, если не "конце jthread сделает join()"? Потому, что в Rust это нельзя не сделать, код не скомпилируется. В обычные потоки (не scoped) нельзя передать не 'static объект (объект, который живет всю жизнь программы). И не в смысле пока жив main, но и после этого;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"?
Обработка ошибок через монады
"Обработка ошибок через монады есть и в плюсах" И надо поддерживать как обработку ошибок монадами, так и исключениями одновременно;
"Какие проблемы у монад я написал в первом комментарии" Да не то, чтобы написали, кроме "Это ужасный код ... все равно смотрится как каша". Дело ваше, чувство прекрасного у всех свое. Меня же больше интересует практическая сторона вопроса, чем эстетическая;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"?
Рефакторинг
"система типов в плюсах не слабее, чем в расте. Думаю с этим спорить бессмысленно". Не готов спорить, у меня нет достаточных компетенций в C++;
"Перечисления в плюсах это std::variant, паттерн матчинг это std::visit". То же самое, не готов спорить, но первый комментарий из первой ссылки из гугла, которую я открыл, с этим не согласен;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"?
Факты
"Слишком мало контекста". Ответы на все эти вопросы вы могли бы получить просто посмотрев выступление, из которого эти тезисы;
"Rust навязывает и заставляет писать правильный код, в отличии от большинства других языков". Ужас то какой, заставляет писать правильный код. Как жить то после такого;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"? Где хотя бы противоречие или несогласие, раз уж вы решили написать почти полторы тысячи символов по этому поводу?
Время компиляции
Видимо хоть в чем-то мы согласны, это уже неплохо;
Что же из этой части в моей статье "не имеет смысла", а что "спорно"?
Сложность
"Rust сложным, насколько я понял по множеству статей, кажется людям, которые переходят с языков вроде python. И причины тут очевидны" Причины настолько очевидны, что их и указывать не надо? И, кстати, будем знакомы, я как раз начал изучать Rust после Python. И я считаю, что Rust - простой;
"Насчет Си - наверно под "маленький" имеются ввиду концепции в языке". Это ему не помогает, в C приходится думать о слишком большом количестве вещей и из-за этого никто не способен писать безопасный код на C и/или C++;
"
Option<NotNull<Node<T>>>". Насколько я знаю, в стандартной билбиотеке плюсов код гораздо более нечитаем, тут же просто по переводу можно довольно точно понять, что происходит;"если там всегда есть объект". Потому, что не всегда там есть объект;
"А если он есть не всегда, тогда зачем NotNull?". Чтобы нельзя было разыменовать нулевой указатель;
"А что вообще значит ситуация, когда Option == None". Что объекта там нет;
"Я под обработкой ошибок понимаю считай весь код, который есть в вашей версии, но нет в моей". Допустим, мне вообще не кажется это важным;
"Поэтому я и сказал, что мне не нравятся исключения в C++". Тогда я не понимаю примера в вашем первом комментарии. Вы не хотите писать "ужасный код" для обработки ошибок как значений и вам не нравятся исключения. Вы хотите жить в мире, где ошибок просто не существует? Я тоже был бы не против, только пока такого не предвидится;
"Наверняка и ваш код на Rust можно сделать более красивым". В данном случае можно т.к.
filter_map_okпринимает замыкание, которое возвращаетOption. Получилось вот так:Заголовок спойлера
Мне по большому счету все равно. Код с
and_thenлучше тем, что ему не надо быть в функции, которая возвращаетOption. Может быть когда стабилизируют try_blocks так будет удобнее во всех случаях. Для меня большой разницы нет,Optionвсе равно придется как-то проверить и никакая магия не поможет избавиться от последнегоmap.В итоге, вы написали очень много слов про C++. У меня в статье C++ упоминается 7 раз. 5 из них это цитаты (или перефразирование цитат) и еще 2 во вступлении. Так что я не очень понимаю, к чему эта гора текста про C++, про который я в статье не говорю? Кто ж виноват в том, что в статьях, из которых я брал тезисы, очень много сравнений с C++.
Я отвечал на пункты по мере прочтения и только в конце понял, что вы мне не противоречите нигде, кроме эстетической составляющей кода. На эту тему дискутировать я не хочу, мне в большой степени все равно, как оно выглядит. Пусть каждому нравится свой стиль кода, я не против.
Простите, но я не понял, что вы хотели показать в примере с вектором, там же написано следующее:
push_back, emplace_back - If the vector changed capacity, all of them;
insert, emplace - If the vector changed capacity, all of them;
resize - If the vector changed capacity, all of them.
Полагаться на то, что у ветора при добавлении не изменится
capacity- это дело рискованное.В связном списке Rust точно так же не инвалидирует итератор.
Мне так не кажется, у меня отдельный абзац об этом в статье.
Мне так не кажется, у меня отдельная часть статьи об этом.
Если вы считаете, что где-то в моей статье есть фактическая ошибка напишите, пожалуйста, я с радостью её исправлю и пересмотрю свой взгляд на этот счет.
Выход за длину это как раз и есть выход за границу слайса и проблема ровно в том, что паники при этом нет, она возникает только при выходе за границу capacity.
Можете привести пример, по вашему описанию не очень понятно, какая возможна бага.
Специально пересмотрел видео, вот дословная цитата:
Проектов было много.
Если вас не затруднит, подскажите, что же помешало тем же самым людям, переписывающим тот же самый код с C++ на C++ на второй и, особенно, на третий раз сделать это в 2 раза быстрее?
После переслушивания выступления нет, не показалось.
Именно из-за этого Ларс в самом начале и говорит:
А еще он говорит, что на переписывание кода с C++ на Rust и на последующую поддержку кода после этого нужно как минимум в двое меньше людей.
P.s. Меня поражает то, насколько Rust сообщество на самом деле скромное и критичное даже к самому Rust'у. Вы просто посмотрите на то, что люди писали в комментариях под фотографией одного слайда (с как раз вырванной из контекста фразой про то, что в Rust продуктивность в 2 раза выше, чем в C++) из выступления (про видео и, соответственно, текст выступления написали позднее). Как минимум половина комментариев ровно про то же самое! "Как они измеряли продуктивность", "А может быть это просто были очень мотивированные писать на Rust разработчики", "А насколько честное это сравнение" и т.д. Я бы хотел увидеть еще еще одно такое сообщество, куда приходят с выступлением о том, что их любимый язык в 2 раза продуктивнее, чем другой, но вместо радости они относятся к этой информации очень подозрительно.
Чтобы это узнать, можете, например, прочитать эту статью.
Это не столько мое мнение, это то, что написано в документации к списку в стандартной библиотеке Rust, то, что я слышал в серии видео Crust of Rust: std::collections и во всех остальных видео и статьях, например, CppCon 2014: Chandler Carruth "Efficiency with Algorithms, Performance with Data Structures" .
Да, пожалуй, говорить, что связные списки не нужны совсем - преувеличение. У них есть своя ниша - удаление или добавление элемента/ов туда, где прямо сейчас находится итератор. Во всех остальных случаях у него хуже производительность и это еще надо очень хорошо протестировать, чтобы понять, что это даст прибавку в скорости работы.
Мне кажется, что искать в дебаге производительный код несколько странно. Для этого и придуман релиз режим, чтобы при разработке можно было код быстро компилировать, а чтобы в релизе код быстро работал. При желании можно сделать свой профиль, в котором будут и оптимизации (какого-то уровня) и дебаг символы. Я так свой трассировщик оптимизировал.
Можете привести примеры?
Красота в глазах смотрящего.
Мы, наверно, считаем "код для обработки ошибок" очень по-разному. Можете, пожалуйста, мне пальцем показать мне весь код, который как вы думаете отвечает за обработку ошибок. Я могу суммарно символов 10 указать.
Можете перечислить все возможные исключения, которые могут возникнуть в подобном коде на C++? Желательно всего кода, а не только той части, где нет ошибок и только опциональные значения.
Не в отличие от. Мне даже искать не надо чтобы сказать,что еще есть, например, crossbeam.
Какой код нашел, такой и привожу, другого у меня для вас нет.
Даже не знал, что это формальные определения, спасибо.
Назвать это общим случаем это, конечно, громко сказано.
надо явно для типа указать, что ты хочешь значение по умолчанию и чтобы компилятор вывел его сам из значений по умолчанию полей;
надо явно сказать "я хочу для всех остальных полей значения по умолчанию".
Вы код в релизе (с оптимизациями) скомпилируйте и проблема исчезнет.
Не вижу, что в этом плохого. Начиная от того, что мы и так доверяем огромному количеству людей, разработчики Rust тут точно даже не в первой сотне по значимости, заканчивая тем, что да, я доверяю чужим людям. И если это доверие нарушено я перестану и постараюсь переосмыслить то, чему у них доверял.
Чтобы использовать безопасные типы надо знать, какие из типов безопасны, а у меня опыта нет.
Можете посмотреть тут, тут или тут
Про эти проблемы я читал десятки раз и я не хочу делать свою статью трехтомником для того, чтобы в неё вошли все возможные плюсы, минусы и подводные камни Rust, сравнение со всеми возможными языками, состояние экосистемы во всех нишах и т.д. Если вас это интересует, я могу вам гарантировать, что при недолгом поиске вы это найдете.
Эм, нет. Просто нет.
Unstable - это не расширение языка, это фичи, у которых еще не зафиксированно API и оно может поменяться со временем;
Тут нет никакого UB;
#[inline(never)]никак не влияет на UB и на работоспособность этого кода;Попробуйте найти тут "создание массив, сортировка и проверка на наличие повторений":
Заголовок спойлера
Уже раз наверно десятый я рекомендую цикл лекций Алексея Кладова. 13 лекций по полтора часа скорее всего ответят на все ваши вопросы и даже больше.
Уж лучше диабет, чем расстройство нервной системы. Да и не думаю, что в статье о переходе Rust -> С++ есть большой смысл. Я гарантирую, что мой C++ код будет ужасен и состоять из UB процентов на 70. Только это не докажет, что Rust лучше (или C++ хуже), а только то, что я лично не умею писать код на C++. Что очень легко прочитать, как "Rust разработчики не умею писать код на C++", что в свою очередь можно прочитать, как "Rust разработчики не умею писать код". Это уже тут в комментариях происходит, что же будет в такой специализированной статье.
Вот обратное было бы интересно. Опытный C++ разработчик пишет некий сервис на C++. Потом N месяцев учит Rust и пишет аналогичный сервис на Rust. Там можно сравнить и код, и ощущения разработчика.Я бы такое почитал. Вообще такое сделал Google и результаты для C++ неутешительные.
Так в этом и плюс Rust,ты можешь позволить себе не знать, что там происходит (и использовать Rust как Python 4) и при этом писать быстрый и корректный код.
Можно и без unstable тоже самое сделать.