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.
2 Likes
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.
3 Likes
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.
4 Likes
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.)
3 Likes
I agree. You can contribute a lot to the general julia environment with a julia-only background.
However, if i open The Julia Programming Language · GitHub 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
https://juliaobserver.com/users?page=20
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.
2 Likes
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 
. 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.
Really?
Depends on the domain. Python doesn’t have much support in the mathematical domains my PhD work is in which isn’t even that specialized (stochastic differential equations). Sure, if all you’re doing is classic stats/ML it has you covered, but in the larger world it has very poor support. For example, the SoCal Julia meetup routinely has a group of esoteric particle physicists who all use Julia because that’s where the tools are.
It’s similar to Android vs iOS apps early in smartphone history. iOS always had a ton more apps, but that means iOS had 50 email clients to Android’s 2. Number of apps was found to be a very bad measure of how well users are supported. In the end, just having one good package per domain is perfectly fine, and the freedom of Android allowed it to take off by easily (and cheaply) build such packages.
I think a similar thing is going on in Julia where it’s quite simple to build a pretty complicated and specific package for the 100 people in your field, but now Julia has an outpost of dominance around a lot of these more specialized disciplines while still being competitive in standard data science and ML areas. In the end, it might not be as large of an audience (but of course, if you just care about the size of the audience then bill the language for web and not for technical computing) but it is a good core audience to have around.
4 Likes
IMO the number of users is a red herring for open source software. The number of contributors (which includes package developers, people who make PRs, open issues, help out in forums, etc) is key, because it drives the development of the language and the ecosystem. Julia seems to have a high contributor/user ratio. It will be interesting to see how this evolves.
3 Likes
I think you should include numpy users as well, which is a large group that often uses it for algorithm development.
numpy is frustrating to work with (I’m doing it today.) Straight, numerical programming is one of the areas where Julia is flat out superior to Python, and should be attractive for a lot of people. Julia has better performance, (far) better syntax, and is more powerful.
5 Likes
FWIW, I would like to hack on the core, but find it very difficult to get a medium-level overview of the thing. A wiki that lists resources (or even walks me through all the moving parts) would certainly be helpful for that, both for the runtime and for lowering/ inference/ code-gen/ optimization. There are some very good talks on youtube by the core devs, but no central overview of them (or transcripts, which would be even better), and a lot of explanations appear to be hidden in commit messages or old discussions that are difficult to discover for newbies 
2 Likes
This is true. Right now julia supports my field at about same level as python did 8 years ago, when I actually started to use it 
But julia ecosystem grows fast, I admit this.
It’s a niche enough area that I think you have to dive in by asking questions. The same is true for the core of any large enough project though since sooner or later every line of code has lot of historical knowledge embedded in it.
1 Like
I personally think Python syntax is kind of unintuitive, especially when it comes to matrix operation, and I never get the point of 0-based indexing. I used to consider teaching Python instead of R to undergraduate finance major students, but the feedback was not good so I gave up. However, I still think Python is a great glue language and most of heavy duty jobs can be done by C or Fortran, and what Python excels is to provide API to packages written in C or Fortran.
Why there are more python users than R users? Because there are more cs guys than statisticians. Why there are more python users than Julia users? Because there are more cs guys than mathematicians and engineers.
My point is that Julia does not have to aim at an user base larger than Python. If Julia can attract most Fortran and Matlab (or Octave) users, then I will consider it a huge success.
4 Likes
I’m coming over to Julia from Python. I’m not trying to start a flame war but a lot of the points in this thread seem off. I want to like Julia, so I hope I’m wrong on some of these points, but this is what I see as an outsider.
-
It’s easier to contribute to Julia than Python. I don’t know what this means. I can contribute packages to either. I’m not competent to contribute to the core of either. I think is true of the average user of both languages.
-
Julia has more (higher percentage) academic users than Python. I don’t know what this is getting at. If I had to stereotype, I’d say industrial users want to use packages to get things done whereas academics are often satisfied with proof-of-concept implementations. One thing you can say about Scikit-learn is that it’s solid because people it’s constantly used, so people have attended to all the boring little details that aren’t academically interesting. Academic software is often abandoned after the student leaves.
-
As for Julia packages, one thing that worries me is that a lot of them look unsupported/abandoned. I see failed test flags, “Last updated 2 years ago”, and breakage due to language changes. Cynically I’d say the package archive looks like a lot of people got interested in Julia, contributed a package, then moved on. I think active users/contributors is the only way to judge either community.
-
Ease of learning. Python wins, hands down. Unfortunately. The only way to learn Julia is to read the manual and ask questions here. The learning materials I’ve tried are either incomplete (Learn Julia the Hard Way) or obsolete (any published book). Reading a reference manual is a poor way to learn a language.
-
Speed. Python is slow at some things, but for most of them I can find a Python package where the core is written in C so it’s as fast as Julia. I like the fact that pure Julia is fast and I don’t have to deal with C extensions, but pragmatically it doesn’t make a difference.
-
Large system support. Neither is adequate.
-
Generic functions vs OOP. I understand generic functions are where Julia gets its speed, but I haven’t seen advantages beyond that. Debugging is painful. If you screw up an argument to a method in Python, it gives you info about that arg (usually: “was expecting X, got Y”). In Julia it issues the general: “ERROR: MethodError: no method matching Y” and dumps out all method definitions. You have to wade through them to find the one you intended to call and figure out why it didn’t match. Example:
julia> max([1,2,3])
ERROR: MethodError: no method matching max(::Array{Int64,1})
Closest candidates are:
max(::AbstractArray{T1<:Real,N} where N, ::Real) where T1<:Real at deprecated.jl:56
max(::AbstractArray{T1<:Real,N} where N, ::AbstractArray{T2<:Real,N} where N) where {T1<:Real, T2<:Real} at deprecated.jl:56
max(::Any, ::Any) at operators.jl:348
…
This tells me nothing about the real problem.
- Type declarations are theoretically optional in Julia but you have to constantly think about types in order to use the language.
Regards,
-Tom
5 Likes
For that to be true in Python you pretty much have to be a competent C or FORTRAN programmer, at least for a huge subset of Python packages (and everything perfomance critical). In Julia, for the most part you only need to be able to write Julia code, and I think pretty much everyone will agree that it’s easier to write code in Julia than in C.
What you’re seeing is just a smaller community. There is no denying that this is a disadvantage compared to Python at the moment. There is still a large variety of well-maintained packages; I very rarely have to resort to using non-Julia dependancies anymore. Unfortunately you have to know where to look, and discoverability is a real problem right now, in my opinion.
I see anecdotal evidence that this mostly not true, though I’m sure it’s true in some cases. For what it’s worth, I know that both myself and many other people on these forums have many packages that we’ve abandoned for other Julia packages, and we don’t always do a good job of documenting the alternatives that we’ve settled on. Also, this being a smaller community, there are many packages that are widely used that don’t get updated all the time, and may sit for months. That doesn’t mean there’s anything wrong with them.
In practice this is just wrong, and perhaps is missing the point somewhat. I can’t write a Python class and have a reasonable expectation of it being performant. That’s a huge problem for an OO language. In Python you also have to be careful about writing loops, instead swimming through oodles of API docs often to just implement simple things in a performant way. I can speak for everyone of course, but for much of the code I’ve had to write in my life this makes Python an absolute no-go.
We don’t yet have a debugger in Julia, so this is definitely a disadvantage compared to Python. However, your argument about the error just seems like a matter of what you are used to. Most people who’ve been using Julia for a few months would find that error dump to be perfectly sensible. In contrast, I was frequently very frustrated with the interpretability of errors in Python, due mostly to the design of Python trying to pretend that types don’t exist. I’d often get errors where the wrong type would get fed through some functions somewhere, and I get some absolutely bizarre error because it got propagated to some function that tried to do something non-sensible with it. The kinds of Python errors you are referring to mostly sound like errors that had to be manually programmed in by someone who was painstakingly trying to avoid just the sort of situation I’m talking about.
Type declarations are optional in Julia analogously to how classes are optional in Python. To be honest I’ve never been able to understand why Python users seem to have such contempt for type declarations, assertions, or type handling of any kind. They are a useful tool (especially when they are optional in some situations like they are in Julia) not an obstacle to be overcome.
3 Likes