Elon Musk: Tons of C++/C engineers needed | Hacker News Reader

Elon Musk: Tons of C++/C engineers needed

twitter.com

103 pointshappy-go-lucky128 comments

If this is their actual hiring strategy (armies of junior whiteboard coders with no preference for engineering experience or education), then the quality of their product will tank rapidly. It’s not that junior engineers are bad hires, it’s that it takes years of hard fought engineering experience to get an idea of what designs will work, what won’t; when to pay down tech debt, etc.

Edit: There are lots of junior-sounding devs on this thread. Don’t let me discourage you. Just be sure you’re joining a team with strong engineering leads that will be good mentors.

What gives you the idea that Tesla is hiring junior whiteboard coders for these roles? They wouldn't know anything about optimizing C++/C/raw metal driver code for speed and wouldn't pass a real hardcore coding test.

Passing a "hardcore" coding test is something you can train for, and tends to not correlate well with actual software architecting and optimization knowledge.

Also optimized code is not necessary well designed.

Very true. Especially in embedded programming where custom code can yield massive perf gains.

You don't even know what 'hardcore' means in this context. Your literally judging their process essentially nothing and you have strong opinion on it. That said more about your prior then anything else .

My first job out of university was writing display drivers (C and x86 assembly). It was definitely a junior position but I was hired for my interest in and [at least] emerging ability to optimize C and write code running “on the metal”. It’s a skill like any other—There’s not some magical age where you get it.

I had a very similar experience, sans the degree, but in the embedded world for an RF company. I still like to write C in my free time today, nearly 8 years after leaving that job. I've shipped a few pieces of performance critical code in C for the Rails shop that I work for today, too, in the form of FFI and language extensions. I honestly don't think I'll ever ~be free from~ give up C explicitly for these reasons (it's also ludicrously satisfying to realize and share these sorts of performance gains in a production application).

Strange that industry has never figured this out, especially as a JavaScript developer. Maybe they will have some magical framework that organizes their code for them only to be astonished when the result is really big, requires lots of people, and does very little.

"Industry" is precisely where the incentives are highest to pursue quantity over quality. Managers are biased to treat having more people reporting to them as a good thing, not a cost for the business. And junior developers are also cheaper to hire, so it's win-win for them.

I wouldn’t be surprised if they follow a “creaming” strategy. That is, hire a ton at a lowish bar, monitor their performance, and fire 75% of them relatively quickly. Ruthless, perhaps, but consistent with what I have seen from the outside.

Where does it say armies of junior whiteboard coders with no preference for experience/education? Sounds like you are straw-manning their plan here.

Here is the job posting for systems software engineers on the Autopilot team [0].

[0] https://www.tesla.com/careers/job/autopilot-systemssoftwaree...

Amazon built an org that handles high turnover, and I respect them for that. If you go into it with eyes open, you can build an org that has more junior dev. Not that Elon's the type to think of the consequences, but it can be done.

Especially with C++ its very easy to shoot yourself in the foot and experience is invaluable.

Actually C++ is the one language you can write type checked Tensorflow/keras chains in that will actually fail to compile rather than give runtime errors when for example arrays don't fit.

Honestly, it really just depends on what their "hardcore coding test" actually entails.

If they give you like 1 short task that you're supposed to solve on a white board, well, that doesn't really map well with what you're actually supposed to do.

But if they sit you down for 8 hours with a reasonably interesting task (both optimization and architecture wise), that's a pretty decent filter. It just takes a lot of time and effort from both the company and the candidate so almost nobody does it.

It's not like the usual filters (engineering experience or education) are this amazing gold standard either. Just because someone wrote barely passable C++98 code for 15 years that doesn't make him a great programmer, and neither does having degree.

I could see working for for Tesla, I couldn't work on Tesla's AutoPilot though.

