4 ms·

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 some

by tandr 6y ago

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)

ylluminate 6y ago
Are you on Discord? If so, pop on into: https://discord.gg/vlang https://discord.gg/vlang and chat at #concurrency
- tandr 6y ago
  Thank you for the suggestion. No, I am not on discord.
  - ylluminate 6y ago
    I'm sorry - at this point I'd say with your input you should pop onto Discord to have more robust discussions.
ahmed_elbashery 6y ago
Did they cite any reason for the rejection? Thanks
- tandr 6y ago
  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 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://github.com/golang/go/issues/41716
- ylluminate 6y ago
  https://news.ycombinator.com/item?id=25604064 https://news.ycombinator.com/item?id=25604064
UweKrueger 6y ago
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-and-usage 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-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.
- tandr 6y ago
  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 vs 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)
  - tandr 6y ago
    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.

by tandr 6y ago

ylluminate 6y ago

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

tandr 6y ago
Thank you for the suggestion. No, I am not on discord.
- ylluminate 6y ago
  I'm sorry - at this point I'd say with your input you should pop onto Discord to have more robust discussions.

ahmed_elbashery 6y ago

Did they cite any reason for the rejection? Thanks

tandr 6y ago
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 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://github.com/golang/go/issues/41716
ylluminate 6y ago
https://news.ycombinator.com/item?id=25604064 https://news.ycombinator.com/item?id=25604064

UweKrueger 6y ago

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-and-usage 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-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.

tandr 6y ago
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 vs 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)
- tandr 6y ago
  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.