Это будет статья-рассуждение о том, почему Rust лучше C/C++. Тут будут затронуты не столько сравнение производительности, сколько сравнение удобства инфраструктуры языка, его темпы развития и актуальность.
Толчком к её написанию были многочисленные «горячие» споры в комментариях под статьями Хабра о том, почему Rust или C/C++ лучше. Я же попробую занять объективно-нейтральную позицию в этом споре, поэтому о минусах тоже будет речь.
Унифицированность
Давайте для начала обсудим заметное количество существующих компиляторов C/C++. Это преимущество или недостаток? Многие сторонники C/C++ уверенно говорят о том, что это огромный плюс. Но действительно ли это так? Давайте погрузимся в эту тему и рассмотрим ее более детально.
Спросите у любого опытного программиста C/C++, и он подтвердит, что попытка скомпилировать программу, написанную на C/C++, с использованием MinGW или Clang без каких-либо изменений в коде, скорее всего, не увенчается успехом. Причина этого кроется в том, что каждый из этих инструментов использует свои собственные реализации стандартных функций, операторов, библиотек и так далее.
Даже если вам удастся скомпилировать программу с использованием другого компилятора, стабильность кода, скорее всего, будет нарушена. Причина этого кроется в том, что, как я уже упоминал ранее, реализации отличаются, что может привести к неопределенному поведению программы.
С точки зрения плюсов, можно было бы упомянуть конкуренцию между различными компиляторами, которая теоретически могла бы способствовать более быстрому развитию. Однако на практике этого не происходит. Существуют, конечно, стандарты, но некоторые разработчики либо слишком затягивают с добавлением новых функций, утвержденных в новом стандарте, либо вовсе отходят от них.
Инфраструктура
Никто в здравом уме не будет отрицать преимущества полноценного тулчейна с возможностью расширения, менеджера пакетов, тестирования и т. д., которые предлагает Rust, по сравнению с C/C++. Это преимущества, которые определенно улучшают процесс разработки программного обеспечения и предоставляют разработчикам более современные инструменты для работы.
Конечно, кто-то может сказать, что у C/C++ тоже есть свои инструменты для сборки, менеджеры пакетов, но, к сожалению, они не стали популярными из-за тех или иных причин, включая сложность использования и отсутствие единого стандарта.
Из этого следует, что одной из ключевых проблем C/C++ является работа с библиотеками и их сборка. Для сборки одной библиотеки может потребоваться загрузка и установка большого количества дополнительного программного обеспечения, что может быть сложно и затратно по времени, а для другой библиотеки - уже другого. Это не только увеличивает сложность процесса, но и может привести к проблемам совместимости.
В Rust есть официальный менеджер пакетов Cargo, который позволяет делать практически все: от создания проекта до его сборки, запуска тестов и деплоя. Это делает процесс разработки более простым и понятным. Дополнительным преимуществом является возможность расширения функциональности через так называемые крейты.
В контексте Rust, крейт - это любая кодовая единица: программа или библиотека, содержащая файл проекта Cargo.toml.
Это означает, что разработчики могут легко использовать и переиспользовать код, что способствует повышению эффективности и сокращению времени разработки.
Небольшим недостатком, а не полноценным минусом, может стать официальный репозиторий крейтов crates.io. Политика фонда вызывает у сообщества некоторые опасения насчет того, не превратится ли репозиторий в очередной npm. Это вопрос, который требует внимания, и он не должен быть проигнорирован, но на данный момент это не является серьезной проблемой.
Строгий компилятор и безопасность Rust
Одной из уникальных особенностей языка программирования Rust является его очень строгий компилятор, который без дополнительных действий не позволит даже переменную назвать против стандартов языка. Это значит, что компилятор Rust работает упорно, чтобы гарантировать, что ваш код соответствует строгим стандартам языка. Однако, следует отметить, что это качество может привести к увеличению времени компиляции кода.
Несмотря на строгость компилятора Rust, одним из самых распространенных аргументов противников этого языка является возможность написания небезопасного кода в Rust. Впрочем, это действительно возможно, но компилятор продолжает выполнять проверки даже в коде, помеченном как небезопасный. Помимо этого:
В 2018 году было доказано, что система типов Rust, механизмы заимствования, владения, времён жизни и многопоточности корректны. Также было установлено, что если мы используем семантически правильный код из библиотек внутри unsafe и смешаем это с синтаксически правильным safe кодом, мы получим семантически правильный код, который не позволяет стрелять по памяти или делать гонки данных.
Источник: C++ быстрее и безопаснее Rust, Yandex сделала замеры.
Вдобавок, стоит отметить, что часто упоминают о том, что такие концепции, как result pattern и другие, далеко не новы для Rust, и что подобные идеи были реализованы и в других языках программирования. Это, безусловно, так. Например, в C++ есть умные указатели, optional и множество других элементов. Однако, стоит учесть, что все эти функции были введены в C++ уже после его создания, поэтому они реализованы на уровне библиотек и их использование не является обязательным. Это значит, что разработчики могут выбирать, использовать их или нет. В отличие от этого, Rust изначально включил в себя лучшие практики и идеи из мира программирования и использует их на уровне языка, делая их использование неотъемлемой частью процесса написания более безопасного кода.
Как говаривал один мудрый человек: если человек хочет написать небезопасный код, то ничто не сможет его остановить. Это может быть истиной для любого языка программирования, но Rust делает все возможное, чтобы сделать процесс написания безопасного кода как можно проще.
Производительность
Производительность является одним из ключевых факторов при выборе языка программирования, и вокруг сравнения производительности Rust и других языков уже написано множество статей. Большинство из них фокусируются именно на сравнении скорости выполнения одной и той же программы на этих разных языках. Есть такие работы, которые выставляют Rust в положительном ключе, а есть и те, которые предпочитают другие языки.
Однако, стоит отметить, что сравнение производительности двух языков программирования - это задача довольно сложная, даже если они используют один и тот же бэкенд*. Сложность заключается в том, что разные компиляторы могут применять разные стратегии оптимизации и концепции, которые в свою очередь могут значительно влиять на производительность. Даже абстракции, используемые в языке, могут иметь значительное влияние на это**.
* Компилятор использует в качестве бэкенда LLVM, как и Clang.
** Автор видео наглядно показывает, как различные абстракции увеличивают время выполнения.
В связи с этим, в данной статье не будет результатов каких-либо бенчмарков, и просто сойдёмся на том, что эти языки равны по производительности. Если вам интересны более точные данные, рекомендую искать специализированные материалы на эту тему. Также вы можете обратить внимание на портал TechEmpower, где авторы регулярно проводят бенчмарки различных веб-фреймворков.
С другой стороны, важным аспектом в области программирования, особенно в контексте современных технологий, является производительность написания и отладки кода. Это непрерывно акцентируется, поскольку время - это ресурс, которого у нас никогда не хватает. С учетом всего выше сказанного, можно утверждать, что написание кода на Rust является не только быстрым, но и эффективным процессом.
Одним из ключевых преимуществ Rust является его широкая база крейтов, менеджер пакетов и современные возможности языка. Эти функции позволяют программистам сократить время, затрачиваемое на написание кода, до нескольких команд в терминале и нескольких строк кода. Это значительно упрощает процесс разработки и делает его более эффективным.
Кроме того, установка расширений Cargo, позволяющих создавать шаблоны проектов, может делать процесс еще более упрощенным. Это дает программистам возможность быстро настраивать новые проекты и экономить время на стандартных задачах, ускоряя процесс разработки и повышая его эффективность.
Неопределённое поведение C/C++
В языках программирования C/C++ существует обширный спектр случаев неопределённого поведения, которые могут стать причиной серьёзных проблем и нестабильности в рамках написанного кода. Это широко вариативно включает в себя все возможные аспекты, начиная от непредсказуемых результатов выполнения функций и заканчивая возможностью выполнения произвольного кода. Это может привести к неконтролируемым и непредсказуемым результатам, которые в свою очередь могут вызвать критические ошибки в работе программы, нарушить её стабильность и даже привести к потенциальным угрозам безопасности.
С другой стороны, в языке программирования Rust, была применена другая концепция управления ошибками и неопределенным поведением. Компилятор этого языка применяет строгий контроль над всеми возможными случаями неопределённого поведения. Это означает, что каждый потенциальный случай неопределенного поведения будет проверен и обработан во время компиляции, предотвращая возможность его проявления во время выполнения программы.
Благодаря этому, Rust обеспечивает высокую степень безопасности кода, предотвращая возможность появления критических ошибок и неожиданных результатов работы программы. Это позволяет разработчикам быть более уверенными в стабильности и надежности написанного ими кода, избавляя их от необходимости проводить многочисленные и сложные проверки на наличие потенциальных ошибок и неопределенного поведения.
Итого
Если встаёт вопрос, какой язык выбрать в качестве стартового? Начинающим программистам часто рекомендуют начать с C++, поскольку большинство современных языков программирования используют парадигму объектно-ориентированного программирования (ООП). Такой подход упрощает понимание более высокоуровневых и абстрактных концепций, которые присутствуют в других языках программирования.
В то же время, стоит упомянуть язык программирования Rust, который придерживается функционального программирования (ФП) и использует уникальную систему владения. Эти концепции используются редко в других языках, что может затруднить переход на другой язык программирования после изучения Rust.
Если рассмотреть ситуацию с точки зрения рынка труда, то Rust крайне мало востребован на территории России. В сравнении с этим, навыки работы с C/C++ гораздо более ценятся работодателями и востребованы на рынке.
Поэтому, несмотря на то что Rust является более современным и удобным языком по сравнению с C/C++, его преимущества угасают из-за недостатка спроса на рынке. Rust предлагает большое количество инновационных функций и преимуществ, но они становятся менее значимыми, если учесть низкую востребованность этого языка в реальном мире.
В итоге, выбор между C++ и Rust в качестве первого языка программирования будет зависеть от множества факторов, включая личные предпочтения, цели обучения и перспективы трудоустройства. Независимо от выбора, важно помнить, что основные концепции программирования остаются неизменными, и навыки, приобретенные при изучении одного языка, часто могут быть применены и в других контекстах.
P.S. В комментариях есть пару дельных замечаний, а все остальные, такое ощущение, будто сразу, как увидели заголовок, с пеной изо рта понеслись писать комментарии. Например, я так и не понял, какой «конкретный код» нужен человеку, если это статья даже не про сравнение синтаксиса языков.
Комментарии (91)
ParaMara
11.05.2024 02:06+14Это либо LLM либо перевод. В лучшем случае - копипаста из переводов, но это уже маловероятно. Зачем?
Rust дико пиарят, это вообще становится неприличным. Да, это единственное без сборщика мусора и с абы каким инструментарием. В остальном - приписываемое Ландау
Ничто так не кормит как неразрешимая задача.
kovserg
11.05.2024 02:06+1Точно лучше бы nim пиарили. Rust и C++ как первые языки выбор скажем так идиотский. Вот C еще можно как первый язык рассмотреть, но не углубляясь в подводные камни (более того C подобные языки будет проще изучать при необходимости). Первый язык должен быть простым и не перегруженным, без не очевидного синтаксиса, как в swift и kotlin или apl c кучей инопланетянского синтаксиса для новичка. Как первый лучше подходят языки тип pascal или lua.
ps: Интересно почему Rust с C# не сравнивают ?
smurfomen
11.05.2024 02:06+2ps: Интересно почему Rust с C# не сравнивают?
Может все таки Rust с C# сравнивать некорректно?
Rust не про ООП (хотя он там и есть), Rust не имеет GC, Rust имеет больше общего с C++ чем с C#, Rust трули кроссплатформенный (для него не нужен JIT вроде бы), rustc использует LLVM (значит и большую часть пассов оптимизаций что и CLang какой нибудь), итдитп.С плюсами все таки общего побольше, вот и сравнивают его с плюсами.
ЗЫ: Да, статейка = такое, не сказать что тут есть о чем поговорить - сравнения как такового автор и не сделал, там вилами по воде и там)
Как по мне, у Rust слишком высокий порог входа, поэтому тебе все равно надо научиться в С++ какой-нибудь, тогда че толку их сравнивать.
Насчет первого языка - холиварная тема, надо начинать оттуда, где прёт =)
У меня один из первых языков С++ - не жалуюсь, зато с освоением новья проблем не возникает сейчас.
Free_ze
11.05.2024 02:06у Rust слишком высокий порог входа, поэтому тебе все равно надо научиться в С++
Какая тут связь?
Steparist
11.05.2024 02:06Как думаете, что будет "моднее" - получить опыт работы с памятью и написать сборщик мусора на c/c++ или, так сказать, влиться в поток пиарщиков rust?
ShaltaiBoltai
11.05.2024 02:06Качество перевода не выше машинного. Причем, о том, что это перевод, в статье не указано. Так сильно автору хочется выдать машинный перевод за труд своего неполупроводникового МНУ.
SpiderEkb
11.05.2024 02:06+2Большинство из них фокусируются именно на сравнении скорости выполнения одной и той же программы на этих разных языках.
Бред.
Вопрос "производительности" в том, можно ли для решения одной и то же задачи использовать особенности того или иного языка, позволяющие получить более производительный код.
Т.е. приспособленность инструмента для решения конкретной задачи.
Если встаёт вопрос, какой язык выбрать в качестве стартового?
Тот, который используется там, где вы собираетесь работать.
Rust предлагает большое количество инновационных функций и преимуществ, но они становятся менее значимыми, если учесть низкую востребованность этого языка в реальном мире.
И почему бы это? Ведь такой замечательный язык... Практически убийца всех остальных языков. А вот никто не использует почему-то...
adron_s
11.05.2024 02:06Наверное потому, что ключевые концепции языка Rust таковы, что при его использовании складывается ощущение езды на велосипеде с квадратными колесами. Создать настолько не похожий ни на что язык программирования, в этом они конечно преуспели. У меня подобный мозговой диссонанс был наверное лишь при попытке писать на brainfuck-е.
freecoder_xx
11.05.2024 02:06+10По-моему вы преувеличиваете. Через пару месяцев практики я принципиально не чувствовал отличий в написании бекэнда на Rust в сравнении с Java.
itmind
11.05.2024 02:06+6После понимания концепции Rust становится понятным и достаточно простым. Для меня например писать на нем быстрее чем на Go, и намного быстрее чем на С или С++. Естественно с учетом отладки, проверки всех ошибочных и UB состояний, а не скорости написания кода. За 30 лет я изучил и использовал множество различных языков програмирования (на которвх написал ПО доведеное до продкашена), на разных этапах мне "заходили" разные языки: С, С++, asm, js , C#, python, Kotlin, Golang и на данный момент Rust, который я считаю лучшим для для себя языком, на котором можно быстро писать качественное серверное и прикладное ПО. Для мобильной мультиплатформенной разработки безусловно Kotlin MP.
SpiderEkb
11.05.2024 02:06+2Интересаради - что из крупного известного на Rust написано?
Язык любопытный (как минимум), но не подалось задач под него.
itmind
11.05.2024 02:06+1Пока я думаю ничего серьезного не написано, но Microsoft , Google вкладывают в него большие средства и вроде собираются переписать свою облачную инфраструктуру. (слухи). Я использую его для написания бэкенда для web и мобильных приложений. В планах сделать opensource учетную систему (типа кассовое по) и выбрал Rust в том числе и для того, что бы квалификация разработчиков была выше и не получалось все кривое и забагованое как у 1с. (Низкий порог входа разработчиков).
SpiderEkb
11.05.2024 02:06+2Тут есть проблема - в крупных долгоиграющих проектах стараются выбирать такой стек, который позволит развивать и поддерживать проект. Т.е. или наличие грамотных разработчиков на рынке, или возможность самим для себя их готовать.
Вот напишете что-то а потом уйдете - как быстро найдут вам замену?
А забагованость - это не от низкого порога, а от низкой дисциплины. Наличие нефункциональных требований, жесткий кодревью, многоуровневое тестирование обязательное тут поможет
itmind
11.05.2024 02:06+2Бизнес выбирает массовые языки (python, java и т.п.) и соответствующие стеки потому, что на них проще найти разработчиков. Замкнутый круг, люди учат востребованные у предпринимателей языки, а предприниматели выбирают языки, которые знает большее количество разработчиков. Но все решает массовость ПО. Если будет ПО, которое будет стоять у сотент тысяч организаций и для доработки этого ПО нужно будет знать Rust, то появится много разработчиков на Rust. Спрос рождает предложение.
SpiderEkb
11.05.2024 02:06MS Ofice стоит во многох организациях - его кто-то дорабатывает? :-)
На долгие проекты боятся связываться со стеком, у которого нет годами доказанной надежности и эффективности.
itmind
11.05.2024 02:06+1Но как-то же эта эффективность и надежность должна доказаться для нового стека. И мне кажется выбирают не надежное и эффективное, а то на чем пишут большее число разработчиков. Надежность C и C++ низкая (Microsoft пачками еженедельно выпускает патчи безопасности латая UB в коде на C++), у java низкая эффективность (жрет тоны памяти, требует написания кучи кода для простых вещей, см. spring, чем больше кода, тем больше ошибок). Но при этом эти языки и их стеки до сих пор выбирают.
SpiderEkb
11.05.2024 02:06+1Но как-то же эта эффективность и надежность должна доказаться для нового стека.
Замкнутый круг.
И мне кажется выбирают не надежное и эффективное, а то на чем пишут большее число разработчиков.
Даже есть риск что проект не взлетит и обернется финансовыми потерями?
Надежность C и C++ низкая (Microsoft пачками еженедельно выпускает патчи безопасности латая UB в коде на C++)
Это характерно для любого большого проекта. У меня один комп на Win, второй на Lin. Так вот обновлений под Линукс летит куда больше чем под винду... И я не думаю, что все они связаны именно с UB и именно с тем что оно написано на конкретном языке.
Хотя само по себе наличие UB намекает на то, что с компилятором "что-то не так". Ну не должно быть такого (IMHO) - или работает предсказуемо, или выдает ошибку.
у java низкая эффективность (жрет тоны памяти, требует написания кучи кода для простых вещей, см. spring, чем больше кода, тем больше ошибок). Но при этом эти языки и их стеки до сих пор выбирают.
Java вообще делалось чтобы можно было делать не требовательные к эффективности апплеты, которые можно запустить везде, где есть JVM. Но потом ее стали пихать в каждую бочку затычкой.
Octabun
11.05.2024 02:06+2С удивлением обнаружил весьма интересные проекты: Tauri, Bevy, bat, nnn. При этом именно на Rust ничего не искал. При очевидной переоценённости, видно - люди пишут на Rust продуктивно и с удовольствием.
Как оффтопик, предлагаю оценку Rust снизу https://loglog.games/blog/leaving-rust-gamedev/
nakirrrr
11.05.2024 02:06+1Например космос starlink китайские спутники современные по написано на rust
dmitriy3342
11.05.2024 02:06+3Cloudflare написала замену NGINX на rust -pingora. Вроде хороший кейс.
SpiderEkb
11.05.2024 02:06Ну то есть пишут. Значит есть надежда что оно таки займет достойное место и будет развиваться и дальше.
Главное - чтобы не стали пихать туда все подряд и переусложнять язык.
vtb_k
11.05.2024 02:06Cloudflare написала замену NGINX на rust -pingora. Вроде хороший кейс.
Более чем
Построенный при помощи Pingora прокси около года используется в сети доставки контента Cloudflare вместо nginx и обрабатывает более 40 млн запросов в секунду. Код написан на языке Rust и опубликован под лицензией Apache 2.0.
Как раз вчера зарелизили новую версию.
Kil1J0y
11.05.2024 02:06Как пример сразу всплывший в голове, ядро linux собираются переписать на rust, уже есть переписанные модули в последних ядрах.
feelamee
11.05.2024 02:06+6кстати
что это за язык такой популярный? Везде вижу, да только никак не найду ни доки ни компилятора. Я о C/C++, конечно
Может посоветуете где изучить? А то вон, даже с растом сравнивают.
/s
Mabu
11.05.2024 02:06+6Потому что неправильно пишут, после имени диска забывают двоеточие и палочку. Надо так:
C:\>C++
GennPen
11.05.2024 02:06+7А про комьюнити почему не написали?
Комьюнити по C++ на порядки больше чем Rust. По C++ можно найти любой ответ на любой вопрос, что зачастую перекрывает все приведенные (якобы?) минусы.
Например, захотел я написать прошивку под STM32 с использованием FreeRTOS (или другой RTOS) и ... погодите, а как это сделать с учетом что сама FreeRTOS написана на C++? Да, есть какие то интерфейсы с FreeRTOS на Rust, но это костыли, и как убедиться в их надежности? И что с библиотеками, писать с нуля свои?
allcreater
11.05.2024 02:06+3Спросите у любого опытного программиста C/C++, и он подтвердит, что попытка скомпилировать программу, написанную на C/C++, с использованием MinGW или Clang без каких-либо изменений в коде, скорее всего, не увенчается успехом
Если программа соответствует стандарту, но много времени писалась под один компилятор, то да, прям совсем без изменений скорее всего не скомпилируется. Скорее всего, в некоторых местах все-таки придется подправить, поскольку пересечение множеств поддерживаемых компиляторами фичей действительно чуть меньше, исходные множества.
Но все не так страшно, как говорят в следующем абзаце. Неопределенное поведение не случается "вдруг" "из-за разных реализаций компиляторов", оно либо есть, как следствие наличия в программе логических ошибок, либо его нет (где-то в далеком волшебном мире).
И вот как раз использование нескольких компиляторов и реализаций стандартной библиотеки очень здорово помогает отлавливать всякие сомнительные места. Фактически, стабильность подправленной программы на всех платформах только возрастёт. Какие-то UB, возможно, и останутся, но если они не проявляются во всех основных компиляторах - это приемлимо.
SpiderEkb
11.05.2024 02:06следствие наличия в программе логических ошибок
А что считать логической ошибкой? Навязывание компилятором своего понимание времени жизни объекта - это логическая ошибка?
Некоторые вещи (типа переполнения) должны вызывать исключение, но не UB (в широком смысле слова).
Ао мне так комплятор дожен делать то, что от него хочет разработчик, а не разработчик угадывать как бы так написать чтобы компилятор в оптимизациях не запутался.
SIISII
11.05.2024 02:06+1На большинстве аппаратных платформ обнаружить целочисленное переполнение можно только ценой потери производительности (требуется явная проверка на переполнение после каждой операции, способной его вызвать). По этой причине его в Це и нету. Хотя лично я считаю, что правильней было бы прямо в стандарте требовать, чтобы компилятор мог генерировать все мыслимые и немыслимые проверки и позволял их включать/отключать индивидуально.
SpiderEkb
11.05.2024 02:06Хотя лично я считаю, что правильней было бы прямо в стандарте требовать, чтобы компилятор мог генерировать все мыслимые и немыслимые проверки и позволял их включать/отключать индивидуально.
Да.
И возможность отключать контроль за временем жизни объекта.
OMR_Kiruha
11.05.2024 02:06+2В С/С++ контроль за временем жизни объекта прописан в стандарте, если вы имеете ввиду scope и lifetime.
Всякий контроль за временем жизни объекта в виде сборщика мусора в C/C++ отсутствуют.
allcreater
11.05.2024 02:06+1ну для большого и ответственного проекта вполне же можно написать обертку над числами с защитой от переполнений. Можно даже предложить в стандарт такое затащить. Просто на практике никому оно особо не надо.
SpiderEkb
11.05.2024 02:06Ну конечно, не надо...
В том и дело, что на практике в одних случаях нужна циклическая арифметика, а в других она не то чтобы не нужна, а вредна т.к. приводит (чисто по невнимательности) к весьма осязаемому отрицательному результату.
Тривиально - есть сумма в валюте, есть курс. Нужно получить сумму в рублевом эквиваленте. И одна ситуация когда возникает переполнение и оно продолжает работать дальше, но все дальнейшие расчеты дают неверный результат, совсем другое, когда переполнение вызывает системно исключение "result too large" в том самом месте где оно произошло и дальше никаких расчетов с неправильными данными не производится.
pooqpooq
11.05.2024 02:06+4Неопределенное поведение не случается "вдруг" "из-за разных реализаций компиляторов", оно либо есть, как следствие наличия в программе логических ошибок, либо его нет
Оно может вдруг начать проявляться при смене компилятора, опций оптимизации, изменения структуры кода, и так далее.
А так да, конечно, следствие наличия логических ошибок. Только чем язык лучше, тем проще там при прочих равных избегать этих самых логических ошибок. Ну и ещё есть разные логические ошибки — с одной стороны есть непосредственно связанные с предметной областью, а с другой — связанные с особенностями языка. И во втором случае C++ подкладывает огромную кучу мин на каждом шагу.
allcreater
11.05.2024 02:06+2Оно может вдруг начать проявляться
Да, спасибо за уточнение. Но именно поэтому я и советую собирать проект разными компиляторами, что в непроявляющемся УБ тоже нет ничего хорошего.
Только чем язык лучше, тем проще там при прочих равных избегать этих самых логических ошибок
Как это там говорилось, "языки программирования делятся на тех, кого все ругают, и никто не использует". Нет универсального критерия "лучшести", у каждого инструмента свой набор задач, преимуществ и недостатков.
C и С++ не подкладывают мины, а перекладывают ответственность за ходьбу по минному полю на программиста. Причем второй язык крайне выразителен и позволяет при желании написать безопасные обёртки/фреймворки вообще для чего угодно.pooqpooq
11.05.2024 02:06Причем второй язык крайне выразителен и позволяет при желании написать безопасные обёртки/фреймворки вообще для чего угодно.
Нет, потому что слабую систему типов ничего не исправит. Если вы, конечно, не предлагаете написать на C++ компилятор для своего собственного языка.
Falstaff
11.05.2024 02:06+16Очень странная статья, сплошная вода и пережёвывание bullet points из рекламных агиток. На этом этапе принятия языка индустрией (он же как-то принимается ей, нет?) уже хочется не рекламы а реальных кейсов с примерами - и не только кода а ещё перевода реальных команд и продуктов на Rust, к тому что предлагает сам язык вопросов уже мало осталось.
Я открыт к новым языкам и подходам, и было бы здорово если что-то потеснило бы C++ (это при том что моя жизнь - это сплошной C++), но когда теснят с напором джентльменов звонящих в двери и спрашивающих нашёл ли я уже Иисуса, как-то неловко уже становится за индустрию в целом. :)
freecoder_xx
11.05.2024 02:06Rust изначально создавался как замена C++, решающая его фундаментальные проблемы. Делали его люди, у которых, что называется, накипело. ИМХО ещё мало сравнивают их, сейчас никакого анти-плюсового напора со стороны разработчиков и спонсоров Rust вообще нет практически. А вы всё жалуетесь.
KanuTaH
11.05.2024 02:06+9Так жалуются-то не на разработчиков самого раста, с ними как раз все понятно - работают люди, пытаются решить какие-то проблемы (попутно добавляя новые, но это уж как водится). Жалуются на авторов статей типа этой, тупо повторяющей одни и те же агитки из одной и той же методички. Rust Evangelism Strike Force надо по-другому уже как-то действовать, рыжие кудри уже примелькались.
Falstaff
11.05.2024 02:06+9Конечно я жалуюсь - и, не поймите меня неправильно, я жалуюсь не на то что люди что-то полезное разрабатывают, а на то как другие люди это подают. Все уже знают что за проблемы решает Rust, эти сравнения уже на зубах навязли, а горшочек всё ещё варит и с завидным постоянством у кого-то появляется идея скормить предыдущее сравнение ChatGPT и опубликовать статью с тем что на выходе получилось. :) Это... уже как бы создаёт определённый образ евангелиста Rust.
На этом этапе становления языка уже как-то не комильфо повторять заезженные сравнения, все уже знают техническую разницу между языками. Мне, например, эти сравнения бесполезны. Если я хочу внедрить что-то в своей компании, я должен дать этому обоснование и оно должно пройти кучу уровней рассмотрения, и не только на техническом, но и на бизнес уровне. Я не могу сказать "вот в Rust нет UB, айда все на Rust", мне нужно показать что это принесёт ценность с точки зрения бизнеса, что весть этот процесс найма и переобучения, адаптации инфраструктуры и документации, окупится и принесёт прибыль в какой-то строго оговоренный срок, что Rust действительно будет улучшением с точки зрения бизнеса. И это даже с технической стороны далеко не так легко продвинуть как кажется, учитывая что существующие решения обложены анализаторами кода в три слоя, покрыты тестами по самое не хочу и проходят кучу других проверок перед тем как всё выкатывается в продакшн.
Вот что мы уже должны видеть от евангелистов - примеры внедрения, детальные, с анализом и решениями потенциальных проблем, с точками зрения всех участников проекта. А мы всё ещё публикуем одни и те же сравнения и пытаемся запугать C++ еретиков
геенной огненнойпроблемами с памятью и undefined behavior. Да. Да, убедили. Хватит, золотая антилопа. Я уверовал. Теперь опубликуйте статью которая поможет мне убедить бизнес. :)pooqpooq
11.05.2024 02:06Чисто из интереса — а как вы убеждали [бы] бизнес о пользе тестов, код-ревью и тому подобных практик, которые нам всем очевидны, а для бизнеса могут восприниматься как лишние траты?
sdramare
11.05.2024 02:06+2Да не надо убеждать, "let them fail". Один раз упавший прод и пара миллионов убытков становятся вполне весомым аргументом в пользу того зачем нужно тестирование, ревью и прочее.
pooqpooq
11.05.2024 02:06+1На практике — нет, не становятся.
sdramare
11.05.2024 02:06+1ну и туда им и дорога, в банкротство. Времена околонулевой ключевой ставки в США и бесплатных денег прошли, мы сейчас увидим много падений эффективных менеджеров.
pooqpooq
11.05.2024 02:06Времена too big to fail никуда не делись.
Gorthauer87
11.05.2024 02:06Ну значит их или будут лечить, чтобы там от такого бреда уходили, или они реально в какой-то момент упадут. Ну если неэффективность тотальная, то тебя не спасёт too big, а если нет, ну значит так жить можно.
SpiderEkb
11.05.2024 02:06+1Где не становится?
Представьте банк. У пары-тройки клиентов десятки миллионов лямов уходят непойми куда. Все. Огромные репутационные потери, прямые убытки, внеплановые проверки со стороны регулятора, штрафы. В пределе - лишение лицензии.
Криво работают проверки в комплаенс-контроле платежей? Тут вам могут очень много чего предъявить - от "сомнительных финансовых операций" до прямого финансирования террористов.
Пример из реального письма от руководства:
Спасибо за оперативное решение вопроса с устранением проблемы в онлайн-контроле платежей, которые генерировали для банка огромные риски и спровоцировали неприятное внимание к банку со стороны ЦБ
Очень оперативно собралась команда
Нашли нестандартное, но эффективное и быстрое решение вопроса.
Каждый этап для исправления и внедрения был пройден в полном контакте с командой, что позволило оперативно закрыть возникающие вопросы.И ни у кого не возникает вопросов по поводу того, что тестирование (компонентное, бизнес, нагрузочное, интеграционное) может занимать времени больше чем разработка. Особенно с учетом достаточно сложной (порой) реализуемой бизнес-логики. И того, что в штатном режиме нагрузка на сервер составляет 40-60%, а периоды пиковых нагрузок может достигать 90% и при этом не должно возникать ситуаций когда что-то это нагрузку не держит, начинает тормозить само и смежные процессы в результате чего миллионы клиентов по всей стране на могут магазине расплатится картой банка, мобильное приложение вылетает по таймауту и т.д. и т.п.
Falstaff
11.05.2024 02:06+1Я совершенно точно не убеждал бы, бия себя в грудь и говоря общие фразы о том как с тестами всё лучше потому что если без тестов, то будут ошибки и всё пропало, а с тестами будем как сыр в масле кататься. :) Потому что бизнес действительно не поймёт, особенно если явных проблем пока не наблюдается и "ведь тесты позволяют отловить такие ошибки как (минутка непонятного технического жаргона)" - это единственное обоснование траты денег компании.
И да "let them fail", как ниже написано - это тоже вполне себе аргумент. Но если оно в явном виде не падает - ну вот тогда надо садиться и презентовать бизнесу статистику. Это мы с вами разработчики и нам интересна техническая сторона. Бизнесу надо показывать что вот у нас за квартал было столько человекочасов потрачено на закрытие багов (и компенсацию из последствий) которые можно было бы предотвратить инвестированием (вставьте много выкладок) меньшего количества человекочасов на написание тестов, вот у нас было столько даунтайма, что отразилось в стольких потерях, и вот экономическая выгода от внедрения. Надо показывать примеры из индустрии, надо показывать опыт внедрения в других проектах или компаниях, надо показывать расчёт возможных рисков и мнения архитектов/аналитиков/всевозможных консультантов и всё прочее.
Точно так же и с Rust. Все разработчики уже поняли техническую сторону вопроса, какой смысл пережёвывать снова и снова. Бизнесу же ничего этого не надо, ему нужно видеть, во-первых, экономическую выгоду - на сколько (сильно упрощая) условных долларов в квартал Rust выйдет лучше пачки статических анализаторов, тестов, code review и прочая, и прочая; во-вторых, примеры успешного внедрения. Бизнес смотрит на всё с точки зрения generated value, и его надо убедить в том что вся затея выльется в экономическую выгоду.
pooqpooq
11.05.2024 02:06А в вашей текущей и прошлых компаниях тоже с графиками и статистиками ходили к начальству, доказывая пользу тестов и ревью, или всё-таки как-то оно так само получилось хотя бы в каких-то из этих компаний?
Falstaff
11.05.2024 02:06Вы именно о тестах, код ревью и анализаторах, или в принципе? Если первое, то к счастью в обеих уже было понимание того, что надёжность необходима; плюс в прошлой (оборонная промышленность) я имел относительно большую свободу что-то внедрять и улучшать процессы, а в нынешней (automotive) и без того процессы уже были хорошо налажены (хотя и обложены формальностями). В принципе же, да, включить в итерацию какой-то рефакторинг - это квест, и хорошо если архитекты, аналитики и нижние менеджеры уже согласны что рефакторинг уже назрел, а иначе надо делать презентацию и убеждать.
pooqpooq
11.05.2024 02:06Если первое, то к счастью в обеих уже было понимание того, что надёжность необходима
Да, именно о первом.
А как в этих компаниях случился переход к пониманию, что надёжность как-то связана с тестами-линтерами-ревью?
Falstaff
11.05.2024 02:06Мне кажется что вы к чему-то клоните, но к чему - сложно сказать. Ну начать с того что в обеих сферах действуют индустриальные стандарты (и да, возвращаясь к евангелистам Rust - не знаю почему они не публикуют статьи с цифрами в руках, показывая что если мы сделаем его индустриальным стандартом, то это будет net gain по сравнению с C++ и тестами-линтерами-ревью) и понимание заложено на уровне крупнее уровня компании. Во-вторых, ни в одном из этих мест too big to fail не работает, если случается происшествие (и я могу припомнить одно или два, без смертельного исхода, но близко), это анализируется и процесс изменяется, потому что и там и там могут погибнуть люди в результате программной ошибки.
(И, да, если интересно, то что я припомнил было связано с логическими ошибками, дополнительное тестирование бы там помогло, а внедрение Rust - нет. Но это так, к слову.)
pooqpooq
11.05.2024 02:06Я клоню к тому, что формировать отношение к небезопасным языкам как к чему-то зашкварному, как к процессу без тестов, ревью и прочего — это одна из наиболее эффективных стратегий. Потому что статей, например, с цифрами про эти вот тесты и ревью и их влияние околонулевое число.
SpiderEkb
11.05.2024 02:06Я не могу сказать "вот в Rust нет UB, айда все на Rust", мне нужно показать что это принесёт ценность с точки зрения бизнеса, что весть этот процесс найма и переобучения, адаптации инфраструктуры и документации, окупится и принесёт прибыль в какой-то строго оговоренный срок, что Rust действительно будет улучшением с точки зрения бизнеса.
Вот именно. Потому что первый вопрос в любом коммерческом проекте - "сколько это будет стоить, как быстро отобьются вложения и сколько на этом заработает бизнес".
Потому что бизнесу все равно какой там красоты код. Ему важна цена и продукта, сроки внедрения и полученная прибыль.
Siemargl
11.05.2024 02:06Я не могу сказать "вот в Rust нет UB, айда все на Rust", мне нужно показать что это принесёт ценность с точки зрения бизнеса, что весть этот процесс найма и переобучения, адаптации инфраструктуры и документации, окупится и принесёт прибыль в какой-то строго оговоренный срок, что Rust действительно будет улучшением с точки зрения бизнеса.
А не будет. Отвратительная скорость писания кода, самый медленный в индустрии компилятор и медленное cargo. Ну и поиск персонала для [любой] экзотики
Ваш код собирается полдня на ++? На расте вдесятеро дольше
Впрочем, бизнес уже сделал выбор, пиара наверное не хватило =)
qwerty19106
11.05.2024 02:06+1Ваш код собирается полдня на ++? На расте вдесятеро дольше
Пруфы будут, или как обычно?
Лично у меня библиотека для работы с матрицами на Rust (nalgebra) собирается гораздо быстрее чем на C++ (Eigen). Вот к линкеру lld есть претензии.Siemargl
11.05.2024 02:06раст фак, еще можно погуглить "rust compile slow"
https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow
Собственно, проблема в анализаторе безопасности - он дает квадратичную зависимость от LOC (и на С++ тоже, если включить)
qwerty19106
11.05.2024 02:06+1Я не знаю, где вы это откопали, но описанное в разделе "Rust compilation seems slow. Why is that? " устарело давным давно.
1) Инкрементальную компиляцию завезли в 2016, и с тех по ее ещё ускорили. А в статье говорится, что ее только будут добавлять!
2) Промежуточное представление MIR внедрили в 2017, так что опять мимо.
3) Там же написано, что время компиляции на тот момент сопоставимо с С++, но хуже из-за более строгой системы типов, что логично.
4) Про "квадратичную зависимость от LOC" звучит слишком фантастично, чтобы я поверил без пруфа. И на С++ тоже.Siemargl
11.05.2024 02:06ну я же написаль что именно надо гуглить. там полно новых ссылок
"давным давно" плохо звучит для раста - ему чутка более 10 лет, и уже фсе - не в тренде )
система типов не особо влияет на время компиляции
почему зависимость квадратичная - я переводил статьи, когда анализатор начали вводить в D и GCC - читать там
sdramare
11.05.2024 02:06+4У раста сейчас накопилась куча проблем, от багов компилятора, которые не фиксят десятилетиями и уже стали мемами(типа крейта cve-rs) до переругавшегося коммьюнити, которое ведет развитие языка в тупик. Это я молчу про "экосистему", где большинство крейтов это ранние беты, заброшенные 5-6 лет назад. По-большому счету если бы не dtolnay и darksonn, на расте вообще ничего практического написать было бы не возможно. И вот, вместо того, чтобы заняться поиском решения этих "трудностей", которые грозят похоронить раст еще до его взлета, раст-евангелисты ходят по форумам и рассказывают про "замену С++". Это просто цирк какой-то.
VladIsLoviN
11.05.2024 02:06+3Еще как лично я считаю плюс Rust'а в том, что самая популярная его книга доступна абсолютно бесплатно и рекламируется на официальном сайте https://doc.rust-lang.org/book/, там даже русский язык есть! Конечно, я не отрицаю тот факт, что про C++ гораздо больше информации, но все же приятно.
adeshere
11.05.2024 02:06+2...какой язык выбрать в качестве стартового?
Боюсь, что меня сейчас заклюют сторонники двух обсуждаемых языков, но лично я в качестве стартового все-таки выбрал бы что-то другое. Но поскольку в контексте статьи это уже почти оффтопик, продолжение спрячу под спойлер.
Простой язык для обучения программированию
Я исходил из того, что САМЫЙ первый язык все-таки должен быть минималистичным. Вообще без библиотек, модулей, крейтов и прочего, так как для некоторых обучаемых (при самом первом знакомстве с темой) эти концепции могут быть сложноваты. Как и понятие компилятора. Имхо, на начальном этапе освоения базовых элементов важна не столько мощь языка, его скорость или обилие возможностей, сколько прозрачная связь между кодом и результатом. Чтобы обучаемый сразу видел, как та или иная процедура работает "под капотом".
В общем, я остановился на интерпретаторе с минималистичной системой команд, предельно приближенных к "железу". Сейчас в моем языке всего 8 команд, что позволяет реализовать их на 3-битной архитектуре.
Сами команды такие
наШею, Вправо, Влево, Вперед, Стоп, Опустить.
Ну и синтаксический сахар (куда ж без него): это команды "Кругом" и "кМаме". Причем, последнюю обрабатывает макропроцессор, раскладывая ее на "элементарные" процедуры из первого списка. А фича в том, что перед исполнением каждая из этих команд озвучивается специальным динамиком. Имхо, такая озвучка здорово помогает освоению языка.
Несмотря на минимальный функционал, язык позволяет прокладывать довольно сложные маршруты по трехкомнатному лабиринту с мебелью. Правда, я не настолько силен в электронике, чтобы изготовить настоящий трехбитный процессор с необходимой периферией, поэтому сейчас наши первые программы работают на эмуляторе, в качестве которого выступаю я сам.
А вот насчет Rust или C/C++ в качестве первого языка у меня есть большие сомнения в связи с тем, что обучаемому на данный момент два года и пара месяцев. Посмотрим, за какое время дочке удастся освоить описанный выше микроязык хотя бы на уровне Middle. (Senior в моем представлении - это когда она начнет сама обучать этому языку свою куклу). А пока что (на первой неделе обучения) нам
труднее всего нам дается команда Стоп
Боюсь, что это мой архитектурный баг... Ведь в отличие от других команд, выполняющих разовую операцию и сразу возвращающих управление, команда Вперед запускает бесконечный цикл движения, выходить из которого надо отдельной командой (ну или с помощью препятствия на пути). Поэтому остановиться на середине коридора напротив двери, в которую хочется повернуть, у нас пока что не получается. Впрочем, вопросы синхронизации - это одна из самых сложных тем в любом языке...
UPD: Вдогонку: не успел написать, как мне тут уже Lisp посоветовали ;-)
Совет интересный, но проблема в том, что обучаемый пока не умеет ни читать, ни писать. Да и разговаривает с трудом. Поэтому всю программу нам пока приходится держать в голове... С учетом этого, наличие в языке всяких служебных символов типа кавычек выглядит большим минусом...
;-)
gev
11.05.2024 02:06+4...какой язык выбрать в качестве стартового?
Lisp!
adeshere
11.05.2024 02:06Lisp!
Не, в моем случае Lisp - это перебор ;-)
Я же имею дело с по-настоящему начинающим программистом, а не с переростком из дошкольной группы детского сада ;-)
В моем случае, когда обучаемый еще не умеет читать и писать, и вынужден всю программу держать в голове, освоить всякие скобки-кавычки-отступы-списки ему будет непросто. Поэтому я и предлагаю отложить эти темы на чуть попозже. Так что для самого первого знакомства с программированием мой самодельный язык все-таки лучше ;-)
adeshere
11.05.2024 02:06+1Вдогонку. Спасибо всем, кто меня заминусовал, за Ваше мнение... но, все-таки, я был бы благодарен за уточнение причины минусов.
Топикастер задал провокационный вопрос:
...какой язык выбрать в качестве стартового?
Уточнив при этом, что речь идет о "начинающих программистах", но не наложив формальных ограничений. А мне вот всегда казалось, что хороший стиль программирования - это когда ты готов обрабатывать не только типичные, но и крайние случаи. Ну вот я и написал про свой личный "крайний случай", для которого
оба предложенных топикастером языка не очень подходят:
Мой "начинающий программист" - слева 
Она же вылезает из иглу особой конструкции - ее можно построить даже в Подмосковье при полном отсутствии наста для кирпичей P.S. Конечно, я понимаю, что тут идет
серьезный разговор серьезных людей,
а не всяческих чайников со всего-то полумиллионом строк кода в продакте, которым априори нечего лезть со своими шуточками в деловую беседу даже в праздничный выходной
Но, вообще-то, в каждой шутке есть ДОЛЯ шутки.
Включая и шутку про "крайние случаи"
eptr
11.05.2024 02:06+3Сами команды такие
наШею, Вправо, Влево, Вперед, Стоп, Опустить.
Наличие в языке команды
наШеюможет вызвать профессиональную деформацию на всю оставшуюся жизнь.
DX28
11.05.2024 02:06+1Несмотря на подсознательную любовь к программированию и изучению нового, для рабочих задач выбираю то где больше вакансий и больше платят.
Вот будет число вакансий + зп на Rust больше чем на C++ - пойду курить методичку. А пока их 4 на всю страну есть более интересные задачи.
qalisander
11.05.2024 02:06Несмотря на подсознательную любовь к программированию и изучению
нового, для рабочих задач выбираю то где больше вакансий и больше
платят.Вот это хороший критерий. В том числе из-за этого я когда-то перешел с c# на rust. Ибо вакансий на c# кажется много, но зп часто ниже как и сложность задач и любят загонять в офис. Это про международный рынок, в рф может быть совсем иначе.
TrueRomanus
11.05.2024 02:06Небольшим недостатком, а не полноценным минусом, может стать официальный репозиторий крейтов crates.io. Политика фонда вызывает у сообщества некоторые опасения насчет того, не превратится ли репозиторий в очередной npm. Это вопрос, который требует внимания, и он не должен быть проигнорирован, но на данный момент это не является серьезной проблемой.
Очень сомнительное утверждение про то что crates превратиться в npm. npm стал тем чем он является не из-за чьей-то политики а потому что язык был (и остается) на хайпе имеет низкий порог вхождения и довольно простые api для работы со своим окружением позволяя затратив небольшие усилия написать почти любую библиотеку. Если библиотеки мастодонты вроде babel и webpack которые среднестатистический разработчик вряд ли быстро и просто напишет но большинство задач решаемых в других библиотеках легко реализовать самому из-за чего куча народа делает "свою правильную библиотеку". В случае rust-а я прям сильно сомневаюсь что такое произойдет, конкуренция в нем если и будет то между 2-3 разными библиотеками а не между 10-100+ библиотек.
oldnomad
11.05.2024 02:06+4Спросите у любого опытного программиста C/C++, и он подтвердит, что попытка скомпилировать программу, написанную на C/C++, с использованием MinGW или Clang без каких-либо изменений в коде, скорее всего, не увенчается успехом.
Я программирую на C уже больше 30 лет, и могу уверенно сказать что это полная чепуха. Для того и существует (с 1989 года) стандарт языка, чтобы любая соответствующая ему программа успешно компилировалась любым компилятором без изменений в коде.
Опытный программист на C знает, где он использует специфические для компилятора (UB или implementation-defined) фичи и, скорее всего, вынесет их в отдельный файл, в котором огородит их #if-ами.
Одной из уникальных особенностей языка программирования Rust является его очень строгий компилятор, который без дополнительных действий не позволит даже переменную назвать против стандартов языка. Это значит, что компилятор Rust работает упорно, чтобы гарантировать, что ваш код соответствует строгим стандартам языка.
Почему-то во всех статьях о преимуществах Rust строгость компилятора продвигается как достоинство. А по мне, так это, скорее, недостаток. Да, я ожидаю что компилятор по максимуму предупредит меня о потенциальных ошибках. Но если, например, я пишу прототип, который затем будет сто раз переписан, я готов проигнорировать часть ошибок, поскольку в данный момент мне не нужна идеально корректная программа.
pooqpooq
11.05.2024 02:06+4Я программирую на C уже больше 30 лет, и могу уверенно сказать что это полная чепуха.
Я программировал на C++ примерно вдвое меньше (но, к счастью, уже перестал), и могу уверенно сказать, что это правдивый пункт.
Опытный программист на C знает
К сожалению, некоторым программистам (даже опытным!) приходится работать не в одиночку, а взаимодействовать с другими людьми, которые могут быть куда менее опытными (или которые могут цениться своим опытом в других областях), и которые могут писать куда более компиляторозависимый код.
где он использует специфические для компилятора
Иногда это можно сделать случайно. Например, случайно использовать в C++14-режиме на gcc 6
autoв качестве типа параметра функции, что gcc 6 сожрёт, а вот gcc 8 уже заругается. Человек это случайно написал, человек заметил, что прокатило, и человек начал это использовать дальше в кодовой базе.Или, например, особенности разрешения имён в зависимых контекстах в конструкторах шаблонных классов, отчего ссылка на injected name трактуется по-разному в разных компиляторах. Я не думаю, что даже самые опытные разработчики с 60 годами опыта на C++ способны достаточно хорошо интернализировать стандарт C++ для того, чтобы понимать, используют ли они в подобных местах что-то компилятороспецифичное, или нет.
Собственно, иногда разные компиляторы ведут себя по-разному, и даже специалисты по трактовке стандарта не могут сказать, кто из них прав, потому что стандарт написан на человеческом языке, допускающем неоднозначные трактовки.
Но если, например, я пишу прототип, который затем будет сто раз переписан, я готов проигнорировать часть ошибок, поскольку в данный момент мне не нужна идеально корректная программа.
Я пишу на ещё более строгих языках, чем Rust, и даже там оказывается, что прототипировать выходит быстрее. Например, потому что оказывается, что прототип менять и частично выкидывать оказывается быстрее, когда компилятор строгий.
oldnomad
11.05.2024 02:06+1Я не думаю, что даже самые опытные разработчики с 60 годами опыта на C++ способны достаточно хорошо интернализировать стандарт C++ для того, чтобы понимать, используют ли они в подобных местах что-то компилятороспецифичное, или нет.
Разумеется, если программист недостаточно хорошо знает язык на котором пишет, он может делать ошибки. Но автор-то пишет про "опытного программиста C/C++". Для меня опытный программист -- это программист, в частности, хорошо изучивший язык, и чётко понимающий, что язык гарантирует, а что нет.
Не могу ничего сказать про C++, но стандарт C23, со всеми приложениями, меньше 800 страниц. Да, не самое лёгкое чтение, но осилить можно.
pooqpooq
11.05.2024 02:06+5Ну, скажу тогда за вас про C++: опытных программистов на C++ по вашему определению не существует.
Впрочем, судя по количеству CVE в сишном коде уровня ядра/иксов/glibc/etc, которые писали предположительно зубры (или бобры, или кто там пишет) от программирования, то с опытными программистами на C тоже как-то тяжко.
SIISII
11.05.2024 02:06Я бы сказал несколько по-другому: на С/С++ можно писать гарантированно переносимым образом -- но для этого программист должен предпринимать определённые усилия. Возьмём, к примеру, тип char. Хотя размер почти всегда у него действительно 8 бит, но бывает (или бывало, во всяком случае) экзотическое железо, где это не так; соответственно, программа, которая слепо полагается на этот размер, может неожиданно перестать работать, будучи перенесённой на другую платформу. А вот наличие/отсутствие знака у char -- куда более распространённая проблема; мне время от времени попадался код, который не работал именно из-за того, что разработчик полагался на знаковость этого типа.
Аналогичные проблемы и у прочих простых типов: тот же int, как известно, был 16-разрядным во времена 8- и 16-разрядных процессоров, но стал 32-разрядным на 32- и 64-разрядных.
Лично я для себя решаю подобные проблемы с типами тем, что объявляю свои собственные типы, которые везде и использую. Если придётся переехать на другую платформу, достаточно будет скорректировать их объявления. Ну и, кроме того, в "высокоуровневом" коде я никогда не полагаюсь на UB -- скажем, на то, что прибавив единицу к 16-разрядному беззнаковому значению FFFF, я получу нуль; в тех случаях, когда такое для чего-то реально нужно, я предпринимаю дополнительные меры безопасности (скажем, напишу что-то вроде (var + 1) & 0xFFFF -- чтобы гарантировать, что после FFFF будет идти нуль даже в случае, если на конкретной платформе 16-битного типа нет).
oldnomad
11.05.2024 02:06К счастью, проблемы переносимости, как правило, имеют стандартные решения. Есть
CHAR_BIT, естьsigned charиunsigned char, есть<stdint.h>, в новом стандарте завезли_BitInt(N)... Теперь сделать бы чтобы этим всем пользовались...SIISII
11.05.2024 02:06+1Ну дык о том и речь: средства есть, но ими часто не пользуются. Так что отсутствие строгости в С/С++ -- это всё-таки здоровенный минус, просто не стоит доводить строгость до абсурда, как это, похоже, имеет место в Расте (и как имеет место в Аде).
nameisBegemot
11.05.2024 02:06+2Таким образом можно сравнивать и другие языки. Например, Джава - тоже улучшенный си++. Где нет лишнего, есть автоматизация сборок зависимостей и сборщик мусора. Но в отличие от раста, Джава распространена больше.
Chupaka
11.05.2024 02:06— Ну чем, чем Rust лучше?!?
— Чем C++!
JordanCpp
11.05.2024 02:06Ага, шутка разряда за триста.
Сколько нужно раст программистов, что бы написать браузер?
Ни одного! :)
nameisBegemot
11.05.2024 02:06Это как в том анекдоте:
Сколько (условно программистов) нужно чтобы вкрутить лампочку?
Как минимум, два. Один чтобы вкручивать, второй чтобы было кому вкручивать
yerm
11.05.2024 02:06Ничего не понял. Стандарт по С++ существует кучу лет. И если писать, не используя всякие там расширения, то код нормально компилится вне зависимости от компилятора. Во всяком случае так было раньше. На С++ не пишу уже лет 15. Проходил собеседование на должность С++ Builder программиста( кстати на тот момент С++ Builde считался вторым по соблюдению стандарта, Microsft был третьим) в начале 2000-х году в Люксофт. Задали вопрос: почему в деструкторе не рекомендуется генерить исключение. Ответ был такой. Если объект размещен в стеке и процессе работы произойдет исключение, то при выходе скоупа при деструкции объекта произойдет второе исключение. При этом поведение может быть любым в зависимости от реализации компилятора, потому что на тот момент стандарт такую ситуацию не оговаривал. После этого ответа сказали что я принят и что до меня никто на этот вопрос не ответил.
flx0
Эта статья выдает в вас человека, который не писал ни на С, ни на С++, ни, скорее всего, на Rust. И вообще, скорее LLM чем человека.