I really like the idea of Julia so much so that i imagine it competing with Python, edging past MATLAB and eclipsing R and Stata. This idea in me was planted by a few of the posts where the authors compared the packages available in repositories of some of these languages. It was when Julia’s websited showed Julia having nearly 8 thousand packages. Today the Juliahub UI packages lists more than 12000 packages. Its a tremendous growth in number of packages in Julia. I am not well versed in Julia but I have been in love with its ideas and ergonomics. This growth of packages make me want to jump the ship and make Julia my primary programming language. So, I will like to know the opinion of community on maturity and evolution of Julia package ecosystem. How does it compare with its niche competitors. Has it reduced the gap? How are other niche competitors affected by her heat? All in all I believe that if Julia edges even one of its competitor it will create a dedicated user group for it. Thats how python grew taking over smaller competitors one by one. Replacing one shell script, one program script a time.
Welcome! This is a very broad question and is hard to answer with a wide brush. As with any language, there are places where Julia (and its ecosystem) excels, and places where other tools may be better. There’s not going to be a single uniform answer. It’ll depend on what you want to do.
One answer I often give is that the amount of benefit you can get from Julia will depend upon how highly optimized and refined your alternatives are — and how well they fit your task at hand. If you (or some mega-corp) has poured millions of hours into some standard analysis/workflow/task in another language, Julia and its ecosystem probably won’t give you an advantage in a head-to-head comparison. But if you need to step outside that standard workflow (and its highly efficient compiled libraries) in any way, then Julia can allow that in very powerful ways. Modeling and simulation tends to be a great example here, because you need to write/define your own models in some way… and if they’re complicated, then the language you use can easily become a bottleneck.
Lastly, we ask that folks not use gendered pronouns when talking about the language here.
My apologies. I was not aware about the gender pronoun rule. I will keep heed to it.
I was looking for something comparative and reflective on Julia’s ecosystem. For example, while reading forum i became aware that it currently leads in simulation and modelling world, now again reinforced by your response. Now, Julia lead in one such field. I am sure it may also be rapidly reducing the gap between some others too. It may also be innovating its own. In forum somewhere i read how autointegration was deliberately excluded in a package as it preferred to not completely copy python ecosystem’s approach and duplicate code.
So, In a nutshell, I want to know how is Julia’s ecosystem is evolving, new innovations, and reduction of gap in some niche fields. In a nutshell, A reflective and comparative analysis of Julia’s ecosytem with some smaller peers.
For example: CRAN currently has around 22 Thousand packages and we are around 12 thousand packages. It appears to me that soon in a few years we may overtake CRAN in package count. Our Julia Package repository will also be more broad than CRAN. It will be a matter of time when we will have more depth in packages than in CRAN. It will completely lead to preference of Julia over CRAN by R folks.
This is exactly how python evolved. It slowly took over small niche fields and than over time increased its depth in those fields too. Now, Its a behemoth.
I like to think of package ecosystem like a lake. Its multiple small or large streams that fill the lake.
Welcome to the Julia forum!
I would maybe not just go for a single measure like “number of packages”.
Languages might have a tendency to a more monolithic package approach, for example in Matlab it is quite common, while others are easier to work with (or are more used to) modularise.
So that single measure might be hard to look at.
On the other hand, if you just consider a single area, maybe something (like ML), and estimate how many work groups use a language (maybe Python), then such a large majority makes the amount of developed packages in that area for that language very high.
On the other hand, if there is a very focused area, it might also be that some enthusiastic small group has done a very nice package – again in any language.
So I am not even sure how to then define “gap” globally for all packages.
I would also say Julia should not always be the language to use.
If you are in a workgroup/company/field of expertise where everything is done in Python, or even Fortran or whatever – being “the first to switch” might be a touch path
I personally worked with 2 packages in 2 languages in parallel for 2-3 years and that was not that comfortable, but it was a very niche area and I wanted to try Julia so I did.
So for your personal level, I would say: If you have some project where you feel it is reasonable to do that in Julia – go for it! It is fun (very biased to hear that in the Julia forum 
).
If you have a workgroup / colleagues and a reasonable code base – maybe evaluate that much more carefully – or go for a hybrid approach.
For the global level “Has it reduced the gap” - “How well is the ecosystem”… I have no clue. Not even how to measure that.
I like the language – the user group – and people here not the forum especially – are great! So on that super-local/tiny/personal/oppinionated level: It’s great!
I’d argue the question is just too broad for a useful statistic or answer. Assuming wrongly that we do have one metric for comparing ecosystems, it doesn’t matter to real people who can only use a fraction of them. One fisherman’s territory in the smaller lake can be much deeper and yield more fish than his territory in a bigger lake. It’s more reasonable to choose ecosystems based on personal needs and preferences instead of some blanket statement, and it’s far more reasonable to not make such a strict choice. Who said we could only use one language?
To be fair, I understand why people keep approaching Julia with the question of whether it can be the next Python in terms of growth and popularity. They’re both interactive and fairly dynamic languages, and Julia is probably the most prominent one with an optimizing compiler attached to it, which is something that several very different projects are trying for Python (an incomplete list, if you’re interested: Numba, PyPy, Codon, Cython, Mojo). But contrary to popular narratives and language comparisons, Julia isn’t an enhanced Python that has yet to reach the same potential, and even if we ignore the ecosystem, there are good reasons to use Python instead of Julia.
One big one is that the CPython interpreter uses many times less RAM than the interactive Julia runtime (CPython did develop much earlier when average consumer PCs had less RAM), which affects what systems we can run the language on, how and where we run code, and whether it’s worth embedding into other languages, especially if you’re working with several isolated and relocatable units with distinct versions. It’s a problem for Julia often enough that an upcoming and highly desired experimental feature is to trim such units to much smaller non-interactive units usually made by ahead-of-time compilers. When this feature matures, it could make a huge impact on how and when Julia can be used, but it still wouldn’t make the full interactive runtime any smaller for people quickly tweaking evaluated code. And this is just one example of how Julia is simply a different language with a different philosophy, not a Python derivative.
For concrete comparisons:
This is a really critical point that took me a little time working with the language and coming to understand the workflow to fully realize. Important understanding to have toward shaping the tools we build for and with Julia.
This exact thing has had me thinking about “Julia is a general-purpose language” and how to approach that.\ in terms of the above and its implications for more general applications and audiences.
@juliohm Thanks, It is very relevant to what i am looking for. It provides a solid base to search for broadness and depth of the Julia ecosystem. More specifically i am looking for
- Fields where Julia leads. Currently Simulation and Modelling. (These users can’t ditch Julia)
- Innovations with Julia ecosystem (Every ecosystem learns from errors of its predecessors and builds its own solutions and ethos.)
- Niche Ecosystems (not python) who we are slowly but steadily making redundant.
@Benny I am not looking for just one metric to compare. A single metric can’t do complete justice. Package count is just one of the metrics. It is just a rough metric which, I believe, becomes more and more dominant as the packages available in a repository increases. So, It becomes a good proxy indicator to ascertain the value of an ecosystem. Currently, I think we do not have enough packages to definetively claim success. 12K packages are just too few when CRAN a niche ecosystem has nearly 22K packages. I will hazard my guess, but i think we need to reach atleast 25K packages to diminish value of these niche competitors. At this count we may have enough depth and breadth where individuals or work groups are willing to ignore some of the rare use cases and adopt Julia. Rare hassels will not be worth to ditch Julia. Julia’s ergonomics will start to give more ROI than these few rare hassels. Slowly but steadily the depth and broadness of ecoystem will increase.