Automatically deriving Clone is a convenience. You can and should write your own implementation for Clone whenever you need it and automatically derived implementation is insufficient.
replies(3):
By the way, this issue also affects all of the other derivable traits in std - including PartialEq, Debug and others. Manually deriving all this stuff - especially Debug - is needless pain. Especially as your structs change and you need to (or forget to) maintain all this stuff.
Elegant software is measured in the number of lines of code you didn't need to write.
Nevertheless, it would be cool to be able to add #[noderive(Trait)] or something to a field not to be included in automatic trait implementation. Especially that sometimes foreign types do not implement some traits and one has to implement lots of boilerplate just to ignore fields of those types.
I know of Derivative crate [1], but it's yet another dependency in an increasingly NPM-like dependency tree of a modern Rust project.
All in all, I resort to manual trait implementations when needed, just as GP.
I rather have a simple and explicit language with a bit more typing, than a perl that tries to include 10.000 convenience hacks.
(Something like Uiua is ok too, but their tacitness comes from simplicity not convenience.)
Debug is a great example for this. Is derived debug convenient? Sure. Does it produce good error messages? No. How could it? Only you know what fields are important and how they should be presented. (maybe convert the binary fields to hex, or display the bitset as a bit matrix)
We're leaving so much elegance and beauty in software engineering on the table, just because we're lazy.
Strong disagree. Elegant software is easy to understand when read, without extraneous design elements, but can easily have greater or fewer lines of code than an inelegant solution.
[1] https://rustsec.org/advisories/RUSTSEC-2024-0388.html
[2] https://crates.io/crates/derive_more
The fact that people are writing blog posts and opening bugs about it (and others in the comments here recount running into the issue) seems to indicate this particular convenience matters.
Unfortunately this problem only shows up when you’re combining derive with certain generic parameters for the first time. The first time I saw this, I thought the mistake was mine. It was so surprising and confusing that it took half an hour to figure out what the problem was. I thought it was a compiler bug for awhile and went to file it on the rust project - only to find lots of people had beat me to it.
Aside from anything else, it’d be great if rust had better error messages when you run into this issue.
The Rust community is very adamant as a general thing that "you're holding it wrong" when people complain about e.g. BDSM passing semantics, but it's also got REIR/RIIR, which is kinda like "you're holding it wrong" for programming.
These two things together are a category error.
I wouldn't write anything but Rust via LLMs, because that's the only language where I feel that the static type checking story is strong enough, in large parts thanks to kani.
OpenAIs Codex model is also ridiculously capable compared to everything else, which helps a lot.
This is a pet peeve of mine so I'm sorry to be overly dismissive. There are bad error messages out there in the world that are impossible to parse, but this is not one of them. Trying to file a github issue before attempting to understand the error message is insane to me.
Whether this is a first order good because Rust's choices about how to split the difference between C++ and Haskell are in fact the best future for software or because they make all the money from Rust jobs and books and teaching and shit is one of those assume good intentions by default but also pay attention to conflicts of interest scenarios. Speaking for myself I think most of the zeal is legitimate with a few people trying to cash in like you get with any community.
But like all philosophies of the "There is One True Way, All Else Must Conform" stripe (in Christianity this is Opus Dei and things like that, in Islam it's called Takfir, it's not a new thing) it's misguided and destructive no matter how genuine the intentions of the hardliners.
edit: people will try to say that I'm uniquely antagonistic to Rust, but I opened the meme bookmark tab for a diff and saw this within like two minutes of writing my comment, it's a known thing: https://impurepics.com/posts/2023-03-24-refactoring.html
Would you mind filing a ticket detailing what you'd wish the error had been? Without additional context, the only improvement I can think of is adding a note explaining imperfect derives when hitting a missing trait bound coming from a local crate derived impl.
I call bullshit on this. If you can show any quote that could even be misconstrued as wanting some kind of language supremacy over every other from anyone in a position of "leadership", I'll eat my hat.
This pseudo-psychiatry "examine your personal issues" line of deflection can't go out of fashion too soon as far as I'm concerned.
If you want to raise an objection to my analysis of the situation, raise a substantive objection, cite a counter example, propose a theory with more explanatory power, whatever.
The thing I'm calling attention to has it's own meme page: https://enet4.github.io/rust-tropes/rust-evangelism-strike-f...
That's not a personal issue, that's a Rust community optics disaster.
There's an "internal" community document entitled "The Core Team Is Toxic": https://hackmd.io/@XAMPPRocky/r1HT-Z6_t
There's an entry on the tropes page about it: https://enet4.github.io/rust-tropes/rewrite-in-rust/
You're trying to make the case that this is a fever dream hallucinated by me in isolation? Like I took a bunch of fucking mescaline and imagined a world where the Rust community is actively trying to get things rewritten in Rust, get the DoD to mandate Rust for whole classes of taxpayer funded software, the groups at the FAANGs doing strategic rewrites of like revision control systems that worked fine, the whole thing?
I just, made it up?
Take a look. Do you think this quirk of derive is obvious from the error message alone? Would you have figured it out, in the context of a much more complex program with dozens of other changes that may or may not have been related?
https://play.rust-lang.org/?version=stable&mode=debug&editio...
The compiler error says my type didn’t implement clone. But #[derive(Clone)] was right there on my type, and my type was obviously cloneable. The error wasn’t on the derive - or anywhere nearby. My program even compiled successfully, right up until I tried to actually call clone() on my object. And my type trivially, obviously was cloneable because all the fields were clonable.
My first thought at the time was that my derive attribute was being ignored by the compiler somehow, but it wasn’t at all obvious why. The compiler’s suggested fix was also wrong and misleading. It suggests adding clone to an irrelevant type that shouldn’t impl clone in the first place. That’s the wrong fix.
In summary, the error message doesn’t offer the real problem, which is that the trait bounds added by derive Clone were wrong. And it didn’t suggest the proper fix - which was to impl clone manually.
I was very confused for a good while with this one. Get pissy if you want but I find this incredibly counterintuitive and I found the compiler’s error message to be uncharacteristically unhelpful.
If this quirk of derive was truly obvious, this blog post wouldn’t have hit the front page of HN in the first place. I cut my hand on one of rust’s sharp edges. Don’t get mad at me for bleeding a little.
Something like this would have helped me immensely:
> Note: even though struct Foo has derive(Clone), Foo does not implement clone in this case. derive(Clone) may have overly restrictive trait bounds (impl Clone where T: Clone). If this is the case, you may need to manually implement Clone for Foo with less restrictive trait bounds:
impl Clone for Foo {
fn clone(&self) …My pet peeve is the learned helplessness around compiler error messages, particularly ones that go to great lengths to be informative and offer solutions instead of just throwing garbage at you.
I think software - like mathematics - becomes more elegant & beautiful when we find ways to simplify it without making it worse in other ways. Minimising the number of lines of code isn’t the goal. But sometimes making something smaller also makes it easier to understand and sometimes even more powerful at the same time. Those are the days I live for.
Alan Kay says the right point of view is worth 50 IQ points. There are plenty of examples of this in software. Innovations in ways of structuring our programs that make them at once simpler and more beautiful. All without sacrificing anything important in the process. We take them for granted now, but innovation is rarely obvious from the outset. Compilers and high level languages. Sum types. Operating systems. Maybe SQL and ECS. Sinatra’s http handler API. And so on.
You started at
> it's fairly common knowledge that the Rust community leadership regards all other programming languages as existing in an adversarial, finite-sum outcome space with any remotely adjacent programming languages and regard it's elimination of other language use as a first-order good.
and now arrived at "there's a subreddit, a glossary entry for a meme and a blogpost complaining of the years defunct core team". Note that the complaints on that blogpost have nothing to do with what you're concerned about.
> Like I took a bunch of fucking mescaline and imagined a world where the Rust community is actively trying to get things rewritten in Rust, get the DoD to mandate Rust for whole classes of taxpayer funded software, the groups at the FAANGs doing strategic rewrites of like revision control systems that worked fine, the whole thing?
You seem to be conflating "projects using or recommending Rust" with "a grand conspiracy of a shadowy cabal of Rust people getting their way, all the way to the top of the US government".
I'll restart my claim: no one in leadership can be quoted saying that people should only use Rust everywhere. I'll go as far as saying that it's unlikely anyone that has a commit in rust-lang/rust (a much lower bar) can either.
Everyone said the same thing of most compiler errors until clang came along and showed everyone how much better compiler messages could be.
The compiler message here doesn’t suggest the true problem here, nor does it suggest the appropriate fix. I’m also clearly not the only one who finds this issue surprising and annoying. This blog post wouldn’t have been upvoted and commented on if it didn’t strike a nerve.
If nothing else, I think it’s quite obvious that the compiler’s error message could be improved. But better yet, I’d love to see it fixed in the language. The bounds derive places on its traits are simply wrong. There’s no reason why T needs to impl Clone. T is irrelevant.
For what it’s worth, I get what you’re frustrated about. I spent 2 years as a programming teacher. I feel like the first month of every cohort I wander around telling upset students that they forgot a semicolon. And the third month I wander around guiding frustrated students to read the compiler error message, which would have saved them 2 hours of guessing.
After banging my head into a wall for awhile on this issue, I made a reduced reproducing test case. Then I went looking in the rust compiler issue tracker. Only there did I finally see a proper explanation of what was going on, amidst a sea of other people struggling with the same thing.
That was half an hour of my life I won’t get back. I’m not helpless. But I am still pretty frustrated by the experience. I see it as a language level bug. It seems to take years and years of bike shedding for rust to fix stuff like this. I’d give even odds this still isn’t fixed in a decade from today.
But maybe, at least, we might be able to improve the error message?
But I didn't say that, I said you will get various degrees of transparency depending on where you're hanging out. Which is a related statement to your hedge.
But this kind of nitpicking is tiresome. I posted threads and links and stuff to a mountain of "everyone fucking knows this".
Everyone hates you guys, I'm just crazy enough to say it out loud even though a bunch of my recent posts are all going to get 4 downvotes in the first hour.
The place this approach falls down for me is in refactoring. Sure, you can get chatgpt to help you write a big program. But when I work like that, I don’t have the sort of insights needed to simplify the program and make it more elegant. Or if I missed some crucial feature that requires some of the code to be rewritten, chatgpt isn’t anywhere near as helpful. Especially if I don’t understand the code as well as I would have if I authored it from scratch myself.