I have deep reservations about using members of the public (and others on the road) as guinea pigs. Before the Walter Huang fatality, maybe, but after that and how Tesla acted about what was clearly a software bug in software that wasn't fit to be on public roads ("beta" label or otherwise), I could never justify working for such a company. Imagine being a software engineer on AutoPilot at the time, and then having the company you work for excuse your bugs by blaming the victim for not circumventing AutoPilot controlled steering into a wall.

Software development ethics don't come up a lot. But I feel like AutoPilot is up there with medical software, aviation, and military, in that mistakes can easily cost lives. I want to be able to sleep at night.

It is a cool problem-space, but only academically.

By this logic, wouldn't you want an opportunity to help direct this space more positively, rather than being completely hands off?

To me it seems unlikely a newly hired C developer could overrule Elon Musk on things like releasing the product to customers or having LIDAR.

The way he demonstrated to treat his engineers would make me more suspicious. I have experience in c/c++ and especially imaging, but no way in hell would I want to work there.

Maybe the guys he publicly fired were idiots, but even then you can manage that differently. It was a to a time when he got a lot of crap from media, but that is not a good excuse. Seriously lost faith in the company for that.

I've worked im automotive in similar fields, even more advanced, and Tesla is not an outlier, probably even better than the rest. Tesla has a huge advantage in its flat modern management structure. They are at least 10x faster and cheaper than the rest. The results are visible to everyone. Bad midmgmt apples are everywhere, esp. in those kind of industries.

The ethics here are not as simple as "don't ship any self-driving AI until you are 100% sure they will never make a fatal mistake." There is no such thing as 100% assurance in this field.

If you are so cautious that you never ship any self-driving code, there are lives that may be lost due to accidents caused by human failure. These accidents might have been avoided if an AI was at the wheel.

I respect this type of work is not for all people. I applaud the brave companies plowing ahead.

There is a difference between 99% and 99.99% assurance in this field though. You can test your self-driving AI to a reasonably high degree of certainty before ever testing in a public uncontrolled environment.

I've argued in several of these threads on self-driving the following point: safety in terms of fatalities per billion vehicle miles travelled (VMT) is already in the single-digit range in Europe, and likely far below 1 fatality per billion VMT when restricted to "highways AND modern cars AND good conditions".

So you need ridiculously huge samples to get statistically significant data on the safety of a single manufacturer's system. As in the order of magnitude of a hundred thousand miles per car for every one of the ~ 900k Teslas sold so far.

Thus you reach a paradox: with current trends in "normal" car safety improvement, you won't know for sure if a particular self-driving model is safer than non-self-driving models until they are close to end-of-life. And then it's a bit late to find out.

The inverse is also true. There are plenty of videos of autopilot preventing wrecks that the human drivers said they likely would have wrecked on themselves. I happen to be one of those drivers when someone pulled onto the highway from a field at night. AP swerved and missed the idiot but I'd not even seen them and would have almost certainly hit them doing about 70mph. A T-bone that fast would likely have messed both of us up really good.

AP will never prevent all injuries / fatalities due to road conditions and other human drivers simply being imperfect. It has a good chance to prevent a lot of otherwise fatal crashes in the meantime however. One could say it would be unethical to not even consider the alternative here.

Just some food for thought. I'm a software engineer myself and Model 3 owner.

I always see this argument and it's like everyone's forgotten that AP isn't the only automatic safety system.

My Volt had the same exact hardware as AP1 (from Mobileye). GM decided not to play games with marketing, and had it only intervene in cases of immediate danger.

For example, you could try and get it to follow lanes, but it's guidance would be directly proportional to your steering input, and it would intentionally stop intervening the moment you were back in your lane, eventually disengaging if you weren't trying to correct at all.

At night in pouring rain coming around a tight highway turn, my car stopped for an overturned box truck covering 2 of 3 lanes and allowed me to go around it. It saved my life with very little fanfare.

AP didn't have to be called AP. AP didn't have to be something you can let take over (except jk don't let it take over or we'll victim blame you when it kills you).

