On Monday, July 24, 2017 at 6:44:10 PM UTC-6, nat...@honeycomb.io wrote:
>
>
> only use goroutines when you know for a fact that you have an issue which
> needs solving via concurrency, e.g., IO-bound workloads. While it's nice to
> have goroutines and channels within easy reach, they do
In the Erlang world, when people ask this question, we often say: "identify
the truly concurrent activities in the system--make those into processes".
To wit, a common mistake is to apply too much concurrency in a system where
none is needed. If you run a new goroutine, then there has to be a
I just watched the presentation, it's a good one. Thanks for sharing it.
The summary seems more towards how to write goroutines correctly, but it
contains good advices and the general message is clear for me now, make
things simple and do things sequentially when possible.
On Tuesday, July 25,
> Why make them concurrent if you need to know to know the end result of
the DB call *before* opening the file?
I actually don't need to know the result of the DB call before opening the
file, only before sending the file as a response.
> only use goroutines when you know for a fact that you
