<hr/>**评论：**<br/><br/>McSquibbly: <pre><p>Historically Python has had a global interpreter lock where only one thread could actually execute the interpreted code. They got around this by doing things like "when waiting on IO do thread work," stuff like that. This is different if you use python multiprocessed</p></pre>thraxil: <pre><p>Everything's relative. Sometimes the problem is easier to solve using Python. There is no silver bullet.</p>
<p>That said, Go was designed from the ground up for concurrency while Python really wasn't.</p>
<p>Last time I checked (it's probably different now, but similar), a Python thread had a base memory usage of about 8MB. A goroutine in Go had base memory usage of about 4K. That means that even if everything else were the same, you could spawn about 2000 times as many concurrent goroutines on a given piece of hardware as Python threads. Of course, on a multicore machine, Python's GIL will hamper things further, making it hard to take advantage of more than one core with only a single Python process. Go isn't perfect, but it does a respectable job distributing work across cores in comparison.</p>
<p>Of course, if you are writing Python and actually need to do significant concurrency, you probably aren't going to use basic threads. Instead, you'll end up on something like Twisted, gevent, tornado, or the new tulip/asyncio stuff. Those will give you better performance but they all come with costs in terms of asking the developer to approach problems in a very specific way that may or may not line up with what they are trying to do. Eg, being very careful to avoid calling a library function that might block.</p>
<p>Meanwhile, the goroutines and channels model in Go is relatively simple to grasp and reason about.</p></pre>jerf: <pre><p>Actually, gevent's pretty cool.</p>
<p>The reason I've pretty much abandoned Python for this use case isn't that Python can't express concurrent solutions... it's more that it's miserably slow (PyPy merely brings it up to "slow") and that I'm tired of dynamic typing. And I work at a scale and in a place where both of those are fatal killers for me.</p>
<p>Oh, and the fact that a lot of the ecosystem is still event-based, which is a really unpleasant way to program once you use something better. Gevent really should have "won". I fail to understand the python community's love of asyncio, it looks like a big hack when you have a nice concurrent runtime like Go.</p></pre>klaaax: <pre><p>Instead of spamming this forum with these kind of questions ( <a href="http://www.reddit.com/r/golang/comments/3665d7/should_use_go_for_webapps_that_scale_what_does/" rel="nofollow">http://www.reddit.com/r/golang/comments/3665d7/should_use_go_for_webapps_that_scale_what_does/</a> ) Take the time to explain your use case precisely. Because you make stuff up it isn't even funny.</p></pre>hobbified: <pre><p>Their "use case" is trolling reddit.</p></pre>dAnjou: <pre><p>Are they?</p>
<p>One obvious advantage of Go is of course that the language was designed with concurrency in mind. But on the other hand Python 3 has now its <em>asyncio</em> module.</p>
<p><strong>UPDATE</strong> Uhm, is it too much to ask to explain why you're downvoting?</p></pre>eatingthenight2: <pre><p>ha nice. I wonder which offers better concurrency a language built around it or a language that added a module as an after thought. Not saying you can't do it in python but if you have a problem that requires high concurrency to solve it python would be at the bottom of my list next to php.</p></pre>lhxtx: <pre><p>Have you even tried to read the asyncio documentation? I think I could read something in a foreign language and come away with the same understanding. The docs are horrible compared to simply typing go func()</p></pre>dAnjou: <pre><p>No, I didn't read it. All I did was questioning the premise of the question, and then adding some information for OP to do further research her/him-self.</p>
<p>Besides, concurrency is already hard to understand on a conceptual level. I doubt a language can make it <em>much</em> easier. Documentation could ... maybe.</p></pre>Exaltred: <pre><p>It can be made significantly easier...it's all about the implementation. In Go all you need to do to use concurrency can be summed up in a few slides on the Go tour. Like ihxtx said, one can just type go func() and you're on your way. Channels might be a bit more complex, but they're straightforward once you learn how they operate.</p></pre>dAnjou: <pre><p>I'm tempted to prove that it's just as easy in Python.</p></pre>lhxtx: <pre><p>And you'll fail miserably. Python has the GIL as well as heavy threading. Not to mention call back hell. Asyncio is <em>horrible</em> compared to go routines. </p></pre>lhxtx: <pre><p>If you haven't looked at how asyncio works, you need to stop posting, go read the docs, try to implement something nontrivial in it, attempt to do the same with go, and then come back here and then give your comments. You'll find Python horrible for concurrency compared to go. </p></pre>lhxtx: <pre><p>You're probably being doenvoted because you're displaying ignorance about go versus Python capabilities. </p></pre>dAnjou: <pre><p>My original comment was at <em>-3</em> even before the discussion started. So please quote exactly the part of that comment where I'm "displaying ignorance".</p></pre>lhxtx: <pre><p>You imply that Python is equivalent or better at concurrency in your post... </p></pre>dAnjou: <pre><p>Sure ...</p></pre>
