Zero-copy in Go: sendfile, splice, and the cost of io.Copy(segflow.github.io) |
Zero-copy in Go: sendfile, splice, and the cost of io.Copy(segflow.github.io) |
Same for Rust. As https://doc.rust-lang.org/stable/std/io/fn.copy.html says, std::io::copy can use copy_file_range(2), sendfile(2), or splice(2).
I do think it is criminal this is not documented (https://pkg.go.dev/io#Copy), but I think io.Copy is fine as an API.
It's also a totally readable article, really.
Context: https://github.com/golang/go/issues/70000 fixed in 1.23.3 (released 2024-11-06), EOL for 1.23.x was 2025-08-06
Yes, essentially duck typing. See https://github.com/golang/go/blob/65504872cbca64d77f45828409...
The logic uses a type assertion to safely verify if the value backing the provided io.Reader interface also implements the io.ReaderFrom interface. If it matches, then it will use the more efficient implementation
if rf, ok := dst.(ReaderFrom); ok {
return rf.ReadFrom(src)
}
I don't think I would go that far. In Java, many libraries make heavy use of the `instanceof` keyword, which is more or less the same as Go type assertions.
In Java type assertions are mostly used when writing code pre-generics style, like downcasting from a common subclasse into the actual implementation, not to see if an interface is supported, as it is a given from the type system.
var _ Foo = (*Bar)(nil)
I do agree it’s not as clean looking as the Java implements keyword, but it’s already a fairly terse pattern and IMO the inconvenience does not justify introducing new language syntax.