I clipped most of what you said as redundant, but it works out to be basically the exact same thing as if they hadn't switched to rust or at least that's the case so far. Additionally, IE/Edge's code base is the newest, not Stylo (2019 when they again switched engines to one chromium based v. 2017)
Rust type system ensures you cannot have a memory error if you do not use unsafe code (marked explicitly as unsafe in the code).
I didn't overly comment on it because I left it as a task for myself to investigate more, but the UaF in question in framing, at least in theory, is something that Rust could realistically encounter. The way the objects work is basically two pointers, one to the data and one to the virtual function table. A temporary object can exist and it can be typecast to another type, which is essentially a second pair of pointers with a different pointer to a different virtual function table. Ideally, scoping rules should prevent a confusion on the part of the machine in terms of which object you're referring to-- you can't access the temporary object outside of its temporary scope, but this is actually something relatively common especially in amd64 architectures where the optimizer concludes you're done with a temporary and omits language specific code that would have made things safe (akin to the omission of an explicit NULL pointer check because analysis concludes the pointer has already been dereferenced), which results in a dangling pointer being held in a register that you end up using. There's nothing as far as I could tell in Rust that protects you from that because there aren't any borrow checking related rules that prevent it and its using the same backend for machine code generation as C/C++. This will likely become more applicable as they move towards supporting dynamic inheritance, but as I said, I mostly omitted my thoughts after review because its too soon to speak and I wanted to research it more.
One does unsafe Rust only for linking with other languages, hardware access or performance.
And as it turns out, many types of typecasting operations where the only way to do so is to use unsafe, which is why even though I agreed with you it was probably in the C++ code that it at least in theory could have been in Rust. I'd have to go back through my notes, but a lot of people seem to be using std::any and something along the lines of as_ptr which is unsafe and the borrow checker won't protect you from mistakes under such circumstances-- things like this, a very common operation arguably necessary in many use cases/design patterns that forces people to rearchitect everything or use unsafe is likely why there's probably a decade or two's worth of these types of discussions. Put simply, for integration into real-world software, it seems in many ways Rust isn't ready and where it is it commonly requires the use of unsafe in order to meld it into an existing product. I suspect it will probably be 10-15 years or more before we see their javascript engine rewritten if they ever do it at all for precisely these sorts of reasons, and when they do, it will likely produce more bugs than their C/C++ counterparts.
A need for unsafe code for performance is more likely related to a design not adjusted to the linear type system of Rust.
This is true to varying extents, but I don't think you realize how common some patterns are and the extent of redesign that will be required. Just as a (bad) example but one I have off the top of my head, the entire journald journal format is written using flexible array's (this is a C structure that has a trailing array element of zero length, where the idea is you can get the offset to the beginning of the array but its contents will be dynamically filled in and its length calculated at run time). To interoperate with this in C++, which doesn't support this concept due to a stricter typing system, I had to wrap the code in question with pragma's that ignored warnings. To convert such a system to Rust would entail a dramatic redesign because its central to the way the piece of software operates and the language view of things is that every or nearly every write is actually to an out-of-bounds address. This is a bad example, but dynamic inheritance is really common and the related sort of typecasting that is used is kinda sorta supported in Rust and presently mostly relates to using unsafe code, moreover, there appears to be relatively nothing in terms of the language to make the sort of bug that cropped up safe, as I noted, in theory it should be possible even if under somewhat rare edge cases, but it will require more review to definitively discern.
Therefore I would guess it is likely some cooperation with C++ code. But who really cares. Rust looks quite good so far and whether it really is good will reveal itself in few years when more data about memory errors in Rust code is collected.
You may be right, time will tell, but what I've seen so far is that interop with C++ is probably something mostly here to say at least for the next 10-20 years, maybe longer. Moreover, my guess is that when we get down to brass tacks that we will find that unsafe code ends up being so common that you end up with more memory bugs, not less.
As for as Linux kernel ... we will see. I think it is likely worth it for new drivers especially if they can write safe Rust wrapper over linux driver interface.
You may be right, but I probably wouldn't get my hopes up. My guess is that in a few years or so we re-encounter each other on the forums under a story headline questioning the future of the language once Mozilla finally tanks and the community steps up to entirely OSS/FS it, which basically ends up killing off language extension and keeps people using unsafe constructs forever.