AP could provide traffic-aware cruise control, could take over when you drift out of your lane, swerve away from imminent crashes, and you would still have been saved from that T-bone, and Walter Huang would still be alive today.

But then Tesla couldn't charge extra for Advanced AP, then extra on top of that for FSD.

On the flipside, in these cases where people self-report "I likely would have wrecked myself", we can reasonably expect that they are paying less attention to the driving situation while using AP than if they were driving a car without AP. So we expect them to be strongly biased towards underestimating their own abilities in the situation.

That's fair, but I'm sort of afraid / amazed by autopilot. I have been through FAA flight school and you learn to develop an instrument panel "scan" in instrument rated flight. I find myself having developed a "scan" that includes looking side to side and behind me. With AP enabled I'm able to take in more of the current situation around me, but in this case, I was not able to see the car that drove into the middle of the highway from offroad at night. AP did a better job than a human did. End.

AP did a better job than _you_, but it's a bit of a stretch to assume that finding is true for most other people, or even just the average person. This is why the scientific method exists, so we don't fall prey to our own bias.

> mistakes can easily cost lives. I want to be able to sleep at night.

Everyone who works in the safety field has to deal with this. How do you think the MCAS engineers feel?

But let's rewrite history, and say Boeing decided to scrap MCAS before it ever shipped on a 737 MAX. Now let's say a MAX crashes from stalling on takeoff - the exact scenario MCAS was meant to prevent. How would those engineers feel? How would we be looking at Boeing if we knew there was work done on a prevention device, and the higher-ups decided to scrap it before it was completed?

No one engineer or manager is responsible for a tragedy. Organizations, sure, but no organization can be perfect. You can only try to use whatever power you have to guide it towards better practices and regulations.

> Educational background is irrelevant, but all must pass hardcore coding test.

This sounds like another example where his hard core coding tests filters for code-grifters.

You know the type: People who game the system by studying L33T coding challenges, and can hack out some nonsense from copy/pasting stackoverflow. They get ‘something’ working, and ship it, and declare that it is done. But when you really investigate it, you find that it is a disaster waiting to happen.

And in general, they cannot engineer a formally-verified, fault-tolerant system to control complex systems, complex heavy machinery, and intricate business logic.

But, these are the engineers that will pass his hard core coding challenge. Welcome to the so-called world of Software “Engineering”.

> And in general, they cannot engineer a formally-verified, fault-tolerant system

Do any automobile manufacturers actually use formal verification? How do you even apply such techniques to things that leverage ML like Tesla’s autonomous driver?

ML for automotive sounds like a disaster waiting to happen.

It seems like ML is statistically safe for everyone else, until that moment when you become the “statistic”.

I always struggled with this. Give me a list of things to memorize and a rigid test - and I'll struggle.

Put me in a real environment with access to documentation, actual team members, and time to learn and understand a system? That's where I actually shine.

Something I kinda like the idea of for a "code interview" would be a "reverse interview". E.g. give them some sample code (likely from production) and ask them to critique it and review it.

I'm no expert in SQL - but I can still spot an injection vector. If I need to use SQL regularly then I'll learn it as needed, etc.

> And in general, they cannot engineer a formally-verified, fault-tolerant system to control complex systems, complex heavy machinery, and intricate business logic.

You wonder why they're not using D or even Rust or Ada to get systems that are more provably safe?

It's in the title: "Tons of [...] engineers needed."

Good engineers that already know C/C++ are 20x easier to find.

> This sounds like another example where his hard core coding tests filters for code-grifters.

There is nothing taught in Computer Science at college that can't be learned online.

I appreciate that Elon is hiring for skill and knowledge and not a paper that says you graduated from some expensive school and therefore are automatically more qualified.

