Критика языка Rust и почему C/C++ никогда не умрет

http://eax.me/cpp-will-never-die/

Игра словами, смысла в статье немного. Чего-то набенчмаркили и решили, что раз язык не в 10 раз быстрее С++, смысла на него переходить нет, а все наши баги найдут статические анализаторы. Не найдут.

Чего-то набенчмаркили и решили, что раз язык не в 10 раз быстрее С++, смысла на него переходить нет

Ну был бы хотя бы как C++...

а все наши баги найдут статические анализаторы. Не найдут.

Как не найдет их и компилятор rust'а.

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

Ну был бы хотя бы как C++...

Наивно ждать, что язык, который даже не зарелизился, будет как C++, зрелые компиляторы которого разрабатываются несколько десятков лет. Дизайн языка позволяет писать компилятор, генерирующий почти такой же код, как и C++ (почти, потому что в safe-коде всё равно будут некоторые runtime проверки, например индексов массива).

Как не найдет их и компилятор rust'а.

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

Наивно ждать, что язык, который даже не зарелизился, будет как C++

Ну не как ява же быть.

потому что в safe-коде всё равно будут некоторые runtime проверки, например индексов массива

Такого говна итак полно, зачем еще один язык? Переносите все проверки во время компиляции(через зависимые типы, через что угодно). Иначе вы никогда не замените C/C++.

Но найдёт куда больше

Надо как-то сравнить.

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

Давай придумаем какой-нибудь пример, который ловит rust, но не может даже теоретически поймать какой-то внешний статический анализатор для C/C++.

но не может даже теоретически поймать какой-то внешний статический анализатор для C/C++

Теоретически, какой-то внешний статически анализатор может поймать абсолютно любой баг. Это же очевидно.

Ну не как ява же быть.

У меня сомнения в аутентичности тех бенчмарков. Вот бенчмарк Servo на Rust против Gecko на C++, например.

Такого говна итак полно, зачем еще один язык?

Например? Языков с управлением памяти как в Rust по-моему очень мало.

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

Ты до конца понимаешь, о чём ты говоришь? Как можно перенести проверку args[1] на время компиляции? Какие тут типы помогут, если границы массива наверное в 80% случаев известны только в рантайме? Делай итерацию через итераторы, из них компилятор может оптимизировать проверки. В примитивных случаях скорее всего тоже. Но в общем случае — или ломаем память или проверяем. Возможно стоит стараться писать код на итераторах. В принципе это вроде и так обычно делают.

Иначе вы никогда не замените C/C++.

Я не думаю, что C++ кто-то сможет заменить. Так же как Scala не заменит Java. Но свою нишу занять можно.

Тогда зачем пилить Rust, если можно запилить статический анализатор?

У меня сомнения в аутентичности тех бенчмарков. Вот бенчмарк Servo на Rust против Gecko на C++, например.

Так мало ли что в этом Gecko наговняли.

Например?

Да почти все проверяют выход за диапазон.

Ты до конца понимаешь, о чём ты говоришь? Как можно перенести проверку args[1] на время компиляции? Какие тут типы помогут, если границы массива наверное в 80% случаев известны только в рантайме?

Да, понимаю. Читай про зависимые типы.

Но в общем случае — или ломаем память или проверяем.

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

Я не думаю, что C++ кто-то сможет заменить.

Хорошо, подвинуть.

Так же как Scala не заменит Java.

Тем не менее, scala применяется на практике и довольно обширно. Основная к ней претензия - сложность языка(почти как к C++).

Но свою нишу занять можно.

Какую?

Тогда зачем пилить Rust, если можно запилить статический анализатор?

а какая разница? если статический анализатор будет накладывать на код кучу обязательных условий - это уже новый язык.

вопрос в том, зачем обеспечивать обратную совместимость исходников, если можно запилить новый язык с match и без #include

зачем пилить Rust, если можно запилить статический анализатор?

Зачем пилить статический анализатор (какого языка, кстати), если можно запилить Rust?

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

