<p>I was wondering what percentage of the community actually embraces Go's distinctive concurrent composition features. Is it something you use often or are you primarily using Go to solve other kind of problems? In my particular case I use it mostly to create web apps or to tackle other problem domains without using concurrency myself. Having said that, there have been some shell scripts I've ported to Go using a fan-out, fan-in pattern. At the end of the day though, concurrency/composition still isn't something I use naturally, but since I like Go and minimalism so much I keep using it for pretty much everything I need to code.</p>
<hr/>**评论：**<br/><br/>zeroZshadow: <pre><p>I use it a lot for our game server written in Golang. Seperate goroutines for player connections, rooms that users play in, and database communication.</p></pre>koalainthetree: <pre><p>How does the game server work? I'm currently tasked with writing a multiplayer game server using sockets and I'd love to pick your brain for pointers.</p></pre>zeroZshadow: <pre><p>We're using websockets from the gorilla package for incoming connections from players, with a seperate goroutine for both reading and writing packets. The packets themself are (de)serialized using protobuf, a bit of a pain to get running well, but it works wonders once you have that done. There is a small message routing system in place to have every packet type handled by its own handler function, on the read goroutine of the user. The gameplay itself runs in rooms that users connect to, being its own goroutine again to ensure the game code itself does not run concurrently with handling messages. All packets that have to be handled by the room instead of the user code, get send into a buffered channel that the room goroutine will read out of and handle. Its a simple select on emptying that buffer, and waiting for the next game tick to happen every 50th of a second. Feel free to pm me for more questions.</p></pre>bradleyfalzon: <pre><p>We use it for a http load balancer style application, where we have backend pollers in their own threads polling databases, polling other backends, updating internal caches. Then http requests to stdlib net.http respond with the caches contents.</p>
<p>We appreciate the cheap (not free) concurrency for this application, but the static typing / most-errors-are-compile-time is right up there. Although, we could achieve similar results using Java or Erlang, Go feels more enjoyable and being able to use it for web apps or this style (we have more) means less languages and tooling to learn and maintain.</p></pre>vascocosta: <pre><p>Yeah, I ended up porting older poller style backends from Java to Go for the same reasons.</p></pre>earthboundkid: <pre><p>Let's say you have a CRUD web app and need to make one initial DB request, followed by three follow up queries based on the results of the initial one. Do you bother to make them all concurrent or just leave it synchronous until performance is proven to matter?</p></pre>barsonme: <pre><p>Yes. :)</p>
<p>It depends on what the DB queries are doing, how efficient your DB is, etc. </p></pre>robertmeta: <pre><p>I do constantly -- it is so cheap and easy to just spawn a goroutine to do something concurrently. I use channels less, but use them regularly.</p>
<p>The development path is so easy for concurrency. Start by writing basically single-threaded code with sane use of functions. Then you just add like a go function() + waitgroup, then if you have advanced coordination needs you use channels. </p></pre>Akkifokkusu: <pre><p>All the time. It makes it incredibly simple to implement a microservice that reads from a job queue, asynchronously checks the health of dependencies, and responds to healthcheck requests. Concurrently processing the jobs also helps with throughput. That's just the tip of the iceberg. At this point, it's pretty rare that I'll write any kind of app without using at least the <code>go</code> keyword somewhere.</p></pre>mordfustang21: <pre><p>I implement it anywhere I can. I worked on a problem recently that used very large data sets, efficiency and speed was improved 10x by using concurrency.</p></pre>Fwippy: <pre><p>Same - most of my use of go is not for long-running web servers, but instead to make tools that process a lot of data. There's usually some easy parallelism wins from using a basic worker pool or a data-flow model, which takes about five minutes to code up.</p>
<p>I could do it in Python or C++, but go hits a sweet spot of productivity & executable speed, and goroutines are a big part of that.</p></pre>gotaway12369: <pre><p>This so much.</p>
<p>Having to write a script that will hit a rest API and create output files with the returned data. The amount of data I pull back is close to 20-30GBs.</p>
<p>Without concurrency, it took the script 3-4 hours</p>
<p>With, ~1-2 hours </p></pre>lapingvino: <pre><p>In my most common code I only use it for a timer, nothing else yet, but in case performance is unacceptable I would use it to parallelize a part of my code.</p></pre>kaeshiwaza: <pre><p>Like optimization, i use concurrency only if I need it. It was the reason I use Go at first, but the more I use it the more I will use it for project where I don't need concurrency but for simplicity and good tools.
Also I use concurrency it for fun ! </p></pre>vascocosta: <pre><p>This is exactly what happened to me. I learned it because it looked so simple and easy to build concurrency with it but then stayed because of the minimalism, productivity and tooling.</p></pre>howeman: <pre><p>A bunch of the gonum libraries are concurrent. I use it all the time in my own work</p></pre>akcom: <pre><p>Most of the times I use Go for a project it's specifically because of the strong concurrency primitives.</p></pre>tty5: <pre><p>Yeah, quite a bit - pretty much every time there is some io (database, file, network) that doesn't have to be run sequentially I split it into a couple goroutines.</p></pre>beeker1121: <pre><p>Currently coding a web crawler in Go; single manager with multiple worker node structure. Each worker concurrently crawls via, just in testing and nowhere near hitting a resource limit, thousands of goroutines. This wouldn't be possible without concurrency.</p></pre>aerth0x1A4: <pre><p>Yes. I think so!</p>
<p>Add one of these "uptime" things to your program, and you have basic concurrency. (or is it parallel?) </p>
<p>Anyways its the first thing I code in a web app...</p>
<pre><code> package main
import (
"fmt"
"time"
)
func main() {
// Run time
boottime := time.Now()
// B
var uptime time.Duration
go func() {
for {
time.Sleep(1420 * time.Millisecond)
// Display Uptime!
uptime = time.Since(boottime)
fmt.Println("Uptime: " + uptime.String())
}
}()
// do things other than sleep
time.Sleep(10 * time.Minute)
}
</code></pre></pre>barsonme: <pre><p>Yeah. It's great to be able to kick off an email to somebody without having to wait for the network request to finish. There's no guarantee that the message will take, e.g., 400ms and it's rude to keep the client waiting.</p></pre>DarkAnHell: <pre><p>Web apps -usually- use concurrency though</p></pre>dlsniper: <pre><p>Web apps always use the concurrency Go as as net/http uses it. And as a regular user, it depends how you design your app/what are your needs. </p></pre>vascocosta: <pre><p>Indeed, but you're probably talking about the standard lib implementation of stuff like net/http. I guess I meant implementing it directly, not as a client.</p></pre>
