I love TWiR's quote of the week this week: "Just because Rust allows you to write super cool non-allocating zero-copy algorithms safely, doesn’t mean every algorithm you write should be super cool, zero-copy and non-allocating."

This resonates with me in @rustlang lately. https://twitter.com/ThisWeekInRust/status/1316600316356247554

It often feels like it *should* be possible to write something that minimizes copies, shares structures across threads/futures, etc. But "The greatest performance improvement of all is when a system goes from not-working to working" (Ousterhout). I can always profile later.

So very recently, I've consciously tried the experiment of not worrying about the hypothetical perfect code. Instead, I call .clone() when I need to, and use Arc to get local objects into threads and futures more smoothly.

And it feels glorious.

I wrote some code today that uses flume channels ( https://docs.rs/flume/ ) as an RPC system: make a new one-time-use channel, send the request and the new Sender via an existing channel, wait on the new Receiver for the reply. @rustlang types made it work on the first try.

I did a quick benchmark; this pattern easily handles ~200k calls/second on my laptop. I didn't worry about how it could have handled far more. That's not my bottleneck. AWS calls that take 1.5s each are my bottleneck.

In the future, after profiling, I might find that some call to clone or use of Arc or some other convenient and visible bit of overhead will turn out to be a bottleneck. And if so, I can start working on that mythical all-references no-clones no-Arc threads and futures code.

Meanwhile, I have short, maintainable code that's quick to develop and works well. I'm free to worry about more important algorithmic issues, rather than whether I unnecessarily copy a String. And I'm enjoying writing it.

I highly recommend trying this experiment yourself.