It really depends on what you're building whether that perf cost is problematic or not, and usually it isn't. If 90% of your code is clean Rust and the last 10% outside of the critical path is a straightforward clone or Arc, then I see no reason not to go that way.

Is the performance difference meaningful? I write Python, so I suspect even poorly ported Rust will outperform artisanally crafted Python.

Yes. Most of the production use cases for Rust are aimed at C, C++, and Go users. In my past experience, even poorly-written Go tends to outperform poorly-written Rust for many tasks, not to mention C or C++.

You're not exactly the target market if you're writing python.

But that is kind of my point. There are plenty of reasons to use Rust that have nothing to do with performance. My brief toe-dip into the Rust world loves the static types, good dependency management, and single executable deployment. That it is faster than my standard language is just the cherry on top.

The unfortunate reality for many Rust fans is that a lot of people would prefer to use a less complicated language when performance doesn't matter.

That Rust program you spent a day golfing to make beautiful use of iterators? Your friend wrote it in go in 15 minutes.

They also get static types, good dependency management, and singe executable deployment. Cython + mypy basically gives you that with Python.

I don’t know why this would be an unfortunate reality. People should use whatever language they want.

Rust gives you a lot of ways to express yourself, but now that I am quite familiar with it, I can write Rust just as quickly as I can write Python or Go.

You can spend all day code golfing in any language.

Yeah, Rust is a really fun language to write in my opinion. If your use-cases are tolerant of non-hyper-optimized Rust, there’s no reason to make it too hard on yourself while you’re learning. As you use it, I think you’ll naturally gravitate towards writing more optimized code, because the language guides you in that direction.

This conversation was about learning Rust, not about writing maximally optimized Rust. Clones and Arcs can make learning a lot easier, since they let you get stuff done without needing to figure out every obscure lifetime error.

For production contexts, we take more care to optimize for performance.

You and I have very different definitions of "maximally optimized." I think of eliminating all possible wasted CPU cycles when I hear those words. In comparison, being able to remove spurious copies and atomic accesses is table stakes for claiming that you know a systems programming language. Most use cases of C and C++ today are in that state.

You’re right, I was exaggerating for effect. But the point is that we’re talking about learning the language. You don’t have to get it perfect on your first try or do everything the best way when you’re just getting started.

Well, clones can sometimes make it faster (e.g. when you use multiple threads that can work independently, synchronization will have a much higher overhead than a literally insanely fast, predictable memory-to-memory copy). And then the compiler may very well be able to elide the copy, it only needs it for semantics.

Yeah, but Python is the slowest language ever. I think that a decent language like D or Common Lisp would outperform poorly written Rust, and they're easier to handle.

Huge is maybe a strong term. The cost of a clone is hugely dependent on the size of the data being cloned. Avoiding clones of large data structures is important, but even that is unlikely to be a bottleneck outside of a hot path.

Arcs can be expensive, but once you’ve got the sense for lifetimes, they aren’t that hard to avoid.

> and using Arc to wrap structs carry a huge performance costs

Does it? It's like using shared_pointer, which some C++ codebases do everywhere for memory safety.

And some languages like Swift even do it by default.