Стали доступны видео докладов с C++ CoreHard Spring 2019

Раст и стабильный ABI - помнишь, сколько танцевали по этому поводу? Сломают ещё раз, если это будет им мешать.

UB - это когда непонятно что ты получишь. Т.е. нет гарантии, что произойдёт именно Wrapping. А теперь посмотри на главную страницу Rust и притащи оттуда, про какую Safety заявляет команда.

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

Легаси никуда не исчезнет само. И его нужно поддерживать и аккуратно переписывать. Грамотные плюсовики могут писать и на Rust. Как и наоборот. Чистых Rust разработчиков найти сложно, то, что касается библиотек, касается и людей. Слишком мало времени прошло. Как бы Rust - это меньший шаг относительно C++, чем C++ в свое время относительно C. Да еще и слегка вбок, не пытаясь сказать: мы можем тащить всё легаси на предшественнике.

Они не пытаются сделать Франкенштейна.

Уровень C++ CoreHard очень сильно поднялся за последние 4 года. Вплоть до приезда на CoreHard докладчиков вроде Джосаттиса.

А какой именно доклад из вышеперечисленных вы причисляете к «самопиару»?

Если у вас есть возможность спрыгнуть с C++ на Rust, то спрыгните, кто вам мешает?

Только вот если вы спрыгнули, какое вам дело до проблем тех, кто по тем или иным причинам в C++ остается?

А какой именно доклад из вышеперечисленных вы причисляете к «самопиару»?

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

Никто не в курсе, почему с сайта cppconf.ru пропали презентации докладов прошлогодних конференций?

Не, проблема в холиварной постановке вопроса про Rust в докладе, а не в Rust или C++. Автор фактически призывает бойкотировать Rust для новых проектов.

Как бы, какое Антону дело до тех, кто думает о том, спрыгнуть или нет? Но пропаганду, что не надо спрыгивать, гонит.

Как бы, какое Антону дело до тех, кто думает о том, спрыгнуть или нет? Но пропаганду, что не надо спрыгивать, гонит.

Вообще-то сам тезис о том, что на Rust нужно спрыгивать, так же нуждается в подтверждении.

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

1) фронт раста на текущий момент генерит избыточный IR по сравнению с фронтом C++, это не очень хорошо, и будет сказываться в проиграше производительности С++

Ну и чтобы понимать - цифры в студию, какова величина эффекта этого «проигрыша производительности»? И IR не является конечным представлением. По нему, конечно, можно делать наколенные сферические бенчмарки в ваккуме, но как это будет относиться к производительности программы в реальной жизни?

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

И, возможно, и никогда не будет достаточно хорош. Но вопрос не об этом. Мне вот интересно, насколько обоснованные выводы о производительности языка можно делать по IR? (без, по-крайнeй мере, серьёзного обоснования таковых) Это ж, утрируя, как рассуждать о том, что быстрее будет "->" или "(*).".

// доклад не смотрел

Мне вот интересно, насколько обоснованные выводы о производительности языка можно делать по IR?

Там речь идет об уже ассемблерном выхлопе. Т.е. после того, как и front-, и middle- и back-end-ы компилятора уже выжали из кода все, что могли.

доклад не смотрел

Так может посмотреть, чтобы не судить о том, что dave напел?

Так может посмотреть, чтобы не судить о том, что dave напел

Глянул быстро. Да, для сравнения используется ассемблерный выхлоп (кстати, было бы неплохо показать с какими ключами компилятора он был получен).

Есть пара замечаний:

1) Вот докладчик долго-долго рассказывал о том как это плохо, код разный приводил, глаза закатывал, говорил «не здорово». А чего ж он код то не запустил, и не привел реальный оверхед исполнения?

2) Доклад переполнен манипуляциями и неточностями - а) выдумываются несуществующие фичи Rust'а (типа защиты от переполнения), которые успешно развеиваются и б) невнятные оценки - типа ну вот видите, это ж вот плохо.

Общее ощущение - докладчик натягивает сову на глобус. Rust он не знает и не понимает, и пытается отсутствие реальных аргументов заместить оценочными суждениями (типа «это не очень»).

(кстати, было бы неплохо показать с какими ключами компилятора он был получен).

Ключи там видны на скриншотах.

1. Вот докладчик долго-долго рассказывал о том как это плохо, код разный приводил, глаза закатывал, говорил «не здорово». А чего ж он код то не запустил, и не привел реальный оверхед исполнения?

Потому, что в каждой конкретной ситуации это будет разный оверхед? Ведь, допустим, для некой функции было добавлено три ассемблерные инструкции в эпилог. Если эта функция в программе вызывается всего один раз, то будет один результат. Если она вызывается непрерывно в цикле 100500 раз, то результат может быть другой.

Здорово ли, что есть лишние обращения? Нет, как по мне.

