Go is a clear winner IF you don't want to have difficulty dealing with asynchronous functions and synchronous functions. In Python (and JavaScript and other single threaded languages) asynchronous functions can use synchronous functions, but not the other way around. Synchronous functions that expect output from asynch functions will end up with weird bugs, or might not even be able to get output, since asynch functions often hand their outcomes to callbacks within the function. So everything that requires an asynchronous operation ends up getting infected with the coding style required to handle asychronicity; you're forced to code everything that needs an asynch op using promises, callbacks, etc.
Go, being multi-threaded, and being designed to be usable by teams with a broad range of skill, eliminates the need to worry about asynch vs. synch code.
Go is the language that does this most beautifully in my opinion. As soon as you do any IO operation, it just parks that goroutine and resumes any other ones that aren’t blocked on IO.
If you look at the IO operations in the standard library, they seem synchronous. In other words, they just do work and then return a result when they are done. But it’s not that they’re synchronous in the sense that it would mean in JavaScript. Other Go code can run while one of these operations is pending. It’s that Go has eliminated the distinction between synchronous and asynchronous code.
Concurrency in Go is a facet of how you choose to model your program, and not a color seared into each function in the standard library. This means all of the pain of the five rules I mentioned above is completely and totally eliminated.
So, the next time you start telling me about some new hot language and how awesome its concurrency story is because it has asynchronous APIs, now you’ll know why I start grinding my teeth. Because it means you’re right back to red functions and blue ones.
—————————————————————————
If you do not have to worry about asynchronicity, then this advantage may not mean as much to you, and Python's larger user base and libraries may be a compelling advantage. But if you do, not having your world of functions divided into two "colors" is a huge advantage.
Go, being multi-threaded, and being designed to be usable by teams with a broad range of skill, eliminates the need to worry about asynch vs. synch code.
See this article explaining the problem with Async functions. "What Color is your function?" http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Quote from the article:—————————————————————————
Go is the language that does this most beautifully in my opinion. As soon as you do any IO operation, it just parks that goroutine and resumes any other ones that aren’t blocked on IO.
If you look at the IO operations in the standard library, they seem synchronous. In other words, they just do work and then return a result when they are done. But it’s not that they’re synchronous in the sense that it would mean in JavaScript. Other Go code can run while one of these operations is pending. It’s that Go has eliminated the distinction between synchronous and asynchronous code.
Concurrency in Go is a facet of how you choose to model your program, and not a color seared into each function in the standard library. This means all of the pain of the five rules I mentioned above is completely and totally eliminated.
So, the next time you start telling me about some new hot language and how awesome its concurrency story is because it has asynchronous APIs, now you’ll know why I start grinding my teeth. Because it means you’re right back to red functions and blue ones.
—————————————————————————
If you do not have to worry about asynchronicity, then this advantage may not mean as much to you, and Python's larger user base and libraries may be a compelling advantage. But if you do, not having your world of functions divided into two "colors" is a huge advantage.