Hacker News Reader

Comment by steveklabnik | Hacker News Reader

We put this aside in the book for this exact reason: https://doc.rust-lang.org/stable/book/ch12-03-improving-erro...

> But I felt like if I could have worked out borrowing it would've generated more efficient code and less memory consumption.

That is possible! But while you're learning, this isn't the most important thing to focus on. And depending on what you're trying to do, using borrowing may be easy, or may be hard, and while you're trying to learn, you don't know enough to evaluate the tradeoff on that basis, so in my humble opinion, it is absolutely okay to clone, and is probably even what you should do in most cases.

Once you're feeling good enough about Rust to start digging deeper, working on trying to not do this is a valuable skill. But imho it's a waste of time when you're starting, and may lead you into a pit of despair.

View on HN

The aside in the book says the opposite of what you claim it to be saying. Here, you suggest that liberal cloning is the way it should be; there, you say it's fine for beginner code, which is a very unsubtle nudge. Which is it?

I am a little offput by how aggro this comment is, but I really like you and so will give you the benefit of the doubt here.

I wrote this text years ago. It is possible I didn't do as good of a job as I could have. This was added directly in response to situations' like the OPs, people saying that they felt bad using clone while they were learning Rust, and so the comment, coming early in the book, and as a text for learners, focuses on that case.

It's also the same as in this thread, I thought I was being pretty clear that I'm talking about people learning Rust?

However, just because I say one thing doesn't mean I'm implying something else; for non-beginners, I don't think clone is a moral issue either way. If you are trying to get ultimate performance, clone may be an issue. It also may not. Some clones are more expensive than others. Furthermore, not everyone needs to get ultimate performance, and that's okay too. It is up to you. The point is that I don't think this question is a useful one for someone to engage with as a beginner. It is a useful question for intermediate programmers to engage with, but so that they can make the right call for them, not because one or the other is the correct answer in all situations.

As a Rust programmer, I have the exact same lived experience of the language that the parent commenter does: that Rust can be relatively straightforward to write if you liberally clone things, but that the prevailing community norm strongly suggests that cloning is a code smell, or something you do in tooling-grade code.

The parent commenter was surprised that you suggesting liberal cloning was the way Rust code should be --- that, like, the median Rust crate should probably be written in the "clone liberally" register. You said that was the reason you wrote the Rust book aside. But I read that book and that aside and reached the opposite conclusion, and I think people who follow your link will mostly see why.

You haven't exactly cleared things up here, either. "For non-beginners, clone isn't a moral issue". Well, that's not what you just said upthread. I'm pressing you on this because it would be helpful to get an actual clear signal on this. Should most code be written with liberal clones, or should most beginner code be written with liberal clones? Like the previous commenter, I just want to understand what you're trying to say.

(A sibling comment here says the exact thing that I'm saying creates the mixed message here: that cloning is fine... in beginner code, but not in serious code.)

This is not, as we both know, a minor distinction in Rust; it is maybe the biggest stylistic distinction in actually writing Rust? Moreso maybe even than async?

> that, like, the median Rust crate should probably be written in the "clone liberally" register.

That is not what I understand myself to have said. The parent said that they "do not write much Rust code." That is very different than "the median Rust crate."

> Should most code be written with liberal clones,

I think this question is a category error. There is not enough context to give an opinion. And I think that means you cannot make a broad generalization about clone; some code should have a bunch of clones, and some code should not, even if they're the same code, because they operate in different kinds of contexts or sure, registers, to sort of stick to the vibes of the original post.

If I am presented the exact same code by two people, and one of them started writing Rust yesterday, and says "what do you think of my code?" I would not even give consideration to the number of clones when attempting to give them my opinion about their code. If someone came to me after writing Rust for ten years and said "hey I am struggling to improve performance in this code" and said "what do you think of my code?" and I saw a bunch of clones, I would say "have you profiled? I would suspect that maybe clones are causing your problem but I wouldn't do anything until I had a flame graph or equivalent." Even then that is not a moral question or answer, it is an engineering one.

> or should most beginner code be written with liberal clones?

Even this isn't exactly what I meant, but is closer. I mean what I said in my parent comment to you, beginners should not feel bad if their code uses clone, whatsoever. That does not then imply that non-beginners should feel bad, I said absolutely nothing in this thread about anything other than beginner code (until the paragraph above in this comment and the paragraph in the comment you're currently replying to).

It’s weird to me the degree to which you’re pressing an offhand comment into being some kind of Statement.

I’d expect anyone writing Rust regularly to know that the impact of Clone is context-dependent, and whether or not you should be fine with using it liberally is also context-dependent. Big object? Hot loop? Avoid cloning. Not worried about performance? Clone all you want if it makes the code easier and faster to write. You can always optimize later.

Sometimes it’s easy to avoid clones, and if you’re writing a lot of Rust it often feels like you might as well, just in case. But at least for my team, “you could get rid of this clone” is generally a take-it-or-leave-it kind of comment in code review.

There’s no easy way to express “it’s a trade-off between performance and ease of use that you’ll get better at with time” in a way that is instructive in any meaningful way, which is why I imagine it’s more useful to push people to err on the side of what’s going to be faster to get them to the amount of experience they need to engage meaningfully with the question within their own context.

Well, if I can mostly ignore fussy ownership and borrowing stuff and just clone everything, all the time, getting rid of clones exclusively in places that I profile and learn to be in the hot path, and the resulting code will be idiomatic Rust, that would be welcome news to me. That's where I'm coming from.

My impression from Klabnik's most recent comment is that this isn't the case. Which is fine! It lines up with my previous assumptions about Rust idiom.

