I think I get way more friction from:

- library authors that go crazy with generics.

- the million ways rust makes performance tradeoffs explicit (even when you're writing part of the program where performance simply doesn't matter).

- the million-and-one things you can do with an option type.

- the arcane macro syntax.

I could probably go on. I've been writing a lot of rust because I wanted a low-ish level language with good C interop, and I didn't want to learn C++, so I wasn't at any point a rust fanboy. I very much appreciate not having to be a genius to avoid segmentation faults, but other than that, I think rust is a somewhat ugly language - for the simple reason that it has a lot of features, some of which partially overlap, and most of which are vaguely inconsistent.

I'm probably sounding a bit harsher than I mean to - obviously, you can't expect a language like rust to have the simplicity and consistency of something like lua, and by and large, it's better than anything else I write programs in.

Still, the point is, as somebody with a lot of (fair and unfair) complaints, the burrow checker is not one of them. It complains rarely, and when it does you're almost always doing something stupid, unless you're doing something fairly arcane, in which case, you should probably use unsafe.

Rust effectively forces you to code like you're writing a multi-threaded app even when you aren't. There's a reason why people suck at writing multi-threaded apps: because it's hard. This is what people are fighting when they fight the borrow checker. And this is why so many people find it frustrating. There's all sorts of designs that flat out don't work or are way more effort than they're worth.

It just turns out that mathematically proving GC-free code to be free of use-after-free and double-free errors is really difficult unless you disallow a lot of things.

https://doc.rust-lang.org/book/ch04-02-references-and-borrow...

> At any given time, you can have either one mutable reference or any number of immutable references.

In practice, this is unworkable enough that it would basically forces you to reference count the Foo, so you could preserve pointers across calls by incrementing the reference count.

On the other hand, Rust's approach is suboptimal in cases where you're using reference counting anyway, or are willing to pay the cost of reference counting.

C also makes you think about ownership in your API design, it's just the language doesn't give you any real tools to express or enforce it. C++ gives you a bunch of tools and options, but you have to hope that you and the API you want to use agreed on which subset of the tools to use.

Garbage collected languages specifically take memory management out of the API design by declaring that the runtime will take care of it for everyone.

If you want lifetime to be something an API can control, then I think Rust's approach makes sense even though it obviously adds complexity. If you don't, then, yes, removing it from the equation definitely lowers the API design burden.

In many ways its analogous to having language support for strings. In C/C++, you gotta hope that the library you're using has the same approach to strings that you want (std::string? char*, wchar_t?, something else?). In newer languages, it's just a given. (For better or worse: because then you end up stuck with UTF-16 in some languages.)