Каков будет реальный оверхед? Пусть каждый для себя сам решит, в своей конкретной ситуации. В конце-концов кто-нибудь скомпилирует Rust-овский код с -C debuginfo=0 и у него не будет оверхеда.

а) выдумываются несуществующие фичи Rust’а (типа защиты от переполнения), которые успешно развеиваются

Типа защита от переполнения в debug есть, а в release нет. Или он здесь что-то соврал? Нет такой фичи в Rust-е?

Общее ощущение - докладчик натягивает сову на глобус.

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

Доклад Ивана Чукича про средства построения DSL, как по мне, так весьма годный.

Здорово ли, что есть лишние обращения? Нет, как по мне.

Нет, это все так. Но для зявленного пафоса доклада как-то маловато будет.

Каков будет реальный оверхед?

Вот хотелось бы чтобы об этом рассказал докладчик.

а) выдумываются несуществующие фичи Rust’а (типа защиты от переполнения), которые успешно развеиваются

Типа защита от переполнения в debug есть, а в release нет. Или он здесь что-то соврал? Нет такой фичи в Rust-е?

Давайте разберемся. 1) Заявлялось ли наличие проверок overflow выражений вида x + y в release? 2) Есть ли способ написать код, который будет всегда делать такую проверку?

Общее ощущение - докладчик натягивает сову на глобус.

Общее ощущение, у растоманов подгорело от того, что в очередной раз опытный C++ник не рассыпался в комплиментах вашему любимому языку.

Итак я теперь «растоман», выходит? И с чего такой вывод был сделан?

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

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

Но для зявленного пафоса доклада как-то маловато будет.

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

Давайте разберемся.

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

Проверка на integer overflow в Rust-е есть?

В debug режиме есть. Что дает некоторым основание считать, что Rust в этом плане безопаснее C++.

В release режиме нет. Т.е. когда программа ушла в продакшен, то в плане целочисленных переполнений Rust не безопаснее C++.

И это наглядный пример того, как местами (подчеркну, местами) безопасность в Rust-е декларируется, но по факту её в результирующей программе не будет.

Да пусть улыбается.

Так выше по треду это человеку в вину вменили.

Но если взялся раскрывать тему - раскрывай

Возникает вопрос: а какую именно тему? Может у автора доклада была своя тема и он ее раскрыл. А вы выдумали себе другую тему и сочли, что автор ее не раскрыл (см. выше про выдуманный пафос).

Проверка на integer overflow в Rust-е есть? В debug режиме есть. В release режиме нет.

Точно нет? А если написать, например:

(i64::max_value()).checked_add(1)

Так ведь речь идет не о специальной арифметике с проверкой на переполнение (которую, кстати, и в C++ можно изобразить, даже без необходимости вызова костыльных checked_add).

Так выше по треду это человеку в вину вменили.

Предлагаю не обсуждать излишне экзальтированные аргументы.

Но если взялся раскрывать тему - раскрывай

Возникает вопрос: а какую именно тему?

Резонный вопрос, открываем видео и смотрим что написано на слайдах: «Сравним с другимим языками: C++ vs. Rust»

Так ведь речь идет не о специальной арифметике с проверкой на переполнение (которую, кстати, и в C++ можно изобразить, даже без необходимости вызова костыльных checked_add).

Так а она заявлялась в таком виде, чтобы кричать о ёё отсутствии?

«Сравним с другимим языками: C++ vs. Rust»

Ну так сравнение и было. В том числе были перечислены и достоинства Rust-а.

А обещания сделать более-менее объемное сравнение результатов бенчмарков не было.

Тем более, что этот раздел был всего лишь частью более объемлющего доклада.

Так а она заявлялась в таком виде, чтобы кричать о ёё отсутствии?

Были же показаны фрагменты кода, на примере которых и говорилось о проверках переполнения (и их отсутствия в релизе).

Ну так сравнение и было. В том числе были перечислены и достоинства Rust-а. А обещания сделать более-менее объемное сравнение результатов бенчмарков не было.

Высказываю свою несовершенное мнение: анализ был проведен слабо ( случаи были рассмотрены поверхностно, при анализе использовался манипулятивный подход, и какие-то прилагательные вместо квантитативных оценок). От докладчика такого уровня я бы ожидал большего.

Были же показаны фрагменты кода, на примере которых и говорилось о проверках переполнения (и их отсутствия в релизе).

Были показаны фрагменты кода, которые работали согласно документации. При этом почему-то сей факт был представлен как недостаток.

И вообще, ну да Rust - это не волшебная кнопка с надписью «сделать хорошо», которая работает. А C++ - это такая кнопка, что-ли?

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

Ну, собственно, было очевидно, что речь идет об обманутых ожиданиях. Что, в принципе, понятно.

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

