EL>Ощутимо лучше чем? В современном С++ не принято использовать голые указатели и Си-стиль. Помимо этого для С++ есть соответствующий тулинг (ASan). Ну и свойство memory safety, оно не composable, если у тебя есть unsafe код, который портит память, то уронить приложение можно и в safe блоке. Memory safe приложение должно состоять только из safe кода, что в случае раста явно не выполняется, так что все эти гарантии — ничего не стоят.
Очень даже стоят. Помню как не вылезал из дебаггера, когда пробовал работать с DirectX 9 в С++. Несмотря на все умные указатели, темплейты и прочие оверлоадинги.
Сегодня полдня перетряхивал структуру рендеринга в программе на Rust для DirectX 12. Вечером исправил все ошибки компиляции. Запустил — работает. Поправил минорный баг (забыл установить дескриптор шейдерного ресурса) — работает правильно.
Не смотря на unsafe, в Rust легко построить стабильное основание для последущей разработки. В отличии от.
R>Очень даже стоят. Помню как не вылезал из дебаггера, когда пробовал работать с DirectX 9 в С++. Несмотря на все умные указатели, темплейты и прочие оверлоадинги.
Вижу жалобы на жизнь. Язык программирования С++ тут не причем, КМК,
R>Сегодня полдня перетряхивал структуру рендеринга в программе на Rust для DirectX 12. Вечером исправил все ошибки компиляции. Запустил — работает. Поправил минорный баг (забыл установить дескриптор шейдерного ресурса) — работает правильно.
Вижу wishful thinking.
R>Не смотря на unsafe, в Rust легко построить стабильное основание для последущей разработки. В отличии от.
Еще один, считающий, что все это от языка программирования сильно зависит.
Здравствуйте, ELazin, Вы писали:
EL>Вижу жалобы на жизнь. Язык программирования С++ тут не причем, КМК,
EL>Вижу wishful thinking.
Вижу стандартого диагноста по фотографии.
R>>Не смотря на unsafe, в Rust легко построить стабильное основание для последущей разработки. В отличии от. EL>Еще один, считающий, что все это от языка программирования сильно зависит.
Да пожалуйста. Пишите на ассемблере, вайтспейсе или брэйнфаке. Удачи.
R>Вижу стандартого диагноста по фотографии.
"Помню как не вылезал из дебаггера" — вот на это предлагается ответить что-нибудь нормальное? Я вполне себе конструктивно пытался дискутировать на тему memory safety и тулинга, но в ответ получил "я не вылезал из дебаггера, значит все что ты пишешь — фигня", но только немного другими словами. Ес-но я подумал что человек, который "не вылезал из дебагера" не может в программирование и что ему не дай, Rust, TCL, Python — получатся жалобы на то, как плох язык программирования Х.
Здравствуйте, ELazin, Вы писали:
EL>"Помню как не вылезал из дебаггера" — вот на это предлагается ответить что-нибудь нормальное? Я вполне себе конструктивно пытался дискутировать на тему memory safety и тулинга, но в ответ получил "я не вылезал из дебаггера, значит все что ты пишешь — фигня", но только немного другими словами. Ес-но я подумал что человек, который "не вылезал из дебагера" не может в программирование и что ему не дай, Rust, TCL, Python — получатся жалобы на то, как плох язык программирования Х.
-Ножами жонглировать трудно и опасно!
-Не опасно и легко, надо просто правильно это делать.
-Трудно и опасно, я пробовал и весь поранился.
-Ты просто не можешь в жонглирование и жалуешься на жизнь.
Здравствуйте, ELazin, Вы писали:
R>>Вижу стандартого диагноста по фотографии. EL>"Помню как не вылезал из дебаггера" — вот на это предлагается ответить что-нибудь нормальное? Я вполне себе конструктивно пытался дискутировать на тему memory safety и тулинга, но в ответ получил "я не вылезал из дебаггера, значит все что ты пишешь — фигня", но только немного другими словами. Ес-но я подумал что человек, который "не вылезал из дебагера" не может в программирование и что ему не дай, Rust, TCL, Python — получатся жалобы на то, как плох язык программирования Х.
Ладно.
1) Статические анализаторы в комплекте с С++ не идут. В стандарте не написано: "Вы должны использовать статический анализатор, чтобы не использовать одну из многих любезно предоставленных нами возможностей выстрелить себе в ногу".
2) Крупные компании прекрасно понимают, что идеальных программистов, помнящих и мгновенно замечающих все неопределенные и неспецифицированные поведения, и с первого взгляда выполняющих двухфазное разрешение имён, с учетом всего исходника проекта, не существует. Поэтому пытаются ужать всю мощь и свободу С++ до приемлемых рамок: https://google.github.io/styleguide/cppguide.html
3) Но это не особо помогает: https://bugs.chromium.org/p/nativeclient/issues/detail?id=245 см. Type 3 Functions, всё равно напоролись на неспецифицированное поведение.
4) Не помню чьё высказвание "Наговнокодить можно на любом языке", которое Вы, вероятно, поддерживаете, совершенно бесполезно для сравнения языков. Вопрос в том насколько легко язык позволяет сделать ошибку обычному программисту. Напомню, что даже Бьярн Страуструп в своей книге по С++ напоролся на неспецифицированное поведение. http://stackoverflow.com/questions/27158812/does-this-code-from-the-c-programming-language-4th-edition-section-36-3-6-ha
5) 5 простых спобов выстрелить себе в ногу с использованием shared_ptr: http://habrahabr.ru/post/191018/
6) Даже комитет по C++ понимает наличие проблем. Планируют введение статического анализа времени жизни переменных, в частности для предотвращения работы с инвалидированными итераторами.
Итого: С++ медленно ползёт в сторону Rust, таща за собой сорокалетние напластования фич, кучу неопределенных и неспецифицированных поведений в невинно выглядящих конструкциях, тонны legacy-кода.
А то что я писал про свою программку на Rust это не wishful thinking, а простое следствие того, что статический анализатор встроен в Rust.
Если выразить инварианты программы на уровне типов, то успешность компиляции будет гарантировать успешность работы. Я, конечно, до такого уровня не дошёл (собственно в Rust'е это полностью и не получится. Например, там нельзя реализовать session types), но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.
EDIT: Вот ещё интересная вещь: https://www.youtube.com/watch?v=AKtHxKJRwp4 79 минут обзора ошибок, встречающихся в реальных проектах на C++. Реакция "какой идиот это писал?" абсолютно неконструктивна. Реакция "какого хрена язык позволяет это писать?" может привести к улучшению языка.
Здравствуйте, AlexRK, Вы писали:
KP>>>быстрый код в общем случае не уступающий C/C++; KP>>>гарантии корректной работы с памятью. EL>>одно исключает другое ARK>В случае раста есть некоторые накладные расходы на проверки, но в общем случае это утверждение неверно.
Подозреваю что как раз в общем случае оно и верно.
ARK>Статически можно проверять все, даже выход за границы массивов
Каким образом? Если у нас язык полный по Тьюрингу, то в статике такая задача неразрешима.
P.S. Вообще, полнота по Тьюрингу нужна далеко не везде — в большинстве случаев это неоправданная роскошь, эдакий unsafe.
Тем не менее, Rust же позиционируется как язык полный по Тьюрингу, да?
Здравствуйте, red75, Вы писали:
R>Если выразить инварианты программы на уровне типов,
Выражай их и в C++ — самая развитая система типов среди mainstream языков
R>то успешность компиляции будет гарантировать успешность работы.
Все инварианты, пред/пост-условия в типах не выразишь.
R>но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, red75, Вы писали:
R>>Ладно. _>...
_>Всё в общем то верно написано. Но как раз потому что "С++ медленно ползёт в сторону Rust" и возникает вопрос в востребованности Rust'a в будущем...
C++ может ползти куда угодно, только груз обратной совместимости будет всегда. У Rust такого груза нет и текущая концепция строилась по ходу его развития, изначально язык был другим и то, что мы видим сейчас – это результат эволюции без необходимости обеспечения обратной совместимости. Именно возможность строить язык не думаю об обратной совместимости дает возможность получить куда как более продвинутый язык по сравнению с решением, которое обязанно обеспечить обратную совместимость с 30-ю годами работы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
KP>>Не противоречит при условии обеспечения гарантий на этапе компиляции. EP>Выполнение которго неразрешимо в общем случае.
В общем случае – да. В то же время, Rust дает тебе возможность получить такую гарантию в условных 90% случаев, в отличие от C++, который не дает такой гарантии никогда. Думаю, выбор довольно очевиден
Здравствуйте, kaa.python, Вы писали:
KP>C++ может ползти куда угодно, только груз обратной совместимости будет всегда.
Да, груз огромный. Помимо непосредственно языкового груза, есть ещё груз идиоматически устаревших книг, преподавателей и прогаммистов, застрявших где-то в конце 90-х. Да и к тому же за счёт возраста мифология богатая
KP>У Rust такого груза нет и текущая концепция строилась по ходу его развития, изначально язык был другим и то, что мы видим сейчас – это результат эволюции без необходимости обеспечения обратной совместимости. Именно возможность строить язык не думаю об обратной совместимости дает возможность получить куда как более продвинутый язык по сравнению с решением, которое обязанно обеспечить обратную совместимость с 30-ю годами работы.
Это здорово, но когда устаканится-то? Ведь пока он будет бурно развиваться "без необходимости обратной совместимости", его жеж и не будут массово использовать.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это здорово, но когда устаканится-то? Ведь пока он будет бурно развиваться "без необходимости обратной совместимости", его жеж и не будут массово использовать.
Уже устаканилось, на версии 1.0 (текущая версия 1.5). Было обещание от авторов что все API, помеченное как "стабильное" не будет претерпевать "ломающих изменений". Текущее стабильно API достаточно для написания user-mode приложений. Если захочется попытаться запихнуть Rust в ядро или начать управлять памятью самостоятельно, то можно натолкнуться на "не стабильное" API, но это уже задачи для людей, которые однозначно понимают что они делают. Ну а до версии 1.0, года так 3, концепции языка менялись очень активно.
Здравствуйте, kaa.python, Вы писали:
KP>В общем случае – да. В то же время, Rust дает тебе возможность получить такую гарантию в условных 90% случаев,
Что насчёт проверки границ? Крайне распространённый случай.
KP>в отличие от C++, который не дает такой гарантии никогда.
Гарантия есть при выполнении ряда условий, которые вполне авто-верифицируемые.
Но да, без явной границы safe/unsafe в самом языке.
KP>Думаю, выбор довольно очевиден
При прочих сферических равных (которых естественно нет) — да, лучше инструмент с явным safe/unsafe контролем.
Для безопасного языка я бы ещё предпочёл явное включение полноты по Тьюрингу для отдельных частей.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, red75, Вы писали:
R>>Если выразить инварианты программы на уровне типов,
EP>Выражай их и в C++ — самая развитая система типов среди mainstream языков
Algebraic data types нет. Я где-то тут приводил темплейтно/макросный ужас, который нужен для более-вменяемого discriminated union.
Здравствуйте, red75, Вы писали:
EP>>Выражай их и в C++ — самая развитая система типов среди mainstream языков R>Algebraic data types нет.
Как это нет если есть?
R>Я где-то тут приводил темплейтно/макросный ужас, который нужен для более-вменяемого discriminated union.
Готовый Boost.Variant есть уже больше 13 лет — бери и используй. Если хочется реализовать свой, то на C++14 он реализуется на порядки проще чем на C++98.
Здравствуйте, ELazin, Вы писали:
EL>По опыту — С++ код, активно использующий семантику перемещения и уникальные указатели бывает иногда довольно сложно понять.
R>>Я где-то тут приводил темплейтно/макросный ужас, который нужен для более-вменяемого discriminated union.
EP>Готовый Boost.Variant есть уже больше 13 лет — бери и используй. Если хочется реализовать свой, то на C++14 он реализуется на порядки проще чем на C++98.
Отсутствие прямой поддержки языком сложно компенсировать. Нормальный pattern-matching c case totality check библиотекой не сделаешь. А так можно, конечно, и гланды ректально вырезать.
Здравствуйте, kaa.python, Вы писали:
_>>Всё в общем то верно написано. Но как раз потому что "С++ медленно ползёт в сторону Rust" и возникает вопрос в востребованности Rust'a в будущем... KP>C++ может ползти куда угодно, только груз обратной совместимости будет всегда. У Rust такого груза нет и текущая концепция строилась по ходу его развития, изначально язык был другим и то, что мы видим сейчас – это результат эволюции без необходимости обеспечения обратной совместимости. Именно возможность строить язык не думаю об обратной совместимости дает возможность получить куда как более продвинутый язык по сравнению с решением, которое обязанно обеспечить обратную совместимость с 30-ю годами работы.
Все правильно. Только вот ты перечислил исключительно отрицательные стороны большой истории языка. А есть и положительные: огромное число уже готовых программистов, инструментов, библиотек. Так вот, если народ будет полностью уверен, что пути C++ и Rust где-то в будущем пересекутся (в том смысле что C++ заберёт к себе все ключевые вкусности Rust'a), то у них не будет вообще никакого стимула слезать с текущих перечисленных выше вкусностей C++. Т.е. как C++11 по сути поставил крест (причём это произошло ещё до выхода самого стандарта, на этапе обсуждения и тестовых релизов в компиляторах) на выход D в мейнстрим (а одно время было ощущение, что ведущие спецы по C++ утомились попытками выжать невозможное из устаревшего языка и готовы перейти на D, где есть всё что надо), так и C++17 может поставить крест (опять же прямо сейчас, а не после 17-го года) на выход Rust'а в мейнстрим. Ведь думаю ни для кого не секрет, что такие языки как D, Rust, Nim и т.п., имеют шанс на выход в мейнстрим исключительно путём перехвата аудитории C/C++? И если C++ не будет давать им такого шанса (быстрым развитием в нужном направление), то...
