[dralley]

>You'll find yourself constantly fighting the borrow checker.

In the beginning, yes, this is true. But most people learn within a month or two which design patterns lead to problems with the borrow checker and which work smoothly, and often this knowledge translates to good design in languages like C and C++ as well.

If you're fighting the borrow checker in Rust, you'd probably have been fighting segfaults and use-after-free in C / C++. I'd rather spend 30 minutes fighting the borrow checker than spend 4 hours digging around in Valgrind.

> Type signatures are littered with lifetime annotations.

You cannot avoid the concept of lifetimes, without a garbage collector. If you don't want garbage collection, you have to deal with them.

Having explicit lifetime annotations in the code is _vastly_ better than trying to track the lifetimes in your head from scratch every time.

[lawl]

> If you're fighting the borrow checker in Rust, you'd probably have been fighting segfaults and use-after-free in C / C++.

That is in my ( admittedly limited) experience just not true. There's plenty of things that are perfectly safe that the borrow checker just doesn't understand.

The borrow checker can prove that a subset of things is safe. But the borrow checker being unable to prove something doesn't mean it's not safe.

[giovannibajo1]

This, one thousands times.

The borrow checker forces you to write in the very narrow subset of code paradigms it can understand. When it fails to compile, it doesn't mean it's wrong: it means that it can't prove that it's correct, which is a completely different statement.