Hacker News new | past | comments | ask | show | jobs | submit login

Channel arrows are basically just read/write operations.

If `ch` is a channel, then this expression means "value obtained from reading from the channel":

    <-ch
And this expression means "write value x into the channel":

    ch <- x
Both expressions can be used as a case inside select statement:

    select {
    case val := <-ch:
        // ...
    case ch <- val:
        // ...
    }
Which will execute exactly one case, depending on which channel becomes "ready" first - channel is ready for reading if there is another goroutine blocked on a write operation, and ready for writing if there is another goroutine blocked on a read operation.

You say you're from C background - if you've ever worked will file descriptors you will notice that channels are basically userspace file descriptors. Channel reading and writing is isomorphic to read() and write() syscalls, and select keyword is isomorphic to select() syscall.

Hopefully this clears up the whole channel syntax thing. I just hope you weren't trolling.




> Channel reading and writing is isomorphic to read() and write() syscalls

This is a very bad mental model because channels operations cannot be canceled (without using select on two channels) or return any error status (at all).


While technically true, I don't really see the impact of the difference. It is idiomatic to use contexts for any kind of cancellation during channel operations, and it works well.

The syscall comparison was made to give intuition about general behavior of channels to someone with a background in C. Of course it's not completely identical.


The ability of read/write to communicate via errors as well as the actual data transferred is significant - there's a reason Go's i/o model is io.Reader/io.Writer and not chan []byte.

You might as well explain channels in terms of any blocking operation if the bar for "isomorphic" (now backtracked to "intuitively" I guess) is that low.


I don't know what's the bar for "isomorphism", but I know that the word literally means "same shape", so just because some nerd that got killed in a duel over a girl used the same word in a mathematical context doesn't give him dibs over its general use.

Unless, of course, system calls can be modeled as operators over sets. In which case, please tell me how.


In normal use of the term, a function's shape is its type signature; at the very least its in and out arity, and usually even more specific.


Well, in my case I used it to signify same behavior in terms of process/goroutine communication. I think it's "specific enough" to warrant the use of word "isomorphic".


It was a rhetorical question.


So you were trolling. Bummer.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: