I really don't see how PyPy is "splitting the user base" when you have to make close to no changes to your code to gain an appreciable speedup in 90% of the cases.

I see many people compare Python to Go and frankly? Go isn't nearly as nice to work with as Python (no exceptions? one among many small but noticeable annoyances). It's much nicer than C or C++ in cases where you require the raw performance but it isn't a replacement for Python.

There are also many areas where performance is literally of zero consideration (small scripts to automate stuff) and those areas are where Python is hard to beat.

I think the problem with Go coming from Python is that the paradigm shift is a lot more substantial than it appears at first blush. My experience was quite the opposite: Go is pleasant to write in, exceptionally simple, and once you fully grok (and appreciate) slices and channels, the expressiveness of the language starts to take a life of its own. I never missed exceptions much (again, because you have to completely accept Go for what it is) and the fact the language specification is so short makes it easy to understand and relatively fast to pick up. Plus it's fast.

My problem with Go has nothing to do with the language per se. Instead, my reservations fall mostly on the ecosystem. It's immature and compared to more established languages like Python, it isn't nearly as rich (after all, it isn't as old). I gather from reading the mailing list archives off and on that there's been some inertial resistance toward certain frameworks (I can't really fault anyone for this--Martini and Revel have too much "magic," for example), and in some cases, prospective users are advised to "roll your own" if it's not something in the standard library. But when it comes to certain odds and ends, it's just downright difficult at times to find something that works as well as its Python counterpart out of the box and is relatively API stable (blackfriday, the Markdown parser, comes to mind--but then I guess offloading that to the client using JS might be better these days?).

Also, the abuse of the word "idiomatic" grates on me a little. There was someone on HN a number of months back who joked (paraphrasing) "Great, we're going to see 'idiomatic' abused as much as 'pythonic' and 'pivot.'"

But, that's why I do agree with you: Sometimes performance doesn't matter quite as much as the ability to avoid "not invented here." And Python has libraries for almost everything--SQLAlchemy is probably one of Python's "killer apps." (I expect Go will progress there, one day, but for some use cases it's not quite at that point in my experience--so the answer is probably to contribute to those Go libraries/projects you find of use.)

Pypy3 + STM is coming, which should resolve your first two points. Pypy is fast enough for most, and is gradually getting faster. I don't see at all how it splits the user base.

With regards to asyncio, a lot of people would disagree with you.

Too little too late? Maybe...that's for you to decide. Yes, there are new competitors that didn't exist when the decision was made to pursue the Python 3 strategy. But Julia has nothing close to the standard library + ecosystem that Python does, and probably won't for a long time if it ever does; and while Go is coming along in that regard, there are some aspects that make it less preferable to Python, especially JITed Python with software transactional memory (i.e. no GIL). I, for one, would never want to code without exceptions if I had the choice.

> PyPy is not fast enough and further splits the user base.

There is no split?

> Gevent is vastly simpler than this.

I prefer asyncio's explicitness to gevent's monkey-patch-and-pray-it-doesn't-block semantics. Also, the asyncio approach makes it very clear when you have released the "lock" on your state--it happens every time you yield from your coroutine. The gevent approach is to hide these synchronization points, which I think is a bad policy. For what it's worth this latter objection is one of the main reasons asyncio is the way it is--GvR had been bitten before by implicit yields.

If you're needing to think carefully on what code you call might cause a switch and what won't, you're already doing it wrong. Instead of treating gevent like coroutines with less predictable ordering, treat it like threads with more predictable ordering. You know that basic operations (eg. checking if something is a certain value, or assigning a variable) won't cause a switch. So you can do two of those in a row, without thinking about race conditions. Anything beyond that...use a lock (or a queue, or any of the other provided concurrency primitives).

Well, thanks to operator overloading, comparisons or assigning a variable (to a property of an object) can cause a switch. If you really need to get a mental model of what your code is doing, or could do under sufficiently unusual circumstances, gevent doesn't really provide any guarantees beyond raw threading.

Glyph (of Twisted fame) wrote a good blog-post about it: https://glyph.twistedmatrix.com/2014/02/unyielding.html

gevent simply has the nicer API. I've never once had an issue where the monkey patching failed, or conflicted with another library. Yes, monkey patching is a dastardly and gross thing, but in practice gevent works amazingly well for 99% of use cases.

Not to mention the performance is very good, especially in the most recent version.

Couldn't agree more.

Python is essentially dead as anything more than a scripting language.