3 ms·

How does software get slow enough that it's one of our favorite things to complain about? There are multiple causes, of course, but I think one of them is death

How does software get slow enough that it's one of our favorite things to complain about? There are multiple causes, of course, but I think one of them is death by a thousand cuts, that is, lots of little performance compromises that ostensibly don't matter. I don't always do everything in the optimal way, but I appreciate that Rust at least gives us the possibility of having safety without compromising speed, and I think it's good to push harder in that direction.

harpiaharpyja 3y ago
My experience is that applications get slow when they are loaded down with bajillions of layers of unnecessary bloat. It's not because of micro-decisions such as whether to use reference counting.
- the-smug-one 3y ago
  A bajillion layers of unnecessary indirection is gonna have the same consequences.
- insanitybit 3y ago
  Your statements seem contradictory. "bajillions of layers of bloat" sounds like exactly the situation of "many micro-decisions" that degrade performance.
afavour 3y ago
I don't think we disagree here. I agree that not using Rc<> is the optimal position but I find myself wondering how many Rust beginners got tangled up in lifetimes, gave up and went back to a garbage collected language. I think it's fine to make an on-ramp that's a little shallower.
- insanitybit 3y ago
  I'd suggest using `.clone()` over `Rc` since it'll be easier. Rc is an optimization to make `.clone()` cheap, but the downside is it makes mutability more complex.
sheepscreek 3y ago
Here’s another way to frame the original argument: A less performant solution in a subset of Rust will still be miles ahead of optimized Python or Ruby, while being as readable. An equivalent C++ solution on the other hand could be less readable and unsafe. Also, limited use of borrowers is not that hard to grasp. Mutable references however make my head hurt. More so when they’re used by someone who doesn’t understand their purpose well. One mutable reference passed down a chain of functions is okay (like a shared context/state object/db connection/etc), but more than a few make my head hurt. You can still make logical mistakes with shared context, so in general - more pure functions = easier to spot logical mistakes (as most mutations will be concentrated in one place). And this is a general rule applicable to all programming languages.

harpiaharpyja 3y ago

My experience is that applications get slow when they are loaded down with bajillions of layers of unnecessary bloat. It's not because of micro-decisions such as whether to use reference counting.

the-smug-one 3y ago
A bajillion layers of unnecessary indirection is gonna have the same consequences.
insanitybit 3y ago
Your statements seem contradictory. "bajillions of layers of bloat" sounds like exactly the situation of "many micro-decisions" that degrade performance.

afavour 3y ago

I don't think we disagree here. I agree that not using Rc<> is the optimal position but I find myself wondering how many Rust beginners got tangled up in lifetimes, gave up and went back to a garbage collected language. I think it's fine to make an on-ramp that's a little shallower.

insanitybit 3y ago
I'd suggest using `.clone()` over `Rc` since it'll be easier. Rc is an optimization to make `.clone()` cheap, but the downside is it makes mutability more complex.

sheepscreek 3y ago

Here’s another way to frame the original argument: A less performant solution in a subset of Rust will still be miles ahead of optimized Python or Ruby, while being as readable. An equivalent C++ solution on the other hand could be less readable and unsafe. Also, limited use of borrowers is not that hard to grasp. Mutable references however make my head hurt. More so when they’re used by someone who doesn’t understand their purpose well. One mutable reference passed down a chain of functions is okay (like a shared context/state object/db connection/etc), but more than a few make my head hurt. You can still make logical mistakes with shared context, so in general - more pure functions = easier to spot logical mistakes (as most mutations will be concentrated in one place). And this is a general rule applicable to all programming languages.