I would say that you need to present a case where Julia would be needed. I do Python and Javascript it covers most stuff that isn't low level. Rust does that, so what is the need for Julia?
Python handles that pretty well. Maybe Julia does it marginally better, but I don't think it's worth learning a whole new language for this unless your day job is only 'Numerics and ml'
This is only true because other people wrote the hot parts in other languages and exposed a python library. That’s fine but isn’t really fair in a battle of languages
I think it's fair. We're not talking about that intrinsic language qualities, we're talking about what you can do. Or that's my take anyway. That's what I think of comparing when the lead line for the whole conversation is "tool belt".
The two are related. If i can't write fast code in the langauge itself but have to resort to another langauge, then that's very much a "what can you do with it" problem.
And I'm saying doing stuff with numpy counts as doing stuff in python. Just because numpy is mostly implemented in c doesn't prevent me from writing ML in python.
Julia is much more amenable to implemening it though in native Julia, so I think it's a lot easier to stay out of C even when there's a similar library hole between Julia and Python.
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).
Good c interoperability is a benefit that Julia and Python share, and exploit for performance gains. They're on even footing here.
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.
Yeah, won't argue there; I was responding to the notion that python is somehow cheating by using numpy. Python has at least 3 paths to cpp interoperability now, but they've all got their warts.
They did that because Python has an appealing user experience for people using that kind of code day-to-day. IMO this is what Julia missed; I've tried it at least once per year since first hearing about it in 2014 and the UX was horrible every time. Pretty sure if I ever found myself needing to write low-level numerical code I'd just use Fortran like everyone else.
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.
From this perspective, I totally agree. If you enjoy learning new languages (at a surface level understanding) for the increase in perspective, you might find Julia worth learning.
Popularity and quality are not really correlated, so the first point is false. As for the second, nobody has to prove anything to you - if you're interested go take a look and you will see for yourself, otherwise don't and keep using Python.
> Popularity and quality are not really correlated, so the first point is false
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.
The comparison ignores things like age (older tools will be ore popular). Certain things have to be experienced. I'm not sure how you want me to prove something like productivity. How would you prove python is better for some things than c.
Again, that comparison makes no sense. Python became somewhat popular for a reason and that built momentum but it didn't get to the current popularity because it's a superior language for any task - rather because many people use it and write tutorials, answer questions on SO, and write libraries and tools.
Python had a number of similar competitors a few years back, the main one being Perl. Python is better than Perl for certain tasks, the syntax encourages writing more readable code. Personally I like Perl, but if I am doing anything non trivial, Python will give me more maintainable code. Perl has a more expressive syntax, which is both a blessing and a curse.
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.
I don't care about proving anything. You are looking at absolute numbers as opposed to things like growth or experience of people who switched.
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.
But you shouldn't be doing the imports and no one does it like it. You shouldn't import it into the global namespace because you can't dispatch on the type so you need to refer to it by the full name.
Well, not really, no. You shouldn't import into the global namespace for clarity - "from numpy import *" is very unclear. But importing specific objects is fine and is done all the time. And if you're in a notebook setting and value "less typing" over everything else it's certainly encouraged.
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.
If Nim had sklearn, pandas I would probably choose it over Julia. I would love a statically typed Python. Have no interest whatsoever in learning a brand new ecosystem and syntax at this point.
