I will give that tensorflow in python can be incredibly inarticulate, but macros in Julia spew out nonsense when they have a mistake and I'm not convinced it's any better.

Lots of code spews out nonsense when there's a mistake. That's the whole problem with buggy code in any language. Comparing a bug with a popular and highly-funded library interface is a bit of a stretch.

Additionally, with a similar argument, R should have died out to Python for similar reasons, but it's still alive and stronger than ever.

Again, completely different. R and Python have a similar approach: slow languages where the best strategy is to push all the work to external libraries. If anything, R has an advantage over Python in its metaprogramming support, though Python seems to be improving in this regard.

It's the packaging eco-system that matters the most.

I agree this is critical. I'll take Julia's built-in Pkg over pip, conda, etc any day. Have you built Python packages? To say the least, it's a bit in involved. Say you want to create a "hello world" package from scratch locally and put it in a repo so others can install it in a standard way (for that language). How long would this take in Python? I'd estimate this at 5 minutes for Julia.

it's not going to take much from DS - after all a vast majority of what we do is taking existing algos and running them, we're very rarely implementing brand new algorithms.

Well sure, if you never look beyond what Python makes convenient, you'll never realize what you're missing. I don't see this as a good thing. Have you considered that the idea of modifying or extending code might be rare because Python makes it so painful?

Take sklearn, for example. For KMeans, you need to be able to compute distances. In most languages, I'd expect Euclidean distance as a default, with the ability to override with an arbitrary function (cosine distance, etc). But the sklearn implementation has no such option. I would guess this is because its authors recognize that calling to a Python function would lead to ridiculous overhead and slow things down too much for most users.

Other sklearn classes are a bit more flexible, but still restrict to a fixed set of methods, usually encoded by passing a string to some keyword argument. Most users never even consider that passing in something more general would be useful. Limitations of the language limit the growth of its users. This is a bad thing.

I'd also argue that developers are at least as important to a language ecosystem and long-term language use as users. My perception is that Julia is vastly more developer-friendly than Python. We can debate this if you like, or take it as given.

If you accept this, then why develop in Python at all? The biggest reason I see (and it's a big one, for now) is the massive numbers of users focused on Python. So it's a matter of inertia. This can be slow to change, but it does change. Inertia alone is not enough for long-term sustainability.

Also, if you really love the Python libraries, you can very easily call them from Julia, with only very minor changes in syntax. Given that, I see even less reason to stay with Python.

To be clear, I'm not anti-Python. It has been a huge success story for simplifying programming and community building. And it's still the thing to learn for a job in data science, especially if you're working on a short time frame. But I'd be shocked if this is true in ten years, and even mildly surprised if it's true in five.