At some level I agree with your sentiment about shibboleth-style filtering. Not having seen these specific "tests" though, I can charitably imagine these being relevant to fault-tolerance/managed intricacy. Things like, "This code failed. How did it get to that state?" or "X can be interrupted at any time. Implement Y such that it atomically…" are examples of coding challenges that _are_ relevant to being fluent in embedded software development. I really doubt they're asking "implement quicksort"-type questions.

I've always wanted to interview someone by giving them some code, and saying "please add such-and-such a feature."

I've had interviews before where people have given me code on paper and asked me to critique it; also gave me a program where they'd introduced a bug, and asked me to find the bug.

It's a shame these things haven't caught on. Developing green field code is only a tiny fraction of what we do.

Its still better to test yourself then just accepting the stamps people put on their head.

Is this what you assume based on "educational background is irrelevant"? Are you somehow under the mistaken impression that the skills you mention are only learned in school, and only found in those with traditional CS degrees? That sure doesn't align with what I've seen or who I've worked with in my career.

Or did you assume that "hardcore coding test" by default only means algorithms questions that you can memorize the answers to?

And are you really sure the people "copy/pasting stackoverflow" are the same ones who pass algorithms interviews? Sure doesn't match my experience.

In any case, you sure jumped to a lot of conclusions from a single tweet.

It's also worth mentioning that a lot of people can learn C++ syntax (and even more C) and solve programming puzzles without any cheating but usually, especially in the context of embedded and/or real-time programming, "C/C++ engineer" means somebody who understands how the computer works and is able to make judgments about performance and correctness of the generated code.

So even a competent programmer, who might have spent last decade writing GUI in Qt, could be practically worthless for real-time embedded C/C++ while passing any whiteboard tests.

I don't care to have a job where my mistakes could possibly end up killing people months/years from now, but I wouldn't mind seeing what he means by "hardcore coding test".

Yeah. That alone would keep me from applying.

You could always just blame QA

Then the shittier devs will inevitability be hired to work and the outcome is clear. The fact that genius people are working at Facebook to help us press like button on Kardashians' ass image at scale and dummies are working for Boeing already has shown its consequences.

"Genius people" staying far away from military contracting (like Boeing!) seems to be working out really well, and they should continue to have mundane and well-compensated jobs offered to them.

I meant Boeing as commercial aircraft producer. And I don't blame anyone regarding this. It's their life/career.

I don't think it's fair to say that dummies are working at Boeing. Their recent scandals seem to at least partly stem from organisational/political problems. And FB "genius"'s mistakes are still far less visible than Boeing engineers'.

An admirable goal, I suppose. With all the mental health issues stemming from software addiction and negative externalities due to ad revenue, these jobs will be harder and harder to find.

Almost any software bug can end up killing someone once it’s deployed to a billion people.

It’s just less likely you’ll hear about it if it doesn’t involve a spectacular plane/car crash, missile launch, radiation release, etc.

Ad targeting comes to mind (e.g., accidentally pushing opioids and worse at mentally unstable people because the computer inferred they are likely to buy).

opioids ads most likely killed 10Ks of people.

Accidentally... or purposefully, as a recent HN thread shown. In deaths because of ad targeting, I doubt most were caused by bugs.

I like how you assume that was an "accident", especially after it came out that Purdue and Allscripts teamed up to push pills through their software. The system is working as expected, it just would horrifying it's original creators

The converse is that you are saving lives by developing a system that is already safer in terms of fatalities per mile than human drivers in some conditions.

A few years ago, I contacted a buddy of mine at Tesla to see if they were hiring. That led to a call from their HR/recruiter and a nice chat. I remember being interested enough to continue the process until we reached the end.

It sounded pretty straightforward. Coding test, talk to a bunch of people onsite, etc. Each of the people would write up a report and it would work its way up to Elon Musk and he would make the final decision as to whether or not to hire me.

In a small company of up to ~200 people, sure. A department that's maybe a layer or two beneath him, ok, maybe? I don't remember where this was exactly, but it was something involving web services or similar in C#, and I don't even think it was front-facing, but for internal use, so probably somewhere in the IT department.

