Volvo is using Rust for its in-vehicle software
I am truly astounded by the hatred exhibited in some of the comments in this thread.  Wow.<p>A few points:<p>If your software development experience is limited to web or mobile development, please understand you lack a massive amount of context when it comes to software in the context of complex hardware manufacturing.  To put it in simple terms, you really don&#x27;t know what you are talking about.  It&#x27;s like someone who writes code for embedded systems in clothes washing machines having a strong opinion about how to engineer, deploy and maintain a tech stack for a SaaS.<p>Next, the cults formed around programming languages are some of the funniest things I read on HN.  Except, they are not funny at all.  There is nothing wrong with C or C++.  Nothing.  The problem is people who don&#x27;t know how to program.  At the core, to perform a certain function the microprocessor will, for the most part, do pretty much the same things, regardless of what language might be used to describe that.  Blink a light in response to a button being pressed?  At some point you are sensing and de-bouncing the input and then setting an output pin.  Maybe there&#x27;s I2C, SPI or CANbus in between, but what you have todo is the same.<p>Languages like C and C++ have been around for longer than most people reading this have been alive.  They have been used --successfully and without issues-- for more projects, products and systems than anyone can imagine and at scales from a watch to spacecraft and everything in between.  This cult of languages as solutions to problems caused by bad programming is nonsensical.  One can write bad code in any language.<p>Professional certifications.  This isn&#x27;t going to stop people from writing bad code.  At all.  Designing and implementing complex code for real time systems is far more complex than designing a bridge or a building.  Certifications are not magical inoculants against bugs and system design problems.  Trying to view and fit software engineering from the context of other engineering disciplines is a mistake.  They are not the same thing.<p>When you are dealing with fault-tolerant hardware + firmware systems things can get exponentially harder.  Folks who work on web products have the luxury of being able to make lots of mistakes and fix them as fast as their deployment system allows.  Imagine if you got ONE CHANCE to ship a non-trivial codebase and it has to be guaranteed to work to a high degree of certainty for ten or twenty years.  Once you ship it, there will be millions of users and you cannot touch it at all.  In fact, you have to telemetry data of any kind.  You don&#x27;t know if there are issues, if it has random failures, race conditions or odd failure modes you cannot possibly simulate at scale in the lab.<p>Imagine this next time you deploy an update.  Imagine you are not allowed to touch it at all after that and it has to work.  Imagine that, and maybe you can get a sense of what some of this work can be like.<p>This isn&#x27;t limited to automotive.  This goes for commercial, industrial, aerospace and other domains.  Hardware is a million times more difficult that pure software products, particularly web type software.  We just shipped a thousand units of one of our new products for installation in a large industrial facility.  The firmware had to go through a year of testing before we dared ship even a single unit.  That&#x27;s another thing to imagine; the idea of having to test and qualify your web SaaS --not with clients as test subjects, on your own-- for a year or more before you can launch your business (and you are not allowed to touch it after that).<p>Anyhow.  Don&#x27;t be language cultists.  That isn&#x27;t the problem.  Bad programmers and bad process is far more of an issue.  Changing languages isn&#x27;t going to magically fix that.  It isn&#x27;t a solution.  You can build anything with C or C++.  If written correctly, it will perform better than just-about anything and be reliable within the bounds of system specifications.