Yep. It's the same performance ceiling. Borrow checking is not the panacea its made out to be. It's just enforcing single ownership.
What part of scanning through some immutable array of bytes to-be-parsed would be so definitively better in Rust?
Any sensibly written parser code would result in the compiler optimizing away all reference count operations. Only the most naive ARC implementations mutate the count for every reference pass implied by the source.
So again... why would it be a sensible choice to use Rust at Apple, where they created and use Swift heavily? Where the problem is that they're using some old unsafe parsing library instead of one written in a safer language?
"A sufficiently advanced compiler will optimize all the overhead away" is the standard line for all high-level languages with automatic memory management. It works for tracing GC too, you just need "sufficiently advanced" escape analysis.
Unfortunately it means there are always performance cliffs: you make some change to your code that looks innocuous and suddenly your performance collapses (e.g. because a function is now too big to be automatically inlined, so certain optimizations don't work anymore) --- and you don't understand why.
I agree that could happen, but a parser would have to be coded pretty strangely to disable these basic ARC optimizations. I don't imagine a parser needing to hold and release references beyond the call stack.
In this vein, both Swift and Rust performance will succumb to any number of their IL-level (and LLVM's IR-level) optimizations being disabled by some seemingly orthogonal change to the source code.
Either way, I hope Apple (and others) can squash this entire category of bugs soon!
