Hacker News Reader

Comment by nemothekid | Hacker News Reader

I don't have the post context, but at 13 lines, I feel even something like Go wouldn't even be considerably larger or marginally easier to understand.

View on HN

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)
    }

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.

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.

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.

Reply on news.ycombinator.com