I laud the effort and I understand that rust gets a lot of visibility here on HN, but when the motivation is to improve security, than why not use a language which goes through great length of ensuring such, e.g. the SPARK subset of Ada?
I have no idea what the SPARK subset of Ada is. But even if it is superior to Rust in one aspect or the other, the fact that you will have a very hard time finding any developers capable of using it kills it as an option.
It's the kind of infrastructure project that doesn't really attract much interest, I doubt there would even be a single external contributor if it were written in some niche language.
That's roughly the situation today with SPARK. Using Ada does not automatically buy you memory safety on the same level as Rust. You can get a lot further with SPARK, but the annotations are very cumbersome to write.
These are well-known problems in the Ada community. There are efforts underway to improve SPARK's ergonomics by adapting ideas from Rust, with the help of the Rust Foundation. Someday soon, Ada will be much closer to Rust's sweet spot on the safety/productivity graph. In the meantime, there are CVEs to patch.
I think this "popularity" reasoning is flawed. It completely misses the context of the tool. Just ask yourself -- are there many UNIX CLI tools written in Ada/SPARK? I'm sure there are some, but not aware of any I use regularly.
Meanwhile, there is a Cambrian explosion of Rust CLI tools taking place.
"Popularity" is really a surrogate for "popular, accessible, infrastructure for an OSS CLI tool for UNIX", a place where Ada AFAIK has not been a first choice. If we were building firmware for a missile guidance computer, maybe the reasoning would be different?
But it's still not a sufficient reason, so I'll add another: People really like using Rust to make these types of tools. It's amazing to me that people are so willing to discount as non-technical, and therefore unworthy of discussion, lots of people really like using Rust.
Computer languages are partially to communicate between people and computers, and partially to communicate among people.
Whatever optimizes for the accuracy of the instruction output is the best. Sometimes it means language features. But it can also mean its popularity so you can get many more human eyes on the same bits of code.
But more importantly, how many of them are contributing to open source is lower (or at least advertising that they know Ada & contributing)
In a safe language like Rust, the level of capability you get doing even say the first couple of weeks of AoC is enough that your small contributions to a project are likely to actually work and be more or less serviceable, so that's a huge help.
It reminds me of when the Ruby folks wrote their YJIT in Rust and there were a few Qs which were like -- Q: "There doesn't seem to be a security reason to write this in Rust, why not use C++?" To which, a totally reasonable A is -- A: "We like Rust (and there is no reason to be miserable forever)!"
People almost never choose a language for one reason (except for the people who use Ada, I suppose -- the reason is the government requires them to do so). Memory safety is a great reason to learn/choose Rust, but Rust is much, much more than memory safety.
Moreover, "Why are you ignoring Ada?" is "Why didn't you write/don't you rewrite this in Rust?" by a different name.
I love to see the broad move towards safer languages, but let's not forget that Rust is not the only safe language for system development. Plus iirc the model-checking ecosystem of Ada/SPARK is much more mature than that of Rust.