Hacker News Reader

Comment by tandr | Hacker News Reader

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)

View on HN

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.

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

Reply on news.ycombinator.com