Hacker News Reader

Comment by tandr | Hacker News Reader

Couple questions about channels:

    1. Will they be as heavy as Go's ? Go has 2 mutexes and some other fluff
    2. Are they "close-safe" like, if I send something to the channel, and it is nil or closed, will it panic crash or stuck forever like Go does, or V is trying to be "panic-free"? Will "prohibited" operation return an error or panic/stuck?
    3. If channels are closeable, will I be able to close them twice without panic (closing closed door might creak, but IMHO should not burn the house down...)

(At some point in the past I did suggest adding an error to channel operations so it will not panic if I am ready to intercept an error, but that was rejected)

View on HN

Hello, I'm the one who has implemented channels for V, so I'll try to answer these questions:

1. "Heavy" is a vague term and I think that it is even used polemically here. Every channel implementation needs methods to avoid race conditions and I think Go uses what is needed for reliable operation, but not more (even when there is a "mutex" in their code it's not a real OS-mutex - Go's channel implementation is actually very efficient). V's implementation uses mostly atomics and sometimes spin-locks.

2. There are no "nil-channels" in V, but a channel can be closed. As in Go, just sending to a closed channel causes a panic - that's a design decision. The point is: not to panic requires some kind of error handling. In a language like C++ this can be done by throwing an exception (which has to be caught elsewhere). But neither Go nor V have exception (that is also a design decision). In V a failure due to a closed channel can be trapped using `or` (https://github.com/vlang/v/blob/master/doc/docs.md#syntax-an...) on the receiving side or by using `select` (https://github.com/vlang/v/blob/master/doc/docs.md#channel-s...) on the sending side or the receiving side.

3. Closing an already closed channel should not cause any panic.

Thank you for such extended answer.

1. I would politely disagree with Go channels are efficient. If they would be efficient, they would be actively used internally as a synchronization primitive. I don't remember seeing external libraries using it past notification mechanism of "it is done" kind either. There would be some nifty tricks possible if cost of channels is much lower, or compiler would be able to use some "very light" channels if it sees it is possible (not sure if it even theoretically possible, but I am not an CS theory guru...)

2. That's kind of unfortunate, I would prefer if error is requested, just return an error

   err := ch <- data_to_send

   ch <- data_to_send

which might panic. But looks like neither of languages allow this. I proposed the syntax above to Go, but it was rejected.

3. That's nice. Is there an error to catch if needed?

    err := close(ch)

Silly me - the syntax that I proposed was the second one

    err := close(ch)

to handle case when you don't want a panic on closing of closed channel. The first one was discussed on golang-nuts, but it died there.

Would highly suggest you pop onto Discord (https://discord.gg/vlang) to chat in #concurrency about this further...

1. There are some principle limits to take into account:

Channel operations involve task switches - especially on unbuffered channels. How expensive these are depends on the scheduler, but basically they are expensive on all operating systems.

Other synchronization primitives (like mutexes, semaphores, atomics) can be implemented in a way that the scheduler is not involved when no (long) blocking is needed (futex, spin-locks, ...).

The Go people took the path to implement their own scheduler, which is highly optimized for channel operations, on top of the OS (similar to a virtual machine). So, they don't use OS-threads or OS-mutexes. This does result in better channel performance, but still there are task switches. And this approach has other drawbacks concerning C interoperability.

V sticks to OS-threads and the OS-scheduler (and not re-implementing these could be called "lightweight"). This means better C interoperability but channel operations are even more expensive.

For this reason I've also implemented `shared` objects into the V core language as a more efficient way of sharing data (see also https://github.com/vlang/v/blob/master/doc/upcoming.md#varia...):

  shared x := ...
  go f(shared x)
  lock x {
      // modify x
  }
  rlock x {
      // read x
  }

2./3. Syntax considerations should be consistent within the whole language. As @illuminate has already pointed out we discuss these things on discord (https://discord.gg/vlang). There's also a channel #syntax.

Are you on Discord? If so, pop on into: https://discord.gg/vlang and chat at #concurrency

Thank you for the suggestion. No, I am not on discord.

I'm sorry - at this point I'd say with your input you should pop onto Discord to have more robust discussions.

Did they cite any reason for the rejection? Thanks

I need to find it, but I remember it was "we discussed it, and no, we decided not to" sort of answer there. There is also earlier explanations (from Rob Pike I think?) that was "we did not like how it looks like, couldn't find a nice looking syntax". The whole discussion left me with a bit of eery feeling, and left me with a bit of a sour taste (together with "error handling" one that I kind of tried to participate in). I pretty much stopped actively following golang-nuts after that, and now only look at proposals through meeting notes that Russ posts on github [1], where you can see accepted/not accepted status immediately.

Btw, there is another saga (drama?) unfolding on github proposal discussions over sum types [2], and judging by the past experience I don't have high hopes for it to get into the language.

[1] https://github.com/golang/go/issues/33502

[2] just one last I saw today, but there are more tickets about same or connected issue https://github.com/golang/go/issues/41716

https://news.ycombinator.com/item?id=25604064

Reply on news.ycombinator.com