For my personal tastes, when the CEO is making hiring decisions on every position, that's an element of micromanaging that I'm not comfortable with, so Tesla is pretty much off my list.

I know Elon is sometimes not popular around here, but how many CEOs at that level would know that level of details abouts the NNs. (he is totally in the weeds, but that is very cool IMO)

I'd love to work there, but I know I would not put in the effort to pass the coding tests.

Working for a manager who thinks they know the details, but are sophomorically off in the weeds, seems the worst of all possible worlds.

The guy has a master's degree in physics. My friend was a SpaceXer and said Elon could ask really pointed questions about forces, temperatures, combustion processes, materials, and so on because he really understood the fundamental science.

Ya I know. I think i remember reading somewhere (probably in that biography) that he actually basically self-educated himself to PhD level in aerospace engineering while starting SpaceX.

Many of them? 1/3 of Fortune 500 CEOs majored in engineering. For decades, the CEO of Intel was a process engineer. The current CEO of AMD is also a process engineer. You bet they know the details of their chip design and manufacturing process. Ginny Rometty, CEO of IBM for more than a decade, had a degree in computer science and electrical engineering. The current Boeing CEO is an aerospace engineer. They’ve not necessarily been amazing leaders, but I bet they know what language Watson/Boeing’s control code is written in.

Dennis Muilenburg was fired. The current CEO of Boeing is a finance guy if I remember correctly.

Tesla doesn’t pay well enough to attract good software engineering talent.

It does compare badly versus employers in the oil & gas, defense, tobacco and casino industry. A shame.

naive question, but shouldn't AV command and control algorithms be built on some kind of formally verified system/language, considering lives are at play here ?

I am aware of MISRA C for automotive but is something like that sufficient to guarantee against unintended behavior ?

If not, can someone comment on why this isn't the case today ?

There's a huge amount of money riding on the assumption that with enough training the neural net solutions will have an error rate low enough that the "Explain why the crash is the other person's fault" PR division can cover for it.

Is there any production software in the world that is written and maintained in a formally verified language? I have only ever seen toy problems and simplified subsystems of real projects verified.

I work on space craft flight software and exactly none of it is formally verified. As far as I know, it's not practical to do so. If we could do it (without ballooning cost and schedule 10x), we would.

Amazon S3 and DynamoDB come to mind are good examples. They are model-checked in TLA+ though the applications themselves are not written in TLA+.

A large portion of Microsoft's in house developed device drivers for windows are formally verified.

Boeing together with DARPA built an autonomous helicopter on top of the formally verified Sel4 microkernel https://ts.data61.csiro.au/projects/TS/SMACCM/

Another one:

Wireguard uses formally verified implementations of ed25519 https://github.com/project-everest/hacl-star

>Amazon S3 and DynamoDB come to mind are good examples. They are model-checked in TLA+ though the applications themselves are not written in TLA+.

Honest question (I obviously don't have a ton of experience in this area), what does "model-checked in TLA+ though the applications themselves are not written in TLA+" mean (in terms of the guarantees you're getting)? If you're not verifying the actual code, then how do you prevent bugs creeping during whatever happens between verification and actually writing the application code?

The HACL* project looks interesting. I would definitely accept that as an affirmative answer to my original question.

> If you're not verifying the actual code, then how do you prevent bugs creeping during whatever happens between verification and actually writing the application code?

Code review! So, SO much code review. Also testing and type systems and linters and code review.

(There's also some work on automatic synthesis, like PGo, but that's all very, very far from being production-ready.)

The main benefit of using TLA+ is that it lets you hammer out issues in the high-level design. Less "oops this has a buffer overrun" and more "oops if this service stalls out for too long our recovery mechanism will violate a core safety guarantee." Turns out that lots of the nastiest bugs are in the design, not the implementation, so using TLA+ saves a lot of time and money. But you still need to code review!

