> For instance, a developer writing the software for the sensors of a forklift

Industrial is a very poor choice of counterexample. You should have stayed with consumer space counterexamples. Everybody in the industrial setting wants their telemetry and data transmitted to centralized computing whether they know what they are going to do with it or not.

As for sensors, how are those distance sensors connected to the microcontoller? Perhaps a redundant automotive bus with real-time constraints like CAN? CAN often has a fairly decently sized, badly written, vendor supplied communication stack in order to use it.

Is that forklift's sensor telemetry going anywhere? If not, then you're probably going to lose out to someone who does when you sell that forklift to Amazon or WalMart. They probably want to know about where the skulls are (gotta track those lazy humans) more than they want to know about where the forklifts are.

> Are all these ARM? NO.

Actually, they increasingly are. USB-C PD negotiation chips, for example, are basically ARM M3/4 cores with specialized hardware. The cost differential between 8-bit and 32-bit microcontrollers is so low that unless you have extreme volumes, you might as well use the 32-bit one and gain all the infrastructure that provides.

> Are all these connected to the network? NO.

Are you sure? Hotel locks had security vulnerabilities because they had a USB port.

The problem isn't whether I can use the I2C bus on your Cuisinart to break into it--if you used a "standard" driver written in C I probably can. These small system don't have to worry about "secure" simply because they aren't worth breaking into--until some really creative person makes them worth breaking into. (Hey, there's a speaker on that innocuous thing that's loud enough that we can talk to Alexa. YAAAARRRR, Me Mateys!)

For Industry 4.0, yes telemetry is important. But, not all industrial cares about telemetry. In that case, what I have seen, is that all the data is sent to a concentrator that has the network stack. This is often a "high-end" (perhaps Linux based) machine with network access. Is not that every chip in a system is connected to the network. For what Rust matters, I'm really want to see high-level stack written on it, or libraries like libssl. I think that's where Rust should be placed not going any lower (in levels/layers).

Regarding ARM, it depends. It's not just a matter of bits over price. Pretty often the combination of features you want are not available in an ARM chip. For example, long term support, some specialized tool, temperature/power supply range, price, available peripherals, etc. And sometimes you might be required to work on some strange 32-bit CISC from Renesas just because the salesperson took the purchasing manager to dinner somewhere.

And yes, everything is hackable no matter the language you use. If you open the case and cut some PCB traces you might read and inject some data making some device to misbehave. But that's the way it is and I don't see the world falling apart because of this. If it really matters, then (electronically) tamper-proof your case would be my advice.

Again, is my honest opinion and the opinion of many embedded developers I work and know: vulnerability FUD is just noise. I'm just being sincere. Of course if you make locks you have to make your system secure. The other billion of embedded applications might not. And that's it.

> Pretty often the combination of features you want are not available in an ARM chip.

No argument. But this is becoming less and less true since ARM has even become standard in automotive.

> And sometimes you might be required to work on some strange 32-bit CISC from Renesas just because the salesperson took the purchasing manager to dinner somewhere.

HAH! Been there ... screamed about that.

We're probably not as far apart as you think, if I'm just writing 100 lines, I'll just reach for C and be finished in an hour or two.

My problem is that none of my projects ever stop at 100 lines. They evolve and only get bigger. Eventually they adopt a "stack" (CAN, BLE, TCP/IP, etc.) from some manufacturer, and it's all downhill from there.

I need help to manage that explosion of complexity and the torrent of bugs it creates, and C just doesn't provide it. I don't think I've programmed an embedded device smaller than the original PDP that K&R developed C on in probably 10 years--maybe more.

And this includes FDA cleared products. The days of just sitting on an unchanging product for 15 years after getting clearance are gone.

> For instance, a developer writing the software for the sensors of a forklift has enough to worry about to not crushing the skull of someone passing near it.

And you don't think having the compiler check memory usage would be useful in this case? In my mind it means more effort can be put on making sure the logic itself is correct.

Maybe, but what checks would the compiler do on my small embedded memory for a program that processes a sensor and raises a pin? It might sound simple but it's an important core project.

Would the compiler check a write outside the buffer that is filled with sensor data? Is that it? I'm not allocating anything so I cannot double free. The program executes in a main loop so there is no data races (perhaps one if the data buffer is shared with an interrupt, but it's a problem as old as the bible and we already have 1000 libraries with safe circular buffers).

Or is the check done at runtime? Will it waste my cycles?

Is that all I should change my language for?

Would the sensor manufacturer help me if I give them a failing case written in Rust?

Is it worth the risk of compiling on a nightly thing that will change next week? Note that people might get hurt for real.

Damn! Now my MCU/sensor is going NRND. Should I freak out because Rust is still not supported for that new MCU yet, and I should write the thing all over again?

While I may not agree with your opinion, I upvoted you because your position is certainly not uncommon and saw your reply go grey. And that irritates me.

I'm getting really pissed off about people downvoting who have nothing constructive to add to the conversation.

Rather than downvoting, fucking REPLY. A downvote is lazy--it's actually worse than doing nothing on a low-vote thread--it's a sin on the level of turning down the premise when doing improv comedy. An articulated position furthers the conversation and actually represents effort.

When did HN readership become such prissy hothouse flowers? FFS.

(EDIT: I turned down the swearing a bit)

I don't actually disagree with any of what you're saying. My only point was that Rust's safety checks and features are useful for embedded. There are obviously many other considerations when making a decision about what to use on any given project.

I suspect Rust will be a clear win on some subset of projects, and will not be worth it others.