How is the byte counting reader supposed to work in user space without putting the buffer in user space? The article claims there is a way but I want to see what is meant by counting bytes in that case.
sendfile(2) and io.ReaderFrom both return the number of bytes transmitted. The issue is that users are unaware of (or forget about) the optional interface upgrades and fail to define all the methods required for interface upgrades on their wrapper structs. You can definitely make a counting reader with a minimal performance loss, but the proper solution is less obvious than it ideally should be.
A good reminder. It is surprising first time you encounter it.<p>Same for Rust. As <a href="https://doc.rust-lang.org/stable/std/io/fn.copy.html" rel="nofollow">https://doc.rust-lang.org/stable/std/io/fn.copy.html</a> says, std::io::copy can use copy_file_range(2), sendfile(2), or splice(2).
Zero-Copy in Go: Why magic is an antipattern, and: performance is observable behavior.
This is almost like the expression problem. Copy is a new operation, and you introduced a new type, thus creating a new grid cell nobody from either side could have reasonably known about - except for the fact Copy is in the standard library so you could have known about it but not done anything.
Ugh, AI slop writing.
Interesting premise for a post, but I had to stop midway due to the AI slop writing adding meaningless information.