Catching return values from goroutines

Question

The below code gives compilation error saying 'unexpected go':

x := go doSomething(arg)  func doSomething(arg int) int{     ...     return my_int_value } 

I know, I can fetch the return value if I call the function normally i.e. without using goroutine or I can use channels etc.

My question is why is it not possible to fetch a return value like this from a goroutine.

Answer 1

Why is it not possible to fetch a return value from a goroutine assigning it to a variable?

Run goroutine (asynchronously) and fetch return value from function are essentially contradictory actions. When you say go you mean "do it asynchronously" or even simpler: "Go on! Don't wait for the function execution be finished". But when you assign function return value to a variable you are expecting to have this value within the variable. So when you do that x := go doSomething(arg) you are saying: "Go on, don't wait for the function! Wait-wait-wait! I need a returned value be accessible in x var right in the next line below!"

Channels

The most natural way to fetch a value from a goroutine is channels. Channels are the pipes that connect concurrent goroutines. You can send values into channels from one goroutine and receive those values into another goroutine or in a synchronous function. You could easily obtain a value from a goroutine not breaking concurrency using select:

func main() {      c1 := make(chan string)     c2 := make(chan string)      go func() {         time.Sleep(time.Second * 1)         c1 <- "one"     }()     go func() {         time.Sleep(time.Second * 2)         c2 <- "two"     }()      for i := 0; i < 2; i++ {         // Await both of these values         // simultaneously, printing each one as it arrives.         select {         case msg1 := <-c1:             fmt.Println("received", msg1)         case msg2 := <-c2:             fmt.Println("received", msg2)         }      } } 

The example is taken from Go By Example

CSP & message-passing

Go is largerly based on CSP theory. The naive description from above could be precisely outlined in terms of CSP (although I believe it is out of scope of the question). I strongly recommend to familiarize yourself with CSP theory at least because it is RAD. These short quotations give a direction of thinking:

As its name suggests, CSP allows the description of systems in terms of component processes that operate independently, and interact with each other solely through message-passing communication.

In computer science, message passing sends a message to a process and relies on the process and the supporting infrastructure to select and invoke the actual code to run. Message passing differs from conventional programming where a process, subroutine, or function is directly invoked by name.