So the reason Rust is slow is because C++ has features that allow programmers to write faster implementations of the same algorithms? I think that's the point he is making.
His point was that fundamentally Rust will have overhead by being safe, and that it's necessary to drop into unsafe to match the performance of C++.
He takes this further, stating that if you're going to drop into unsafe for hot code, why not just use Java/Go and FFI into C++.
This is misleading or incorrect for a few reasons.
* Rust isn't considerably slower than C++ (again, the benchmarks are total nonsense and way out of date)
* The performance differences are not a matter of safety features (such as bounds checking array accesses), but separate features like constexpr, int generics, and SIMD.
* His statement on Go/Java ignores that Go and Java will pay a significant cost for calling out to C/C++ for the "hot code"
As an aside, Rust now has explicit SIMD, and there's progress being made on `const fn` (the contexpr equivalent) and int generics.