Re:Go kit: Go in the modern enterprise
by riobard on Wednesday February 11, 2015 @06:16PM
(#9036350)
type Service interface {
Handle(req Request) Response
}
Re:Go kit: Go in the modern enterprise
by frowaway001 on Wednesday February 11, 2015 @09:04PM
(#9036944)
Now make Request and Response generic so that you can tell different requests and responses apart.
Then make Future generic so that you can use all the existing combinators out there, like `sequence` which turns `List[Future[Response]]` into a Future[List[Response]]`.
Your reply actually highlights one of the key features of Go: if you design it right using channels, constructs like Futures and Promises aren't necessary.
Re:Go kit: Go in the modern enterprise
by frowaway001 on Thursday February 12, 2015 @08:23AM
(#9038648)
So how would I write code which works regardless of whether I'm using channels, lists or other applicable structures?
Re:Go kit: Go in the modern enterprise
by codygman on Wednesday February 11, 2015 @09:54PM
(#9037110)
> design it right using channels, constructs like Futures and Promises aren't necessary
Careful implying that using futures and promises are incorrect unless you can prove that channels can do anything futures and promises can do while doing it better.
Do you have any examples?
In Go they are incorrect at worst, not idiomatic at best. That's due to the nature of the language as channels are built-in primitives capable of fulfilling the roles of either, not a slight on the efficacy of the constructs themselves.
Request => Future[Response]
I don't know what the equivalent would be in Go but I can't imagine its any clearer than this.