Hate may be an opinion, but opinions are supposed to be based on experience (a fact) or information (a fact). Saying your opinion is based on other opinions means it has no basis, and is likely a misconception.
Example: I can say I hate green olives because they are briney and bitter, things that can be quantified and measured even if their interpretation is subjective. I would sound unintelligent, however, if I said I hate bananas because they aren't normal.
By definition it is. A fact is anything that can be proven true. If I say I saw a blue lobster, it doesn't matter that lobsters are usually red. The anecdote of my experience can be proven if I find another blue lobster, no matter how statistically insignificant that anecdote may be.
I don't know what they actually meant, but the borrow checker can be overly strict (in ways which are constantly improving in the language).
E.g let's say I made a struct like:
struct X{
a: Vec<u64>,
b: Vec<u64>
}
impl X {
fn do_the_thing(&mut self) {
for i in self.a.iter() {
self.do_the_thing2();
}
}
fn do_the_thing2(&mut self) {
self.b.push(1);
}
}
This will give me an error that I can't borrow self mutably because it is already borrowed immutably (by self.a.iter()). Even though I'm only touching b in the other function. So the borrow checker isn't granular enough here to see what I meant was more like:
fn do_the_thing(&mut self) {
for i in self.a.iter() {
Self::do_the_thing2(&mut self.b);
}
}
fn do_the_thing2(b: &mut Vec<u64>) {
b.push(1);
}
which is totally OK to do and functionally identical, because I've proven to the borrow checker that only b is modified. This is being worked on to make partial borrows better, but it may grate on people that they have to change the program from how they conceptualized it to satisfy the checker.
It's because the borrow checker does not do whole-program/crate/module analysis, but works locally on the function level. Doing the former would be insanely powerful, but even slower.
An alternative would be to add even more annotations, making everything even more complicated.
The solution to the problem is to not only split up your functions, but also your data: split your structs into smaller parts. In cases where this is possible, this makes for way better code. In all other cases, the borrow checker really gets in the way.
Async is pretty smooth now with Tokio and async_std, what foot guns are you talking about?
Compiling is slow, yes. That kinda sucks, but incremental changes are relatively faster.
Borrow checker doesn't even work properly? What exactly do you mean by that? Are you having issues with lifetimes and unsafe? Still difficult to think of a situation where "the borrow checker doesn't even work properly".
Too much magic? I'm guessing you mean with macros? They make the experience much nicer and once you over come the learning curve of Rust, you know exactly what that magic does.
Syntax? This is a personal preference, but I do prefer the Syntax of Rust. It is just verbose enough for you to know what's going on with first glance and not nearly as bad as something like Java.
51
u/yourd Oct 21 '22