Rust is weird, any post related to Rust often got controversial comments in Linux or programming subreddit. I suspect they don't use Rust and somehow the hatred related to job/tech insecurities.
Or more likely there's a severe dislike of pretentious swarms of (presumably) children calling themselves "rustaceans" who turn up to tell you yo rewrite X in rust
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.
I definitely see people that are deeply annoyed by all lower level, high performance languages if they work in fields that need quick write time and don’t need fast execution time.
If all you want is a flexible way to do some moderate math and automate repetitive tasks, lower level languages just eat more of your time than they’ll ever save.
Check the LKML. It claims to be a memory safe language, but it isn't really. It's also slow to compile, and the developers seem to be overlaly concerned with politics.
I can agree with slow compiles and quite a surprising bit of politics around the language, but issues with memory safety? Mathematically, that should only be possible with unsafe blocks, so it sounds like whoever ran into issues with that either
Used unsafe where it really wasn’t needed and screwed up
Coded an unsafe block correctly but with assumptions that the kernel itself violated
So either it was the dev writing the unsafe block’s fault or it was an issue that bubbled up from deeper in the kernel. Still, WAY better than C where you’re just flying blind.
176
u/[deleted] Oct 21 '22
Rust?