[HN Gopher] Volvo is using Rust for its in-vehicle software
___________________________________________________________________
Volvo is using Rust for its in-vehicle software
Author : georgehill
Score : 466 points
Date : 2022-09-24 08:34 UTC (14 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| chimen wrote:
| lpapez wrote:
| You can literally make that with a one-liner Userscript in your
| browser.
| unrealhoang wrote:
| And then rewrite it in Rust.
| quickthrower2 wrote:
| Would filter out trust, crust, ...
| lpapez wrote:
| 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
| tmtvl wrote:
| That would be frustrating. Unless the matching is made
| case-sensitive, which would probably be a good idea when
| trying to filter out a proper name.
| alserio wrote:
| > frustrating
|
| nice work
| quickthrower2 wrote:
| assuming people always case things correctly.
| ArchieMaclean wrote:
| /([^a-z]|^)rust([^a-z]|$)/i
| allisdust wrote:
| Of course. It needs to be written in Rust and compiled to wasm
| for maximum irony.
| pxmpxm wrote:
| %s/Rust/Ruby on Rails/g would be amusing, just to see if the
| content even changes.
| goodpoint wrote:
| I wish! The hype cycle is unbearable.
| awestroke wrote:
| I'm working on an extension that filters out comments that
| whine and complain about Rust being mentioned.
| tus666 wrote:
| Bit scary there is probably a bunch of code in a car explicitly
| marked as "unsafe".
| kevincox wrote:
| Yeah, unsafe isn't the best keyword but alternatives like
| manually_verified are a bit too long.
| eutectic wrote:
| I think it's supposed to be a bit scary, so you pay extra
| close attention.
| cesarb wrote:
| 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".
| maxerickson wrote:
| The compiler can't enforce manual verification, so that would
| be potentially misleading in a bad way.
| Gigachad wrote:
| People lose their minds over 5 lines in an unsafe block but
| sleep soundly seeing tens of thousands of lines of unsafe C
| powering their car.
| uninstallgentoo wrote:
| tus666 wrote:
| I wonder if there are legal implications though if there was
| a crash and it provides evidence that the maker actually knew
| it was unsafe.
| blub wrote:
| 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.
| IceWreck wrote:
| Unsafe rust can be safe. Its just that the compiler cannot
| verify if it is. Same as writing any C/C++ code.
| lawn wrote:
| It's more scary that there's a bunch of unsafe code out there
| that's _not_ marked as such.
| lizardactivist wrote:
| They're hard at work in this thread today; people must be
| convinced to buy Tesla, and to stay away from Polestar.
| amelius wrote:
| Does it run on a GPU now?
| Onewildgamer wrote:
| 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.
| pornel wrote:
| People keep asking "why should I learn Rust if there aren't any
| (non-blockchain) Rust jobs?". Here you have it. They're
| creating Rust jobs.
| Onewildgamer wrote:
| 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.
| 42e6e8c8-f7b8-4 wrote:
| It is hard to learn on your own. I tried off and on, but
| found a gig where I could learn on the job, 40 hours per
| week. I love it now.
| benced wrote:
| They are the safest car manufacturer.
| jeena wrote:
| 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.
| krater23 wrote:
| 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.
| robomartin wrote:
| 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.
| kanbara wrote:
| robomartin wrote:
| > sounds like you are language culting c/c++ :)
|
| 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.
| robomartin wrote:
| 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).
| Gwypaas wrote:
| Rust is coming to Linux.
|
| https://lwn.net/SubscriberLink/908347/da67a5162d1bc4a3/
| jandrewrogers wrote:
| 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.
| ParetoOptimal wrote:
| > Choice of programming language is the least of their
| concerns, that isn't the source of their code quality issues.
|
| I'm curious to see if the Rust programmers affect the
| organizations as well by introducing unions to combat this kind
| if thing.
|
| On another note I disagree that language will have no meanigful
| effect, even in a hostile environment such as this.
| jandrewrogers wrote:
| 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.
| ParetoOptimal wrote:
| > 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.
| dmitriid wrote:
| > 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.
|
| [1] https://www.volvogroup.com/en/about-us/traffic-
| safety/safety...
| marvinvz wrote:
| 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.
| jrsj wrote:
| 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.
| oppositelock wrote:
| 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.
| AlotOfReading wrote:
| 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.
| teaearlgraycold wrote:
| > Concurrency problems often are not debugged; locks and
| similar are just sprinkled around until they disappear in
| testing.
|
| It does sound like Rust could help here
| Snild wrote:
| Not with liberal use of `unsafe` it can't.
| 19h wrote:
| IME It's often harder to do it the unsafe way rather than
| to just do it the safe way
| klabb3 wrote:
| 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.
| spoiler wrote:
| > 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
| kennywinker wrote:
| > embedded code that's inherently unsafe
|
| 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
| jgilias wrote:
| 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.
| psychphysic wrote:
| It depends if the same pressures that lead to sprinkles
| of locks will lead to sprinkles of unsafe.
| [deleted]
| tialaramex wrote:
| 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.
| psychphysic wrote:
| 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.
|
| So the risk might still be there.
| steveklabnik wrote:
| Redox: " A quick grep gives us some stats: the kernel has
| about 300 invocations of unsafe in about 16,000 lines of
| code overall."
|
| https://doc.redox-os.org/book/ch01-07-why-rust.html
|
| This is probably not an up to date number but it gives
| you some idea of a random snapshot in time at least.
| psychphysic wrote:
| 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.
| voorwerpjes wrote:
| I agree with you but just for completeness the rust
| equivalent is unsafe { *ten_things.get_unchecked_mut(11)
| = blah }
|
| Which goes to show that usually the unsafe methods are
| more verbose and annoying to deal with. Devs won't reach
| for them just out of laziness.
| 1-6 wrote:
| 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.
| iancmceachern wrote:
| This is the case for a lot of engineering, I've seen it time
| and again.
|
| The business processes force the engineering work product to be
| a dumpster fire.
|
| The great companies dont.
| dmitriid wrote:
| 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)
| drdaeman wrote:
| 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.
| stubish wrote:
| 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.
| jokoon wrote:
| What are the most commonly used UI software for rust?
|
| I don't think there is a QT equivalent? I guess there are
| bindings for QT, though, but I don't know if it plays well with
| the particularities of QT.
| pjmlp wrote:
| Actually there are some ex-Qt developers doing just that.
|
| https://slint-ui.com/
| justinclift wrote:
| Thanks, that looks pretty interesting.
|
| They explicitly support the RP2040 as well, with demo code.
| Very useful. :)
| nicoburns wrote:
| 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.
| huhtenberg wrote:
| 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.
|
| But, yeah, it's (possibly) written in Rust. Yay.
|
| [1] https://www.polestar.com
|
| [2] https://www.reddit.com/r/Polestar/ ---
|
| Edit - Added "(possibly)". The point was that the choice of the
| language matters less if your bugs are higher level and your QA
| process is lacking.
| the_mitsuhiko wrote:
| The Polstar software is written in Rust?
| faitswulff wrote:
| 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/`.
| namdnay wrote:
| Keep in mind that 90% of the engineering done in a car
| comes from a supplier or the supplier of supplier
| aeonik wrote:
| 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.
| alfiedotwtf wrote:
| This comment makes me want to use a bicycle from now on.
| usrusr wrote:
| 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.
| smolder wrote:
| 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.
| ytjohn wrote:
| I've seen rust used in a lot of bicycles.
|
| More seriously, most ebike firmware is written in C.
| _the_inflator wrote:
| I side with you. Basically "Volvo is using Rust..."
| translates to: "Volvo is adding Rust to its stack of
| complexity".
| huhtenberg wrote:
| 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.
| the_mitsuhiko wrote:
| From what I can tell from test driving a Volvo CX90 and a
| Polestar these cars don't have much in common in terms of
| software.
| davedx wrote:
| This is a terrible comment. The interview was thoughtful and
| constructive, and the top rated comment is a polemic rant about
| a subsidiary of Volvo?
|
| Jesus fucking christ HN
| FpUser wrote:
| There is nothing terrible in this comment.
| davidro80 wrote:
| huhtenberg wrote:
| 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.
| codegeek wrote:
| 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.
| marcodiego wrote:
| 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.
| bradleyjg wrote:
| 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.
| Daneel_ wrote:
| 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 won't be purchasing another Volvo.
| rjsw wrote:
| 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.
| 6stringmerc wrote:
| 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
| donw wrote:
| That's nothing. Chevrolet has built its cars with rust for
| decades now.
| mherrmann wrote:
| And there I was, already looking at Wikipedia to come back here
| and school you that Rust hasn't been around that long. Got it
| just in time.
| plankers wrote:
| So I guess this means Volvos will be... crashing... less?
| abusaidm wrote:
| " Why Rust is actually good for your car." That gave me a
| chuckle. It's a better title the one in here too
| chrismorgan wrote:
| > _Um... yeah. Rust is bad._
|
| -- https://dilbert.com/strip/1997-01-12 ("buying a car")
| ta8903 wrote:
| 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."
| dcz_self wrote:
| Funnily enough, about a month ago I gave a presentation about
| deliberately putting Rust on my bike.
|
| https://dcz_self.gitlab.io/posts/jazda_rust/
|
| Pictures of the less-desired rust included.
| frozencell wrote:
| sgt wrote:
| They used to keep the rust in the chassis. Now it's on chips.
| That's progress!
| tazjin wrote:
| Makes sense that one of the most safety focused manufacturers
| would go for it.
| uklpants wrote:
| 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.
| nabakin wrote:
| 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.
| CBarkleyU wrote:
| 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.
| wallaBBB wrote:
| 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.
| veltas wrote:
| 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.
| uninstallgentoo wrote:
| pjmlp wrote:
| 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.
| jeffreygoesto wrote:
| 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.
|
| Ah. Found it, [1][2]
|
| [0] https://github.com/PolySync/misra-rust
|
| [1] https://news.ycombinator.com/item?id=32237780
|
| [2] https://news.ycombinator.com/item?id=30174827
| qznc wrote:
| 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.
| thrwyoilarticle wrote:
| Some MISRA rules lead to absurd code, e.g. single return
| from a function meaning any error checking adds another
| level of nesting.
| tubs wrote:
| Without raii this is kinda needed.
|
| Though simple param checking should be allowed ideally.
|
| But you can always just do a deviation, it's not super
| hard.
| veltas wrote:
| 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.
| hxtk wrote:
| 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.
| sirsinsalot wrote:
| MISRAble
| teknolog wrote:
| My first job as a SWE was at Ericsson, and they also had
| this requirement. Solution: gotos everywhere!
| riedel wrote:
| I am pretty sure that SPARK Ada would be an alternative.
| ElCheapo wrote:
| ADA has existed for a loooong time
| ChuckNorris89 wrote:
| And the market for available ADA devs is ... <crickets>
|
| Even the USAF and defense contractors like Lockheed Martin
| switched to C++ from ADA for the F-35.
|
| ADA is basically dead and buried outside of maintenance for
| 35+ year old planes, but I doubt those are seeing much active
| SW development done on them.
| tmtvl wrote:
| 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.
| nicoburns wrote:
| I think it being open source from the get go has also
| made it a lot more viable.
| diydsp wrote:
| That's made it accessible to amateurs, but cost is less
| relevant in safety industries than reliability.
| nicoburns wrote:
| 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.
| Jtsummers wrote:
| 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.
| dagmx wrote:
| Surely the biggest thing has been accessibility from the
| start?
|
| It's all good and well to hear about Ada but how did one
| start using it for free at home to learn and then
| evangelize it in the work place?
|
| How did one find learning materials about it in the same
| amount as an openly available language?
|
| How did one contribute back to the language ?
|
| Lots of cool stuff happens in proprietary spaces first.
| OSS variants tend to gain traction very quickly though
| pyjarrett wrote:
| See https://ada-lang.io/ and https://learn.adacore.com/
| bregma wrote:
| 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).
| pjmlp wrote:
| Actually they make enough noise to keep 7 compiler vendors
| in business for the last 40 years, with regular ISO
| standard updates.
|
| It is a little more than just maintenance.
|
| https://www.adacore.com/
|
| https://www.ghs.com/products/ada_optimizing_compilers.html
|
| https://www.ptc.com/en/products/developer-tools/apexada
|
| https://www.ddci.com/products_score/
|
| http://www.irvine.com/tech.html
|
| http://www.ocsystems.com/w/index.php/OCS:PowerAda
|
| http://www.rrsoftware.com/html/prodinf/janus95/j-ada95.htm
| 29athrowaway wrote:
| And the results suck
| ChuckNorris89 wrote:
| Products can suck regardless of the programing language
| used.
| 29athrowaway wrote:
| 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.
| aliqot wrote:
| > ADA is basically dead and buried
|
| This made me clutch my chest and gasp and I have no idea
| why
| ardel95 wrote:
| They do claim to be the safest cars!
| eggy wrote:
| 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.
| autotech wrote:
| 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.
| techwiz137 wrote:
| Progressive on the cars, but their VIDA software uses terrible
| and slow database, and requires...get this: Internet Explorer to
| work on modern PCs.
| ddalex wrote:
| I drive a Volvo and it's the most amazing car that I've driven.
| The comfort of long range drives is something else.
| helloguillecl wrote:
| 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.
|
| Now I have a reason to try Rust.
| Grazester wrote:
| Modern volvo's are terrible cars where it comes to reliably. I
| guess yours is holding out for now.
|
| https://www.jdpower.com/business/press-releases/2022-us-vehi...
| nazka wrote:
| You may end up liking it too much. :D
|
| 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.
|
| Have fun!
| Galanwe wrote:
| > 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" :-)
| unrealhoang wrote:
| Unsafe, pointer and transmute will tell Rust to leave you
| alone.
| 411111111111111 wrote:
| At the cost of having most of the community saying that
| you can't code and are irresponsible any time your code
| comes up.
| unrealhoang wrote:
| If only you make a library out of it, and it's unsound.
| Not so different from any other programming language
| community I guess.
| herbstein wrote:
| 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.
| jmillikin wrote:
| 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.
| bogeholm wrote:
| The actix-web thing, where a couple of unsound
| optimizations in a popular library caused some drama?
|
| Yeah it was kind of unfortunate, and I think resolved by
| now?
|
| As a saying goes (in some locations), "Now we probably
| can't boil more soup from those bones".
| UncleMeat wrote:
| 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.
| mustache_kimono wrote:
| 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.
| UncleMeat wrote:
| 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.
| rapsey wrote:
| Yeah it is all those other C programmers causing memory
| corruption.
| izacus wrote:
| 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.
| generj wrote:
| 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.
| frozencell wrote:
| > but I love Volvo
|
| If you like Volvo, you'll like China
|
| " The Zhejiang Geely Holding Group currently owns the car
| lineup and has invested an 8.2-percent stake in the truck
| lineup, with the ultimate goal of reuniting them."
| mathverse wrote:
| 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.
| frozencell wrote:
| 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.
| qzw wrote:
| 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.
| kube-system wrote:
| The did, for new auto manufacturers, which AFAIK just
| meant Tesla. Other parts of their economy still requires
| joint ventures, though.
| jugg1es wrote:
| 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?
| davedx wrote:
| Is this post being astroturfed or something? Lots of irrelevant,
| un-constructive or plain trashy comments
| robocat wrote:
| "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
| esskay wrote:
| 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.
| panick21_ wrote:
| There is still a huge amount of software in a car beyond the
| center console.
| manmal wrote:
| You'd still need a ton of C/Rust if you provided only
| CarPlay/AndroidAuto APIs.
| jcampbell1 wrote:
| 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.
| manmal wrote:
| 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.
| SV_BubbleTime wrote:
| >and get access to the CAN or an abstraction over the
| CAN.
|
| Automotive EE here, no, absolutely not.
| logicchains wrote:
| 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).
| singhrac wrote:
| 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).
| rapind wrote:
| The goal being an SEO takeover of Rust + Volvo...
| cultofmetatron wrote:
| as much as I love rust. why not ADA. it was designed for this
| sort of use case.
| he0001 wrote:
| 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.
| chinathrow wrote:
| What does your dealer say? Your car is under warranty, I
| assume.
| he0001 wrote:
| That it's a bug and should be fixed with a upgrade, but it
| hasn't been fixed yet.
| nequo wrote:
| If you're in the US, report it to the NHTSA:
|
| https://www.nhtsa.gov/report-a-safety-problem#index
| pfortuny wrote:
| Wow, the jerking also? That is enough for a recall, or
| should be!
|
| If you are in the EU, have you spoken to the consumer
| ombudsman (or whatever name it has)?
| WHATDOESIT wrote:
| 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.
| tobyhinloopen wrote:
| 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.
| autotech wrote:
| 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.
| coding123 wrote:
| You probably have to stop using Bluetooth if you want
| dependable blinkers on your car. This is so 2022.
| tobyhinloopen wrote:
| 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.
| przeor wrote:
| I have opposite experience with Mazda. Now driving XC40
| jbverschoor wrote:
| Sounds like a non-RTOS doing RT things
| cj wrote:
| (RTOS = Real-Time Operating System)
| sgt wrote:
| throw827474737 wrote:
| 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
| nicoburns wrote:
| The entire comment is a joke. Commenter does not work for
| volvo
| pxmpxm wrote:
| 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
| rgacote wrote:
| First thing that came to my mind was something doing
| garbarge collection (obviously not RTOS).
| Waterluvian wrote:
| Aren't blinkers run by a simple electrical system with no
| computer?
| sgt wrote:
| Not since... 2005
| Keyframe wrote:
| 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.
| londons_explore wrote:
| > They may blink fine for a awhile but then stops for a period,
| and then suddenly all missed blinks blinks in a rapid
| succession
|
| If you had a windows 95 PC controlling the blinker, the exact
| same bug and symptoms would be totally expected...
|
| Do how in 25 years have we not managed to quash this class of
| bugs? (Where a simple task needs to be done at a certain time,
| and gets delayed).
| londons_explore wrote:
| 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.
| michaelmior wrote:
| 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.
| foobarbecue wrote:
| If timing is critical, you need an RTOS. (Real time operating
| system)
|
| Or just don't use software. I wouldn't expect the blinker
| delay to use software, just a timer IC.
| georgyo wrote:
| 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.
| diydsp wrote:
| That's an underrated point: rust solves memory issues, but
| now schedule feasibility is outstanding.
| blub wrote:
| 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.
| hcarvalhoalves wrote:
| It's so f**ing stupid we're discussing memory leak or
| concurrency issues of a TURN SIGNAL. I'm never buying a car
| from the 2020's.
| lenkite wrote:
| 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.
| [deleted]
| jeffrallen wrote:
| 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.
| zepearl wrote:
| > _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...".
| reaperducer wrote:
| _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.
| Mankaninen wrote:
| 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.)
| jeffrallen wrote:
| 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. :)
| aidenn0 wrote:
| 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
| diydsp wrote:
| That is a blatant sign other tasks are not being scheduled
| properly.
| jrib wrote:
| 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.
| spaniard89277 wrote:
| 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.
| Waterluvian wrote:
| 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.
| lotsofpulp wrote:
| I appreciate that others are willing to beta test these new
| car features.
| plankers wrote:
| On public roads with other people who haven't consented
| to testing anything, no less.
| Waterluvian wrote:
| 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.
| papandada wrote:
| I just don't see myself ever trusting a car
| Waterluvian wrote:
| 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.
| bspammer wrote:
| At least smart home stuff can't send you into a ditch at
| 60mph
| Waterluvian wrote:
| Well not with that attitude!
| DuskStar wrote:
| But when your smart oven and smart smoke detector
| conspire...
| Eleison23 wrote:
| 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.
| ummonk wrote:
| Have they made it stronger or something? The lane keep assist
| on my 5 year old Subaru is just a gentle tug. Feels like a
| gust of wind at most.
| diydsp wrote:
| When passing bikes i always hug the yellow lines to give them
| space. Lane assist (in a rented beemer) tended to jerk the
| car straight toward them.
| skhameneh wrote:
| 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.
| dzhiurgis wrote:
| 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.
| flkiwi wrote:
| 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.
| amenghra wrote:
| 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 :)
| KerrAvon wrote:
| 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.
| Rygian wrote:
| It's your software version nicknamed Vetinari by any chance?
|
| https://www.instructables.com/Lord-Vetinari-Clock/
| keewee7 wrote:
| A few years ago Volvo could be considered a premium brand but I
| now see Danish cops replacing their aging VW Passats with
| Volvos. Not a good sign.
| KerrAvon wrote:
| 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.
| sva_ wrote:
| I think with Volvo it's a bit like with ThinkPad: The quality
| went downhill after a Chinese acquisition.
| sorenjan wrote:
| 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.
| jeffrallen wrote:
| You get the left one for free, but if you want to make
| right turns, you'll need to upgrade to a subscription
| package.
| Daneel_ wrote:
| 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.
| rightbyte wrote:
| 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.
| mort96 wrote:
| Holy shit, those are the kinds of bugs which should make a
| vehicle not road legal.
| randerson wrote:
| 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.
| TheRealDunkirk wrote:
| 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.
| YZF wrote:
| 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.
| throwawaymaths wrote:
| > 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).
| ddulaney wrote:
| 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.
| rthomas6 wrote:
| 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?
| bonzini wrote:
| ASIL is the automotive equivalent of DO-178. The standards
| for say the software in the ECU are not the same as those for
| infotainment.
| wyager wrote:
| 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.
| TheRealDunkirk wrote:
| 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.
| FpUser wrote:
| >"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.
| unity1001 wrote:
| > 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.
| AlotOfReading wrote:
| 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.
| davidrm wrote:
| 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.
| TheRealDunkirk wrote:
| When I said "the same way," I meant wholly-overloaded, top-
| down, waterfall-driven, and bureaucratically nightmarish. So,
| yes, all that stuff. ;-)
| amelius wrote:
| > 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.
| DoingIsLearning wrote:
| > 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.
| amelius wrote:
| Yes, I'm talking about infotainment software.
|
| I don't think any car manufacturer combines the
| functionalities you mention in a single software system so
| it would be easy to separate them.
| AnAnonyCowherd wrote:
| > 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 -\\_(tsu)_/-.
| antegamisou wrote:
| Your comment will come off as elitist/condescending but you're
| 100% spot on.
|
| People without actual engineering background (should) have no
| place in safety critical systems design.
| [deleted]
| xyzzyz wrote:
| 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.
| VyseofArcadia wrote:
| 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.
| badpun wrote:
| > 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.
|
| At the end of the day, you still work for them, so with
| enough "nos" they'll just fire you or assign you to
| projects which don't matter.
| JumpCrisscross wrote:
| > _you still work for them, so with enough "nos" they'll
| just fire you or assign you to projects which don't
| matter_
|
| They'd have to replace you with someone else similarly
| certified.
| _trampeltier wrote:
| 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.
| criddell wrote:
| 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.
| halffaday wrote:
| 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."
| TheRealDunkirk wrote:
| 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. ;-)
| kajaktum wrote:
| 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.
| tomrod wrote:
| (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.
| unity1001 wrote:
| > 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.
| TheRealDunkirk wrote:
| 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.
| unity1001 wrote:
| > 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...
| jamincan wrote:
| Usually the state delegates that responsibility to a
| professional organization.
| geethree wrote:
| NCEES has a software PE certification that was discontinued.
|
| https://ncees.org/ncees-discontinuing-pe-software-engineerin...
| [deleted]
| [deleted]
| uup wrote:
| 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.
| bb611 wrote:
| 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.
| TheRealDunkirk wrote:
| 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.
| [deleted]
| ydlr wrote:
| Maybe we need professional certification for CEOs.
| throwawaymaths wrote:
| For better or worse, we do, and It's called an MBA
| oneplane wrote:
| Somehow it seems that an MBA doesn't certify someone a
| whole lot more than a sociopath certification would...
| throwawaymaths wrote:
| Hence the "for worse" option
| DoingIsLearning wrote:
| 'going'?
|
| 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.
| kazinator wrote:
| In actual engineering, that is the entrenched model.
|
| In civil engineering and other, individual engineers can face
| consequences for disasters like collapses.
|
| And other disciplines; a surgeon can face consequences for a
| surgery that was done by a team, and so on.
| tobyhinloopen wrote:
| Volvos software is absolute shit since they went with android
| stephc_int13 wrote:
| I can see where Rust could fill the same niche Ada once occupied.
| pxmpxm wrote:
| Would love to hear how - validated constraints on
| input/types/flow is one of the design objectives of Ada. In
| what way is Rust relevant here?
| mustache_kimono wrote:
| Can you describe what you mean here? I don't understand this
| feature re: Ada.
___________________________________________________________________
(page generated 2022-09-24 23:00 UTC)