Hi,
Can you please throw some lights - where is real time use cases for unidirectional channels? will that work like Kafka Topic, can some process sends and consumer process consumes the data? if yes then thus that becomes bidirectional channel right?
bc:=make(chan int) //bc is bidirectional channel, which can WRITE & READ
rc:=make(<-chan int ) //rc is unidirectional channel, which can READ/RECEIVE only
wc:=make(chan<- int) //wc is unidirectional channel, which can WRITE/SEND only
fmt.Printf(“BC\t:%T\n”,bc)
fmt.Printf(“RC\t:%T\n”,rc)
fmt.Printf(“WC\t:%T\n”,wc)
In Go, channels are used to communicate between goroutines: a communication is sent, a communication is received. While channels are essentially bidirectional, it’s useful in a type-safe language like Go to document and enforce at compile time when local usage is limited to sending or receiving.
Thank you for your code example, let me explain my understanding around your code, correct me if I’m incorrect:
naturals := make(chan int)
squares := make(chan int)
Both are bidirectional channels, it does unidirectional implicit conversions, no issues.
go counter(naturals)
This goroutine launched with “out” write channel just to take the values 0 to 99; and its closed to available to other routines(not to have deadlock); Here is my question/doubt is “out” reference of “naturals” channel? when we close the “close(out)” does indirectly closing “naturals” channel? if yes then only it is available into “go squarer” routine as “in” channel to read the values right? Please help is my understanding is correct! It’s great code example on channels to understand it.
*But still what could be the real world scenarios, I know goroutines communications/sharing by channels, but one particular go routine closes the channel and then only that particular channel is able to access/read in other goroutines, otherwise it’s deadlock issues; to me it’s sequential around unidirectional channels, there is no concurrency right?