I know. But for me personally, the `io::Reader` and `io::Writer` is still not comfortable enough. Mainly because it's return values, `io::Error` to be specific. Because I found that in many of my cases, predefined `io::ErrorKind` is not enough for me, this results my abuse of `io::ErrorKind::Other`.

In Go, `error` is an interface that can later be asserted, so I can return any `error` then deal with them as late as I need.

This gives me ability to write some complex `io.Reader` and `io.Writer`. For example, an `io.Reader` that can Decode data stream, and returns both CodecError and IoError when it encountered any.

In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down).

BUT ... Maybe it's Go's fault, it treats me too well, make me want something that I cannot have for free (performance cost) else where.