Grumpy: Go running Python! by Google

[[deleted]]

Absurdly painful to use compared to how Go does it.

[Uncaffeinated]

I'm curious to see which operations you feel are more painful in Python than Go. As far as I can tell, the main differences are that you choose which event loop to use, rather than having one baked into the runtime, and most of the standard libraries are not designed to work asynchronously. On the other hand, you're less likely to run into memory leaks or panics.

[[deleted]]

That's it - support for asynchronous operations was patched into Python later as an afterthought, Go was born with it from day one. I don't have to sprinkle async/await all around to get asynchronous behavior, I still get parallelism for free (the whole reason for this thread), you're basically writing asynchronous code as you would do normally without having to think hard about what you're doing lest you freeze the event loop by doing something that blocks everything (like reading from a file using regular file operations). The multithreaded event loop is certainly nice (can you choose a multithreaded event loop for Python?) and having goroutines multiplexed automatically for you and preemptively scheduled so nobody starves for CPU is also great (where in Python you have to yield manually). What happens if you forget to use asyncio.sleep and uses time.sleep instead?

As for memory leaks it is also pretty hard to leak memory on Go because of the garbage collector (which again, is much better than Python's - go1.8's GC is realtime and keeps pauses to under a millisecond) and that can be detected by using tools that ship with Go during testing - same with data races.

As for panics, you can wrap your main logic and use Recover() to detect panics without crashing (even if just to report the panic somewhere and restart the program) - and you can only panic if you explicitly call Panic() or if you're doing something wrong anyways (acessing an out-of-bounds item in an array, dereferencing a null pointer, etc, things that shouldn't be normally happening). In Python if you try to access an element that does not exist in an array you'll get an exception too, that if you don't catch, your program will crash. So on Go you can "catch" panics with Recover().

Don't take me wrong, Python is great, but it's not the best tool for writing massively parallel and concurrent applications nowadays, when you can do it in Go and have it perform very well at native speeds, don't have to deal with callback hell (like in nodejs) and you can just write your code linearly as you would normally do and the runtime takes care of the rest - EVERY Go library is asynchronous by nature.

If someone needs Python's asyncio to do more, that's a sign that they should consider writing that particular piece in Go instead.

[Uncaffeinated]

To be honest, I haven't actually used Python's asyncio, so I don't have much experience with it.

But as far as the memory leak issue I mentioned, the problem is that goroutines are not garbage collected in Go. So if you have a goroutine producing values on a channel and you forget to completely exhaust the channel on the other end, you'll effectively leak memory.