Я, например, если бы делал сравнение C++ и Rust-а, то упомянул бы о таких вещах, как отсутствие привычного ООП в Rust-е, наличие в Rust-е встроенных проверок границ при работе с массивами (соответственно с плюсами и минусами), наличие в Rust-е макросистемы, которая может компенсировать отсутствие в нем некоторых возможностей C++ных шаблонов. Хотя не факт, что все это удалось бы уместить в доклад.

Но это мой выбор, у Полухина свой выбор. И какой бы выбор не был сделан, всегда будет кто-то с обманутыми ожиданиями.

А C++ - это такая кнопка, что-ли?

Нет. Просто сам факт того, что Rust так же не является такой кнопкой, то смена C++ на тот же Rust может быть лишь сменой шила на мыло.

В release режиме нет. Т.е. когда программа ушла в продакшен, то в плане целочисленных переполнений Rust не безопаснее C++.

Можно включить в Cargo.toml: [profile.release] overflow-checks = true

Спасибо за дополнение.

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

Нет, не совсем об этом. Речь идет о низком качестве доклада.

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

И немедленно застрелились сразу 3 капитана очевидность.

Нет, не совсем об этом. Речь идет о низком качестве доклада.

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

Речь идет о низком качестве доклада.

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

И немедленно застрелились сразу 3 капитана очевидность.

Вы недооцениваете падкость войтишников на новые серебряные пули.

В release режиме нет. Т.е. когда программа ушла в продакшен, то в плане целочисленных переполнений Rust не безопаснее C++.

В отличие от С++, в котором переполнение знакового целого - UB, переполнение для знаковых целых в Rust определено как 2's complement и в safe Rust может вызвать только логическую ошибку.

Да, спасибо что приносишь подобные доклады на ЛОР. Посмотрел парочку.

смена C++ на тот же Rust может быть лишь сменой шила на мыло.

Ну, по крайней мере, сесть на мыло безопаснее. Шёпотом: 70 percent of all security bugs are memory safety issues

Шёпотом: 70 percent of all security bugs are memory safety issues in C code used by Rust

Исправил

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

Но всё же от профессионала ожидаешь больше, нежели от любителя.

Вы недооцениваете падкость войтишников на новые серебряные пули.

Но такой доклад разумных людей не убедит (они и так это знают), а неразумных вообще никакой не убедит. Смысл такого доклада, получается, немного теряется.

Что сам посоветуешь?

Я пока посмотрел полностью только четыре доклада. Мне понравился доклад Ивана Чукича.

Если интересно, как организовать message-passing между прибитыми гвоздями к конкретным ядрам нитям, то можно посмотреть доклад Максима Хижинского. Но, если его доклады с предыдущих конференций CoreHard смотрели, то здесь нового особо ничего не будет.

В отличие от С++, в котором переполнение знакового целого - UB, переполнение для знаковых целых в Rust определено как 2's complement

В С++20 переполнение знакового целого определено как 2's complement, всё закапываем раст?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html

Рад за них. А потом результат 2's complement попадает в vector::operator[].

Но такой доклад разумных людей не убедит (они и так это знают)

Вот прям так сразу и знают? Подключены к телепатическому каналу абсолютной истины?

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

Рад за них. А потом результат 2's complement попадает в vector::operator[].

vector::operator[] принимает параметр size_t, прям как в расте usize, видишь опять похожи один в один.

https://en.cppreference.com/w/cpp/container/vector/operator_at

Дело не в size_t, а в UB по дефолту. Многие пишут at()?

Да он слился просто и хотел убежать с треда :)

И как бы нить всего доклада: давайте не писать на Rust, давайте не делать инфраструктуру для Rust

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

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

Проверка на integer overflow в Rust-е есть?

В debug режиме есть. Что дает некоторым основание считать, что Rust в этом плане безопаснее C++.

В release режиме нет. Т.е. когда программа ушла в продакшен, то в плане целочисленных переполнений Rust не безопаснее C++.

Мне кажется это не имеет отношение к языку, а к его среде. Например msvc по моему опыту вообще самый строгий компиллер и не уверен что он прям инт+инт оверфлов отлавливает, но на потенциальные проблемы реагирует порой даже избыточно.

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

Такие проекты на Расте и не появятся, ведь всем известно, что Раст является сертифицированным языком для написания хелловорлдов, не более.

там в докладе приведена ссылка https://hackernoon.com/why-im-dropping-rust-fd1c32986c88 на бывшего растофанбоя, который вернулся на с/с++

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

Как чувак не осили асио и придумал флейма на доклад, заметим - теоретического флейма. Рабочей модели как он сказал нет.

Как чувак не осили асио и придумал флейма на доклад, заметим - теоретического флейма. Рабочей модели как он сказал нет.

Он рассказывал в 2017-ом году про детали реализации DLP-системы, в которой использовалась именно эта модель обмена сообщениями: https://www.youtube.com/watch?v=e1AD27EtYTU

А сейчас он просто сделал доклад только на эту узкоспециализированную тему.

Rust. Поджигая пердаки since 2010.

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