Очевидно, не должен. Берем сишный и крестовый код и проверяем.

вопрос в том, зачем обеспечивать обратную совместимость исходников, если можно запилить новый язык с match и без #include

Затем, чтоб кому-то это было полезно. Язык новый никому не нужен. Тем более, он столь же уродлив, как и C++.

Чтобы ничего не менять в разработке. Зачем мне новый язык? А статический анализатор, детектящий всякие неприятные штуки - вещь полезная.

Очевидно, не должен

если не будет ограничений, это будет хреновый статический анализатор

Язык новый никому не нужен

говори за себя

Зачем мне новый язык?

вот тут анонимус правильно вопрос ставит

Зачем мне новый язык? А статический анализатор, детектящий всякие неприятные штуки - вещь полезная.

А вот Мозилле полезнее новый язык. Бидапичаль, кто-то остался без статического анализатора.

говори за себя

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

А вот Мозилле полезнее новый язык.

Это нужно будет еще посмотреть. История знает немало примеров, когда какое-нибудь начинание завершалось так и не выстрелив. Rust начинался когда перспективы C++0x были весьма туманны. А релиз версии 1.0 происходит, когда поддержка C++14 появилась и в GCC, и в clang. Пока Rust будут лечить от детских болезней, уже и C++17 в основных компиляторах может появиться.

А вот Мозилле полезнее новый язык.

Это нужно будет еще посмотреть.

Ы? Я, возможно, неясно выразился... Мозилла считает, что новый язык для неё полезнее, чем статический анализатор. Это вполне очевидно уже сейчас, без всякого будущего опыта.

Пока Rust будут лечить от детских болезней, уже и C++17

Не думаю, что Rust будут лечить настолько долго, но не суть... естественно, Rust может и не взлететь. Но, ИМХО, Rust и есть тот самый «smaller, cleaner language within C++».

Почему ты решил что компилятор Раст должен что-либо находить в коде на С++? К слову, С++ (будучи нагромождением костылейфич за более чем 20 лет) парсится очень неохотно. В С с этим намного лучше.

А что не так с Джавой? Она - быстрейший из «интерпретируемых» языков (по бенчмаркам всего в ~2 раза медленней С++, что очень неплохо). Правда, памяти намного больше жрёт.

А вот Мозилле полезнее новый язык

Да уж. Мозилла прям образец для подражания. Успешность зашкаливает=)

Почему ты решил что компилятор Раст должен что-либо находить в коде на С++?

Пусть ищет в коде раста.

А что не так с Джавой?

Все с ней отлично.

Она - быстрейший из «интерпретируемых» языков (по бенчмаркам всего в ~2 раза медленней С++, что очень неплохо)

На практике чуть хуже, но не в том дело. Rust-то нативный язык, нацеленный на «уровень» C++. В отличие от Java.

Rust и есть тот самый «smaller, cleaner language within C++».

А я вот еще надеюсь на лучшее.

Есть нативные языки которые медленнее и Раста и С++. Думаю, Раст может достичь производительности С++, когда компилятор причешут.

Уже ищет и находит. Весь Раст вокруг этого построен.

Мозилла прям образец для подражания. Успешность зашкаливает=)

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

Rust и есть тот самый «smaller, cleaner language within C++».

А я вот еще надеюсь на лучшее.

На что-то конкретное или просто на всё хорошее?

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

goto 0

Пока Rust будут лечить от детских болезней, C++ будут реанимировать снова и снова

пофиксил

goto 0

Еще один форумный тро-ло-ло, которому Rust нужен только чтобы потрепаться на LOR-е.

Уже ищет и находит. Весь Раст вокруг этого построен.

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

Да руст ещё вполне.
Метапрограммирование держит.
Хоть и выглядит инопланетно.
А Go – это наколенная поделка.

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

На что-то конкретное или просто на всё хорошее?

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

если тебе лень читать тред сначала, мне лень тебе его пересказывать

