4 ms·

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so complicated. (https://rust-lang.github.io/rust-project-goals/2025h2/ergonomic-rc.html#key-design-question-will-this-make-rust-easier https://rust-lang.github.io/rust-project-goals/2025h2/ergono...) Complexity is not necessarily an automatic dealbreaker for a Rust language proposal—lots of Rust features are complicated because they solve problems that don't admit simple solutions—but the purpose of this particular feature is to make it easier to write code that uses reference-counted pointers and reduce how much stuff the programmer has to keep track of. It doesn't let you do anything you can't already do, it just makes it less clunky. So if people can't easily understand what it does, then that's bad.

kstrauser 1y ago
As a side note, this might just be a me thing, but I distinguish between "complex" and "complicated". Certain things have an inherently complexity. Stripped to their essence, they're still going to have a lot of moving parts. It's just their nature. However, you can also add complication on top of something that makes it more complex than it needs to be to perform its function. Think "complication" in the watchmaker's sense. It might be neat to add a dial that shows the number of weeks since your last dentist appointment, but you don't really need that to have a functional wristwatch, and its presence makes the whole thing a lot more finicky and fragile than it would otherwise be. Complexity is fine. Sometimes we're working on complex problems without simple, straightforward, correct solutions. I do try to avoid complications, though.
- ameliaquining 1y ago
  Yeah, I was slightly sloppy about that, but also the distinction doesn't entirely help at this level because people get into vicious fights about whether a particular bit of complexity is really "necessary". E.g., lots of people argue that async Rust is unnecessary complication, either because you can just write all the state machines by hand (which is terrible for expressiveness, but do you really need expressiveness?), or because you can just spawn an OS thread for every task (which is terrible for performance, but do you really need performance?). Whereas the pro-async perspective is, yes, it's very complex, but nothing simpler would have done everything that it needs to do.
  - kstrauser 1y ago
    Oh, I hear ya. That makes perfect sense, and you're so right: my idea of a complex solution might be someone else's complication, and vice versa. I didn't mean to disagree with you, and surely not to correct you, because not everyone agrees on the distinction I make between the ideas. I meant that more in the spirit of "oh, while we're talking about this, here are my thoughts on a tangentially related idea".
- jstimpfle 1y ago
  > Complexity is fine. Sometimes we're working on complex problems without simple, straightforward, correct solutions. Often the best way to proceed is to just solve a simpler problem :)
- inhumantsar 1y ago
  > Simple is better than complex. > > Complex is better than complicated. https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/
misnome 1y ago
I wonder if the block-level `clone(var_a, var_b)` was considered. It’s a bit verbose but very explicit and much better than the current situation.
- ameliaquining 1y ago
  Do you mean something like this? https://github.com/rust-lang/rfcs/issues/2407 https://github.com/rust-lang/rfcs/issues/2407

kstrauser 1y ago

As a side note, this might just be a me thing, but I distinguish between "complex" and "complicated". Certain things have an inherently complexity. Stripped to their essence, they're still going to have a lot of moving parts. It's just their nature. However, you can also add complication on top of something that makes it more complex than it needs to be to perform its function. Think "complication" in the watchmaker's sense. It might be neat to add a dial that shows the number of weeks since your last dentist appointment, but you don't really need that to have a functional wristwatch, and its presence makes the whole thing a lot more finicky and fragile than it would otherwise be. Complexity is fine. Sometimes we're working on complex problems without simple, straightforward, correct solutions. I do try to avoid complications, though.

ameliaquining 1y ago
Yeah, I was slightly sloppy about that, but also the distinction doesn't entirely help at this level because people get into vicious fights about whether a particular bit of complexity is really "necessary". E.g., lots of people argue that async Rust is unnecessary complication, either because you can just write all the state machines by hand (which is terrible for expressiveness, but do you really need expressiveness?), or because you can just spawn an OS thread for every task (which is terrible for performance, but do you really need performance?). Whereas the pro-async perspective is, yes, it's very complex, but nothing simpler would have done everything that it needs to do.
- kstrauser 1y ago
  Oh, I hear ya. That makes perfect sense, and you're so right: my idea of a complex solution might be someone else's complication, and vice versa. I didn't mean to disagree with you, and surely not to correct you, because not everyone agrees on the distinction I make between the ideas. I meant that more in the spirit of "oh, while we're talking about this, here are my thoughts on a tangentially related idea".
jstimpfle 1y ago
> Complexity is fine. Sometimes we're working on complex problems without simple, straightforward, correct solutions. Often the best way to proceed is to just solve a simpler problem :)
inhumantsar 1y ago
> Simple is better than complex. > > Complex is better than complicated. https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/

misnome 1y ago

I wonder if the block-level `clone(var_a, var_b)` was considered. It’s a bit verbose but very explicit and much better than the current situation.

ameliaquining 1y ago
Do you mean something like this? https://github.com/rust-lang/rfcs/issues/2407 https://github.com/rust-lang/rfcs/issues/2407