<p>For anyone who's tried both Go and Python async (ex uvloop + sanic, apistar, etc) for their webapp, what are the pros and cons of working in each language?</p>
<hr/>**评论：**<br/><br/>soapysops: <pre><p>Go's async tends to make more sense because goroutines behave almost exactly like threads - at least, from the programmer's perspective they do. It's probably best to see Python's support for async as more of a performance optimization for people who need to use Python but also care about concurrency. (You could say the same about node.js).</p>
<p>I think Go's way is strictly better, but that was not clear until very recently, which is why there were so many projects out there making different attempts to do the same thing. Fortunately, Go's way of doing things does not actually require the use of a specialized language. Python could add a layer implementing Goroutines (I guess they would call them Proutines or something) once they finally get rid of the GIL. It would definitely be a lot of work, but it is possible.</p>
<p>You could also argue that the only reason Go's way makes any sense at all is due to some inherent limitations in the design of current operating systems, since it's basically just reimplementing things the OS does inefficiently in order to improve performance.</p></pre>kwerkor: <pre><blockquote>
<p>once they finally get rid of the GIL</p>
</blockquote>
<p>Are they actually going to do this?</p></pre>horan116: <pre><p>No, the GIL handles far too many things, that would require a python 4.x release and we see how hard it has been moving to 3.x. There are plenty of great discussions around why they cant or why it's extremely difficult to get rid off it. I don't think they have to either, python is an excellent wrapper language, maybe the best. I think Go is better suited to do the things python is not great at and fill the C level language gaps easily.</p></pre>weberc2: <pre><p>PyPy is playing around with a GILless implementation, and that's probably the interpreter you should be using if you care about performance anyway.</p></pre>zthunder777: <pre><p>Larry Hastings (and other core py devs) have been working on the “gilectomy” for 2+ years. It works and doesn’t break as much as one might think. But, as of his 2nd gilectomy talk at pycon (2017), it is still slower than the GIL in many cases. </p></pre>narzeja: <pre><p>I've done a lot of stuff using Python asyncio in a professional setting, and only used Go on personal toy projects, so keep that in mind. I will ignore any differences in performance in my assessment.</p>
<p>Concurrency in Go is native and pretty easy to get started, but you need to master using channels and waitgroups to get anything useful done, but that's about it complexity wise, really. Goroutines are natively multi-threaded so you may need to sprinkle locks all over your code if you use any shared state, or just communicate with channels. I like Go because of the low barrier to entry and the static typing.</p>
<p>Python Asyncio is a mess of futures, tasks, event-loops and a lot of boiler plate before even getting to the point of executing stuff. The asyncio documentation is absolutely horrendous, and you need a completely new vocabulary to reason about it. But once you get past this initial barrier, things become easier, especially reasoning about your program logic. Asyncio runs in one thread, so any shared state is natively immune to race conditions.</p>
<p>A very important downside to asyncio is, that <em>any</em> library you use <em>must</em> have non-blocking IO (i.e. specifically written for asyncio), otherwise you don't gain anything other than added complexity. You can't just write your main programming logic in asyncio and then use the <code>requests</code> library to download things, as your program will then block on IO. Well, you can, but you shouldn't.</p></pre>__ek: <pre><blockquote>
<p>Python Asyncio is a mess of futures, tasks, event-loops and a lot of boiler plate before even getting to the point of executing stuff.</p>
</blockquote>
<p>This is true for all language impls without M:N threads. I wonder how long it'll take for the majority of language implementors to realize that M:N is the way to go (heh). There was an announcement recently that Java is getting this feature in the future so there's some hope at least.</p></pre>kostix: <pre><p>Let me, as usually, recommend <a href="http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/">this classic essay</a> which deals nicely with the distinction between any callback-based (Python + any async I/O library) vs provided-by-the-runtime solution to concurrency.</p></pre>anacrolix: <pre><p>Came here to drop this link</p></pre>sethammons: <pre><p>I've used Python Twisted and Go (usually stdlib). Twisted is aptly named. I'd never program the backend of an API in Twisted again. We have a couple of teams who maintain a system that are in Flask. I've put in a few PRs to it. I find it way harder to read and navigate Flask code than Go. Maybe a fancy IDE would help. /me shrugs.</p>
<p>Go has first class concurrency and that is the major selling point for the services that we write. Go's static typing lets me skip a whole class of tests I would have to write in python. "This thing param should be a list; did we get a list or a string here?"</p>
<p>Python is much better with things that deal with numbers. Math in Go can be a pain. Also, dealing with JSON is much more pleasant for a developer in Python, though it is good in Go as soon as you write all the "convert the payload to JSON code" because you then have static typing again. I found Go to be a pain with "incoming API request, fetch JSON data from multiple dependencies, merge it together with some formatting, and return JSON. Lots of intermediate structs. </p></pre>kron4eg: <pre><p>Regarding math, there’s gonum project, which is already nice and getting better over time.</p></pre>daveddev: <pre><p>Here are some code comparisons that may be worth looking over: <a href="https://github.com/MagicStack/vmbench/tree/master/servers" rel="nofollow">https://github.com/MagicStack/vmbench/tree/master/servers</a></p></pre>Talked10101: <pre><p>I would say that Python async is often performant enough to be a good choice depending on what you are trying to do. It is very easy to throw some task to be run in a thread or process and not block the response cycle. The async thinking takes a bit of getting used to, but I have really enjoyed working with asyncio and aiohttp. Though the service was in fact to performant for our core service to keep up with. </p></pre>lelease: <pre><blockquote>
<p>Though the service was in fact to performant for our core service to keep up with.</p>
</blockquote>
<p>Sorry, could you clarify what you mean here?</p></pre>: <pre><p>[deleted]</p></pre>lelease: <pre><p>Wait, what were the deciding factors for you guys moving over to Golang since you said Python async is performant enough? Did you benchmark Go and find it to be so much faster that it's still worth moving over?</p></pre>
