I think it's incorrect to state that Rust 'forgot about Ada'. Rust was designed to approach safety in a very different way. Ada's take on safety has an emphasis on strong semantic typing and run-time correctness. Rust's take on safety emphasises compile-time correctness. Very different. I would argue that compile time safety is a better way to go but everything has trade-offs to consider.

Rust's borrow checker gets bad press because it forces programmers to confront their unsafe programming methodology and fix it. I think it's beautiful and ends up teaching you more rather than cultivating a culture of 'let me do what it takes to shut the compiler up so I can ship the product'. I find it very disingenuous to write the language off because it strives to be militant about safety.

Oh and Ada's compiler is super testy too! It just doesn't get the same bad press simply because far too few people use Ada compared to Rust.

I personally think that the reason people fundamentally add a moniker like 'Duncan MacLeod' to Rust is simply because Rust has gotten far too many things right and that irks dyed in the wool folks. Especially given that the choice of programming language is often enough a more emotive issue than a technical one. Having been one such person myself, I see a lot of folks spout FUD as a default position when confronted with evidence of the good design choices Rust has made. This is true.

Now that does not mean that Rust is perfect - not at all. However, it's safety features, in the face of high performance - are very compelling. Once folks draw a box around the emotive aspects and start doing objective analyses, Rust does make one pause and ponder. That's the reason why there is evidently a growing sub-culture of Rust enthusiasts even within large traditionalist companies like Google, Microsoft, Intel and Arm, to name a few.

Back to the point (!) Ada simply became too niche despite aiming to be general purpose by design. Today the open source Ada community is small compared to the Rust community and I think that is a huge problem for the perpetuation of the language, irrespective of the subset of high profile folks who've switched to it from C.

A large and vibrant community is the reason why Rust's future holds more promise. The language evolves by open source consensus-by-merit (on Github!) and that's a very strong proposition for it's future. Balancing nimble-ness and backwards compatibility has worked well thanks to the editions feature (something that C++ has now borrowed from Rust).

I'd love to see Ada succeed but at present I personally think Rust stands a better chance. Time will tell.

No need to talk about Ada in the past, it is alive and doing well, with more deployments into production that Rust currently has.

Yes the open source around Ada is not that big, not all programming languages need to embrace free beer to stay relevant, if they have something worth paying for.

Right now, they have the certified compilers, ISO standards (open source consensus-by-merit does not do high integrity computing), IDEs, debuggers, and 40 years of experience deploying code into production.

What irks me about Rust is statements like "Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge", which resemble the meme that "Rust Evangelism Strike Force" has become.

The only thing that this does is turn off the attention from anyone in the known about what Rust might bring into the table.

Finally, Rust's borrow checker also gets bad press, because it still considers invalid code that for a human is perfectly clear that it should compile, hence the Polonius ongoing effort. It also makes it quite hard to do any kind of GUIs without spreading Rc<RefCell<>> everywhere, hence Raph Levien efforts how to improve writing GUIs, and the regular GNOME/Rust meetings.

C++ has not borrowed epochs from Rust, some people were supporting a proposal, which was discussed at Prague meeting and deemed impossible to have such feature without spreading ABI breaks across TU or module interfaces.

"No need to talk about Ada in the past, it is alive and doing well, with more deployments into production that Rust currently has"

Of course. You may have misunderstood my intent - I'm not disputing Ada's strengths or it's penetration. I'm asserting that it does not have the same degree of general purpose appeal that Rust has today.

"Yes the open source around Ada is not that big, not all programming languages need to embrace free beer to stay relevant, if they have something worth paying for."

That's a very subjective opinion. I would assert that safety and security realities are forcing a fresh look at the importance of truly open source options. The mindset is now becoming more of - if you aren't doing open source then you are setting yourself up for pain - especially from a security standpoint.

"Right now, they have the certified compilers, ISO standards (open source consensus-by-merit does not do high integrity computing), IDEs, debuggers, and 40 years of experience deploying code into production."

Please read the thread above. I'm asserting that most software is not written for safety domains. While Rust has not penetrated the ISO26262 styled domains, those domains don't represent the bulk of software written and definitely don't dictate any given language's general purpose popularity.

Further: I would say that it is far less likely for Ada to break out of it's niche and appeal to the masses the way Rust has generally speaking. Also it is far more likely that Rust will make inroads into the functional safety space and given that it's already proving value in many general purpose segments it's likely to stick.

"What irks me about Rust is statements like "Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge", which resemble the meme that "Rust Evangelism Strike Force" has become."

Yes you seem to belong to the set that I was alluding to - and I mean that in a nice way. I too was in that set. On the balance of probability you will find that there is no need to get irked once you decide to make an empirical comparison of technical and strategic strengths of the 2 languages.

Also: 'Evangelising' empirically good options is never a bad thing anyway. Doing the same without any substance if definitely worth getting irked over. Not so in this case. Save your irk-cycles for something that is truly worth expending energy on - there's lots of that going around sadly.

"The only thing that this does is turn off the attention from anyone in the known about what Rust might bring into the table."

Again a very subjective and non-constructive viewpoint frankly.

"Finally, Rust's borrow checker also gets bad press, because it still considers invalid code that for a human is perfectly clear that it should compile, hence the Polonius ongoing effort. It also makes it quite hard to do any kind of GUIs without spreading Rc<RefCell<>> everywhere, hence Raph Levien efforts how to improve writing GUIs, and the regular GNOME/Rust meetings."

Agree. Partially. You're cherry picking but in this instance I think it's justified. The false positives with the borrow checker get a lot of attention. Furthermore, the Rust compiler's ability to infer memory lifetimes is evidently continually improving.

GUIs are a pain point but are now also getting attention. There are quite likely equally proportioned gaps for Ada as well. Or for any other language. Rust's larger community is definitely helping here.

"C++ has not borrowed epochs from Rust, some people were supporting a proposal, which was discussed at Prague meeting and deemed impossible to have such feature without spreading ABI breaks across TU or module interfaces."

You are quite right. It was a proposal and not a definite pick up of Rust's editions. That's still useful insight and acknowledgement of the predicament that C++ finds itself in when balancing nimbleness in terms of change and backwards compatibility. Rust has evolved a reasonable solution to it - in part because it's standing on the shoulders of giants but more thanks to the fact that it's a community consensus driven language and not a drive-by-ISO-committee language which C++ evidently is.