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

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

Я не мог не заметить, какой интерес у читателей этого блога вызвала тема «можно ли котятам поиграть с новыми клубками шерсти?» Так что мне захотелось поделиться еще несколькими своими размышлениями на связанную тему, касающуюся языков C и C ++ и вероятности того, что Rust их убьет.Нет необходимости говорить вам, что это неизбежно вызовет большую священную войну, поэтому, прежде чем продолжить, подумайте дважды, если вы действительно хотите продолжить чтение этого сообщения и особенно участвовать в «конструктивных дебатах» через комментарии.

Оригинал статьи можно найти здесь. Он был переведен и опубликован в нашем блоге с разрешения автора.

Примечание : Далее в этом тексте я предполагаю, что Rust — это сознательная попытка создать быстрый и безопасный язык .Ведь изначально он был задуман ребятами из Mozilla как инструмент для разработки движка браузера. Но если окажется, что это еще один только безопасный язык на , тогда я просто не пойму всего этого. Существует множество самых разных безопасных языков на любой вкус, и если Rust не предназначен для замены C ++, то (1) зачем ему включать небезопасное подмножество ?; и (2) почему авторы выбросили легковесные процессы из Rust? Они ведь удобны, не правда ли? Другими словами, если я ошибаюсь в своем предположении, то вся эта история просто не имеет никакого смысла.

Если вы случайно зашли на форум linux.org.ru, имейте в виду, что этот пост не имеет отношения к списку из 10 чисто технических причин, по которым не нравится Rust, который обсуждался в этой ветке. Беседа по скайпу с уважаемым товарищем @ sum3rman показала, что существует несколько мнений о том, насколько «технические» эти причины. Так что я должен признать, что составленный мною список паршивый, но я все же рискну процитировать здесь некоторые из наиболее интересных пунктов из него.На самом деле, количество простых здравых причин достаточно велико, чтобы не заботиться о технических.

Для любого здравомыслящего программиста кристально ясно, что C / C ++ не умрет в ближайшем будущем. Никто не собирается переписывать почти все существующие настольные приложения, ядра операционных систем, компиляторы, движки игр и браузеров, виртуальные машины, базы данных, архиваторы, аудио- и видеокодеки, тонны других C-библиотек и так далее и тому подобное. , на другие языки.Это огромная масса быстрого, отлаженного и проверенного временем кода. Переписывать это слишком дорого, рискованно и, честно говоря, не имеет смысла, кроме как в головах самых неистовых фанатов Rust. Спрос на программистов C / C ++ всегда был высоким и будет оставаться таковым еще долгое время.

Хорошо, а как насчет использования Rust для написания нового кода?

Что ж, как вы, наверное, помните, это далеко не первая попытка создать «лучший» C / C ++. Возьмем, к примеру, язык D.Он был выпущен в 2001 году и действительно является хорошим языком. Но здесь нет ни вакансий, ни достойных инструментов разработки, ни замечательных историй успеха, связанных с этим. Первоначально проект OpenMW был запущен на D, но затем авторы внезапно решили полностью переписать его на C ++. По их признанию, они получали кучу писем, в которых люди говорили: «Вы делаете крутой проект, и мы хотели бы внести свой вклад в него, но мы не знаем и не испытываем желания изучать эту глупую букву D». Википедия сообщает нам, что помимо D было много других попыток убить C ++ — например, Vala, Cyclone, Limbo, BitC.Кто из вас хоть раз слышал об этих языках?

Думаю, пора начать изучать уроки истории. Ни один здравомыслящий человек никогда не начнет использовать новый язык в своих проектах, пока вы не покажете им несколько крутых инструментов разработки, поддерживающих его, не расскажете им пару историй успеха и не покажете дюжину программистов, работающих с этим языком и живущих рядом. Что касается программистов, то они никогда — за исключением, вероятно, самых молодых — не будут тратить свое время и здоровье на изучение другого «самого лучшего» языка, пока вы не покажете им несколько классных инструментов разработки (не такой лягушонок, как Racer) и пару таких языков. десятков тысяч готовых библиотек (не «экспериментальных», не «нестабильных» и т. Д.), Расскажите им пару историй успеха и покажите им десяток открытых вакансий в их городе или поселке.Вы знаете, это как дилемма «курица или яйцо». В очень редких случаях эта проблема все же решается (относительно репрезентативными примерами являются Go и Scala) — в основном благодаря инвестициям времени и денег со стороны какой-то крупной компании (Google, Typesafe), которая по какой-то причине считает целесообразным популяризировать новый язык.

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

