The question here is -- are you "productive" because you write _good_ code faster, or because the language allows you to _not think_ about certain aspects of design and just postpone issues to the future (or GC).

OP wants to be fast and "productive", but forgets that in systems programming your first priority is good design and solid implementation. This is because _other_ components will be relying on your code to do their job. It pays to go extra step and make sure your component is properly written. Rust offers more than any other systems language to help with that.

That’s true, but not what that quote is about.

There are two sides to any coin. The complexity of the language is a consequence of the complexity of the problem it is trying to solve and the constraints it is operating under.

The borrow checker is not just some crazy torture device that exists for no reason. Criticizing the difficulty of the borrow checker without considering why it exists in the first place is completely misguided.

False dichotomy -- there are always more than two sides to any issue. People find themselves fighting with the borrow checker because their mental model of what they're writing is not what Rust is interpreting. This is probably indicative of two things: (1) their mental model is incorrect in some ways, and (2) Rust's semantics don't map that well onto how we think about systems programming problems. If satisfying the borrow checker makes you think "whoops, that was dumb" then you're in category 1. If it makes you think "aargh, how do I express this in a way Rust will accept?!?" then you're in category 2. With an ideal language category 2 wouldn't exist.

Of course, it's very easy to think you're in category 2 when you're really in category 1 but don't see how you're wrong...

But are all instances of category 2 actually category 1? That’s a strong claim.

It is, and it's a claim that I didn't make. But even if it were true, I think people won't believe that it's true, because there will be instances where they won't understand the borrow checker's reasoning.

I think you can understand what the borrow checker is doing and still think it is being too stringent.

Writing correct code that has all edge-cases in mind is not very intuitive.

Teaching people to keep this in mind is a hard problem.

I believe that reinforces Sargun’s point.

One of the reasons I love functional programming is it allows me to think less about edge cases, because values are passed as values.

If Rust passed copies instead of references by default, people who wanted performance could fight (or embrace, whatever your preferred term/level of experience is) the borrow checker, while everyone else could enjoy the fundamental safety of not sharing data.

Rust doesn't pass references by default, so I'm not really sure what kind of dichotomy you're trying to draw here. Also, such fundamental changes likely have far reaching effects that would likely change Rust itself in ways you can't anticipate.

I'm relying on his description:

> The biggest issue I have with the defaults, and the borrow checker is that places in FP where you would normally pass by copy — pass by value, in Rust instead it assumes you want to pass by reference. Therefore, you need to clone things by hand and pass the cloned versions instead. Although it has a mechanism to do this automatically, it’s far from ergonomic.

Yeah, I don't really understand what the OP is trying to say there other than "I'm frustrated." The lack of examples makes it hard to know. Passing by value works just fine in Rust, so it's hard to unpack what the author was getting at.

I'd guess he's referring to this.

https://internals.rust-lang.org/t/why-do-i-have-to-indicate-...

Yeah, still doesn't make any sense to me. That request is asking for implicit references (a small syntactical change as far as I can tell), which is different from what you asked for and doesn't seem to match up with what the OP wants either.

Without examples or further clarification, I don't think it's possible to understand what the OP actually meant.

Places where I want automatic cloning:

1. Anywhere I call clone(). That should be the default / automatic. 2. Anywhere where I can get copies than explicitly move for lambdas

The problem with the latter is that I have to call clone outside of the lambda and bind it to a short-lived variable into to get moved to the scope of the lambda.

(1) is basically saying "Rust should have copy semantics by default instead of move semantics." I'm very glad that's not the case. Those implicit copies would become easy performance foot guns. In most Rust code I write, using `clone` is fairly uncommon, so it's also optimizing for the wrong thing anyway. Finally, things that aren't cloneable are far more common than things that aren't moveable, so you'd need to smooth out that gap as well.

(2) is interesting and I'd be happy to see work done there to make that nicer, but it's hard for me to understand that being a big sticking point.