>Less "oops this has a buffer overrun" and more "oops if this service stalls out for too long our recovery mechanism will violate a core safety guarantee."

Yeah, but we already have processes to manage the latter. It's the (potential) buffer overruns that keep me up at night!

>Turns out that lots of the nastiest bugs are in the design, not the implementation

I'm not saying it never happens (does TLA plus make sure everyone's assuming SI units?), but that hasn't been my experience at all.

> Yeah, but we already have processes to manage the latter. It's the (potential) buffer overruns that keep me up at night!

I'd _hope_ you'd have those processes, working on space flight and all :P. Good processes > good tools. It's easier to start using a good tool than overhaul your process. So for people who don't have that kind of discipline or heavyweight process, TLA+ gives a lot of benefits for really cheap. AWS, for example, found it really easy to slot into their workflow.

Re buffer overruns, I just remembered OpenComRTOS, which used TLA+ to verify low-level properties of their code.[1] They found it super helpful.

> I'm not saying it never happens (does TLA plus make sure everyone's assuming SI units?), but that hasn't been my experience at all.

'Fraid it probably can't help you with the SI units. I'm thinking about "design bugs" more like this:

> 1. Suppose we have a document with version 57

> 2. A bulk of delete and reindex will remove the index-v57, increase the version to 58 (for the delete operation), then put a new doc with version 59. While the engine places the index-59 into the version map, the safe-access flag is flipped over (due to a concurrent fresh), the engine won't put that index entry into the version map, but also leave the delete-58 tombstone in the version map. The delete-58 tombstone is stale because the latest version of that document is index-59.

> 3. Another bulk of delete and reindex will increase the version to 59 (for a delete) but won't remove docs from Lucene because of the existing (stale) delete-58 tombstone. The index operation will append document (version 60) to Lucene (instead of overwriting). At this point, we will have two documents with the same id.

Which was a bug TLA+ found in ElasticSearch.[2]

[1]: https://dl.acm.org/doi/10.5555/1779934.1779955 [2]: https://github.com/elastic/elasticsearch/issues/31976#issuec...

TLA+: you mean the transitions of one variable are formally proven. Whilst a plus, this is not that different from how compilers were written since the 1980s.

Never saw any crash happen there.

You should think of these systems like you think of garbage collection. They lower (sometimes eliminate) one particular kind of problem, and that's it. It does not prove the code works, doesn't OOM, doesn't segfault, doesn't dos itself, doesn't enter infinite loop, etc.

AWS S3, as far as I know

The design of S3 was formally specified, but not the actual code.

I would count Simulink RT as formally sound and safe, because you can only wire matching boxes together. Graphically. It's the standard in Automotive, flight stuff also I heard.

I do actually have a bit of Simulink generated code in my current project. I absolutely do not consider it to be formally anything. It's one of the highest risk areas of the project IMO because it is very complex and a very black box.

I worked with a Simulink-generated system in a previous job. The generated code was absolutely unreadable by humans, and honestly downright ugly. I agree, it is very high-risk because it is a black box.

I've used Simulink to model dynamic systems. I would say the C code it generates is "safe" in terms of memory access that can be used for embedded systems, but it does not check for undefined control behavior.

I did not only use it, I generated a C++ compiler backend for it. Of course is generated code ugly, that's not the point. It's generated.

Logical problems (and problems in C extensions) are of course always possible, therefore you have Stateflow and other methods. Other formal methods cannot guarantee that neither.

The Ada language allows for a subset of the language called SPARK (not to be confused with the Java framework).

In Ada you can do Design-by-contract but in the SPARK subset you can actually formally prove the implementation's correctness.

SPARK is used to my knowledge in rail signalling system, air traffic control systems, Class III medical devices, and now also NVDIA plans to use it for sections of their ADAS platform.