C / C ++ подвергается критике по разным причинам. Кстати, большинство критиков никогда не видели кода C ++ в производстве. Короче говоря, проблема C ++ заключается в том, что он очень быстр (а также требует небольшого объема памяти, заряда батареи и т. Д.), Но небезопасен в том смысле, что допускает переполнение массива, адресацию освобожденной памяти и т. Д. В прошлом эта проблема побуждала программистов разрабатывать множество безопасных языков, таких как Java, C #, Python и другие. Но они оказались слишком требовательными к ресурсам по сравнению с C ++, а также имеют некоторые другие недостатки — возьмем, например, неизбежную проблему «остановить мир» во время сборки мусора.Вот почему программисты изо всех сил пытаются создать язык, такой же быстрый, как C ++, но при этом безопасный. Ржавчина — один из кандидатов.

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

Я искренне надеюсь, что программисты найдут способ ускорить его со временем, но до тех пор это вряд ли будет представлять больший интерес, чем Scala или Go с точки зрения компромисса между безопасностью и скоростью.По-прежнему остается открытым вопрос, можно ли вообще сделать язык одновременно быстрым и безопасным, или он автоматически обречен быть вдвое медленнее, чем C / C ++ из-за постоянных проверок на переполнение массива, безопасных оберток привязок к C-библиотекам и тому подобное.

А что, кстати, делает Rust безопасным? Проще говоря, это язык со встроенным анализатором кода, и он довольно сложный: он может отлавливать все ошибки, типичные для C ++ и иметь дело не только с управлением памятью, но и с многопоточностью.Передайте ссылку на назначаемый объект через конвейер в другой поток, а затем попробуйте использовать эту ссылку самостоятельно — программа просто откажется компилироваться. И это действительно круто.

Но C ++ тоже не стоял на месте в течение последних 30 лет, и за это время было выпущено множество как статических, так и динамических анализаторов, поддерживающих его. В качестве одного примера посмотрите короткое видео о дезинфицирующих средствах Google — они действительно очень крутые. В любом случае, в любом серьезном проекте вы используете систему непрерывной интеграции и запускаете множество тестов при компиляции сборок.Если вы этого не сделаете, то ваши проблемы будут намного хуже, чем отсутствие безопасности языка, потому что статическая типизация не гарантирует правильной логики выполнения! Итак, если вы все равно запускаете тесты, почему бы также не использовать дезинфицирующие средства? Правда, всех ошибок они не находят. С другой стороны, если у вас нет проверки на переполнение массива где-то на более глубоких уровнях вашего кода, а дезинфицирующее средство не сообщает об ошибке, возможно, это просто потому, что все необходимые проверки уже предоставлены на один уровень выше и другой только замедлит программу? Даже без дезинфицирующих средств вы найдете множество вещей, просто собирая проект с различными компиляторами на разных платформах с проверкой инвариантов вашего кода assert в стиле «assert (obj-> isValid)» и с правильным фаззингом.Грубо говоря, вопрос фактически сводится к старой доброй священной войне о (т) он (о) ретическом и колхозном подходах к разработке программного обеспечения (, то есть новаторский, но слишком идеалистический подход и традиционный эмпирический подход, считающийся небрежным. и упрощен сторонниками первого — прим. переводчика ).

Часто можно услышать аргумент, что 90% времени выполнения тратится на выполнение только 10% кода (что, насколько я понимаю, просто эмпирический закон — быстрое сканирование через Интернет не выявило каких-либо строгих правил. научные исследования по этой теме).Следовательно, вы можете написать большую часть своего кода в безопасном Rust, а остальные 10% («горячий» код) в его небезопасном подмножестве, так что плохая производительность текущей реализации Rust на самом деле не проблема. Хорошо, но разве это не означает, что мне вообще не нужен Rust, потому что я могу написать 90% своего кода на Go, а остальные 10% на C? Только искатели «серебряной пули» и «воздушные феи» будут использовать Rust только для того, чтобы чувствовать себя довольными тем, что все 100% программы написаны на, казалось бы, одном языке. Но на самом деле это два диалекта одного языка, которые мало чем отличаются от комбинаций «Java + C» или «Go + C».

