Rust was invented with an elevator firmware use cases in mind. The inventor happened to work for Mozilla, so it got traction in the lower level parts of Firefox next.
It has explicit error handling and no exceptions. All mission critical C++ software I’ve worked on uses --f-no-exception and panics then restarts on out of memory.
Hardware errors were way more common than OOMs for those embedded code bases, and we didn’t have the testing budget to fault inject OOMs everywhere in simulation.
I know other fields still try to use the “handle all error codes” approach, but “let it fail then restart” is simpler and (in my experience and theoretically) easier to get to be reliable, especially in distributed environments.
This isn’t a new idea. For instance, during the apollo 11 landing, the guidance computer was crash looping, but managed to recover the trajectory enough on each loop to get to the ground. Look at the section about 1201 and 1202 alarms here:
> Rust was invented with an elevator firmware use cases in mind. The inventor happened to work for Mozilla, so it got traction in the lower level parts of Firefox next.
TechSpot is referring (without attribution) to an interview the MIT Technology Review did with Hoare, and tacked on a claim that Rust was invented "to prevent issues such as his elevator breaking down" that isn't there in the source material. Elevator firmware is not systems software in any case, and the Rust manual Hoare authored states:
> Rust's goals arise from the context of writing large programs that interact with the internet -- both servers and clients -- and are thus much more concerned with safety and concurrency than older generations of program.
The language described there relies on a much larger runtime than Rust today does. It is no systems language. Later it even grew things like the @ garbage-collected pointers.
Those would eventually go away as it turned out that people writing apps don't want to think about memory at all (and are better served by using a real apps language) and Rust instead started embracing its potential as a systems language:
> Although Rust didn't start out that way, one of the most interesting applications of Rust has been very low-level programming, even down to the level of kernels. The interest in this application of Rust was something of a surprise to us, but in hindsight it makes perfect sense. Low-level control over memory management isn't something that most applications software, especially on the server side, wants; most of that software has migrated over to languages like Java, Ruby, and JavaScript that trade control and performance for convenience by making memory management automatically, and dynamically, managed by the runtime. The remaining class of software, most of which is written in C and C++, is software that must manage memory manually in order to achieve some combination of performance, simplicity, and/or the ability to self-host. The prospect of using a new language for this class of software, which includes OS kernels, game engines, and browser engines among others, is what is fueling the growth of the nascent Rust community.
For a lot of systems software, and I am thinking of system service managers ("init systems") in particular, failing and restarting is not viable. OOM conditions must be recoverable. Rust has recognised this and is trying to correct the course they went down in its early days of ignoring this, being unimportant for an apps language, but vital for a systems language.
One feature they have taken to is throwing panics on OOM conditions:
These "panics" can unwind the stack and be caught with panic::catch_unwind, but with the proviso of only "sometimes". If you take that at face value, then it's not a very useful feature. The implication in the issue linked above however is that this could become a viable way to recover from OOM conditions. And the mechanism proposed there is indistinguishable from exceptions other than that it's insisted that it has nothing to do with exceptions and that you can't rely on it catching panics for you.
https://www.techspot.com/news/97654-how-broken-elevator-led-...
It has explicit error handling and no exceptions. All mission critical C++ software I’ve worked on uses --f-no-exception and panics then restarts on out of memory.
Hardware errors were way more common than OOMs for those embedded code bases, and we didn’t have the testing budget to fault inject OOMs everywhere in simulation.
I know other fields still try to use the “handle all error codes” approach, but “let it fail then restart” is simpler and (in my experience and theoretically) easier to get to be reliable, especially in distributed environments.
This isn’t a new idea. For instance, during the apollo 11 landing, the guidance computer was crash looping, but managed to recover the trajectory enough on each loop to get to the ground. Look at the section about 1201 and 1202 alarms here:
https://en.m.wikipedia.org/wiki/Apollo_Guidance_Computer