UweKrueger

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.

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.