Comparing with Python


1 Like

Fair enough. From talking to a number of people who want to migrate from a different language e.g. Matlab or SAS, the most common question is why one chooses Julia over Python given the vast Python libraries available. Then, the common response is that Julia solves the two language problem as it is fast. Then, the response is that does speed even matter for the use case. So the conversation pretty much circle arounds speed. Language features don’t play well in such discussions either as they’re so debatable as you mentioned above.

How about having a list that goes like this. Feel free to add or yay/nay anything below:

Python has advantages in these areas

  1. Better development tools e.g. debugger
  2. Large talent pool
  3. Natively supported by cloud vendors e.g. AWS Lambda
  4. Natively supported by apache spark

Julia has advantages in these areas

  1. Easy to make things fast without much effort
  2. Reduced operating cost due to more efficient use of hardware (related to #1)
  3. Ability to build domain specific languages using macros

Ok I feel these things are still debatable but W/E

Julia advantages:

Nicer syntrax for matrix operations.

  • A*B vs
  • A' vs A.T
  • A[:, end÷2] vs A[:, len(A)//2]
  • [A; B] vs np.stack([A, B], 2)
  • [A B] vs np.stack([A, B], 1)
  • [A B; C] vs np.block([A,B], [C])
  • foo.(A) vs np.vectorize(foo)(A)

Also the ability to not always broadcast every operation, so that one gets errors when one screws up.


You can use them from Julia using PyCall :wink:


While python has a no doubt hundreds of times as many academic users as Julia (maybe even thousands).
The academic users are like <0.0001% of all python users.
Where as they are >90% of all Julia users.

Which means the julia community (and ecosystem) is a really vibrant academic place,


You can find a lot of discussion that is relevant in this thread: “Julia motivation: why weren’t Numpy, Scipy, Numba, good enough?”

Many points are brought up. For me, the focus on first class numerical programming support is among the most important. Numpy’s syntax is pretty awkward compared to Julia.

I have really come to love multiple dispatch, which relieves me of almost all the tedious input parsing that you encounter in Python (and even much more so in Matlab!) I would estimate that about 25% of all coding time I’ve spent in Matlab was on input parsing, or figuring out how to efficiently branch my code based on the type of a variable.

Lightweight or zero-cost abstractions are great! You can choose an appropriate level of abstraction without sacrificing speed, and get very elegant and readable code.

EDIT: Oh, and of the remaining 75% of programming time, I’d say most of it was spent figuring out insane code vectorization tricks, to help performance. This is pretty much the same in Numpy.


I don’t have the numbers, but my understanding is that while many people use Python, Julia has a comparatively (in a relative sense) large number of active contributors to the language. To contribute to Julia, you just need to know Julia.


IMO this is an extremely important point, both for the ecosystem and the management of expectations. Julia attracts people who need to implement something and want to do it in a generic and efficient manner. Those who are using another language just for an existing toolkit or library, mostly writing “scripts”, may benefit little from Julia at this point, especially if their key library is missing or WIP.


Depends. If you want to contribute to e.g. code optimization some C, LLVM IR and internals and some background on femto-lisp would be needed.

Sure, but you don’t need that to contribute in other ways. There’s a lot more you can do knowing just Julia than in many other languages.

1 Like

Agree. The MATLAB style syntax is more consice and makes more sense mathematically. Although Julia can be a good general purpose language, I still like the bloodline from Fortran to MATLAB to Julia.


That is because Python is at a more mature stage, and more contributions go to packages instead of the language itself.

I don’t think that is the correct explanation. I believe it’s because the barrier to entry for contributors are lower in Julia than in Python.

Python is still very actively developed, and they would have more contributors if it were easier to do.


Yes, if you’re one of the <10 or so people who have ever wanted to work on the very core of Julia, you need to learn this. If you’re one of the tens of thousands of people who want to work on Julia Base or its packages, you don’t have to. To a first approximation, you don’t have to.


Honestly, I don’t really think we are going to get all that many people who spend the vast majority of their time in pure Python coming over to Julia any time soon. Most of the Python people I’ve interacted with simply don’t consider tasks that Python isn’t “good enough” for worth doing. As I’ve stated here before, my emotional reaction to that is of course extreme frustration, but I am forced to admit that this isn’t totally unreasonable in a huge class of “real world” situations. While that doesn’t quite explain the loyalty to Python (which is still a bit of a mystery to me), I think that realistically there is 0 chance that you will get most of those people to switch to a compiled language with multiple dispatch.

My point is that we should really focus on people who use Cython, PyPy and Numba, not so much on the average Python user. There is some chance that we will win some of them over in the long run if there is an exodus from Cython, Numba, MATLAB and R, but that’s probably still at least 10 years off.

(I think much of this is echoing @Tamas_Papp’s earlier comments in somewhat different language.)


I agree. You can contribute a lot to the general julia environment with a julia-only background.

However, if i open and go over the repositories and list contributors i see a way shorter list than ‘tens of thousands of people’.

Let’s say there is momentum to solve problems with julia and contribute packages (btw: even the METADATA repo only has ~600 contributors), language development (and standard lib) are somehow a way smaller group and major part is julia computing.

There’s at least 2000 who have contributed to a package online

From the ratio of package developers / script writers that I know, I am extrapolating that there’s a lot more Julia coders out there. But sure, if it’s just authors of recognized packages on Github vs people who work on the Core module, it’s still thousands vs the few that work on core… same difference.

JIT compiler. I know, python team is struggling with this too, but julia has it out of the box. Killer feature. Multiple dispatch too.

A HUGE amount of libraries, tutorials, stackoverflow answers, etc. Definitely, it is hard to compete with this.


Sorry, i cannot follow. What has the list in juliaobserver (which stopps at 1941, so i have some problems to see this as ‘at least 2000’) do to with contributions to the julia language?

If you’re going to try and be pedantic, at least read the statements carefully :stuck_out_tongue:. I started off by saying

which includes “or its packages” in its count. That’s a short way of saying that contributions to Julia include any commit or help building reusable sets of code that people are posting, and that there are by far more people who are contributing Julia code than have ever hacked on the femtolisp parser or the (quite small but still significant) C core. If you include unregistered packages you get a few thousand package authors. If you include all of the people helping in dev chats and things like this which are great starter pieces but don’t show up in other counts (which is what a lot of people are writing), you’re getting to the tens of thousands easily (DiffEq has about 30-40 contributors total over all of its repos, but there’s a few hundred people who have actually contributed fixes over Gitter/Slack/email just by code inspection and notifying us).

So pick your number: a few thousand vs a few, or tens of thousands vs a few. Either way, the vast majority of people putting patches to libraries and sharing reusable code are doing so in full Julia, which is the point. That doesn’t mean you have to, hell some libraries like Sundials.jl are have a big C(++) component, but to a first approximation people won’t be writing C code even if they are making code for others in Julia, which is a big difference from many other scripting languages.