I'm not quite sure where the disconnect is either, but yeah, "should I clone everywhere" or "is cloning everywhere idiomatic" is just one of those models that is useful, but like all models, is invariably wrong in some cases.

Just as one example, consider a function I wrote. It accepts a &str as a parameter. Internally, among other things, it clones that &str into a String. If you asked me whether that was "idiomatic" devoid of any other context, I would say, "probably not? Why not just ask for the String or a Into<String> instead?" But it's not a certainty. Just a likelihood.

But now let's add context. The context is that that function I mentioned is Regex::new. Does that change my answer? You bet your ass it does. Because cloning that pattern string has now turned into a definitively negligible cost. (By many orders of magnitude.) And there is upside to accepting a &str: it's non-generic, a little easier to understand and is unlikely to ever run afoul of type inference. Those aren't huge upsides, but there is actually no downside here because of the context.

As others have pointed out, there is no one-size-fits-all answer to this question. There are models though, and those models (e.g., "don't worry about cloning while you're learning Rust") are very likely to serve you quite well. That might not be every path that everyone learning Rust always takes. But it's a decent bet in my experience.

This makes sense! (Also, even if I was deliberately cloning liberally, I'd still pass &str to most things).

> My impression from Klabnik's most recent comment is that this isn't the case.

Okay last comment in this sub-thread because I have to get back to my job here, which hilariously is adding some boxing and possibly cloning in order to improve a codebase.

I feel like I'm going crazy. I feel like this:

> if I can mostly ignore fussy ownership and borrowing stuff and just clone everything, all the time, getting rid of clones exclusively in places that I profile and learn to be in the hot path, and the resulting code will be idiomatic Rust

is exactly what my last comment said. This whole chain, in my experience, is me saying "clone is not a moral issue" and you saying "why are you saying that people that use clone should feel bad." So I need to bow out. I wish I could figure out where this disconnect is, but it's clear that this thread is not achieving that.

Your comments and much of this thread have been helpful to my understanding. (Like the Rust book!--thank you!). I also appreciate your effort to be kind/respectful/understanding, elevating the conversation, where others might have responded with anger or disparagement. Thanks for the example.

There is one tangential thing that I’ve thought about before—it would be nice if there was some way to encode this into the library ecosystem (ie crates.io) I have no idea how this would be realistically possible though—it’s pretty clear that you can rely on categories that are statically verifiable like “no-std/no-alloc”. But what mechanism could be used to allow library consumers to distinguish between things like “laser focus on high perf/low-alloc” vs “prioritizes API over perf-at-all-costs” vs “this package is an experiment/Baby’s First Crate/shitpost” ?? They’re all valid choices for different consumers or usecases.

Yeah, there is something in this space for sure. I think one of the issues is time; code can start off as a fun experiment, but transform into one that's not, which maybe just means that it is metadata associated with a specific release, yadda yadda, but there's a lot here to think about. For sure.

I recently have been accepting some PRs to some Ruby code that I wrote ten years ago that ended up being still in-use today. "Shitpost" or "baby's first crate" isn't accurate, but "hey I was very serious about this before but now it's not as high priority for me but that doesn't mean I abandoned it" is a tough thing to encode.

Absolutely true re evolution. That's why it would have to probably be crate keywords rather than categories, I'm thinking.

This whole space about encoding library non-technical aspects like intent and status seems like it has a lot of possibilities. I wonder if there's prior art in other language ecosystems?

Perl has the Acme namespace for expressly silly projects, that’s the first thing that comes to mind…

Maybe defining the interesting axes (for each, one for whether it is considered a goal, the other for whether it has in fact prioritized that goal in practice; not saying whether it succeeded in others' eyes), and for each axis give a number 0-10 (or whatever) rating it, in the author's view. Then maybe users of the library can give similar ratings as they compare it with others.

Or not.

I replied just below, to another comment, with an idea. Not fleshed out well, but oh well.

I think documentation is the right layer to express what is or is not a goal for the crate. Whether you met the goal is not something you as author can judge reliably.

https://crates.io/crates/misfortunate - is not intended to be used seriously. A redditor pointed out that arguably my Double (a smart pointer where the mutable and immutable references point to separate things and you can swap their places) might actually be useful! But I don't want you to depend on misfortunate::Double in your real software project - if that is useful (and maybe, with careful documentation, it is) you should give it a name suiting its purpose and include it in a crate of stuff that's intended to be used, not as something like a practical joke or thought experiment.

I think the confusion comes from the fact that Steve would consider code written by someone who "hasn't written much Rust" to be "beginner code," so he meant exactly what the book says. I would agree that people getting the hang of Rust shouldn't worry too much about this, but that production code that deep clones buffers when it could use references is badly written (then again, it may not matter at all!).

> The aside in the book says the opposite of what you claim it to be saying. Here, you suggest that liberal cloning is the way it should be; there, you say it's fine for beginner code, which is a very unsubtle nudge. Which is it?

That's phrased way too harshly, considering you're talking to someone who has put significant efforts into making Rust accessible to others.

my interpretation of the “clone is the way to go” comment is that it’s in the context of the OP saying “I haven't written much Rust…”, which puts a pretty clear frame around the intended applicability of the statement no? I don’t taking it at all as being an absolute statement.

"Beginner code" is a bit misstated, yes. An abundance of .clone()s does suggest that the code path might be unoptimized, but unoptimized code isn't solely written by beginners. If you want to use Rust for quick prototyping, you're going to use .clone() a lot. It's a bit regrettable that the book doesn't clarify this more.

Reply on news.ycombinator.com