TIOBE index rank: #23 as of Jan 2021

Ok, I made a log-log plot of the data (starting on January 1, 2018). As long as I didn’t goof anything up, I think it’s safe to say that the growth is not governed by a power law:

Maybe it’s not so clear cut. If you plot a power law with a non-zero y-intercept, the curve looks somewhat similar to the curves above:

x = 1:100
y = @. 3x^2 + 300
plot(x, y; xscale=:log10, yscale=:log10, legend=false)

Although I would say the shape of the curves in the first plot seems a bit different from the shape of the curve in the second plot…

1 Like

I think it’s time for me to write up my Python vs. Julia thoughts collected over the past 4 years or so :laughing:


Anticipation 100


Yes, we could really use some more thoughtful writing on this. There’s a blog (don’t recall where, but Scandinavian, IIRC) that has several posts comparing Julia and Python on certain points, very much at the level of the languages, and very good. They’re not dime-a-dozen medium ML posts.
I started writing something based on “Fluent Python”, which is a very good book. It’s also a good vehicle for showing how Julia is much better as measured by what’s important to the author. I didn’t go through all of it carefully; there may be a place where Python is better, but I didn’t find it.

1 Like

Libraries, tooling, number of experienced developers, “time to first plot”, and number of available tutorials and answers. Even though the typical Python answer is less thoughtful because there are relatively more novice users in the community, as holds for most more popular languages (Janis Lesinskis' Blog - The decline of the average level of experience in the software industry). Still, I’m confident that this will change and that Julia will one day be a better choice for most projects currently done in R and Python.


Probably not here though. Ironically, it might be on the Julia Discourse where you have a better chance of finding a OSS dev with 10 years of Python experience (ready to rant about what they didn’t like). It’s one of the interesting side effects of having a community build almost entirely by expatriates of other OSS communities.

No, qualify the domain or show me proof that there are more devs working on block-banded matrix libraries in Python or SDE solvers, let alone experienced devs. The ship has long sailed to say that generically. You can say that for very specific parts, like ML, but as a blanket statement it is clearly not true.


Okay, you’re right on the libraries. Julia has many amazing libraries for specific domains.

I still think it holds for most tools, simply because Python is used by more users. For example, compare the 11.4k stars and 122 contributors for a Python formatter with 185 stars and 19 contributors for JuliaFormatter.jl. I’m not saying that one of these formatters is better than the other, just that one is used by more people for a longer period of time. Also, Python has multiple solid linters, such as pylint (3.2k stars), where Julia currently has no linter that I’m aware of. I’m not saying that I need a linter right now in Julia. It makes complete sense that languages with more users have more tooling available.

This is a difficult one to discuss. I was thinking about when I would start a software company right now. I would have an easier time to get Python developers with experience than Julia developers with experience. That means that for many companies, Python is a safer/better choice. In other situations, you might be right that there are more experienced Julia developers.

1 Like

Agreed it might be “most”, but “most” still needs a qualification as “most” still depends on a given domain.

That’s not what I was saying. I was saying you’ll have an easier time on this Discourse finding an experienced Python dev than on a random programming forum for Python programmers, just because this forum attracts those who are deep into open source dev and are typically the authors and maintainers of frameworks and libraries, where as indeed Janis Lesinskis’ Blog points out a very interesting effect that’s pretty clear at PyData and the like.


I’m really thinking of the language itself. Because that’s where there’s most ignorance. Everyone can see there are more experienced python users (vastly more python users overall). Almost any really good scientist/dev I can think of, if they don’t have significant experience with Julia, they don’t believe overall productivity could be that different from Python.

And I’m not thinking about scripting applications, rather building medium to large scientific/technical libararies or systems.

Not thinking about existing application libraries either. That’s not about the language. Tooling and tooling libraries yes, I consider that part of the language.

I understand choosing Python for various reasons. But, in general there is very poor understanding of what you are giving up for making that choice.

1 Like

I don’t understand the reasoning here — more users does not necessarily imply more developers (= people who contribute to a package).

In my opinion, it is true that more users does not implies more developers, but usually more users could imply detect more errors, or suggestions (I know that it is the minority of users that do that, but it is a greater number than developers).

1 Like

I think most people here who work on OSS would think that isn’t necessarily helpful nor does it accelerate the project. The type of user doing this matters a ton. If it’s the wrong type of user, it slows down the project so much you have to ignore them or, what happens a lot, you get maintainers burning out and leaving.

1 Like

A specific example I ran into recently about libraries : the best library in Python for HMM seem to be hmmlearn, which only supports Gaussian emission probabilities, while the Julia package (HMMBase.jl) supports arbitrary distributions. So you can use a mixture of 5 distributions if you like, or a custom one (just need to define pdf and logpdf).

HMM’s are hardly new technology, so I was quite surprised that Python doesn’t even have a good library for them. Maybe I’ve missed something, but I think it’s just a case where Julia type system and general performance allows for more generic solutions.


The dearth of feature requests (“suggestions”) is rarely a bottleneck for FOSS projects :wink:


@rikh There’s a linter built into the Julia VS Code Extension. Here’s the repo for that linter:

The linter is not perfect, but I still find it to be pretty helpful.


Calling C/C++/Python/R/Fortran/shell code within Julia is also arbitrarily easy (especially when compared to other languages). But I seem to be using this less and less as Julia packages become more numerous/developed.

Just a side-note: you have to keep in mind that Python users are religious about PEP 8 and formatting in general. We have made ceremonial transitions from autopep8 to yapf to black and whatnot over the past decade :laughing: anyways, that’s not a good measure in my opinion, at least not when Python is involved :wink:

Of course, Python has more users. But when it comes to scientific computing, I think you have extremely skilled people in the Julia community and I personally do not know any comparable discussion forum where I can interact with Python users who are skilled in so many different areas of CS/Maths/Physics.

I really have fun reading through discussions which start with “function f is a bit too slow” and end up with different papers, debates and suggestions on how to improve the overall approach to solve the problem also outside of the context of CS. I think this is quite unique and I am grateful that I can be part of it…