Комментарии 32
Ерунда какая то. Тут или ученый изнасиловал журналиста или этот Густавсон немного не шарит в той области, где его поставили командовать.
1.
В первую очередь разработчики выбрали его из-за энергоэффективности.
Каким, интересно, образом язык программирования влияет на энергоэффективность? Включить режимы пониженного потребления МК, отключить тактирование модулей и т.п. одинаково энергоэффективно на любом языке.
2.
построен на базе процессора Arm Cortex-M, поэтому команда решила, что в новом поколении автомобилей Volvo стоит перейти с C/C++ на более современный Rust
Причина и следствие логически совершенно не связаны. Лампочка работает от 220 вольт, поэтому мы решили пойти попить пива.
3.
если в команды часто меняются сотрудники, то они могут быстро включиться в работу
Если в команде часто меняются сотрудники то что то не так с начальством этой команды.
4.
Всё из-за того, что ECU должен управлять системами электромобиля через CAN-шину, а готовых модулей для этого нет.
Я правильно понял этот текст? Программистам пришлось делать свою работу, потому что готовое ПО за них никто не написал.
5.
В процессе выяснилось, что разработчики делают меньше ошибок в коде.
Как выяснилось? Параллельно вторая команда решала эту же задачу на С и какой то специальный хрен сидел и скрупулезно подсчитывал ошибки обеих команд?
6.
Густавссон считает, что Volvo получила код, который легко поддерживать и модернизировать
Было бы удивительно если бы он считал иначе. Учитывая что в его команде "часто меняются сотрудники", у которых проблемы с написанием ПО для банальной CAN шины и которые вместо их решения занимаются подсчетом ошибок.
7.
Rust при этом доказал, что его можно использовать в масштабных проектах, в которых важна безопасность и отказоустойчивость
Каким образом доказал? Видимо, это тоже личное мнение Густавсона. Так то при желании и на брейнфаке можно написать проект, в котором важна безопасность и отказоустойчивость.
С 4го пункта сам аж орнул в голосинку =)
Представил, как мы в команде разрабатываем игру и такие - у нас новая задача, на которую нет должного ПО, поэтому переходим с анрила на годот.
Лампочка работает от 220 вольт, поэтому мы решили пойти попить пива.
Ну не знаю, звучит вполне логично
Да перевод кривой. Это даже не перевод, а пересказ какой то. В оригинале все звучит логичнее. :)
В оригинале он пишет, что до 2019-го года над блоком управления никто активно не работал и этот блок программировали на смеси языка Ада и С/C++. Было много багов с работой с памятью. Парень был знаком с Rust еще до версии 1.0 и ему язык нравился. Потому он решил его использовать.
Про энергоэффективность там другая связка. В контрольном блоке использовался энергоэффективный процессор и Rust легко встал на этот процессор.
Пришлось видимо писать многое с нуля, и для работы CAN шиной, зато потом у них в общем стало меньше багов в системе. Итп итд.
Пришло юное дарование, поняло что ни С++, ни, тем более, Ada оно не знает и знать не хочет. Зато обладает развитыми софтскиллами, позволившими убедить вышестоящий менеджмент в том, что "вот, прям ща, забабахаем все на расте и будет всем щасьтье, даром".
А минусы будут?
Ну вот например, аналогичные юные дарования в 2012-м году пришли в Банк Содружества Австралии и Океании и убедили менеджмент переписать всю банковскую систему (кто хоть раз сталкивался, примерно представляет объемы и сложность бизнес-логики и интеграций) с богомерзкого легаси-кобола на "современный стек". Заняло это ни много ни мало 5 лет - 2012-2017гг. И стоило банку $750 млн (которые, естественно, не окупились никак). По пути огребли куеву хучу багов, например, в один день обнулилась кредиторская задолженность всех клиентов без исключения - для банка это ЧП планетарного масштаба - откат "с ленты" на предыдущий день и буквально руками восстановление всех операций (а банк при это должен продолжать работать - его не закрыть "на техобслуживание").
Ну и надо ли говорить что то, что было "современным стеком" в 12-м году, в 17-м уже стало если не легаси, то близко к тому...
Что характерно, ни быстрее, ни эффективнее, все это работать не стало...
Ну и дело не в минусах, как таковых. Дело в том, что там плюсов явных нет. Чтобы доказать что раст лучше плюсов (равно как и наоборот) нужно иметь две идентичных по функционалу реализации и дотошно их сравнивать по всем параметрам - эффективность, потребление ресурсов, скорость разработки, устойчивость, простота внесения изменений и много чего еще. И в цифрах доказывать что "сделаем вот так - потратим столько-то, срок окупаемости такой-то, общая экономия на горизонте n лет такая-то".
Уверен, что ничего подобного там не делалось т.к. это слишком сложно и результат может оказаться не тем, который хочется. Так что проще "включить софтскиллы" и проехаться начальству по ушам.
Я понимаю, что переписывать банковскую систему - мероприятие весьма рискованное. Но что ж теперь - не переписывать её вовсе? Продолжать писать на коболе, пока не отвалится само?
Ну и надо ли говорить что то, что было "современным стеком" в 12-м году, в 17-м уже стало если не легаси, то близко к тому...
Всё-таки есть небольшая разница между легаси пятилетней летней давности и сорокалетней (?)
Разница есть. И она в том, что кобол разрабатывался специально для высокоэффективной работы с БД и ведения коммерческих вычислений [с фиксированной точкой, округлениями и вот этим всем вот]. И здесь он самодостаточен. И, несмотря на причудливый синтаксис, это достаточно простой и эффективный (в своей области применения!) язык на самом деле. Потому что не претендует на то, что на нем можно сделать все. Наоборот, на то, что на нем можно делать строго конкретные вещи, но делать их очень эффективно.
А "современный стек" это языки общего назначения. И чтобы что-то сделать с БД или той же фиксированной точкой, нужно подтянуть кучу зависимостей и все равно получится сложно, вычурно и т.п.
Мне кажется между переписыванием всей (!) банковской системой и переписыванием кода блока управления есть мааааааааленькая разница.
Пришло юное дарование, поняло что ни С++, ни, тем более, Ada оно не знает и знать не хочет.
Ага, ага:
Julius told me his first job was building air traffic control software, where a lot of Ada is used.
And so he used a mixture of C and C++ for about 15 years.
In 2020 they had made a first proof-of-concept in C before continuing the project with Rust.
В 2024 считать Раст модным и молодёжным уже даже как-то странно.
Julius told me his first job was building air traffic control software, where a lot of Ada is used.
И буквально тут же он заявляет, что "however, the consensus at the company was that Ada was both too arcane and to proprietary for them, at that time", типа контора написала кучу кода на языке, который сама же (а точнее по-видимому граждане типа этого Густавссона) расценивала как мистический и нипанятный, мда. Забавные вещи в общем пишет гражданин.
В 2024 считать Раст модным и молодёжным уже даже как-то странно.
Лучшее доказательство его незрелости - это то, что "в 2024" в кругах растаманов все еще считается нормальным писать про него статьи откровенно евангелистского характера типа этой, состоящие на 0% из технических деталей и на 100% из голословных бла-бла и вкусовщины, хехе.
Третий пункт в тексте прочитал несколько раз. Подумал, что уже совсем с головой не дружу и не вижу взаимосвязи
раньше убеждали про qnx auto
Э-э-э... А какая связь? QNX - операционная система реального времени, разработанная специально для встраиваемых систем. Построена по принципу микроядра. Имеет кучу сертификатов по безопасности и всему прочему.
Это одна из множества RTOS. И да, весьма неплохая, хотя многие ее возможности избыточны для применения в авто. А вот во всяких военных вещах (тех же беспилотниках) она показала себя очень хорошо.
Также использовалась в смартфонах Blackberry (они выкупили QNX у предыдущих владельцев и на ее основе сделали Blackberry OS 10, которая "идентифицирует себя" как QNX 8.0.0).
Сейчас это далеко не единственная RTOS для встраиваемых систем (vxWorks, WindRiver Linux и т.п...)
И, кстати, в статье ни слова о том, по какой операционкой они работают. Ну не под голый же процессор пишут...
Как писать крупный софт без ООП?
Если говорить о расте, часть ооп характеристик у него есть - инкапсуляция и полиморфизм. Только наследования нет, что на самом деле в крупном софте может быть плюсом (отсутствие наследования делает код проще для понимания имхо).
А так, даже без вообще каких-либо фишек ооп крупный софт пишут - ядро Линукс например
Нужно ли в автомобильной промышленности сертифицировать код ответственных систем как в авиации? Просто я сомневаюсь, что код не на C/C++ в сертифицирующем ведомстве вообще кто-то будет смотреть.
Насколько я помню, то как минимум в ЕС для сертификации автомобиля код не смотрят.
Есть ряд обязательных тестов для машины в целом и для отдельных компонентов.
И есть сертификат соответствия, в котором производитель сам гарантирует что его автомобиль соответствует всем нормам и стандартам.
нет вроде. Есть конечно MISRA, но никто не заставляет, afair
Код не смотрят обычно, но требуют предоставить отчеты и метрики. Проще говоря - просят показать что тесты разного уровня присутствуют и что какой нибудь код стандарт для автомотива соблюден, это обычно отчет от статик анализатора. Для раста вроде даже что то есть https://www.reddit.com/r/rust/comments/telabz/autosar_announces_new_working_group_for/
В переводе/пересказе об этом не упоминается, а в оригинальной статье написано так:
It was not classified as a safety-critical component and it was an Arm Cortex-M processor, so there was no technical or bureaucratic blocker for using Rust.
Вообще соответствующий стандарт существует - ISO 26262.
И есть проект, который ставит целью сертификацию Rust для safety-critical окружений - Ferrocene. Но тогда его ещё не было.
просто это "модно/стильно/молодежно"...не какой-нибудь вам замшелый C. А то что пришлось весь код перелопатить, ну так китайцы заплатят))
Электромобили Volvo и Polestar используют Rust в коде электронного блока управления