Over 10,500 Julia registered packages, thereof over 9000 pure-Julia/non-JLL packages. Congratulation Julia community!

There are finally again over 3000 registered Julia packages (there were more in the past, then those not compatible with Julia 1.0 thrown out of the registry).

This is not yet reflected at Juliacomputing.com while it is at Julialang.org, where I proposed the change at its Github. I had done so in the past (then not realizing jll packages were not wanted in the count), and again recently.

I liked the sound of “over 3,000”, more than “over 2,800”.

Actually there are 3307 packages if you include jll packages, but without them there are 3003 packages and counting (a lot more waiting with PRs to the registry to get them registered).

I’m just amazed by the Julia ecosystem, the breath and depth, not just for e.g. quantum computing (smallest particles) to AstroJulia (Celeste.jl, for largest survey of the whole Universe), but also ExoJulia, seemingly to help in finding exoplanes.

The longest names package names are, some of the very specific packages:


Someone asked for the formula for the number of packages, and it’s:

3321 (lines) - 13 - 304 (count of JLLs, by searching for _jll", in the file, with the comma) =


Thanks for the PR and it’s truly an exciting time to be in the Julia Community!


This is a nice development, but also a signal that we should be thinking about ways of navigating the package ecosystem.

Many registered packages are unmaintained, some are community maintained with varying levels of commitment, while some are experimental. This is fine and natural for a language embedded in the open source ecosystem, but newcomers to the language may find this overwhelming with the current tooling.


One possible way forward would be to encourage people to add a repo status tl;dr a badge indicating whether the repo is wip/active/… you can get an idea for this by looking at the recent commits on GitHub but it can be difficult to directly distinguish between

  • stable, not many recent commits, but things are working and there will be support (e.g. PyPlot.jl)
  • main maintainer(s) have moved on, support is partial at best, probably doesn’t anymore (e.g. Mocha.jl)

PS: a way to get adoption would be to encourage people to use a general quality checker like Aqua.jl in which you could add checks for this kind of stuff


Good idea, but at least in case of Mocha.jl, it’s actually not in the Registry any more (packages not compatible with 1.0 were dropped), and in addition it states:

Update Dec. 2018 : Mocha.jl is now deprecated.” (but such is missing in an outdated fork of that project, however it’s easy to see it’s an outdated fork).

1 Like

Yeah I wanted to take a super obvious package so that it didn’t seem like I was pointing the finger…

1 Like

So what is package 3000?

1 Like

It seems to GitHub - sisl/AutomotiveVisualization.jl: Visualize automotive simulation from AutomotiveSimulator.jl

It’s actually package number 3301 in the Registry, but disregarding the JLL packages, it seems to be number 3000!

Not disregarding JLLs I found by scrolling through a lot of history, on Jan 30, New package: PeaceVote (2999th), New package: mlpack_jll (3000th) and New package: NiLang (3001st). I think these are from the last time, we got to 3000, not from before the purge (not sure when it happened), and I’m not sure I scrolled by it.

There are a lot of interesting packages, not just those above, also e.g. (I had to check what it was):

mlpack_jll is a wrapper for (yet one more) “fast and flexible C++ machine learning library”

NiLang.jl is A differential eDSL that can run faster than light and go back to the past.

The strangeness of reversible computing is mainly due to our lack of experience with it.—Henry Baker, 1992


Now over 3500 package if you count JLL packages with, strictly 3497 registered (and about 10 packages waiting to be registered).

Juliacomputing.com still only has “Over 2,800 registered packages” on their homepage, not wrong, but I suggest updating. There are now 3133 packages excluding JLL packages. I’m not actually sure if it’s best to exclude them.


There are now over 4100 (4117 to be exact) registered packages. JuliaComputing.com still shows only “Over 3,500 registered packages”, while Julialang.org shows “over 4,000”. At JuliaCon “4000 packages” was announced, and I had been eyeing the General index regularly waiting for it and they beat me to announcing (as was busy watching JuliaCon when package 4000 dropped).

The 4100th package is Mesa_jll.

The one before, is ConstrainedRootSolvers, then Mesa_jll, Ising2D, then ARFIMA (it includes “any of its subclasses, like e.g. ARMA, AR, ARIMA, etc.”).

The 4000th package was PDSampler.jl, EDIT: sorry assumed file in chronological order (it’s in UUID order, and I remember taking it into account when announcing previously), now (again) rather looking at the commit log, counting backwards, to 4100, just don’t have the patience to scroll back 117 packages).

1 Like

We’re now up to 4314 packages. I want to skip for now introducing package 4300, as it’s an exception, was part of Julia Base.* It’s still very intriguing historically.