Либо вы путаете тред, либо вы подразумеваете одно из первых своих сообщений в теме, где дали ссылку на это поделие: https://github.com/sshilovsky/rust-xx

В любом случае осталось непонятно, зачем вам лично нужен Rust? Чтобы обертку вокруг x11 написать и все?

На более крутой чекер времени компиляции(тут выше про зависимые типы уже упоминали)

Если ты о Rust, то лично я согласен с Грейдоном, который сказал: «Я бы не добавлял новых фич в язык еще... лет несколько, в нем уже достаточно. Нужно сеcть и написать спеку того, что уже есть, выяснить темные места и исправить их».

Ну а если ты про Си++, то фантастика в другом отделе.

Я про «smaller, cleaner language within C++»

Понимаешь в чем дело...Ошибки типа «прочитал/записал не туда, куда хотел» это ошибки либо совсем детские (не умеют работать с интервалами, да), либо ошибки логические, приводящие к дальнейшему сбою в работе. Первые ошибки делает совсем уж школиё, которое только вчера научилось в Helloworld. А от вторых тебе не поможет ни один анализатор. Например принял ты структуру по сети/из файла, прочитал смещение поля, считал значение поля. Все, вроде бы, хорошо и длина подходит, и за пределы не вываливаешься, но ни один руст тебе не разрулит ситуацию, если смещение поля у тебя передается как BigEndian, а ты ее читаешь как Little (или наоборот), не важно. Далее ты пишешь значение этого поля (читай «мусор») куда-то еще, а потом снова, а потом это попадает, например, в драйвер (в секции unsafe, разумеется, да) и далее читаем очередное нытье о том, что «прога на руст читает и пишет херню => руст говно, такое же как и си/си++/чтототутеще».

Руки, только руки, и голова. Что поделать, если у разрабов мозилы все это растет не из плеч и они не осилили сделать «чтоб не текло» и все свалили на инструмент.

У меня сомнения в аутентичности тех бенчмарков. Вот бенчмарк Servo на Rust против Gecko на C++, например.

Так мало ли что в этом Gecko наговняли.

Ну это слабый аргумент. Так же и в Servo «наговняли», причём, не удивлюсь, если те же люди.

Но в общем случае — или ломаем память или проверяем.

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

Такое можно оставить на откуп оптимизатору.

Так же как Scala не заменит Java.

Тем не менее, scala применяется на практике и довольно обширно. Основная к ней претензия - сложность языка(почти как к C++).

Подобную нишу Rust и может занять.

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

Может. Обсуждали очень специальный случай, который воспроизвести ещё надо постараться. И по-моему его пофиксили/пофиксят.

Руки, только руки, и голова. Что поделать, если у разрабов мозилы все это растет не из плеч и они не осилили сделать «чтоб не текло» и все свалили на инструмент.

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

Школиём каждый может обзываться, только по факту С/С++ программы текут и падают. И ещё хорошо, если просто падают, а то и данные портят, и уязвимости содержат. И язык, который способен эти вещи предотвращать, нужен.

Про unsafe замечание хорошее, хотя unsafe не значит «что хочу то и делаю», там не так много ограничений опускается. Но unsafe кода меньше. К нему по очевидным причинам больше внимания. Поэтому в гибридном коде багов будет гораздо меньше.

Да, можно писать 95% кода на хаскелле/пайтоне/Java, а оставшиеся 5% на C. Но в этом подходе есть свои проблемы.

Кроме того Rust просто хороший красивый язык. На нём приятно писать. Это тоже важно.

и уязвимости содержат. И язык, который способен эти вещи предотвращать, нужен.

Ну вот казалось бы, Java, берешь и предотвращаешь. Так ведь нет.

И где там уязвимости языка Java? Всякие баги в апплетах это не уязвимости языка. Какую из этих уязвимостей можно использовать, чтобы взломать или хотя бы положить LOR?

Java, берешь и предотвращаешь. Так ведь нет.

А где там сказано, в чем ошибка? Может, она в JIT. Или в родном коде. Или Java-код тупо не проверяет что-то.