Do you stay away from all type systems? This would be an accurate negative framing for any type system, which all necessarily reject some correct programs.
Not really. Just it's super difficult to understand how exactly borrow checker operates and when would it allow program to compile or not, causing all kinds of unpredictable situations and unless you are "black belt"-level, difficulty providing any estimates. Not mentioning loss of morale when you have to fight it every single day.
This is not my experience using Rust. I had six months of programming experience when I first tried Rust. I definitely got confusing errors at first, but I grasped the system within a month or two. And that was in 2014 - the borrowchecker and especially its errors have way improved since then!
But this is also a very different objection from your initial objection, which was just a statement of fact about type systems for turing complete languages.
Not at all; currently I am able to write non-trivial programs in >60 languages and ranging from low-level distributed transactions (did own Paxos already) through 3D visualizations, business software, mobile apps, Deep Learning models and AI, system software all the way to advanced ETL pipelines using imperative, functional, logical, co-routine-based, generics, reactive, declarative etc. concepts and am always on the lookout for a better language as I can't find the perfect one ;-) So I want to understand where Rust stands and if it is meaningful investment to learn it, both programming "pleasure"-wise and business sense-wise.
Is it? Could you give an example? I've found a borrow checker bug in the current release but the rest of the time its behavior is perfectly predictable. Granted, I wouldn't be surprised if the documentation was horrible, my understanding of the checker is based on one way I would do it.
It's simply one more thing you need to keep in your internal "context" while writing a program, taking mental resources you could spend elsewhere. Perhaps an IDE guiding you and outright rejecting the code or offering code completion that is compatible with borrow checker might be a solution, though we aren't there yet I believe.
You have to keep the kind of problems the borrow checker nags you about in your mind anyway. Memory errors and concurrency problems don't go away because the compiler doesn't complain about them. Personally, I find it easier to use Rust than C++, because I don't have to worry so much about iterator invalidation and stuff like that.
Experienced Rust programmers usually say the opposite: the borrow checker frees you from thinking about it since the compiler lets you know when you mess up.
Yes, and sometimes I wish C++ stayed somewhere in pre C99 levels where a single person could master it. As much as new features are useful, they make codebases unreadable to anyone that doesn't grasp all concepts. Even Google internally "javaizes" C++ and uses a strict subset to keep some sanity. Scala is another language that can go insane in the same fashion if teams don't enforce strict rules.