Comment by junon
1 year ago
> Leaky abstraction problem which leads to "async contamination".
There's not much else of a way to do it any better. Not sure your exact gripe here, other than dogmatic.
> Violation of the zero-cost abstractions principle.
It's not a principle, it's just a benefit of Rust's design that you get often but not always. `Clone` is not zero cost, should we throw that out too?
> Major degradation in developer's productivity.
Yawn, speak for yourself. I implemented incredibly extensive firmware with Embassy (async embedded framework) in months instead of years for a custom PCB I made. Async was literally the last thing on the list that caused problems - in fact it sped up my productivity and reduced power usage of the board overall.
> Most advertised benefits are imaginary, too expensive (unless you are FAANG) or can be achieved without async
No, they cannot. You are so confidently incorrect to an impressive extent.
Stopped reading after that section. This person has some bone to pick and left level-headedness at the door in doing so.
> `Clone` is not zero cost, should we throw that out too?
Am I mistaken when I say that `ToOwned` is sometimes zero-cost?
And that `.to_owned()` vs. `.clone()` is free when the trait instances allow it?
Both _can_ be free but are not inherently free.
For example, to_owned on an owned type is a no-op typically (it's a blanket implementation).
Clone on a unit struct or a unit enum variant is also a no-op in most cases (unless explicitly implemented not to be, which is very much frowned upon).
> `Clone` is not zero cost
I think you've misunderstood. "Zero cost abstraction" is not the same as "zero cost".
I understand, that wasn't really the point I was making. I don't know of a single systems language that has zero cost async abstractions. The author is making an impossible, nonsense ask.