I think the cost aspect is overblown. The biggest issue is that anything related to Ada is not really that well known and often what is known is based on stereotypes from the 80's. Also for most people they would not see it as career growth move to switch to an Ada based technology stack.

seL4 comes to mind. Also IronFleet[1], which is small but end-to-end verified in Dafny. People tend to verify the cores of complex systems, not the entire thing. See here[2] for more on that.

I suspect there'd be a lot of stuff using either SPARK or Event-B, but Tokeneer[3] is the only thing I found with five minutes of Googling.

[1]: https://www.microsoft.com/en-us/research/publication/ironfle...

[2]: https://www.cs.purdue.edu/homes/pfonseca//papers/eurosys2017...

[3]: https://www.adacore.com/tokeneer

I've looked into formal verification in the past and from what I've seen it boils down to either annotating your source code with constraints that are then checked to verify the software does what you say it does, or you write a specification in a separate language that is supposed to represent the intended functionality of the system and then you write the system such that it matches the specification.

The problem in both these cases is that "formally verified" just means that you verify your specification doesn't violate anything you've said it shouldn't, but you might have written your specification incorrectly, or your specification might not match what you say it matches, which then makes the whole thing irrelevant.

That's not to say there's no value in formal verification, but I tend to see the value more in verifying some tricky protocol or very concurrent thing works properly (because these often have subtle bugs that are very hard to detect from inspection), rather than as a way to verify that your whole system works.

Plus for autopilot, how would you even specify that? The problem is too big and ill-defined to be specified in any way that would be amenable to verification. Of course, individual sub-problems could be verified but that's no guarantee that the system as a whole works.

is it not possible to specify global constraints and verify the code against that ? (ex. minimum 2 sensors should give an estimate of each attribute, vehicle should not be able to crash into anything, hierarchical control modes for sensor failure, etc.)

You can definitely do the first of those examples and probably the last of the examples, but the middle one (vehicle should not be able to crash into anything) is really hard. How do you prove the vehicle can't crash into anything? What do you specify in code to ensure that? I guarantee whatever specification you make I can come up with an edge case that it won't handle. That's the main problem with specification, not that it doesn't work, but that we don't know enough about what a solution would look like to fully specify it.

And just to dive into this a little more, let's say the first example you gave fails, and we have one sensor saying something is 10m in front of us and the other saying there's nothing for 100m, what do we do in this situation? Well, it depends on the context, maybe the one sensor is picking up a bit of retread tire in the middle of the lane and we can just drive over it, or maybe the other sensor is malfunctioning and there's actually a bear in the road. I don't think there is an easy answer to what to do in general just given the sensor state.

Thank you

I'm disappointed Tesla's safety-critical driving systems are developed using C/C++ instead of a safe language like SPARK Ada. I hear SpaceX also uses C++ for onboard ship software.

I can understand there are compatibility issues at play wrt embedded systems, but aren't there ways to formally verify C/C++ code ?

Good luck finding any software engineers who are proficient in Ada, much less a variant of it.

I mean, they're out there: according to the SPARK Wikipedia page, it's been used in things like some Rolls-Royce jet engines, some military planes, some air traffic control applications, a cubesat project, etc. But there's orders of magnitude more engineers out there proficient in C and/or C++, plus even if you're willing to train, it's not that easy to find engineers willing to move into something that doesn't have broad industry support and might therefore limit their future career moves.

C and C++ are already both used for safety-critical systems. MISRA C is the standard in automotive, and there's civilian (DO-178C) and military standards for C++.

The only guarantee we most likely have is that you can hard kill it with an off switch or possibly by hitting the brakes. The higher steering logic runs on ML anyway and I don't see a way to formally verify the behavior of an algorithm trained on a set of one billion road pictures.

Wilson Williams responds:

“ If you ever need a solid ideas man with no coding knowledge whatsoever, hit me up.”

To which Scott Lawson responds:

“ Ideas are cheap, execution is gold.”

Finally Wilson again:

“ Anyone can learn to code, you can't learn how to have good ideas.”

I assume Wilson (I’m using their names as presented) is kidding, in which case it’s very funny.

I don't think he's kidding. Most people think that being a "good ideas guy" is how you succeed without understanding that everyone has those ideas, but few can execute them. I'm sure many of us in tech were approached by friends and family with amazing app ideas after iPhones became popular without understanding that ideas are cheap and getting a product launched is the hard part.

He’s not kidding for sure

I miss C++ a lot. The modern standard library is a thing of beauty IMO. Such a shame that I could not find a good gig when I was looking few months ago, at least not where I am.

Looks like Tesla though are doing C with C++ features rather than C++. I'd also be interested in knowing what their "hardcore" questions are like...I heard that they ask a lot from your past experience.

> Looks like Tesla though are doing C with C++ features rather than C++

Tesla's UI is in Qt 5 which is fairly C++

Good point. Whenever I see a job ad advertising C/C++ together, it's basically saying "we do C with objects".

> "but all must pass hardcore coding test."

The time necessary for this means a huge opportunity cost for every applicant.

Ok. Recently few layoff happened at Tesla. New hires are a replacement.

Can’t they just build it all in React? /s

Why not rust?

Or Java? /s

Karpathy is building the NN backend in PyTorch, for which C++ is the most popular deployment language.

Because then all the biased reviewers and short sellers would spread wild rumors about how your Tesla car has this rust in it, and you need to get it coated with POR-15. It's a huge deal breaker for them.

Rust's ecosystem is genuinely nowhere near the maturity of C++.

Can you elaborate on this, or point to a good source of more info on the topic? As a longtime C++ programmer starting to look at Rust, I'm quite interested.

Libraries, compilers, text editors, debuggers etc. Languages in isolation are a tough sell.

* crates.io has a ton of libraries. C interop doesn't look that hard.

* whats wrong with rustc

* Intellij rust is a neat editor. You'll need clion for debugging though.

Those are examples of some sort of ecosystem. I didn't say rust doesn't have any, I'm saying it pales in comparison to C++.

Please name one GUI library written in Rust which is widely used in production.

Exactly, there are none (yet). Unlike C++ which has Qt and WxWidgets which are all mature open-source GUI libraries and are used in production and seen in the wild.

I'm guessing that you think there's an agenda behind my question. Just to clarify, I really am just trying to understand the current lay of the land regarding Rust.

It is just an open question about the state of mature cross-platform GUI libraries in Rust. My point is that the current state is that compared to C++, the Rust ecosystem is not mature (yet) and there are no production ready cross-platform GUI libraries written in Rust.

That is one setback when trying to consider using Rust for cross-platform GUI development.

We seem to be talking about safety-critical systems here. You don't need a GUI library for a safety-critical application, nor is any GUI system ever safety-critical (though it could interface to safety-critical systems).

This is a great question. Don't they want to be as safe as possible? Hiring a "ton" of C++/C engineers quickly is a recipe for disaster.

Exactly. We have to stop writing more C/C++ one day; can we at least autopilot down our freeways, and eventually colonise Mars on the back of a safe and secure language like Rust.

Rust for the Red Planet

Rust for the 2020s

Mars is covered in Rust

It just makes sense :-)

C++ != C

Flamebait :)

How so? They are different languages and different skill sets.

Recruiters shouldn’t group the together.

I have yet to meet a C programmer who can actually write C++ code. They just use the C++ compiler to write C compatible code.

I'm pretty sure that that would evaluate to false in C++

It's undefined behavior (in both C and C++), so it can evaluate to true and false at the same time.

It wasn’t meant to evaluate. It was a lazy way to say that they are two different languages and only people who have no idea, recruiters, group them and treat them as one.

Ah, Elon needs more sweatshop programmers?

Reply on news.ycombinator.com