на 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) и при этом писать быстрый и корректный код.
А Cloudflare в том числе использует Rust потому, что Nginx слишком медленный:
As Cloudflare has scaled we’ve outgrown NGINX. It was great for many years, but over time its limitations at our scale meant building something new made sense. We could no longer get the performance we needed nor did NGINX have the features we needed for our very complex environment.
Рад, что они были вам полезны! Теперь я знаю, что как минимум один человек по этим ссылкам походил, я потратил на них много времени. Теперь точно не обидно, что я это сделал.
Тогда расскажите нам, несведущим, что же такое NonNull. Или вам так не нравится то, что создатели языка сделали так, чтобы даже в их unsafe приключениях нельзя было разыменовать нулевой указатель? Вот гады то какие, о корректности заботятся.
Можете привести пример, по вашему описанию не очень понятно, какая возможна бага.
Специально пересмотрел видео, вот дословная цитата:
Проектов было много.
Если вас не затруднит, подскажите, что же помешало тем же самым людям, переписывающим тот же самый код с 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 тоже самое сделать.
Гугл же зачем-то переписал свой сервис с C++ на C++ 3 раза перед тем, как на четвертый переписать на Rust.
А Cloudflare в том числе использует Rust потому, что Nginx слишком медленный:
Насколько я помню, первый компилятор Rust был как раз на OCaml, так что не удивительно.
Рад, что они были вам полезны! Теперь я знаю, что как минимум один человек по этим ссылкам походил, я потратил на них много времени. Теперь точно не обидно, что я это сделал.
Тогда расскажите нам, несведущим, что же такое NonNull. Или вам так не нравится то, что создатели языка сделали так, чтобы даже в их unsafe приключениях нельзя было разыменовать нулевой указатель? Вот гады то какие, о корректности заботятся.