Proper Community Engagement

You cannot ever have multiple mutable references to the same array element (or any other object, for that matter), because the borrow checker forbids it (and if you cheat and do it anyway with unsafe code, it is immediate UB because of noalias). Without mutable aliasing, it's not possible for two different parts of the program to both think they own the Nth slot in the array at the same time.

The lack of mutable aliasing must be provable at compile time just from the types of the arguments. It immediately follows that you cannot conjure a mutable reference out of thin air in safe code - it must come from something you already own or another mutable reference. It does not matter whether you're indexing into an array or doing some more complicated dance. Mutability is transitive, and all of the relevant loopholes are either protected by unsafe (UnsafeCell<T>) or by runtime checking (RefCell<T> and most of std::sync).

In the specific case of the static fake heap, this fails on several different grounds:

0. All interactions with mutable statics are unsafe, because of thread safety. Unsafe code can, of course, do a UAF in Rust. That's not news, so in order for this argument to be interesting, the whole thing must work in safe code. But we can just pretend you said "a long-lived boxed slice" instead of a static array, so let's ignore this and continue.
1. To get a mutable reference to the Nth element of an array (or slice/Vec/whatever-it-is), you must borrow the entire array mutably. It is sound to take out multiple non-overlapping mutable borrows against the same array, but you are limited by the API exposed by slice (see e.g. slice::split_at_mut()) unless you write your own unsafe code to do it manually. Regardless, you still cause the whole array to be borrowed mutably until all element borrows are returned.
2. Your array borrow must outlive the borrow of the individual element. This means that whatever part of the program thinks it owns the Nth slot in the array must not actually hold a reference to the element (or else it would prevent any other part of the program from using at least that slot in the array, if not the whole array). It may only hold an index into the array, it can only materialize that into a reference temporarily when needed, and it must receive a mutable reference to the array in order to do that. The latter reference must be constantly passed around pervasively throughout your entire program, or else the array must be protected by RefCell<T> (single-threaded) or a lock of some kind (multi-threaded). RefCell<T> will panic if you try to mutably alias the array at runtime (the locks will block, as you might expect, and if it deadlocks, oh well, that's your problem). This is still technically possible, but it looks very ugly and not at all like idiomatic code (which is what DARPA says they want as output).
3. It is not legal to drop anything in-place in safe code, because the dropped object would still be accessible, and someone might try to use it. So when we say that the object is "freed," we mean that the bitmap no longer considers it to belong to anyone. The object still exists and has a valid value. Some other part of the code might mutate it (through this careful dance of never holding a long-lived reference to anything as described above) or even replace it with an entirely new object, but it cannot replace it with random garbage. It must uphold all invariants of its type, which may be arbitrarily complicated, and which are enforced through the use of visibility restrictions. This can cause logic errors, sure, but it is a far cry from a "real" UAF in which random bytes are interpreted as some entirely inappropriate type.

I will admit that DARPA's goals seem (at best) extremely ambitious to me. But if they do succeed, their generated code will not look anything like what you describe (or else they won't have accomplished what they now claim to be trying to do).

Filesystems have nothing to do with C. If you really want to learn about syscalls and how a computer works, you need to write or at least read assembly.

> And on top of that, learning C means it is generally easier to learn other languages after the fact. C's lack of rules and restrictions are a double-edged sword but it is typically much more direct to code.

C is full of rules and restrictions, they're just not enforced by the compiler. Try explaining undefined behavior to a new programmer! Of course, no-one teaches that, so students aren't really learning C, they're learning just enough to get the right output from one run of some toy code. And that's dangerous because they think they know how to write reliable code in C when they don't.

> Again, I communicate with professors and I would advise the same for you before making these kinds of comments

No need to be condescending. I have a PhD in computer science and a lot of my friends are professors at various universities in the USA and New Zealand. While we can have different opinions on what makes a good first language, what professors choose to teach is a matter of facts. Here's some actual data from 2019: https://research.leune.org/publications/ICCSE21-CS1CS2.pdf
See Tables III and IV. C has actually been minuscule for a long time; Python was rising at the expense of Java and C++. As far as I can tell from anecdotal data, Python has only accelerated since then due to the soaring interest in AI.

> 1. Python being a more approachable language for non-programmers meant that they were the perfect target audience. The mistakes are due to inexperience. But Rust is far from being the solution.

I agree! But Rust isn't the only option that's stricter than Python. That's why I highlighted Julia for scientific users, not Rust.

> You can have memory leaks in Rust, you can have poor logic in Rust, and you can have egregious mistakes in Rust.

I wouldn't push Rust for scientific users but this kind of argument is a common fallacy that's language-independent. You can make mistakes in any language, but there are large classes of mistakes that are prevented in some languages but not others, and that matters a lot in practice.

When you're publishing scientific papers, programming errors can have huge impact --- not just on the results, but on whoever depends on those results --- and using a language that catches more errors has huge value that in many cases would justify the extra effort required.

> Rust's first-mover "advantage" over "new-langs" like C3, Odin, and Zig will be erased

None of those languages can replace Rust because none of them provide the combination of performance and memory safety that Rust does (let alone the other kinds of safety Rust provides, like data-race freedom).

I actually think a simpler language than Rust that hits the same performance+safety target could be built and might be great --- try taking Rust and replacing its generics and macros with Zig-style comptime, but keeping the aliasing and borrowing model. But AFAIK no-one has even started trying to do that, and in the 10-20 years it would take to reach maturity if started now, Rust will likely be too entrenched.

Gotta love an argument by authority. Please bring actual data or logical arguments, not "some people with a title said so".

Also, speaking of professors, as a professor I happen to communicate with other professors regularly. Many of us think that Rust is a much better choice for a first language than C. C is a terrible choice because it's basically a big collection of foot-guns, and there's just not enough time in a semester to list them all.

But change is slow, so it'll take a while until CS departments pick up teaching Rust. Some already did, and more will follow I am sure.

Go’s trump card is Kubernetes, a lot of software gravitates around containers, which means there are a lot of building blocks already written in Go people can reuse (there is a strong batteries included effect like for Python or Java, and understanding Go is necessary to fix or adapt existing deployed code).

Rust people do not seem to understand there is a point where you need to stabilise the API/ABI and commit to it so people start writing long-term apps and publish reusable components. You can only go so far in Gentoo mode.