Yep, very much this. I code async CLI apps and I seriously don't care that the CLI args and the data structures they get transformed to are cloned 250 times at startup because after that 99% of the actual heavy-duty code is working with channels and references with nearly zero memory pressure. Memory usage gets bumped up by about 2% after the first 1-2 minutes of operation and it stays constant for next 11 hours during which I've monitored it.
I don't even need to benchmark anything. The apps are working ultra fast on a Celeron J450 CPU at ~20MB RAM usage and barely hit 10% CPU (since they're mostly network-bound).
No need for premature optimization. I haven't dived in the lifetime hell of Rust yet but I'm already quite productive and I will only be using zero-allocation techniques if my current code proves inadequate the the ever-increasing demand that these apps will soon face.
Re:Rust 2024 the Year of Everywhere?
by mwcampbell on Friday September 23, 2022 @10:53AM
(#32952740)
I figured that working outside the borrow checker meant using unsafe.
That's just the most obvious smell. But this also happens if you start passing indices around, using them much like unchecked pointers.
You don't need to feel bad about "working outside" the borrow checker, and maybe that's a signal that needs boosting. I've been using Rust for ages and I'm not averse to cloning things when I need to. It's cool that you can create zero-allocation libraries by threading lifetimes everywhere, and I certainly appreciate all the library authors who go the extra mile by doing so internally to their libraries, but in my application code it's easy to tell that a given thing isn't going to be a bottleneck and isn't going to be negatively impacted by a little copying and allocating.