Но закон 90/10 в любом случае — чушь. Следуя его логике, мы могли бы переписать 90% WebKit, VirtualBox или GCC на Java и получить тот же результат. Но это явно неверно. Даже если это не потому, что соотношение в некоторых программах сильно отличается, давайте сделаем некоторые вычисления и посмотрим. Предположим, что вся программа написана на небезопасном C / C ++ и время ее выполнения, скажем, составляет 0,9 * 1 (небольшая часть горячего кода) + 0,1 * 1 (большая часть холодного кода) = 1. Теперь сравните ее с программой. написано на безопасном языке со вставками C: 0.9 * 1 + 0,1 * 2 = 1,1, что теоретически составляет разницу в 10%. Это много или мало? Ну, это зависит от масштаба проекта. Для Google даже несколько процентов могут помочь сэкономить миллионы долларов (см. Раздел 5 «Использование» в статье). Или представьте, что при следующем обновлении JVM внезапно начнет требовать на 10% больше ресурсов! Я боюсь даже предположить, сколько нулей они получат в цифре после преобразования этих процентов в доллары! 10% — это много для задач, где используются C и C ++.

Мы продолжаем повторять фразу «преждевременная оптимизация — корень всех зол», как мантру. Но если мы хотим следовать ему слово в слово, почему бы не использовать пузырьковую сортировку вместо быстрой во всем коде? В конце концов, мы не можем точно знать, где возникнет узкое место, не так ли? Зачем оборачивать обычные счетчики действий в акторы или транзакционную память, если мы можем сразу использовать более эффективные атомики? И, вообще говоря, в тривиальных случаях , вообще нет смысла принудительно инициализировать каждую без исключения переменную, реализовать кучу вспомогательных проверок и так далее.Пусть даже будет прирост производительности на 2-5% вместо 10%, но это не так уж и плохо, если на размышление у вас ушла всего пара лишних минут. Кроме того, как мы уже выяснили, это может иметь огромное значение в программах на C / C ++! В конце концов, кто осмелится утверждать, что найти горячую точку, переписать код (возможно, тонны кода) и доказать, что он стал действительно быстрее, — это легче, чем думать о производительности заранее?

Даже не считая проблемы скорости / безопасности, я также скептически отношусь к дизайну языка как таковому.В частности, что касается используемых в нем пяти типов указателей. С одной стороны, неплохо заставить программистов задуматься, хранятся ли их переменные в стеке или куче и могут ли они обрабатываться или не могут обрабатываться несколькими потоками одновременно. Но с другой стороны, представьте, что вы пишете программу и в какой-то момент обнаруживаете, что некоторая переменная должна храниться в куче, а не в стеке. Итак, вы переписываете код для использования Box. Затем вы понимаете, что вам действительно нужен Rc или Arc. Опять же, вы переписываете весь этот код.А затем вы снова переписываете все, чтобы в стеке была обычная переменная. Все это вам придется делать без приличной IDE. Регулярные выражения не помогут. Или вы можете столкнуться с кошмаром вроде «Vec >>>» — поздоровайтесь с Java! Но самое печальное в том, что компилятор уже знает все о времени жизни каждой переменной и может автоматически вставлять все эти Box, Arc и т. Д. Но по какой-то причине эта обязанность была возложена на программиста.Было бы гораздо удобнее позволить программисту просто написать val (в конце концов, мы живем в третьем тысячелетии!) И явно указать Box или Rc там, где это необходимо. С этой точки зрения разработчики Rust все облажались.

Это, в частности, значительно сужает область применения Rust. Ни один здравомыслящий человек не станет писать веб-и серверное программное обеспечение на таких языках, как или — особенно с учетом того, что он не предлагает каких-либо значительных преимуществ перед этими языками для JVM.Даже Go — с нормальными легковесными процессами (не фьючерсами) — кажется лучшим выбором для решения этих задач. Что касается фьючерсов, вы должны научиться обращаться с ними правильно, чтобы не прострелить себе ногу — а вы говорите о «безопасных языках», да? Конечно, у всех этих языков есть свои особенности — возьмем, например, ту самую «остановку мира». Но эту проблему можно решить как путем разделения кода на микросервисы, так и с помощью других методов. И да, никто не захочет переводить Rust на JavaScript, использовать его для написания скриптов для AWS или в качестве языка запросов для MongoDB.Для Android это тоже маловероятно, но по другой причине: там много разных архитектур, поэтому JVM будет работать намного лучше. Так что, если вы думаете, что Rust «хорош для любой задачи», я должен вас разочаровать.

