Hacker News Reader

Comment by hornetblack | Hacker News Reader

It's not much shorter, but it was pretty easy to write it you know the libraries.

    package main

    import ("os"; "io")

    func main() {
        io.Copy(os.Stdout, os.Stdin)
    }

View on HN

The order of os.Stdout, os.Stdin is interesting. I'd assume src->dest being more intuitive order.

Any ideas if this dest<-src order is by design following go design principles or was mainly authors' personal choice?

By the way, Pipe in the same package is the other way around: (PipeReader, PipeWriter)

Channels in go use the exact syntax you mention (dst <- src). With this in mind, the argument order of io.Copy is consistent, as well as io.Pipe. You read from a reader - the output of the pipe, and write to a writer - the input of the pipe.

memcpy() and strcpy() and a whole bunch of functions inspired by them have take (dest, source). Maybe it's not theoretically superior, but it is familiar to a whole lot of programmers.

It is by design. All those work in the same direction:

    dest = src // Variable assignment.
    <-ch; // Read from channel.
    // in net/http
    type HandlerFunc func(w ResponseWriter, req *Request)
    // in io
    func Copy(dst Writer, src Reader)
    // builtin
    copy(dst, src) // Slices.

So the reason is consistency. I suppose the Pipe exception is to map Unix's pipes.

Reply on news.ycombinator.com