However, it's just a wall I haven't really bumped into. I suspect many people don't, and a part of that is popularity - so much exposure can do a lot to expose the warts. Though I think that goes for both Julia and Python.
But I think once you know numpy well you probably won't run into that restriction (can extend in the native python) unless you're an expert (for the ML usecase).
Rust does it too, calling external unsafe code so they don't need to rewrite the world all in one go. I'd say that the extendability of a language isn't just fair, but a crucial aspect in comparing languages because that's what people do in the real world.
It's a real shame because Julia initially felt like it might develop to be the natural successor to Python in scientific computing, but over time that has seemed less and less likely.
Main problems were cryptic errors in the REPL, super slow start-up and first run times (JIT issue I seem to recall reading was being improved), and a generally very poor third-party package management system.
On the last issue, I'd say Python is not perfect but pip and various virtualenv management systems are "good enough". Having something like the Rust/Cargo setup is what I would prefer.
Popularity is a good enough proxy for how good a given tool is at a given task. Go give 100 people a hammer and a tootbrush and ask them to nail a plank, and you can divine the relative usefulness of each tool based on the number of people who used each.
> As for the second, nobody has to prove anything to you
Nobody is beholden to anyone, but if you're putting a contrary position forward with no evidence be prepared to be asked to elaborate. Such is life.
Then no doubt the majority of those 100 people would use the toothbrush to hammer the nail. It is after all a far more popular tool.
Then you have PHP, which is (or at least was) an inferior langauge to Python when python started getting popular. Python does more that just web dev. Likewise with Ruby.
Python could easily be described as "better" depending on the task.
Even something like inverting a random 4x4 matrix is just so much simpler. In julia it's just "inv(rand(4,4))". In python, you'll have to install numpy first and then writing it out is like 4 times as many characters.
And yeah, you need to install numpy first. But if you're doing this work you of course already got it installed.
import numpy as np np.linalg.inv(np.random.rand(4,4))
And you have to write it like this, because of lack of dynamic dispatch.
> np.linalg.inv(np.random.rand(4,4))
Which of course is nothing to do with python, and is trivially reduced to the aformentioned `inv(rand(4, 4))` with imports.
> And you have to write it like this, because of lack of dynamic dispatch.
Not at all.
Dynamic dispatch would help if you also defined a "rand" function in scope, but that's a way more general argument and IMO you'd lose more than you gain with it.