The next package, or that whole ecosystem is very interesting “quantum circuit simulation (the “Quant” part) on exa-scale HPC machines (the “Ex” part)”.

Package 4301 is GitHub - ICHEC/QuantExQASM.jl

Circuit composition and OpenQASM translation package for QuantEx project. Creates a backend-agnostic algorithm and circuit composition framework, which can subsequently be used to generate OpenQASM, or tie directly to other quantum assembly languages.

I wasn’t sure I would ever see quantum, and natural language processing (NLP) in the same sentence or package, but here you go, there’s a toolkit for that, with one of their packages: GitHub - ICHEC/QNLP: ICHEC Quantum natural language processing (QNLP) toolkit

See e.g at Wikipedia, and the example program there:

The program adds two four-bit numbers.
// quantum ripple-carry adder from Cuccaro et al, quant-ph/0410184

* Package 4300 is actually GitHub - JuliaAttic/Grisu.jl: The old Base.Grisu module made into a package, the Grisu algorithm is, I’m sure, very intriguing, but it was replaced by Ryu algorithm (in Julia 1.4, and rest of former code removed in Julia 1.6), both were implemented by our great @quinnj known for e.g. CSV.jl.


Net code reduction is nice from 6K C++ to about 1K Julia. Initial performance benchmarks show it’s just under 2x the native C++.

1 Like

would you be able to get the number of packages with at least one commit in the last 6 months and more than -say- 10 stars? that might give a rough idea of how many active packages are out there.


Depending on the goal of a package it might not need updating within 6 months (granted it would have to be a very focused and simple package).


I second this, e.g:

1 Like

There’s a Github API, and GitHub - JuliaWeb/GitHub.jl: A Julia package for interfacing with GitHub seems would be helpful (but some packages are elsewhere, e.g. on Gitlab, while it’s known most are on Github). Someone could look into this (I will not).

There’s now one more package, intriguing one:

it was JLL package number 524. I.e. on-JLL packages are (only) up to 3791.

BLIS is some replacement for [Open]BLAS I believe. It would be nice to know more about how to switch between; and I also want a Julia distribution without either by default (without me compiling from source).

Active is different from useful though. I’d still say Calculus isn’t a great package but there’s no reason not to use it: it’s mature and it shouldn’t need any updates other than when Julia 2.0 comes out. Getting a count of usable packages would be interesting to me IMO, but that seems hard to define.


Packages updated in the last 6 months or year would give some kind of a lower bound though.

“Activity” is a very weak proxy anyway for “being maintained” (eg the maintainer could approve CompatHelper PRs, while leaving critical issues unaddressed).

All such data is imperfect, but that’s OK. The exact number is not really meaningful but trends could be interesting.


We are up to 5000+ packages, and package 5000 is https://github.com/pbayer/Proquint.jl

At www.modulecounts.com/ Julia count is broken, seemingly because of this line:


Any idea where to get a similar file in json format or change the code to accept this toml format: https://github.com/JuliaRegistries/General/blob/master/Registry.toml (see also https://github.com/edebill/modulecounts/blob/83f4d1f3e148b611780df3c1a4193455d1e09533/db/migrate/20170402164232_add_julia.rb#L7 )

1 Like

4 years ago pkg.julialang.org was very different…


We’re now up to just over 6000 packages, which is a nice round number to achieve before upcoming JuliaCon. And that was a large enough number to break my browser in a sense… :slight_smile:

Number 6000 is:

@MKAbdElrahman, I’m not sure, is this somehow related to Microsoft’s rather recent package with similar name and description?

There are now 6016-13 = 6003 packages (based on “6016 lines (6014 sloc)”) calculated from Registry.toml file. Note, you can’t just look at the last line to see the latest package, since the file is not ordered, chronologically, and thus neither count backwards to see which is number 6000. So I go into the git history to find out:

and strangely even while seeing the appropriate " 6013 lines (6011 sloc)" I still only saw line 5680 as the last line of the file if I scroll down. It seems I just discovered a bug in Github (for more probably Firefox?), since if I refresh a few times I do get the full 6013 lines, so sometimes the file seems truncated (while footer always ok). Might be good to know, and probably only happens for large files. Can anyone replicate this in Firefox or other browser?

This is rather strange and can also happen (though less frequently?) is I’m just viewing the file (not a specific commit). Note, also Firefox crashed just after, as it does frequently with memory running out, but this keeps happening after restating it. If I do “View Page Source” I seemingly always get the full file, though, but it’s also unclear if by doing so retrieves the file again.