Most of Rust's safety is done at compile time and compiles away to nothing or is in the design of the apis that check you're not doing something dumb when you call them. So if you tried to copy a slice of a buffer in excess of a buffer it would panic but it wouldn't impact on performance any more than C code doing the same.
Obviously you can forego safety in C but that's the point Rust is trying to address - safety without penalising performance. That makes it perfect for IoT and its why the assumption that C can rest cosy because of IoT is a bad one. If I were writing any code for IoT I wouldn't choose C unless I had no choice. I might choose C++ assuming I could be sure of using only C++11/14 and nothing else. But I would choose Rust in preference to either of them.
I realise that's in theory. HTC have kind of fucked up in recent years and it's less to do with their hardware but how they've marketed them.
Yeah C is there and I haven't said any different. But it's a horribly dangerous language to code IoT and I expect that will reflect in the languages people choose to develop such devices over time.
The Nature article while more informative only provides a handful of selective quotes from the essay but still no link. Instead it frames the essay in the context of Churchill's interest in science. How about an actual link to the actual essay?
Either way Rust is a viable option providing the architecture is supported. Rust relies on LLVM to generate machine code so if LLVM supports an architecture then so potentially does Rust. It already supports a lot of architectures ARM, MIPs, x86 on Windows, Linux, OS X and a bunch of microcontrollers.
I'd also point out that at least one kernel HAS been written in Rust. I wouldn't seriously propose using Redox in its existing form, but it kind of pisses on the argument that even if we were talking about the kernel (and we're not) that somehow Rust is ruled out there either.
There is no way this is an acceptable alternative to just buying a battery and swapping it in. Some people might even carry a spare when they're travelling.
It is a very deliberate ploy by Apple to offer a replacement service but make it so expensive and inconvenient to use that they can maximize the chances that people just buy a new phone instead. As I said originally Apple aren't the only practitioners of this scummy practice but they pioneered it.
You can code review this subset of C++ til you're blue in the face but the next project over to you may not. Even some of the most reviewed and widespread code in existence has suffered serious errors that were the fault of the language. Look at the Heartbleed bug as one example. And it's extremely clear that when we're talking of software that powers IoT devices, or cars, or hydraulic presses in factories, or X-Ray machines or anything else which has a critical function that even ONE screwup could have catastrophic consequences. Even if your software has less critical failure modes, it's still a pain in the ass if it crashes, leaks, suffers mysterious race conditions or is exploitable because the code has to enforce its own buffer checks.
That's why Rust makes such a good fit for systems software. It shuts down an entire swath of potential programming errors before they can even happen. In the normal course of programming there are no pointers, or null pointers, or explicit memory allocation/deallocation. Things like strings and arrays are intrinsic types and are enforced against their length. Threads that share data MUST protect them with locks or mutexes or have ownership. Things that break in C/C++ at runtime are stopped by the compiler.
C and C++ aren't going anywhere I'm sure, but neither are they defensible by saying if you know the exact subset which is safe that it absolves all the stuff which isn't in that subset.
We are not a loved organization, but we are a respected one. -- John Fisher