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 concurrent benefit of doing so, in particular, the current goroutine should be able to do something else in the meantime.
Another common mistake is to build a pipeline of goroutines and channels in a case where you can just spawn a new goroutine for each incoming request. The former solution runs the risk of reinventing the Go schedulers on top of the Go schedulers and this is usually a losing proposition. Furthermore, each goroutine in the latter solution can track its own state, where a pipeline has to "impersonate" the data that it is currently processing. The pipeline often leads to the need of spawning more goroutines as well in order to handle things on the side, and each node in the pipeline ends up being a directly-coded node.js event loop. You can also try to think about the system as communicating agents. Imagine a group of human beings and how they would communicate and delegate: some times it is more efficient to do a piece of work yourself rather than ask someone else to do it. Some times, it is the other way around. Concurrent programming isn't much different, though note that there is one big difference: in a concurrent system, you often have shared knowledge among all the agents. In a (truly) distributed system, you have a correspondence to epistemic logic: different agents knows different parts of the state and will have to ask for data. On Tue, Jul 25, 2017 at 6:38 AM Glen Huang <hey....@gmail.com> wrote: > 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, 2017 at 8:48:59 AM UTC+8, Dave Cheney wrote: >> >> This presentation, or more accurately, the summary at the end, may be of >> interest to you. >> >> https://dave.cheney.net/paste/concurrency-made-easy.pdf >> >> A recording of this presentation at GopherCon Signapore is also available >> by searching for those keywords. >> >> On Tuesday, 25 July 2017 01:34:30 UTC+10, Glen Huang wrote: >>> >>> Hi, >>> >>> I'm still pretty new to go. Hope this question isn't too stupid. >>> >>> I'm writing a restful API server, and in order to send a response, I >>> need to query a db to get its content type and then send the actually file >>> that lives on the file system. Now the question is, should I put >>> db.QueryRow and os.Open each in a goroutine to make them concurrent? >>> >>> And a more general question is, when using APIs from the stdlib or >>> 3rd-party packages, how do I determine whether to wrap them in goroutines >>> when more than one of them need to happen sequentially and the order >>> actually doesn't matter? Should I manually time the API executions to make >>> the call? Should I writing things sequentially by default and only when >>> hitting performance problems do I profile the program and wrap calls in >>> goroutine? >>> >>> How do you decide when to use goroutines? >>> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