И вот еще несколько причин, чтобы его покончить:

• Макросы, используемые как костыль, чтобы компенсировать чрезмерную многословность, вызванную отсутствием обычных исключений. Я уже писал о проблемах метапрограммирования — именно из-за них, в частности, нам вряд ли когда-либо удастся получить достойную IDE для Rust.Кроме того, хотя я не уверен, кажется, что у макросов в Rust даже нет пространств имен.
• Люди — идиоты, и Cargo активно поощряет загрузку пакетов прямо из репозиториев git, минуя Crates.io. В результате мы рискуем столкнуться с огромным беспорядком с пакетами, как в мире Erlang с его Rabar. Между прочим, я подозреваю, что в мире го есть похожая проблема.
• Как и многие новые языки, Rust идет по пути упрощения. В целом я могу понять, почему у него нет приличного наследования и исключений, но сам факт, что кто-то принимает решения за меня в отношении подобных вещей, вызывает у меня некоторое недовольство.C ++ не ограничивает программистов в отношении того, что они могут или не могут использовать.
• Теперь, когда мы встали на путь упрощения, почему бы не выбросить все эти языковые расширения? Нынешнее положение вещей напоминает мир Haskell, где каждый программист кодирует на своем собственном диалекте.
Умные указатели
• , к вашему сведению, далеко не бесплатны, а не обеспечивают фиксированного времени сборки мусора. Что, если какой-то поток получит честь освободить очень глубокую структуру данных? Пока он блуждает по лабиринту мертвых ссылок, все остальные нити, зависящие от него, терпеливо ждут, тупо.У Erlang с его мелкими кусочками похожая проблема — я сам сталкивался с ней много раз. Умные указатели также имеют свои собственные проблемы — например, фрагментацию и утечки памяти. Просто оставьте слабый указатель в структуре цикла — все напортачило. И все это на языке, притворяющемся безопасным … Если вам нужно фиксированное время сборки мусора, изучите поведение своей программы под нагрузкой и примите меры предосторожности (например, предусмотрите пулы объектов), если вас не устраивают цифры, или управляйте память вручную.
• Кто-нибудь видел строгое описание семантики Rust? Есть хоть модель памяти? И вы называете это «безопасным» языком, «обеспечивающим правильность» программ, особенно учитывая, что он может интерпретировать исходный код десятью разными способами?
• Не могу не напомнить вам еще раз, что источник проблем обычно в людях, а не в технике . Если ваш код C ++ недостаточно хорош или код Java очень медленный, это не потому, что технология плохая, а потому, что вы не научились правильно ее использовать.Таким образом, вы тоже не будете удовлетворены Rust, но только по другим причинам. Разве не легче научиться пользоваться более популярными инструментами и полюбить их?

Итак, подводя итог, лично я буду вкладывать свое время в изучение C / C ++, а не Rust в следующие 5 лет или около того. C ++ — это промышленный стандарт . Программисты уже более 30 лет используют его для решения огромного количества задач. Что же до Rust и тому подобного — это всего лишь диковинные игрушки с туманным будущим.Люди предсказывали скорую смерть C ++ с 2000-х годов, но с тех пор C / C ++ не стал менее популярным и востребованным. На самом деле, как раз наоборот. Он развивается (C ++ 11, C ++ 14), выпускаются новые инструменты (например, CLion и Clang), а количество вакансий просто огромно.

Программист на C ++ вряд ли когда-нибудь столкнется с трудностями при поиске работы с более чем достойной зарплатой и при необходимости сможет быстро изучить Rust. Но обратный сценарий очень и очень маловероятен.Кстати, выбор языка — далеко не единственный и самый важный фактор при выборе новой работы. Кроме того, опытный программист на C / C ++ может легко найти свой путь в исходном коде ядра PostgreSQL или Linux, имеет доступ к современным мощным инструментам разработки и имеет под рукой кипу книг и статей (например, по OpenGL).

Итак, берегите свое здоровье и не теряйте зря время — у вас их меньше, чем вы думаете!