Every automotive code base I've seen has been a dumpster fire. This (mostly) isn't the fault of the developers and Rust won't fix it. The business process creates this outcome. No one likes it but little is done to address it.
The software development timeline is slaved to the rigid manufacturing timeline. There is no allowance for slippage, so making things work By Any Means Necessary is the rule of the day. Concurrency problems often are not debugged; locks and similar are just sprinkled around until they disappear in testing. It is TDD taken to an extreme -- passing the enumerated tests, technically, is the definition of done even if the code is obviously poor or broken.
There are a vast number of software and hardware components sourced from myriad vendors that are swapped out every year to save a few dollars or deal with a supply chain issue. There is no stable baseline but all of these components need to work together. The code has to constantly adapt to the reality that someone sourced parts for a new model year that work differently or are in a different programming language.
This code is usually required to be supported for 10+ years. The developers don't just have this year's tech stack and code base to deliver on a rigid schedule, they are required to maintain several older implementations concurrently, often built in different languages and architectures.
Basically, the automotive industry has failed badly at the transition from being hardware manufacturing companies to being hardware + software manufacturing companies, and try to run their software processes the same way they ran their traditional hardware processes. Choice of programming language is the least of their concerns, that isn't the source of their code quality issues.
It's even worse than that. The standards they run on have contradicting errors in the dozens or hundreds. See this talk https://youtu.be/hXnS_Xjwk2Y?t=899 starting at 15 minutes in (that includes testing for Volvo).
Relevant (for those who don't want to watch video):
- 3000 pages of specs
- 1 million LoC from suppliers (because you use different systems from different suppliers)
- 200 problems
- of which more than 100 problems were in the standard itself (standard being AUTOSAR that described how different parts from different suppliers communicate with each other)
The language won't fix it (it's just a tool after all), though it may enforce certain rules that help the developers not shoot themselves in the leg. Rust has some fairly strong guards, as long as you don't circumvent them. At least it takes some conscious effort to make a Rust program segfault, and almost every IoT appliance (non-automotive, though, I haven't worked with those) I've had that I've reverse engineered had a command that could crash it - I've rebooted my cat feeder way too many times to my liking.
What could be an important change is the culture. At the very least, developers who tend to pick Rust may be (hopefully) more inclined to do things the right way and don't just slap shit on the codebase until it sticks. I've seen way too much of this attitude in embedded developers.
And another important change could be management policies. If they are conscious to pick something uncommon, they might have better tolerance toward spending more time but doing things properly, than pushing people to release whatever seem to work (somehow).
I'm pretty sure a lot of bullshit in IoT happens because management want to release things as fast as it's possible, and developers either don't care or can't fight it.
The language will fix a chunk of it. Much buggy code simply cannot be compiled, and if you can't compile it you can't ship it. You are mostly left with logic and design errors, which can become more obvious due to the language. Middle management will hate it because due to the language they lose much of their ability to compromise on quality, passing the buck. Upper management may love it or hate it, depending on how serious they are about improving quality, as the language forces the spending for that level of quality.
Volvo should actually be contributing to a consortium of automotive computer developers that pool resources together to build shared software on cars. The ultimate outcome would be like an Android-like license that allows car manufacturers the freedom to build-on-top of a software stack that gets security updates.
Cars get tricky, though, because bugs can lead to loss of life.
It's not like people actually do this though. I've been programming Rust for 5 years now. Since three years 'mostly Rust', now 'only Rust'. As far as I've seen `unsafe` is used very sparingly in every codebase I've had to deal with. Mostly when interacting with C, as there's no way to call C without `unsafe`.
But even then that's usually abstracted away and then a safe interface being provided.
Maybe, but the thing about unsafe is, it isn't like fairy dust so sprinkling it on stuff doesn't help. This is a common misconception from people who haven't worked with unsafe (even if they've written some Rust)
ten_things[11] = blah; // is a buffer overflow so it either won't compile or it panics
However
unsafe { ten_things[11] = blah; } // is still a buffer overflow, same effect but also Rust warns that unsafe is useless here and should be removed
Now of course we can write a potential buffer overflow in unsafe Rust, but now we're not just sprinkling unsafe on stuff and hoping, we've got a plan, perhaps a stupid plan but it's a plan so that's an improvement.
I'm sure you're much more knowledgeable than me about Rust at least.
Still based on my experience reading early Redox code it was chock full of unsafe blocks, and I suspect they didn't do that out of malice but to expedite development.
Well if I knew less than the last guy I'm defo beat here :)
Would be interesting to see what those figures were like 5 years ago (i.e. a year or so after its initial release). It seems like the concern here is that embedded Dev for cars isn't getting getting to maturity.
At the end of the day it's embedded code that's inherently unsafe, so the benefits are all in the code that belongs in the safe zone. Unsafe Rust is at best equivalent to C/C++ and at worst it's a false sense of security. Mixing safe and unsafe without a clear boundary is not something I can speak to with confidence but my gut-feeling is that it's worse than C/C++.
Even OS kernels are borderline, and it's still being figured out how exactly Rust fits, but yes we are slowly moving in that direction. Kernels have a lot of logic that qualify for the safe zone, and software engineering culture that is... let's say ahead of automotive.
> Unsafe Rust is at best equivalent to C/C++ and at worst it's a false sense of security.
This is a bit of a misconception for people who've not worked with unsafe Rust. It's not like the language and most of its features disappear. It just allows a few extra features that are unsafe, like working with pointers... Which, granted, is a lot of interaction with hardware. But you can kinda "cordon" this to a small subset of the codebase dedicated to this low level hardware IO
I'm not really an expert in embedded systems, so take this with a grain of salt, but that doesn't track with my experience or with my theoretical understanding of embedded systems. First off, embedded systems are just regular systems with tighter constraints and less high-level constructs. With that understanding, if embedded code is unsafe... so is any code on any system.
Second, embedded systems have peripherals that are accessed via direct memory reads and writes. Which is only unsafe if access to those peripherals is shared in an unsafe way. Sure, the rust code that reads and writes to memory addresses will use `unsafe`, but everything above that can be written without using unsafe. Which I guess makes your statement technically correct, but imo not practically correct
I have no experience in automotive software development so I could be very wrong about this. But I suspect that Rust is a very poor choice if what he said is true about automotive development since, at least some, Rust devs openly talk about Rust being a more complicated language to program in. Increasing the complexity of software development in an environment like that will ultimately add the problem instead of solving it.
But referencing the parent comment's discussion of business processes, its highly unlikely the problems will appear until Volvo tries to move to some other vendor or swap out the software solution for the next greatest thing.
Generally speaking they also don't pay software development well so I would guess they aren't exactly getting the best talent either. I think cars are cool, but I wouldn't take a 50% pay cut to develop software for them.
It's not a question of talent, just timing and process. The timing is rigid and there's a hard, non-negotiable deadline when metal starts being stamped. The process around certifying makes you work at a tiny fraction of your normal speed, because most time is spent filling out auditing requirements.
You still need to pay enough to attract the kind of people who understand what "undefined behavior" is and why you should avoid it. That number is somewhat higher than what most mid-level automotive programmers are paid, in my experience.
German car manufacturers already have unions. Unions don't help against overmanagment and leadership without technical (digital) understanding. "Creative" parts of the company are often praised (while mostly badly stealing ideas from the competition) while devs are seen as a "resource". Experts usually get asked AFTER the project is on fire or already crisp.
A substantial amount of this development is already done in managed/safe languages when possible. In many cases, the software developers are represented by a works council or similar. These are generally capable and skilled developers that want to do a good job, not half-literate code monkeys slinging bad C in a sweatshop.
Whatever ethos you imagine Rust developers uniquely have, it doesn't address any of the constraints and incentives that are creating the code quality problems in automotive. Even the best developers in the world would have a difficult time producing a quality product in that environment.
> Whatever ethos you imagine Rust developers uniquely have
They tend to seem more of the type to go on strike, form a union, or leave a job because of political views.
> Even the best developers in the world would have a difficult time producing a quality product in that environment.
Right, i'm saying I think at least more experienced rust developers would refuse to work in that environment.
They seem like they would risk more of their own well-being for ethical reasons, for better or worse.
I suppose if Volvo started depending on highly socially conscious domain experts and had a choice between changing working conditions and ditching rust though, they'd change the latter.
I'm happy to be proven wrong, but experienced C programmers seem to be more conservative "don't mix politics and programming" types.
> I suppose if Volvo started depending on highly socially conscious domain experts
It's amazing that you're saying all that and the same time completely oblivious to the fact that Volvo is in Sweden. Which has unions, labor protection, amazing working conditions etc. etc.
The reason Volvo is doing what it's doing is due to Volvo's commitment to safety [1] and not because of some mythical exclusively social ethos of some programmers.
In Germany we already have unions, including the software development, as the unions are traversal to the industry regardless of the role each employee has on the building.
I think you are on something. Tangentially I used to sit next to a colleague who was responsible for research software development in Python. The amount of necessary coordination in developing such software made the dev mental health to suffer. In contrast in Julia which I was already using at the time development is more autonomous as things just work together.
A lot of comments so far are complaining about the software quality in cars now. But what did you expect? This is what happens when you hire the same kinds of people to write the software for your car that you've hired for 25 years to write the terrible internal applications inside the company that everyone hates, and in the same terrible way. The end result is going to be exactly the same.
Over the years, I've seen various discussions brush up against the issue of professional certification. Professional Engineer, in civil engineering, is a serious credential, which can hold people professionally liable for bridges that fail, or buildings that fall over. Making cars a network of computers that all talk to each other, operated entirely "by wire," and giving up any consideration of mechanical backups (like with a plane) is going to very quickly drive the point home that the programming profession needs a similar credential. As a mechanical engineer who has made a living writing software for 30 years, I understand the difference, but the legal externalities are not going to care that software is VASTLY more complicated than, say, designing a plane wing with a factor of safety.
Now, I have to go figure out why my Rails application can no longer restart the delayed_job process on deploy. Is the problem in Rails, Ruby, my gems, Capistrano, permissions, SSH, or some updated package on my Linux VM? Designing a bridge, frankly, is easier, because it's "concrete" and closed-form. Sure, I'll figure out my deployment problem, but next month some obscure thing in the 24 layers that make up a simple web app these days is going to get updated, and break something else. At least once a bridge is built, it's done.
When professional certifications are required to write car software, you won’t have top tier people writing it. Instead, you’ll get mediocrities who will jump on the certification as a way to secure a sinecure at a company requiring it.
Consider existing professional certifications, like, for example, Cisco certification. How many top tier people have it? Some do, but in my experience, not many. Instead, they are overwhelmingly held by low-to-mid skill people, who see it as a ticket to a better job. Top tier people can easily get top tier job, and have no need to waste time on some certifications.
I think you've missed the point. A professional engineer isn't just a certification. It also grants the power and indeed the duty to say "no" to things that are unsafe. If a cost-cutting change is proposed that means the bridge might collapse, you say no.
But in software? If management says you need to cut corners to get something out by an arbitrary deadline, well, you cut the corners or they'll find someone who will.
I like how a city engineer at little rock put it to me one time. “Having a license does not mean you have all the answers, but you are kind of responsible for them.“
I work as an electrician in industrie automation. To say "no" is very important. It's not easy, but I don't have to worry they ever fire me for my "no" because they know I'm right.
As an electrician for example, we have to check almost everyrthing with various tests and sign it with my name.
For me, the software world still looks and feel like wild west.
And surely, there will never be anyone who’ll just cynically use their professional credential to make a lot of money this way. Of course, there are plenty of people who do shady things like this today, but clearly obtaining professional certification will make angels out of humans.
If. Many people will take a risk, as the risk will pay off in most cases that aren't totally egregious. Most shady scenarios are not "people will certainly die if I sign off on this", they're rather "eh, this is somewhat against the rules, but it's not that important, it just increases the risk from one in 1000 years to 1 in 300 years". People who will accept the risk to their personal careers will be in high demand as "people who make projects happen", and they'll be highly renumerated for their increased risk profile.
In any case, if PE was required to work in software, I wouldn't have had a job in the first place, so I'll always oppose these kind of efforts to shut out the outsiders and underprivileged people.
Well said. And if you fail to say no to something that is unsafe, you can be sued for malpractice. The fact that management pressured you is of no consequence.
In theory, yes. In practice, probably not. Most stuff that "falls over" after being built is due to poor maintenance or skipped checks. I never read any news about "PEs" (people seem to be drooling over that title) being sued.
A PE is not a certification, it's a license, legally-recognized by the state. (Like other licenses, such as for mental health counseling.) You have to take 2 tests, one to start, and another to finish, after 3 years of professional work. As with most engineering students, I took the first part (the EIT), but never took the second, as my job never needed it. I wish I had, though. It would have been a nice feather in my cap.
In any case, I can ASSURE you that it was comprehensive, and you have to "know your stuff" to pass it. I've been Microsoft certified, so I've seen this side too. If there were a similarly-reputable license in software engineering, there would NOT be "certification factories" to crank out people who can pass the cert test, and who can do little else. I don't know what the analogue for doing actual mechanical/electrical/civil engineering problems would be in the software engineering realm, but that's the KIND of thing that would have to be tested. It would require a working computer and internet access, and not a duffle bag of engineering textbooks, like I had. ;-)
I think certification is secondary. The most important thing is liability. The problem is that software problems are ephemeral and often gets disregarded. If a software is slow, people seems to just live with it and/or just buy faster computers. Just think about how weird it is if things just randomly fall of, it happens so irregularly that I don't expect them to happen. This is simply not true of software.
> If software engineers in a specific field (automotive) were held liable for bugs in their software, no one would want those jobs. Would you?
If almost no one wants them, then they would pay very well and be in high demand, and that comes with lots of benefits and perks, and you can require the use of the best tools to ensure those disastrous outcomes don't happen. So yes, I'd take that job.
then why would engineers in other industries accept theirs? IMO software should move a lot slower, but the economy does not work that way. There's way too many experimental things that go live in production.
I think it was either Bjarne Stroustrup, Scott Meyers, or Herb Sutter who said that if we "went slower" (took less risks / program more like embedded / NASA / JAXA / ESA), we would still be living in the computing stone age. The real trick is to take calculated risks given your business environment and constraints. Usually, on any given team, there is one person who thinks they are "flying to the moon" with their accounting software (or whatever). And their pace is ridiculously slow, and code vastly over-designed and tested. They are always planning for once in 10,000 years events.
(I am not disagreeing with your claim): This assertion is a bit at odds with the notion of certifications, but only when considered without other factors. Economic theory suggests then the achievement of the certification is not costly enough to cause a separating equilibrium of talent versus not.
> This is what happens when you hire the same kinds of people to write the software for your car that you've hired for 25 years to write the terrible internal applications inside the company that everyone hates, and in the same terrible way.
I work in "automotive," and my company created an internal textbook on waterfall development 25 years ago. I know, because I was part of an external consultancy to review it. And it was great! At waterfall! And they're still using it! Now we're getting into alternate power, and we've lifted the same software process we've been using since we had to break our firmware into 8 pieces BECAUSE THAT'S WHAT FIT ON A FLOPPY to send to the plant to upload into the ECM, and started using it with completely new build systems and processes. We've hobbled what could be a completely fresh start with 25-40 years of technical debt before even getting started. I would posit that heading off this train wreck was the place of the CIO or CTO, but they just made the CIO the CEO, so ¯\_(ツ)_/¯.
The idea that the best solution to computer complexity is more bureaucracy and a professional cartel is absurd.
We know how to solve the problem of software reliability. We have a rich body of formal methods that allow us to build perfectly reliable computer systems, up to the failure envelope of the hardware itself (from thermal, radiative, mechanical, etc. stress).
The reason we only use these techniques on certain critical systems is that the cost is somewhat higher than normal "unsafe" development and the incentives are not there yet.
Instead of turning our industry into a horrific morass of red tape, with questionable upside and unquestionable downside, let's just incentivize the use of correctness technology where appropriate.
The use of formal methods in safety critical code is already well-established. MBD is a very common method to write ECU software, for example. It's not universal though and proofs of the more complicated system requirements are challenging at best.
Well, to be fair, I'm not saying that certifying software developers is reasonable. As a practical matter, the industry moves too fast anyway. A PE license is for life. Even if there were a software engineering license, I wouldn't necessarily trust someone who was licensed back in the COBOL days to know anything about modern web development. I'm just saying that if there's enough LEGAL pressure, this is almost inevitable. A Fortune 1000 company is not going to just absorb the costs of failed products (like self-driving cars killing people), and do nothing about it to cover their asses.
> A Fortune 1000 company is not going to just absorb the costs of failed products (like self-driving cars killing people)
Except, that's precisely what they do. Such costs are calculated into the product when it is being developed. Just read about the Avandia drug scandal.
>"A Fortune 1000 company is not going to just absorb the costs of failed products (like self-driving cars killing people), and do nothing about it to cover their asses."
And introducing certification is not going to to stop the killing and will not "cover their asses" either. Out tech currently is simply not adequate to solving this problem in the way acceptable to corporations and the end customers.
This is why I do not understand people being called software engineers when they're anything but. As you said engineer is more about ethics and liability. I am designing and developing software for more than 40 years but I would never call myself an engineer. Nor would I ever want to become one.
When it comes to the issues of safety the proper outcome should be organized by a processes, verification and other things that would not let that piece of code get into production. Putting this kind of load on software developer I think is utterly demented idea.
For engineers the foremost value is safeguarding human life and the second might be protecting the environment. If anyone is developing software that can cause loss of life or damage the environment then I think the engineering ethics and processes you mentioned are a necessary load. Of course then the output of the
Programmer is reduced, but that is the tradeoff to make for the type of code flying airplanes or driving cars
The processes and other things do not have to be set by programmer. It is insane to have programmers do all those things. Their task is to design develop software given constraints. Safety is a constraint that can be specced separately. And testing should be done by the independent team
Exactly why any good Software Engineering, certified from Engineering Society of the respective country, has formal methods as part of the compulsory lectures.
Proper engineers learn them, not random dudes that decide to call themselves "engineers" after a six weeks bootcamp.
I actually find it ridiculous that engineers can be held personally liable for work performed for a company. It's not a model I would support moving towards, at all.
If the world starts coming after corporations for these kinds of very-real safety issues caused by software, they're going to "do a pro move," and come after the programming profession.
The first person to get jail time during the 'DieselGate' scandal was James Liang, surprise surprise an Enginnering Head at VW. An army of Execs and C-levels were in the know but the first guy to go is a low-rank Engineer.
I'm confused by this post. First you wrote: <<Enginnering Head at VW>>, then you wrote: <<low-rank Engineer>>. Which one is it? Engineering Head at VW probably makes huge money has has 10,000 well-paid staff under them.
compared to a CTO, the enginnering head is low-rank. According to the prosecution he was making 270k in the US so not exactly mega bucks.
My point is execs and C-levels always claim that their pay is justified by the risk and liability of their decisions but when the wheels hit the tarmac things change very quickly.
Agreed. We know issues at the design stage can be avoided by improving systems, making that the personal problem of someone with a PE is a bandaid solution.
Improve regulation, fund regulators, incentivize companies to fund quality processes.
> the programming profession needs a similar credential
I don't think it needs the credentials, it just needs (language?) to distinguish between roles where you can sign off on a product and be held legally liable if the product is found to fail its specification.
This, in my mind, is the difference between a software engineer and a software developer (I consider myself a software developer).
I worry that this won’t have the effect you want. Some of the worst software I’ve ever used met all aspects of its specification because “be pleasant to use” could not be meaningfully captured in a formal spec.
I’m not sure what the solution to bad software is, but I don’t think it’s making the spec higher stakes.
There are already design standards for avionics software. DO-178 and DO-254, namely. Some car manufacturers follow something similar voluntarily. Maybe requiring something like this standard and having something like the FAA to enforce it is what we need?
I don't know where you get your information, but you've completely missed what automotive software development looks like. The amount of verification and validation, and the number of standards (most of them are self-imposed, not a legal or homologation requirement) is absurdly high.
Here's a scenario. You're nominated to be an ECU supplier or a software sub-supplier for a VW brand, first thing they hit you with is requirements which span 1000 pages for a simple system (door, seat, HVAC), or 10x more for a more complex one (infotainment, engine ECU, "main" vehicle ECU etc.). 1 of those requirements is "SW shall comply with VW 8xxxxx norm" which is one of many VW norms that they deliver to you. The other requirement is "SW shall comply with KGAS", KGAS stands for "Konzerngrundanforderungen Software" which translates to "Group Basic Software Requirements", (group is VW), and both, you guessed it, are thousands upon thousands of requirements.
Then there's Functional Safety, or FUSA, which is a reference to ISO26262 (based on IEC 61508). Then there's also ASPICE (ISO/IEC 15504). New thing is UNECE R155 (cybersecurity). These three prescribe a very detailed development process commonly known as the "V model" for system and software development, which means you need to elicit requirements, define system requirements, system architecture, software requirements, software architecture and software detailed design. After that, you get to coding. For each of those there's a validation method: unit tests, software integration, software qualification, system integration and system qualification. ASPICE 4.0 has expanded to cover Embedded Hardware and Mechanical design as well. Other than the engineering processes they also cover other areas such as project management, configuration management, supplier monitoring, problem & change management etc.
Then come the external and internal audits, pardon, assessments. Your internal Quality department needs to monitor all engineering activities and report them to the customer, customer's Quality dept. will do their own audits, you and them will also hire an independent company to audit/assess you so that there's no bias.
BUT guess what - almost none of this is required for non mission critical software, so your infotainment is actually the only thing developed in a way you've described it. Brakes, ABS, ESP, Engine ECU or the EV powertrain (BMS, inverter etc.) are all written according to what I described above. There's no need for more bureaucracy, the automotive industry (especially German one) is very good at self-regulating and would make an average web developer throw up on his first day. Failures of the UX/UI in modern vehicles is just a business problem - guys who spent decades building and selling options like leather seats, and checking spreadsheets at the end of a fiscal period are still at the helm or their business processes still live on in those companies.
> the programming profession needs a similar credential
And who will handle the distribution of that credential... The moment it is required to have one, thousands of private universities of questionable quality will be dispensing such credentials just like how they have been dispensing engineering titles. Totally legal. What difference will it make compared to the existing situation...
Or is it so that these credentials should be distributed by a few elite institutions to make it safer.
What difference does this make from the current situation in which top corporations hire top people for top tier work? So everyone will have to hire MIT, Pekin U, Tokyo U or Berlin U graduates?
And what happens when centers like San Francisco suck all of those graduates away from the rest of the market and cram them into the expansive tech business? Leaving the Automotive industry as scarce of such top talent as it is now? Will the auto companies pay more money than Google et al to attract that top talent? Something which they could easily do now, but arent?
...
So basically your proposition will not change anything, but it will just introduce more bureaucracy into software.
Read my comment above. A PE is a license, a credential approved by the state, not a certification given by a company. As with other licenses, it's FAR more comprehensive than just passing a test, and requires working experience. My wife required 2500! hours of work to qualify for taking the second test in her mental health counseling licensing. We're talking about 2 different things.
> A PE is a license, a credential approved by the state, not a certification given by a company
And state, that is behind in everything related to technology, is going to be the arbiter of the 'best practices' in a field that progresses faster than what even the top universities of the world can cope up with...
So basically this would force software into a profession lagging from ~100 years behind like other engineering fields...
The certification exists, at least in Canada. You can be a software PE. It's [snip] generally not required for anything. The other side of it is that some safety critical work does require a PE to sign off on it, and that work may include software, and that PE is going to be held responsible. He may be a EE in his training but he'd be responsible for the software engineers/developers doing the work properly.
> A lot of comments so far are complaining about the software quality in cars now. But what did you expect? This is what happens when you hire the same kinds of people ...
I think the main problem is that there is no competition since you are buying the car not for the software (at least most people don't).
Make car software an open marketplace, and you will see improvements in quality.
> Make car software an open marketplace, and you will see improvements in quality.
For infotainment inside the cockpit sure knock yourself out. But I absolutely do not want to be on the road or at crossing as a pedestrian with cars running modded ABS or ESP units.
I own a 2021 Volvo and the blinkers doesn’t blink regularly. They may blink fine for a awhile but then stops for a period, and then suddenly all missed blinks blinks in a rapid succession. It’s extremely annoying. There are other bugs, like when you are using the auto pilot where it sometimes may suddenly jerk the wheel even though there is nothing wrong with the road. Scares the shit out of you. That has happened thrice now.
Same experience here. The new Volvos are extremely buggy and unsafe to drive.
Even annoying shit like media controls randomly not responding (including not being able to turn off or change volune), autopilot suddenly wanting to commit suicide, autopilot randomly shutting down, random error messages of stuff not working, random messages for things that were unchanged (child lock engaged, even though it was already engaged)
I really like the design choices, and i like the software and audio quality, but once you actually start using the car, it goes downhill fast.
I’m glad I got rid of mine. After 3 horrible Volvos and horrible shit service, i’ll never get another one even though I still think they look great.
Now driving a Mazda CX-5. Absolutely fault-free, no software issues, runs perfectly.
Most if not all development still takes place in Sweden. I think any perceived quality loss is more likely to be because of the increased complexity both in modern cars in general, and because Volvo wants to be more upmarket and premium which leads to more features and therefore bugs. Although I wouldn't consider indicating lights to be a premium feature.
Precisely. It was only after I’d purchased a 2020 Volvo that I realised that they’re trying to compete with the luxury car manufacturers on a fraction of their budget.
It shows.
I have nearly every safety feature turned off in the car because they all generate false positives at an astounding rate.
> I own a 2021 Volvo and the blinkers doesn’t blink regularly.
Same here (V60 2021), it skips a beat from time to time (now happy to know that I don't have problems with my brain nor ears :) ). Luckily so far I didn't have issues with the autopilot but thanks for the heads-up.
On the other hand a few months ago the radio volume got stuck for 15 minutes (couldn't even switch it off) while I was on a pass road with nowhere to stop, luckily it wasn't too loud => this made me think "ok, the media device is not directly a safety-critical subsystem, but what if the volume suddenly goes up to max, and maybe it stays there? Or if the trunk automatically opens? Etc... => tricky to define what is important from a safety perspective in a car...".
Similar experience in a subaru. After fighting the lane keep assist feature a couple of times when it got confused and jerked the wheel all of a sudden, we just turned it off permanently.
It's not a technical problem. We knew this was going to happen if we transform cars into computers. It just take some management change to make your car unsafe or misbehave.
My FIAT Panda from the early 2000s has none of those problems. I need no updates, and every problem it has can be fixed by any car worshop, or even myself.
Relays and basic electronics that don't handle anything important, that's all it has.
It is lightweight (fuel efficient), agile in town and on dirt roads, cheap and easy to maintain.
Lane keeping in my Subaru has been amazing. Better than any non Tesla I’ve tried. But sometimes the PID loop is really nasty and while I want to bias to the left of the lane it keeps fighting me. If I let go it throws me into the next lane. It hasn’t happened ever since I learned how the car reacts to that behaviour.
But it’s still very, very bad and I hope Subaru’s controls engineers are addressing it.
Indeed! For a base model car it’s pretty amazing. Now that I’m aware of this PID problem I just avoid it (but it’s still shamefully bad, Subaru…)
The rest of the features, however, make this the safest car I’ve driven so far. Adaptive cruise control, reverse automatic braking, and collision avoidance will make all cars safer.
I should write about it but the collision avoidance saved me from hitting a cyclist that flew out of a parking lot with a reaction time I wouldn’t be capable of.
I hear you. Every generation of technological evolution has hold-outs who can’t come to “trust” the new thing. I can’t come to trust smart home stuff, for example.
It seems rather derogatory to call people "hold-outs" because we don't trust buggy, novel technology.
On the other hand, we have a term for people who are always installing the latest beta updates and purchasing shiny gadgets: we call them "heatseekers". It's the heatseekers who tend to have unreliable tech and lose control of the gadgets that are supposed to make their quality of life better.
It seems pragmatic and wise to take new technology with a grain of salt. Since I have used computers and other technology for over 40 years, I have developed a good sense for what will be reliable and proven, and what should be avoided until it has been given a chance to mature. Often there are things in the latter category that can be taken up by scammers and hucksters who are eager to make a quick buck.
As always, keep in mind the adage that those who won the Gold Rush were selling the shovels and supplies. I personally enjoy selling shovels.
Yeah, I'm in it with Home Assistant, so at least it's open ish and not on the cloud, but there's still more maintenance than I'd like. Still, motion sensor lights are cool.
Same with Toyota. The LKAS is utter garbage, does not work on normal roads, and I find it distracting/dangerous to use. This is regarding TSS 2.0, I know there's a 2.5 and I think 3.0 just released but I don't believe the overarching issues have been fixed. I tried park assist only once and it hit a curb...
However, the collision avoidance is excellent. It works great, never had unwanted breaking, it assists breaking in emergency, and the rear cross traffic frequently senses incoming cars we can't see.
In older cars things like blinking lights was done with a dedicated circuit. By putting everything in software, we've actually made this class of bug appear more often.
For example, you could have a dedicated "do this thing at this time" processor. It can't be blocked, and if it accepts a job, then it is able to do it on time.
The main processor then tells this processor to do all timed tasks.
I don't imagine any class of bugs will ever completely disappear. Sure, we know how to write software that is extremely unlikely to suffer from certain classes of bugs and we have better tooling for testing, but ultimately it's dependent on humans.
First thing that came into my mind when I read the title, there's a reason why even stuff like infotainment was being done by whatever QNX flavors. If i hit the unlock button, I really don't wanna have to wait because of some IO stuff that's preventing the context switch.
I'm not so sure anyone actually wants fad buzzword salad frameworks du jour driving their multi-decade lifespan appliances - not a ton of upside in your fridge running fullstack cuberentes docker react node restful AI SAAS on bay area RSUs
Ok the RT thing is clearly a joke, but the unit test comment hopefully similar, or was that meant seriously? Likely no, otherwise please url for logging a ticket
I once fixed a bug where the blinkers were drifting on a bus. If you activated the warning blinkers and waited some 15 minutes it looked insane with the lights blinking left then right. Really annoying to watch.
I own 2022 Volvo XC90, bought in May. Not a single issue like that. Is there an update of sorts to the software? I remember when I was taking my car from dealership they did update ‘somthing’. Car is awesome btw.
I’m driving rental MB C-class this week (after 4months of Hyundai Kona EV) and holy smokes it is obnoxious. No bugs per se, but touch-everything is horrible. Tons of warnings, panic breaking, limp mode. Top it with horrible throttle response and this thing reeks of legacy. Sure ride quality and steering is good, but I can see now how people hate touch interfaces.
I had a rental MB a few months ago and while the build quality and ride were excellent, it remains by a very wide margin the absolute worst car I have ever driven. There were dozens of buttons and knobs and touchpads (so many touchpads!) in the cabin, none of them with any meaningful information about how they are used, much less an obvious use. The interior was utterly barren of visual contrast, so I couldn't discern important information even when it wasn't shouldered out of place by the implacable clutter. It was a car for a hoarder with means. I'm also not exaggerating for effect: I hated it, and I was overwhelmed by the sheer amount of stuff I was supposed to operate.
They may blink fine for a awhile but then stops for a period, and then suddenly all missed blinks blinks in a rapid succession.
Clearly, it's a software issue, not a hardware issue. Hard to believe that software is really cheaper than a 555 timer. I wonder why this decision was made.
A modern car has >100 ECUs, blink is distributed to a few ECUs, think: front body, rear body, left door, right door plus instrument cluster and maybe a trailer control ECU. It does not look premium if they do not blink in phase so you send CAN command for blinking. (A separate cable introduce cost, weight and faults due to corrosion that are tricky to diagnose, in total you want to avoid that.)
If something disturb CAN or an ECU reboots you would get the described behavior. But it is not obvious (at least not to me) that it must be a software error - could easily be hardware designed with too small margins.
(I have not worked with this issue at Volvo and do not know the actual cause of the problem.)
Alternatively, you could design the system to fail in a way that was less dangerous.
For example, an ECU that controls blinkers does it with a 555 timer, based on a "start blinking" CAN bus command. It resyncs on each new "start blinking " command. It times out after 50 blinks, if no "stop blinking" command comes.
This makes each ECU autonomous and responsible for doing "the safe thing", once it has been commanded to.
Finding all the new subtle horrible timing problems in this design is left as an exercise for the reader. :)
Because blinkers aren't on a mechanical switch anymore. You have the "lane change mode" where it blinks a few times, they also blink when the alarm goes off it or when hazard lights go on.
3 different controllers or software becomes an easy choice when CAN is already running everywhere
My Ford Mach-E has a bunch of similar timing glitches, including blinkers. Sometimes the touch screen doesn’t detect inputs for a second and then all the touches fires at once.
I tell myself it’s some component busy GCing for a bit :)
People (I assume Ford managers included) underestimate the essential complexity of the systems required to do something as simple as process touches and display a low-latency response to them. Apple makes it look easy.
Given that Rust prevents invalid memory accesses and enables fearless concurrency, this is probably caused by some kind of memory leak or deadlock.
In this case, the older blinks are possibly not deallocated and slow down the processing of newer blinks. Fortunately automotive software has all sorts of watchdogs and at some point the blink watchdog must kick in and it kills the blink manager which is then restarted and it processes the blink queue in quick succession.
People who say "fearless concurrency" have clearly never debugged a bad concurrency problem. Those strike fear into the heart of any honest hacker, and no amount of nagging from the compiler or good marketing can make concurrency fearless.
I understand what the marketing means. But grep your codebase and dependencies for "unsafe"... That should put paid to your fearlessness.
memory safe - correct. But "fearless concurrency" is mostly plain propaganda. Lots of deadlockable code in Rust. You still need to pay close attention to structuring code for concurrency and some libs are deadlock prone in async.
This seems like a real safety flaw. When someone glances over their shoulder before a lane change, they're looking for maybe 0.5s tops, and they'd expect to see at least one blink from a nearby car's blinker if it were about to change lanes. Yes, people shouldn't rely on everyone signaling, but signaling does make the roads safer and therefore a lack of signaling makes them more dangerous.
I drove an XC90 for a few days a couple of years ago — it was by far the nicest car interior I’ve ever been in, and very thoughtful ergonomically in a lot of ways — little things like the side indicators warning lights being big amber triangles in the A-pillars instead of tiny amber spots in the mirrors.
I think it’s more likely the Danish cops got some big fundage.
My dealer just said classics like “we can’t reproduce the issue”, “it’s new software, some bugs still need fixing, we can’t do anything about it”, “weird, we looked at it but couldn’t find anything” and “we changed $something and this should fix $issue” (and it didn’t)
I’ve been at the dealer 6 times in 7 months to fix random shit on a brand new car and they managed to fix only two things: the ticking sun roof, and the charge port not opening. (Which is kinda annoying on an EV).
Some EV fans like to claim EVs are more reliable because they have less moving parts. These people obviously never owned a computer.
For what it's worth, as an auto tech we are limited in what we can do. For a vast majority of car makes, we have no access to anything that happens on the back-end of the control modules. We can look at some data stream on a scan tool, but that is limited at best. There is no debug access or anything of that nature. It's also well outside the skillset of most technicians to delve into software. Also, If you look into the pay plan of most dealer technicians, (flat rate/paid per job) then you understand why we don't want to spend all day looking at your turn signal. We won't get paid for most of the diagnosis time.
Your comment perfectly matches the overal attitude of the dealer, and it really pissed me off.
I bought a 60k eur car in the same building. I do expect you to waste a day finding an issue on a brand new car. If you don’t want to, don’t sell the POS cars.
The exact same thing was happening to a Volvo I've driven around 5 years ago (I have never chosen Volvo again since then because of it). I don't think they're going to help now.
Honeslty I'd rather they just did as minimal programming as possible. Slap an open api on all cars and let carplay/android auto/any other piece of software have access to said api to do as they please.
The longevity of in car software is utterly attrocious. Taking a very basic car like a Toyota Aygo as an example, in 2015 they released their mid-range models with a large touchscreen in the center console, boasting support for connecting your phone and such. In reality it didn't work from day 1. They used Mirrorlink which had already become out of date tech and wasn't supported by any of the handsets anymore.
Now, they could've released a software update to fix this. Except they didnt. They kept selling that car for several years, advertising phone integration that didn't work.
Car manufacturers give absolutely no care at all to their software and never have.
Isn't the car side of CarPlay and AndroidAuto not much more than providing a video player and sending the screen touches back to the phone? I haven’t used either much, but I don’t think it interacts with much more than the touch screen and audio. The in-house code should be minimal.
Currently, yes. But Android Automotive and future CarPlay run on the car‘s hardware and get access to the CAN or an abstraction over the CAN.
Those still supersede only the user-facing code (dashboard, buttons, entertainment), and all the other low level code still needs to be written: engine control unit, ABS/ECS etc, airbags, battery management, indicators, windows, heating, wipers, drive by wire, etc - and let’s not forget all the glue code (essentially an OS of its own) to tie all those components together, OTA orchestration, etc.
Car metrics are not “can data”. Even if they arrive over CAN at some point. You are so far removed from “CAN” at that point it isn’t worth mentioning and misleading to do so.
I saw a lot of fairly unstructured C in embedded programming - copied source / header files, hacked together Makefiles, lots of "works on my machine". Almost no abstraction to prevent use-after-free (mostly rigorous code review).
I always saw that the problem it would solve is more about tooling - Rust would be a fairly good fit because it has a good cross-compilation story, and the tooling around e.g. cargo and running builds is quite good (in my opinion). The blocker right now is absolutely vendor support; no reasonable hardware company can afford to hack their own HAL without vendor support (and in fact they pay a lot for support right now, and use it).
I think what these companies usually miss (good for Volvo) is that iteration time in a "higher-level language" like Rust can actually be much faster than in something like C. The setup time for a dev environment in embedded can be a week (making sure exact version match between compilers, checking out files, compiling, resolving build failures). On top of that, just having access to a language with strings and algebraic types is huge.
I think there's maybe room for a Rust consultancy that could take one of the existing large manufacturers, build a toolchain around it (possibly with their blessing / support). Ferrous Systems does this (I hope there is as much demand as I am imagining).
“Please don't post insinuations about astroturfing, shilling, bots, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.” https://news.ycombinator.com/newsguidelines.html
I was just thinking about how if Rust were a community driven project the top comments on any HN post would be about how "it's terrible marketing for your language meant for industrial applications to be called rust" and "OSS needs to get its shit together."
I remember proposing looking into introducing Rust as a second language next to C++ just 3 years ago while working with a German car manufacturer in Berlin, every single architect refused and most of them were making fun of me, anyway I'm not bitter ...
Actually back then it was the beginning of me stopping carrying about improving and just go with the flow like a dead fish. Everyone is happier, I have much less clashes with coworkers much less stress and you know what they say: Nobody got ever fired for choosing IBM.
I think this is the main reason for the state of software quality in cars now. People who care can't stand the industry and leave, if you want to stay you have to stop carrying.
Oh, when you really think so, I think you are wrong. I'm working now for several years in software for the german car industry. There are many people that try to improving everything in the workflow. But they don't want to add more complexity with a language that is in heavy development, changing fast, is not certified and can read only from a small piece of developers in the field only for a new hype. The real problem with the software quality is, that everytime when anything works it is tried to make it cheaper and outsource anything whats possible until all breaks and the people that had any idea how it worked changed to another company.
It sounds like you didn't read the article. The problem is that despite good software practice, esoteric memory bugs are still an issue. If switching to Rust eliminates an entire class of bugs, the choice is obvious especially if you already have a competent development team.
I know how you feel. There are definitely workplaces that attract naysayers and eventually the whole culture becomes one of naysaying. It becomes self-reinforcing because anyone that actually wants to improve things is in the minority, gets shut down by their coworkers and eventually gets frustrated and leaves.
You can't really do anything about it. In my experience that kind of culture comes from the top and at least where I am those people are part of the problem. Look for another job.
I know Rust has many goals on paper that align with this decision, however, what large codebases in the field of high-integrity software are written in Rust? Does Rust comply with high-integrity software standards (CENELEC EN 50128, DO-178C,DEFSTAN 00-56, or IEC 61508) in any capacity?
SPARK2014 has been around much longer, does comply with those standards, is a formally defined PL with a great set of verification tools specifically designed for high-integrity software. There are large codebases (software for the safe operation of helicopters at sea (27k LOC of SPARK2014); NATS iFACTS air traffic control system (>529K LOC of SPARK2014).
I am glad that AdaCore is teaming up with Ferrous Systems to help bring some of Ada and SPARK's goodies to Rust, but it's nowhere near them at this point. This seems more a Rust champion at Volvo convinced their group to use it.
>>>JG: Then I pitched to the managers, “If we want to do a serious Rust effort within the company, then I want to take part in that and become an employee”, since I was a consultant at that point.
The availability of programmers in either Rust or SPARK2014 shouldn't be a heavily weighted factor, since anyone working in SPARK2014 probably already has the relevant experience no matter how few apply, whereas the dozens or more of Rust programmers who might like working at Volvo would be cutting their teeth trying to build 1/20 of what Ada/SPARK2014 already have, and possibly deliver far less.
Rust is to C++ as SPARK2014 is to Rust at this point in my opinion, but current popularity wins out a lot in all human endeavors. I'll stick with SPARK2014 and Zig for now until Rust catches up SPARK2014.
I love Volvo cars. I hope they have enough investment in support and engineering, because Rust isn't an easy language to pick up. I wouldn't want to escalate minor software problems through the management that needs engineering team's response and I'm waiting because there is not enough people to support across continents.
I welcome new Rust jobs, I myself have attempted to learn (and fail). But having it in a customer facing and a software embedded in customer's car is not what I expected.
Maybe starting in a backend service that they can monitor and deploy changes in events of outage would be an easy start. For something a scale of customer owned cars, I hope they are prepared.
If you pick a new tech that is interesting to potential employees, it can really help hiring. You can get a lot of experienced applicants wanting to sink their teeth into the new tech. Lots of places found this when they went with Go. Unless you need to produce vast amounts of mediocre code, you generally want to hire the people interested and able to pick up a language even though it isn't easy.
I'm an automotive technician, I have worked for an EV startup. Some of the most frustrating diagnoses I have been involved in were caused by bugs in the software. We had one where a power trunk would not release if the vehicle was out in the sun. The ambient light sensor and the power trunk actuator were not even on the same network bus. We had a gut feeling that it was software, but by the time we were sure, it had been 2 full days of extensive testing.
I do not see any indication in the article that Rust is used in safety critical components:
"And it happened to run on the architecture that was best supported in the embedded bare metal space of Rust at the time. It was also not safety critical component, so we did not have to worry about safety certifications."
I find the article very low on actual information. I don't think Rust will be used in an ABS soon. The Android/Elixir/Rust examples in the article are for the useless gadgets that no one wants.
The article says that they need approval to use Rust in safety critical components and you get approval by showing Rust is working in other places. They say in the article that one of the reasons they chose Rust was for it's safety-first approach which matches well with Volvo's ideology.
> I thought this would be useful for Volvo Cars because it embodies the same type of Ideology that you want when you’re developing safety-critical software.
So I think "Makes sense that one of the most safety focused manufacturers would go for it." is accurate.
Im actually a bit suprised. Getting anything but MISRA C/C++ certified is usually a no-go, but maybe and finally this is an alternative to fucking MISRA.
Certification is already in the works afaik. This [0] is also interesting, a check how much MISRA checking can be removed because the rust compiler already does a similar check.
For ECUs running the car it's MISRA still, Rust is in the pipeline, but still far far away. 5-10 years before it becomes common. Standard is being worked on, but compilers and other tools will take a lot more time. These are generally not your of the shelf MCUs, and for many compilers are quite tailored.
But for anything regarding networking and UX (screens), a lot of languages and frameworks are being used right now.
Also, if you hate MISRA subset of C so much, you probably won't like Rust, since both impose some similar rules.
I don't know much about Rust but the problem with MISRA is significant defects with the specification that force you to write bad/broken code in rare cases, and produce more work without benefit in others. A Rust MISRA standard would be great. Limited but more expressive and concise than C probably.
There is also AUTOSAR, which focused initially in C++14, got recently updated to C++17, and now is collaborating with Ferrocene regarding having Rust as well.
Rust essentially puts some parts of MISRA into the type checker (e.g. no pointer arithmetic). Why is MISRA bad?
I expect something like MISRA for Rust as well. There will probably be rules like "keyword unsafe forbidden". If you really need it, try writing a deviation record. The advantage is that Rust should require fewer rules.
I've seen code that solves it using a `retval` variable, a typical case of code that is written to avoid breaking MISRA rules instead reimplementing the problem that the MISRA rule tries to avoid except with less idiomatic code and more bugs.
I do web backend stuff. A coworker of mine writes Go according to MISRA C style and this is the main thing that's always annoyed me: it seems like half the codebase is comments justifying deviations, like explicitly commenting when we are using the `if err != nil...` idiom to note any deferred cleanup that takes place and justify why it's safe to early return.
To be fair this matches up well with Rust's general error management style. Everything seems to add another level of nesting, and often adding another function isn't worth the pain of the borrow checker for local vars.
Frankly it makes code worse a lot of the time, that's been my experience anyway. It's probably necessary if you adhere to not using goto and need cleanup code in a function, but otherwise I've seen code trying to adhere to one exit point create bugs. Linux coding standards are the pragmatic choice, use cleanup goto's. They're idiomatic, clear, safe, easy when done right.
Hmmm, I work providing the toolchains for a popular embedded realtime OS used in many safety-critical applications including auto and I have seen a rise in demand for Ada. Not ADA of course, which is an American law and does not apply to most international manufacturers.
I've also had queries about Rust, but it's not going to be available in safety-critical systems for many years. Part of the safety argument is toolchain adherence to a published standard, and there is no such thing for the Rusts (any version). In the in-dash infotainment systems anything goes, so they often run Linux (unsafe) and Python (unsafe) or even Perl (unsafe).
for FOSS the reference implementation is co-created by the consumers of the software. the users will only accept a new release if it fits their functional needs and passes their verifications.
the Linux kernel, the toolchain, or libraries like ssl libs are co created by the very organisations that consume the software. FB, Google, Amazon, Microsoft, IBM with red hat, Suse, Oracle, SAP they all concrete the Linux kernel, and for each kernel release they validate, each of them, the technology.
that's how the reference implementation _is_ the standard.
same goes for rust, which brilliantly leverages build automation of the cargo package repository to protect the compiler and toolchain from regressions:
I think that's a good indication that the reason Rust has become relatively popular is more likely to be its status as the new cool thing rather than anyone actually caring about safety and correctness.
It’s relevant in terms of there being a skilled developer pool to hire from. There are exceptions, but the vast majority of software technologies that have been success have done so by being accessible to hobbiests to install locally, even if that’s not their primary use case.
The good news about professional programmers is that they're capable of learning. Ada is not a hard language to learn, if you have some familiarity with procedural programming (which 99.99% of programmers do). Considering the amount of time spent on safety-critical systems, there's enough time to train up a new hire that only knows one language on Ada, assuming they're actually a competent programmer.
They spent trillions of dollars in the project including millions of dollars of rework.
I would rather feed students in school quality food, give them school supplies, and take care of their needs, rather than wasting valuable resources fixing avoidable defects.
Rust doesn’t play well with QT. GTK is commonly used, as is electron, or Tauri which is also web based. Rust doesn’t really have a good native GUI story yet.
What's up with all these "X uses Rust!" articles recently? Is it that surprising that a memory-safe, low level language with a large community is actually getting used in production?
I have never done any Rust, but I love Volvo (I have driven 3 different Volvos) and I'd buy them without trying them (done it twice) if you want a car that is consistent and user-friendly, this is the one to go for.
Just a few warnings. Everybody when they start are “fighting with the borrow checker”. And some people are frustrated by it. But you have to see that it is a good thing. Because Rust is warning you about a whole type of bug that your old way of doing things were actually creating this kind of bug. And now rust can catch them! It’s like a guy the frustration of someone coming from a dynamic language to a typed language and being frustrated because he has a type number but now he wants it to be a string. Sure you can do that in a dynamic language but it can created all kind of bug.
And another point. Remember what the language is made for and also not made for. Yes you are going to be faster in X language for different things. But for what Rust is good at, the power it gives you, the dev experience, and the performance are amazing.
I usually would grab Typescript first for the back and then reach to Rust where speed and security safety is critical. And it’s so good to code in it.
> Rust is telling that your old way of doing things were actually creating a whole kind of bug that now rust can catch!
As an experienced C programmer learning Rust, my frustration is less "oh it prevented a bug I would have made" and more "no but its fine in this context leave me alone" :-)
Unfortunately, "it is fine in this context leave me alone" is often incorrect now or at the very least will be incorrect in the future when some other change breaks invariants that you are using to justify its correctness today. This is not always the case, but we observe very clearly that even C++ programmers using modern smart-pointer style fuck up object ownership and lifetimes.
Although I think much of this is technically true, I think this is wrong way to "sell" Rust to C programmers. A far better approach is to say "Rust is a completely different paradigm that you may have to learn," because when you start to use closures, iterators, etc., it definitely is. It's not C. It's OCaml is C's clothing. It will allow you to beat it into submission, but if you have to beat it there is probably a better way.
There is this belief "I know C so I know what's fast here", and, while that's sometimes true, I think it's wrong often enough re: Rust to try doing things a different way at a relatively high level. I think when you're starting off with Rust your goal should be to implement virtually everything in the dumbest/most obvious/Python-ic way possible, and then to experiment with optimization/rewrites. And while you should try the thing "You know to be fast because you know C" you should also spend that time reading how the std lib implemented a feature and leaning on the std lib, benchmarking as you go. One reason is because the paradigm is obviously different. Another is because the std lib has lots of features for common uses which are optimized very carefully, which C just doesn't have, and one shouldn't ignore/forget that.
Sure. IMO, Rust should be sold to CTOs and regulators. The fact that our industry doesn't seem to be taking memory safety seriously for applications that operate on untrusted data is frankly an embarrassment. I don't doubt that people will want to keep using the thing they are used to a like. I'm saying that we need a plan to solve memory safety as an industry.
> Unfortunately, "it is fine in this context leave me alone" is often incorrect
That's a very overused argument and IMHO wrong way to sell Rust.
The reality is, even if 100% of C bugs were memory safety related, that still does not mean every C program is riddled with bugs. If that were the case, nobody would write C programs in the first place.
There is a strong selection bias in play here. You only see times where memory safety caused an issue because you get a segfault/overflow/etc but just have invisible correct behavior at all other places.
Maybe I was lucky with the people and companies I worked at, but memory safety overall has never been a big issue with our C softwares. Sure it happens from time to time, but it's definitely not any kind of plague.
Still I'm learning Rust, so why?
For me, it has to do with the library ecosystem. It's very hard to find good quality, easily pluggable, performant C libraries. You always end up having to re implement half of the data structures you need, or use sub par configuration formats just because you don't have readily available libraries.
I think this is a much more compelling, and frankly true, argument for C programmers to use Rust.
Every C program of meaningful complexity that operates on user data is riddled with bugs.
Go look at the linux kernel. Arguably the most important C program on the planet. Absolutely enormous incentive to get it correct. It is... full of bugs. Including a large number of memory safety bugs.
Or you know, sometimes the tooling just simply is inflexible and can't figure out what is it the code is trying to do. There's a reason why parsin code is a NP-complete problem.
So tell them off and carry on? Why would you care about their opinion?
Writing low-level systems code often that involves pointer arithmetic or type punning. The whole point of Rust is to be able to write such code with the iffy parts clearly delimited.
One of the things that set off the whole actix debacle was a PR removing unsafe code with the equivalent safe code was rejected, even as it was shown to cause unsoundness reachable by safe code using the framework.
You’d think so, and yet when I test drove a Volvo the A/C controls were only accessible via touchscreen.
Not separate physical controls. No voice commands. Only the ability to tap on the touchscreen at least three times to change the A/C. It was a real bummer and soured me on the brand. It’s hard to believe they are safety focused with design decisions like that.
No idea why your comment is downvoted. By buying Volvo products you are supporting a hostile power, China. A country that does not even allow our companies to operate in China without nonsense restrictions like joint ventures with local companies that strip our companies out of IP and know how.
Due to the recent events in Ukraine and Russia things like this should be really talked about.
I believe China recently removed the joint-venture requirement. It's either a sign that China's maturing and slowing economy is no longer so attractive that they can impose such an onerous requirement, or that China thinks it's already gotten everything out of Western companies and now is at technological parity. Or maybe both.
I love how people keep complaining about China, while buying "Made In China" products every single day, somehow buying habits and morals don't get in sync.
I accept the downvotes, I don't say Volvo cars are not "good", "fun" or whatabout. Not my point. I do not want to interfere with anyone having fun with Volvo cars.
It's fitting as Rust is the Volvo of programming languages (and I mean that in a positive way, much as Volvo characterised itself in its successful "Bloody Volvo Driver" advertising campaign).
Even just the Ada ability to define integer and other ranges always seemed great! Rust doesn't provide integer overflow checking on release builds unless you use specialized methods.
I think creating new number types like "Positive" also seems to require using unsafe, or at least the stdlib used it for a few of the number types I looked into.
I am truly astounded by the hatred exhibited in some of the comments in this thread. Wow.
A few points:
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't know what you are talking about. It'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.
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'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's I2C, SPI or CANbus in between, but what you have todo is the same.
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.
Professional certifications. This isn'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.
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'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.
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.
This isn'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'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).
Anyhow. Don't be language cultists. That isn't the problem. Bad programmers and bad process is far more of an issue. Changing languages isn't going to magically fix that. It isn'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.
Counterpoint is that C and C++ are increasingly removed from what the hardware is actually doing and are now more of an emulation language mired in legacy thinking rooted in 1970s era memory and processing models.
Modern languages are trying to introduce constructs to make safer, more performant software on average, lessening the tendency of hardware chip makers having to hack their way into performant execution of C/C++.
This is not to say C/C++ can’t make good software, it’s that we limit ourselves by clinging to them, and would be far better off with gradual adoption of modern low level languages, just as we shed Assembler for C over time.
Therefore, there are ways to write bad code. Do you think it's reasonable there may be better tools that prevent writing some cases of bad code?
I mean, I think we all can agree that, in general, a codebase with significant test coverage hass less bugs than a similar codebase without test coverage. So, I don't think it's crazy to require, potentially via a tool, some degree of test coverage. Yes, some people will cheat by constructing some bad tests, but, in general, I think we should expect some level of quality improvement.
Rust adds another tool that, on average, should improve quality.
Again, this is not a solution. This is not a silver bullet. Neither is depending on the programmer to write correct code.
> Therefore, there are ways to write bad code. Do you think it's reasonable there may be better tools that prevent writing some cases of bad code?
Bad code is written every day in every language. The root causes for bad code do not include the chosen programming language. If language was a root cause, every codebase using language <x> would have problem. Clearly that isn't an issue.
Why do we write bad code then?
- Unintended errors
- Bad design
- Not understanding the problem being solved
- Not understanding the constraints
- Not understanding the hardware/environment
- Lack of skill
- Lack of knowledge
- Limited experience with the tools, frameworks, libraries, domain, etc.
- No understanding of lower-level concepts
- Lack of education (formal or self-taught, does not matter)
- Not having a full grasp of fundamentals
- Not being thorough or detail-oriented
- Etc.
There are a lot of reasons for which bad code is written. Language choice isn't one of them. It's an excuse. If baseline languages like C and C++ were so impossible to use properly Linux would be an unmitigated disaster. It is not.
In the end, the language isn't the problem, at all, it's bad software developers.
Don't take my word for it, Linus Torvalds [0] has been quite vocal about this very issue. In fact, he recoils at C++. And, frankly, having seen what comes out of, as he put it, substandard programmers, I could not agree more. I believe part of the problem is how we've been teaching programming. The first thing anyone coming out of school reaches for are complex class hierarchies, complex data types and layers of unnecessary crud.
I remember a project a long time ago that used Objective-C to implemente a genetic solver. It was unusable due to just how slow it was. I re-coded it in C. It ran about 400 times faster on the same iPhone hardware. The first was the result of lazy uninformed programming. The new version was simple, to the point, performant and had no bugs. Not to mention it used massively less memory.
Here's something everyone needs to internalize: The processor --the hardware executing the code-- has no concept of object-oriented anything. No polymorphism, inheritance, complex data types, etc. When all the smoke and bullshit clears out, all it knows is a set of very simple and efficient operations we can weave together to do useful things. That's it.
All the abstractions provided by languages are for the benefit of the programmer and have nothing whatsoever to do with code quality, correctness, bug content or suitability for a purpose. Which means most, if not all of that, isn't necessary.
Modern programmers probably have no clue about the range an scale of projects that were completed without any issues while not having access to things like TDD, objects, massive libraries, complex data types, decorators, etc. I mean, we have written operating systems, sent people to the moon, saved lives with medical equipment, developed consumer and industrial products and more. Funny how all of that was possible and people today go on about needing to use a better language.
In my opinion, there's only one area that can justify a new language. Everything else is well covered with C and, if one must C++. That is, AI. And no modern language fits the bill yet.
It is hard to define what an AI-first language might look like. Being that I used APL professionally for nearly a decade, I happen to think that a language based on a notation developed for AI might be the best idea. The reasons are similar to the reasons for which musical and mathematical notation allow for rich expression of ideas. In other words, the justification isn't "I need it to write better code", but rather that, as the field advances, we might very well need better ways to describe what we want the computer to do.
> Bad code is written every day in every language. The root causes for bad code do not include the chosen programming language. If language was a root cause, every codebase using language <x> would have problem. Clearly that isn't an issue.
Every programming language has its own style of bad code. Java has enterprise OO overengineering. Haskell has monad obsession. C++ has enterprise OO template shenanigans. C has pointer crazyness.
You should pick the programming language thinking on minimizing issues for the task at hand. That means C is good for the stuff for which is good (obviously) but not for everything but AI.
Yes, C can cover everything. Now go write a web frontend in C, and you will see that, even though you somewhat can, it is a huge pain.
And don't mistake me: I agree with you on OO huge frameworks being terrible, but I disagree with you at C being the pinnacle of programming for everything but AI.
BTW: the Rust borrow checker just ensures that you have properly made your mind about what pieces of code own what data (and by owning, I mean who has the responsibility on writing and calling free on it). I think a piece of software ensuring that is a fair improvement. Worst case, the good programmers will just explain ot to the compiler via type annotations and just continue with their lifes. But they were going to do that already, wouldn't they?
Por of this is what I would describe as a self-fulfilling prophecy effect. C is hard. You can't use it without thought or you'll create code that is excellent at crashing entire systems. Given that current CS instruction graduates "OO-first" high-level-of-abstraction developers, it is only natural that the tools and frameworks they create start at that level, rather than a lower level that requires more work, design and planning.
One of my professors used to pound this idea that you should not write one line of code until you have devoted enough time to structural design and, more importantly, data representation. Of course, I am going back to a time when none of the modern languages existed. My choices at the time were assembler, Forth, C or APL. I won't even mention COBOL or FORTRAN as they were never part of my reality.
Today people think nothing of having functions create and pass entire objects, dictionaries and other complex data structures that consume memory, time and energy (in very real terms, Python requires nearly 80 times more energy to do the same thing when compared to C).
As this "contagion" doesn't seem to have an end in sight, CS reality today and in the future will move away from fast, space, time and energy efficient languages like C.
The energy component is something I have been more aware of over time as we start to become more concerned with carbon neutrality and related issues of climate change. While Python is great for what I am going to call "lazy" programming (you don't have to give it any of the thought required in C or C++) it is objectively terrible in terms of execution time, memory footprint and energy consumption. Do we want a world dominated by Python applications? At a large scale you would need more computers --lots more-- energy and resources to do the same things that could be done with more efficient options.
How many CS graduates come out of school with almost a Python-first education? Not to go too far, my own son, MS CS, spent nearly no time at all with assembler, Forth, C and C++ in school. It was crap like Java and utility like Python. Everything is worth learning, of course, but, give me a break. Thankfully he chose to listen to me and invested time and effort getting good at low-level programming. His first job out of school working for a very good company was C/C++ centric and he did great. Most of his school friends could not have landed that job.
To be clear. I am not opposed to reaching for a variety of languages. I have. I still do. What I do not do is blame a language for problems of design, logic and engineering I create. The language isn't the problem. It never is. I am the problem.
To beat it to death: It's like blaming a welding machine for making bad welds. So long as you don't have a truly horrible machine, someone with proper welding skills can make good welds.
I learned this one the hard way actually. I have a Miller 130XP MIG welder. It's a very basic entry-level 120 VAC MIG welder. I could not make a good weld to save my life. Believe me, I tried. I watched videos, practiced, even got some instruction. I sucked.
When I built my solar array I had to weld a number of custom brackets for the ground mount structure. Not trusting my capabilities I asked a professional welder I knew to do the welding. When he came over he saw my 130XP there and say "I'll just use your machine". He had monster machines in his truck. He proceeded to make stunningly good welds with a machine I was convinced was total crap. I could not believe my eyes.
I eventually took college-level classes on welding and got massively better. I can make good welds with that little machine now, because I know what I am doing. And, yes, I later bought a more efficient modern inverter-based ESAB machine. The new machine wasn't going to make me a good welder. Blaming the machine was the wrong mental framework.
> I remember a project a long time ago that used Objective-C to implemente a genetic solver. It was unusable due to just how slow it was. I re-coded it in C.
Quick question. Why would you do such a thing? How can you square this with your claim that switching languages is never the answer?
I agree with you that a good development process is essential. The thing is, some languages make for a worse development process, because they inhibit automation of important steps in code review. I expect you wouldn't trust the weaker type systems of Forth or BLISS, or the unstructured control flow of COBOL, for a job where you could use C instead. If there are analysis phases that C can automate and these other languages can't, isn't it obvious (given only a moment's thought) that there could be other languages that improve on C?
Because that was the only way to write iOS apps. It sucks. It's unnecessary. And yet you could not avoid it for a good portion of an iOS app.
> you wouldn't trust the weaker type systems of Forth
I used Forth professionally for many years. I can't think of a single end-product issue caused by Forth. The range of applications I wrote went from device drivers and low level robotics code to full console-based applications, like specialized text editors.
> isn't it obvious (given only a moment's thought) that there could be other languages that improve on C
At the core, as I said before, these things only exist for the benefit of the programmer and generally don't exist in what I am going to call the real world inside the processor.
Here's an example: A bytes() object in Python and MicroPython is not mutable. It also happens to be one of the lightest data structures you can use if doing communications work. In a recent MicroPython project we needed to manipulate the data in bytes() objects without causing reallocation of new objects. I wrote a set of routines in ARM assembler to do this just. For example, take a bytes() buffer, calculate a CRC-16 of the data, add it to the end and modify values in the front based on this CRC calculation.
In other words: There is no such thing as a non-mutable data type.
I think the simplest way I can put this is:
Bad code is the result of bad programming, not a consequence of the chosen language.
I should make it clear that I don't have a problem using any language (I have, many) or someone choosing to use whatever they like. My argument is that this idea of blaming solid, reliable, battle-tested languages like C for problems that are, in reality, the consequence of bad programming is dishonest.
> Bad code is the result of bad programming, not a consequence of the chosen language.
You've repeated this many times now. What I haven't seen you talk about is how to fix all this programmer badness. Do you think bad programmers should all be fired and blacklisted from the whole industry? Who will replace them? How do we make sure their replacements aren't just as bad as the ones who were fired? How do we even identify the bad ones before they write bad code? What if they want to become better programmers instead of getting fired? How do they figure out whether they're sufficiently good?
The value proposition of a new language is not measured strictly by how fast it lets you write new code. It also needs to be a medium for communication between programmers. Communicating the intent behind your code helps identify the ways it could be improved. If your intent can be codified in a way that even the computer can understand, that process speeds up dramatically.
Proponents of new languages are winning the debate over how to fix systemic problems in the software industry. The reason they are winning is because their opponents in this debate do not have a coherent solution. If you can suggest one, maybe you'll change everything.
> What I haven't seen you talk about is how to fix all this programmer badness.
Well, that wasn't part of the conversation until now.
In a sense, I have hinted at this. There are two elements, education and experience.
I firmly believe good programmers come from having a solid foundation built on low level code. That means a good progression might be assembler, Forth and then C. If I ask someone to explain how a list is stored and manipulated in memory in a language like Python, I expect at least a plausible explanation rather than a shrug. For me it doesn't even have to be be absolutely correct to show me they have gotten their hands dirty with low level code.
Forth is interesting not only because of the RPN paradigm; one can learn a lot from implementing it from scratch on any microprocessor. From there you go on to actually turning that into a useful console-based computer. For example, implement all the peripheral drivers, a file system, file manager, text/code editor, etc. I would not have anyone touch C until they have completed the prior work.
There's a reason for which companies like Google have seemingly crazy hiring processes for software developers: Our schools seem to be doing a crap job of training them. If that were not the case, there would be no need for such tests. A degree with a decent GPA would be enough.
> Do you think bad programmers should all be fired and blacklisted from the whole industry?
I am assuming that's not a serious question. There are bad doctors, attorneys, cops, teachers and carpenters. There is no such thing as equality of outcomes in anything. Hopefully the natural process in each domain expunges incompetence over time. That's the best we can hope for. Other than that, I can't tell you what we should do.
I have to go back to my premise (flipping it around a bit): A different programming language isn't going to magically turn a bad programmer into a good one; much like a $4000 computerized welder wasn't going to make me a better welder.
At the extremes, if someone doesn't know how to solve problems computationally, there's no language you can throw at them that will turn them into CS problem solvers.
> Proponents of new languages are winning the debate over how to fix systemic problems in the software industry. The reason they are winning is because their opponents in this debate do not have a coherent solution. If you can suggest one, maybe you'll change everything.
No. That's not correct. The reasons we keep taking crazy rides up and down a bunch of languages is that developers are coming out of schools with skills that require them to start at that level. As I said in another comment, the first thing every recent grad reaches for is a complex object structure. Because that's all the know. They don't actually know we were doing things like sending people to the moon without any of that stuff. They think it's necessary. And so, they develop tools and frameworks "in their image", if you will. Which means that the entire thing is a self-fulfilling prophecy.
I remember one of the most impactful examples my son (a recent MS CS grad) experienced while working with me on a project. He needed a serial communications library for a robotics system we were building. He reached for a library and used it. The thing did not perform well and was giving us problems. That's when I became involved. The library consisted of, I don't know, two to four pages of classes, methods, etc. After understanding what it was doing I re-wrote what we needed in something like ten lines of procedural code.
The unnecessary bloat in various programming languages ecosystems is something that should make anyone take pause. I mean, you see things like someone creating an entire object hierarchy with methods and properties for what amounts to managing a few thousand bytes of data in an array in memory. Instead of a raw close-to-the-machine for loop iterating through the data you end-up with a dozen objects instantiated, copious properties, layers of methods and...well, you get the point (I hope).
> Well, that wasn't part of the conversation until now.
Sure it was. You kept saying "this isn't a solution." All I did was point out the converse.
I experienced the kind of "modern" CS education that you consider a failure, and believe it or not, I have about as much scorn for it as you do. I did get some good exposure to serious analysis and low-level programming, but the other half of what I learned was pretty much a waste and I had to unlearn it the hard way after leaving school. So, I'm not here to defend the Java idiom of mile-high towers of superclasses, runtime polymorphism that nobody will ever need, or wild pointer goose chases that accomplish nothing but stalling the pipeline. All that stuff is a waste of everyone's time. I like my compiled code to stay lightweight and close to the metal.
I am here to defend expressive type systems that permit detailed annotations of what should or shouldn't be done with a particular piece of data. I shouldn't have to rely on comments alone to say "the pointer returned by this function must be freed by the caller" or "the pointer returned by this function must NEVER be freed by the caller." I want the compiler to understand me when I say these things, and I want it to enforce my rules.
C doesn't have that, obviously, but I'm sure you already know that it was a huge change from its immediate predecessors, which didn't have types. Even early C didn't have structs. It added these features because they made programming less error-prone. Nobody wanted to manually calculate field offsets and risk getting it wrong.
That was 50 years ago. There have been missteps since then (I think every PL theorist counts OOP among these) but that doesn't mean C has to be the absolute last systems language ever in the history of computing.
It isn't a failure. It simply isn't optimal. Just my opinion, of course. Which means I could be very wrong.
> "the pointer returned by this function must be freed by the caller" or "the pointer returned by this function must NEVER be freed by the caller."
Those two are examples of bad programming. Both constraints are almost guaranteed to create, at a minimum, an unmanageable mess and, at worst, very dangerous software (think embedded controller for a robot or a rocket).
While I have not looked, I would be very surprised if something like that existed in the Linux codebase, which is C.
> that doesn't mean C has to be the absolute last systems language ever in the history of computing.
I don't think I have suggested this at all in this conversation.
My position is very simple: Don't blame the language for bad programming. This is rarely the problem.
The fact that someone can cause a mess using pointers does not mean pointers are the problem. They simply don't know what they are doing. The Linux codebase uses pointers everywhere, right? Is it a mess? No. Maybe that's because they are using the language correctly.
I am also not saying that all work in evolving programming languages should stop because C is perfect. Not the case I have made at all. What I will say is that --again, my opinion-- quite a few of the modern paradigms are complete nonsense in support of lazy programmers.
The question to ask might be something like:
Would you have been able to create the software without bugs using C?
If the answer is "yes", then it is likely the newfangled language was not needed or justified.
As an observation, pretty much all of these languages look like C. Outside of assembler, the only three languages I have used in my career that explored other paradigms were Forth, LISP and APL. I used these languages professionally for about 10 years. Not one of the modern languages people rave about have done anything to truly push the mark forward. In many ways APL was, in my opinion, the pinnacle. It' problem was that it surfaced way ahead of hardware being able to embrace it. For example, this code would take half a page of crud to create with any of the C-derivative modern languages:
+/⍉10 10 ⍴ ⍳100
And we were able to do this FORTY years ago.
What does it do?
This creates a vector of 100 consecutive numbers, 1 to 100.
Of course, this is a super-simple example of something that isn't necessarily ground-breaking on first inspection. Anyone should be able to reproduce this result with reasonable efficiency using C or derivatives. Not one line, but, who cares, that's not the important metric.
One of the most interesting demonstration of APL for those who have never seen it in action is this implementation of Conway's Game of Life in APL. Very much worth watching:
Once you internalize APL (which does not happen through casual use) it changes the way you think about how to solve problems computationally. You, quite literally, think at an entirely different level. Your brain visualizes data structures and implementation in a very different form. The closest equivalent I can reach for is using musical notation to describe music; which, of course, requires someone to have internalized the connection between notation and music.
This is where I was going when I said that we likely need a better programming paradigm for AI. That, in my opinion, can easily justify a new language. And, yes, I am biased --ten years of APL use will do that to you-- I think it has to be symbolic. Quite literally, a new language --just like musical notation is a language for music.
Going back to my core premise and the title of this thread: Throwing Rust at software development isn't going to fix bad programming. I don't see the point. And, yes, I could be wrong. If all hope of having capable programmers is gone, then, yes, of course, we need to make sure they don't make a mess just 'cause they have no clue.
Just like health checks and business clearance certifications don't avoid nasty food joints to open doors, or folks selling stuff on the sidewalks, yet they eventually get closed down.
Not sure I know what that means. To clarify, the cultist behavior comes in when there are tools that are perfectly fine and people insist on using something else.
> i want modern, secure languages with good paradigms and good package managers which have nice syntactic sugars and actual string types, memory checking and garbage collection.
Sorry, you lost me at garbage collection. Nobody I know who does serious real time embedded wants to touch garbage collection with a ten foot pole.
Everything you mentioned above is for the benefit of the developer. None of these things are necessary to build good software, at all.
The proof is in history. Not to go too far, Linux: C.
BTW, that's not to say we don't use other languages here. I have personally worked with everything from multiple assembly languages through Forth, C, C++, Visual Basic, LISP, APL, JS, Objective-C, PHP, Python, MicroPython and who knows what else. We just haven't turned any of the above into a religious belief.
In that context, with that level of experience, from consumer to aerospace, time and time again I find myself making the same observation about C and C++ being more than adequate for just-about everything. We are reinventing the wheel to allow for less capable, less knowledgeable software developers (or both).
Polestar is a Volvo subsidiary that does electrical vehicles that overlap a lot with Volvo's own EVs. Polestar 2 is their main model and its specs are nice, pretty much the second best after Tesla.
However what PS2 is also known for is an absolute shite quality of their firmware.
Cars refusing to start and requiring a "service" out of blue (with one lucky guy scoring this in the middle of a forest). Chargers not engaging or, better yet, not disengaging. Basic functions, like blinkers and car locks, breaking after an update. Updates, in general, are more of "oh, fuck, not again" events rather than the positive news.
Like, I understand it's a complex software. I had a Bimmer show at "-10 km to destination", an Audi refusing to open a truck if parked too close to the wall, but the amount of bugs in Polestar is insane over the baseline.
Volvo used to have a lot more control over their firmware than any other auto manufacturer that I knew of. Firmware images were counted as spare parts, and were charged for and managed by the official dealer service network.
They had a central database that kept track of the revision state of every car, including what firmware revision was installed in each ECU. Volvo owners tended to keep using official service centres longer than those of other brands, so this database was usually correct.
Not sure where I heard the story, but I’m a longtime Turbo Brick fan and actually had a Bosch ECU custom programmed in Sweden by an employee who did it quietly on the side. Went from 222hp to 285hp - would’ve been more but the AW small auto transmission would eat itself.
After Ford bought Volvo, they expected compliance and sent instructions and materials for the next infotainment system to be used in Volvo cars. A Ford product. Equipment, interface, code platform all sent from corporate out to Gothenburg and that was that. So Ford thought.
When they visited Sweden to check on the progress of the new model. When they saw the infotainment system it was nothing like what Ford had sent with the mandate to use it. Of course they questioned Volvo and I believe the response is true because I’ve known a few born and raised Scandinavians…
“Oh, that system was not good. We decided not to use it and built our own.”
By then it was already working and done to the point Ford just shook its head and let them proceed.
Needless to say, the relationship was not to be long-term, who could’ve seen that coming?! /s
No programming language will prevent "limited thinking logic" bugs. It may prevent bugs caused by bad syntax or bad practices encouraged by the programming language. If it is a programming language it must do exactly what you tell it to do. If you tell it to do something wrong, it will do something wrong, no matter if it is in rust or any other language.
As another point of reference, using the touchscreen interface was the single worst thing about the 2021 XC40 I drove for a while. So I’m not sure anyone should be taking advice from volvo on software.
Completely agree. I own a 2020 V90 CC and the software is far worse in many regards than the car that it replaced: a 2016 base model VW Golf. I have radio glitches, the parking sensors kick in when no objects are present, the drive profiles that should activate when you use paired keys don’t activate. Not to mention using CarPlay or android auto only allows you to use the lower half of the display, with the upper half rendered useless.
I have nearly every safety feature turned off in the car because they all generate false positives at an astounding rate. Automatic braking kicks in for parked cars, billboards on the side of the road, cars traversing roundabouts in front of you, heck, probably even for gusts of wind.
They refreshed the interface recently with Android Auto, however they’re missing key features and have regressed on some major integrations - for example, they don’t support CarPlay in the current iteration.
I'm not the OP, and I don't know about Polestar specifically, but I've worked with many other vehicle systems, and they are incredibly complex. Each ECU in a car is running it's own firmware, and the larger ones can be running their own OS.
There's usually a mix of Assembly, Simulink, C, C++, Java, JavaScript, Shell scripts, Python, etc...
I've seen the OS be various flavors of embedded Linux, QNX, or even Ubuntu.
You can usually find a bit of everything even in a single vehicle. The code is integrated by an OEM and can come from dozens of potential suppliers.
My bikes run c++ (both arduino and segger-flavored) and a funny language called monkey-C in the subset of the code I know. And presumably mostly c++ in the parts that I don't know (much larger parts). Some people I ride with also have java in the mix and it doesn't seem to bother them at all.
Just use a 90s EFI vehicle with a full modern aftermarket ECU system from Haltec or Motec or whomever, and you can have a better car than was ever sold OEM.
There's no mention of the Rust language on the site or their careers page, at least with queries like `rust site:www.polestar.com/us/` or `rust site:about.polestar.com/careers/jobs/`.
Don't know for sure, but their share the "platform" with Volvo.
That's off the point though. The choice of language matters, but it matters less than the development process and the professionalism of people involved.
I'm actually quite fond of my comment, even though it is effectively a rant.
Volvo and Polestar operate at the arm's length. There are interviews that talk about a shared EV platform. There are also numerous reported issues with core EV functionality in the Polestars, oftentimes so severe that it's unclear how they don't lead to immediate fleet recalls.
It's possible that the people interviewed are unrelated to those responsible for the problematic areas, but the context is still important.
May be the crowd is getting a bit tired of the whole "Rust fanboism".too many articles on HN about Rust. It's just another language at the end of the day.
Why? You could just match on word boundaries '\bRust\b'
You would still get false positives with that but only regarding actual word semantics (i.e. articles mentioning Rust as oxidation process and not as programming language) but that's the tradeoff I guess
Perhaps it's a bit different if you're not a native English speaker, since the emotional aspects of the word are missing. To us, it's just a foreign-language keyword, like "if" or "for".
I don’t think there’s any automotive manufacturer crazy enough to use Rust in safety-critical components. They have to have air-tight documentation and Rust is neither certified nor a proven solution in this space.
The software development timeline is slaved to the rigid manufacturing timeline. There is no allowance for slippage, so making things work By Any Means Necessary is the rule of the day. Concurrency problems often are not debugged; locks and similar are just sprinkled around until they disappear in testing. It is TDD taken to an extreme -- passing the enumerated tests, technically, is the definition of done even if the code is obviously poor or broken.
There are a vast number of software and hardware components sourced from myriad vendors that are swapped out every year to save a few dollars or deal with a supply chain issue. There is no stable baseline but all of these components need to work together. The code has to constantly adapt to the reality that someone sourced parts for a new model year that work differently or are in a different programming language.
This code is usually required to be supported for 10+ years. The developers don't just have this year's tech stack and code base to deliver on a rigid schedule, they are required to maintain several older implementations concurrently, often built in different languages and architectures.
Basically, the automotive industry has failed badly at the transition from being hardware manufacturing companies to being hardware + software manufacturing companies, and try to run their software processes the same way they ran their traditional hardware processes. Choice of programming language is the least of their concerns, that isn't the source of their code quality issues.