"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.
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.