Hacker News Reader

Comment by ameliaquining | Hacker News Reader

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/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.

View on HN

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.

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.

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".

> 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 :)

> Simple is better than complex. > > Complex is better than complicated.

https://peps.python.org/pep-0020/

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.

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

Reply on news.ycombinator.com