4 ms·

Find an example that shows using a timeout channel along with another async activity on another channel, and then switching on that. Then you will start to see

• laureny 14y ago
  Please do show how to do this in Go when you have a few minutes, I'm really curious (and happy to write it in Java once I see what you mean).
  • ciniglio 14y ago
    I think they mean something like: c = make(chan bool) go doSomeWork(c) select { case b := <- c: # do something here if something happened on the channel case <- time.After(5 * time.Second): # timed out :-( }
    • RyanZAG 14y ago
      Well the timeout can be handled in java too Result result = future.get(5, TimeUnit.Second); if (result == null) // do something if timed out else // do something with result My original question was phrased badly though, and what I meant to ask was: is the underlying implementation faster? Since Golang is designed as a systems language, is the channel/gorouting system a lot more performant than the Executor/future method of Java? EDIT: I see what newobj is talking about now: With the Java method, the 'task queue' in this case is very rigid and would be hard to add futures from multiple locations, while the goroutine method allows easy access to add new messages to the channel from anywhere. You could probably emulate the goroutine method using a synchronized queue or similar, but the goroutine version handles it automatically.
      • laureny 14y ago
        Right, just a nit pick:t if get() times out, it throws a TimeoutException instead of returning null (much cleaner).
      • laureny 14y ago
        Right, just a nit pick:t if get() times out, it throws a TimeoutException instead of returning null (much cleaner).
      • NateDad 14y ago
        FYI - you can also have 100,000 goroutines on a standard desktop without hitting resource problems (the go authors mentioned debugging a system in production that had 1.3 million). I doubt the same could be said for futures.