Is Rust Really a "Holy Grail?"

I decided to catch up on one of the lapses in my current knowledge of technology by reading Seth Rosenblatt's article about Rust for CNET Reviews this morning. For those unfamiliar with the name, it has been applied to the latest attempt to design, implement, and deploy the ideal programming language. I have lived through several generations of such attempts, including ALGOL, PL/I, and, of course, the notorious close-enough-for-government-work Ada. Since I subscribe to Isaiah Berlin's proposition that an ideal state is one from which you can no longer advance (since any change must be for the worse), I feel I have a right to be skeptical.

Here is Rosenblatt's summary description of Rust:

Rust is an attempt to create a programming language to replace C++ with one that can handle today's heterogeneous, multicore hardware better while also being more secure. According to Mozilla Research's FAQ on Rust and Servo, on which it plans to build a new Web browsing engine like the heavily-used WebKit, Mozilla's own Gecko, or Internet Explorer's Trident, the new language will stop "entire classes of memory management errors" from causing crashes and security vulnerabilities. 

The other major hallmark of Rust is that it has relatively easy-to-use programming language primitives, the simplest level of programming language expressions available to programmers, that are expected to make it much easier for software developers to use modern hardware's multicore central processing units.

Needless to say, it is easy to be critical of these foundations. Hopefully, computer science students are still taught that there are only a handful of primitives necessary for "universal" computation; and they have always been easy to grasp. So the second paragraph is a red herring.

I am willing to grant the first paragraph. However, the literary side of me tends to cringe at the thought of a programming language named for a process of oxidation that usually results in the deterioration of what were intended to be solid metallic structures. Nevertheless, I am less worried about metaphors than I am about Mozilla's priorities. Ever since the days of ALGOL, it has been recognized that even the most daunting challenges of algorithm design pale against the problem of how those algorithms engage with the operating system over such ugly necessities as file management, input streams, and, that area that has been chronically neglected by every generation of Firefox, printer control. Yes, we need quality algorithms to manage the inner guts of computation; but, without an effective superstructure to manage interfaces, those guts may as well be the proverbial tree falling in the forest with no-one around to hear.