Please only speak for yourself. Long-time C++ developer here. When I switched to Rust, I saw that experienced C++ developers already enforced coding standards that Rust basically "only" codifies in the type system. There's nothing inherently uncomfortable in Rust's borrowing rules.
Definitely not. It's the single most common source of single-threaded memory safety bugs. Not allowing it in safe code is one of Rust's core values. For the very few exceptional cases when you absolutely, positively cannot write code by obeying these rules, there's unsafe.
This is a very weak argument. A lot of old, outdated, sloppy, and/or bad coding practice could be justified this way. Before compiled high-level systems languages, we used to write machine code directly. This doesn't mean that we should still be doing it as a common (default) practice.
This; also his opinions are basically the exact antithesis of what Rust's values represent. So basing Rust core language features upon a Jon Blow rant is very problematic IMO.
To add to this, the shared/unique guarantees of references allow for significantly stronger prior assumptions to fuel aliasing analysis, which is an extremely powerful, and extremely valuable optimization. Modern C++, which works with a combination of const T&, T*, and std::unique_ptr<T> (in my experience, all other pointer types are Bad News), has its work significantly cut out for it to perform reasonable aliasing analysis. I say this as a professional C++ programmer.
To add to this- "most people" should never be implementing their own data structures, because getting them right is hard. I think there is little value to stapling Coq onto Rust to be able to do this safely, given that you'll need to utter unsafe to make any sort of efficient data structure. For example, trees want to be implemented with pointers into an arena rather than with the nodes owning their children. Even with Rust's guarantees, arenas can be tricky to get right.
I think the argument is not about literal custom allocators, but goes like this: If your code uses array indices instead of pointers, if you have a system where you "allocate" and "free" those indices, you're effectively performing the same job as an allocator, just in a more specialized way. Since the borrow checker does not track these indices, you can "free" an index and then accidentally use it later, which is the same basic type of error as a use-after-free. Not as dangerous, since it's memory-safe and type-safe, but you can still end up referring to stale data.
One counter-argument is that you can detect such misuse with techniques like what generational-arena does, but that does come with a performance cost, and it only detects the error at runtime rather than compile time.