Sorry, the text in quotes is my own, I'm not quoting anything. Probably I should have found a way to write that without quotation marks.
Rust added a new borrow-checker implementation, "non-lexical lifetimes" (NLL) in December 2018, as part of introducing the 2018 "edition" (a compile-time flag that says what compatibility level you're targeting, roughly analogous to --std=c99). In 2019, they backported it to the original 2015 edition and removed the original implementation, "AST borrowck". As the names imply, NLL has the ability to handle more complex patterns without assuming borrows are live for the entire lexical scope just because it's accessed somewhere in a pair of braces; this turns out to be very useful in practice, since a lot of natural patterns (including those written by beginners not trying to do anything complicated) trip up the older implementation. However, NLL initially accepted some code that was invalid, and it was shipped anyway, and at least a couple of production Rust users ended up writing things incorrectly accepted by NLL. See https://lkml.org/lkml/2020/8/23/214 for my summary of what happened with some links. (I don't think this caused any problems in practice; my sense is that it was undefined behavior, which shouldn't be possible in safe Rust, but the compiler almost certainly chose a behavior that happened to match the intended semantics.) And there's work in progress on a new borrow-checker implementation called "Polonius."
All this is to say that, if you wrote a paper in 2018 saying that Rust's (AST-based) borrow-checker feature is great and Ada should pick it up, you're still behind Rust because there's a new one. If you wrote a paper in 2019 and based your work on NLL, you stood a nonzero chance of picking up that bug. If you write one today, maybe you should base your work on Polonius, but Polonius will itself probably take a fair bit of real-world use to shake out its own bugs.
> It's easy to find projects on Github where dynamic allocation is used; e.g. https://github.com/ghdl/ghdi
Thanks, that's useful!
Though (and maybe this is my unfamiliarity with Ada), from some quick looking around to see where it dynamically allocates, I find https://github.com/ghdl/ghdl/blob/master/src/synth/synth-hea... , which seems to bind the C malloc function and intentionally not bind free and leak all memory, am I reading that right? That's definitely safe but suboptimal.