I came across comment in the recent discussion on increasing Julia’s adoption.
This raises an important point for anyone interested in Julia’s role in astronomy: even when the technical benefits are clear, adoption is often limited by the availability and maturity of domain-specific packages — and by the established culture around Python tools.
So I thought it might be helpful if, as a community, we created a shared and as-comprehensive-as-possible list focused specifically on astronomy/astrophysics tools and software written with and for Julia.
Julia Astro packages and their Python equivalents
Python astronomy packages for which Julia currently lacks a clear counterpart
Julia packages or tools in astronomy that don’t have a direct Python equivalent — areas where Julia truly shines
Such a list could be a useful reference for astronomers evaluating Julia for their workflows, and a practical guide for developers looking to contribute where the ecosystem needs it most.
If you’re working in this space or know relevant packages, please feel free to add them! The more perspectives we gather, the more useful this will be.
Because Julia packages are designed to be highly composable, they tend to be smaller and more focused in scope — and this holds true for the JuliaAstro ecosystem, just as it does across the wider Julia community. With that in mind, I’ll start by breaking down the contents of one of Python’s foundational astronomy packages and mapping its components to the equivalent tools and packages we already have in JuliaAstro. Which i will post in a seperate Comment. More Comparisions will be coming soon, when I have time to make them.
I am happy to discuss any of the “equivalent” packages I have mentioned here especially because one man can not hope to have tried out everything and used it to the fullest. So I hope that more opinions can chime in here. On examples, if these packages are good enough or not good enough yet.
Once we start to have gathered enough equivalencies I would be happy to start a Github Awesome Julia Astro or something similar listing everything in one hopefully well searchable list.
I have looked into this issue in the past year and there is not much lacking in the base Julia packages for astronomy.
Although it is not listed on the JuliaAstro website, Astrometry.jl is in the general registry. It is not complete, but does contain a complete pure Julia version of the SOFA functions as a submodule. There is also a pure Julia FITS.jl package in development, which is also not complete, but should be useable, and will hopefully be release soon.
I think the one base package that is lacking is a Julia version of Astroquery, which would enable downloading archival data from various astronomical databases. There also needs to be more coordination in making most of these package more mature and interoperable.
The next JuliaAstro Zoom meeting is Wednesday, April 30 at 16:00 UTC. It is postponed by one week from its normal fourth Wednesday of every month. This could be a topic of discussion.
Howdy, I think this would be a great addition. I quite like BioJulia’s ecosystem comparison page and wonder if we could try to emulate something like this on our site?
Speaking of which, we have a PR in the works which aims to clean up our page organization a bit more and also include missing packages like Astrometry.jl. Feedback welcome!
A comparison table could indeed be nice for those familiar with Python and looking towards Julia!
Some more suggestions/additions:
I guess adding Unitful.jl itself here would help clarity.
Thanks to Julia flexibility, one may not even need specialized table types – builtin arrays can be fully-functional tables already This concept may be nontrivial to indicate in a concise table, but is nice to remember.
It’s the same situation as with np.array – Julia doesn’t necessarily require a 3rd-party library to provide an analogue to it.
I wonder if you actually use JuMP for modelfitting? I’ve always thought that it’s most suitable for optimization problems one can fully write in an algebraic way, which most astrophysical models aren’t.
For probability distributions, there’s clearly Distributions.jl.
For uncertainties specifically, there’s a whole spectrum with Measurements.jl kinda in the middle of it Two other packages are MonteCarloMeasurements.jl and Uncertain.jl.
To read and process (radio-)interferometric data, there’s VLBIData.jl and its companions.
For delimited files (like csv), there are multiple packages, e.g. CSV.jl and QuackIO.jl.
For fixed-width tables, there’s FixedWidthTables.jl.
I personally found ImageFiltering.jl somewhat more straightforward.
There’s VirtualObservatory.jl that already supports quite a bit of VO protocols functionality, with the ultimate goal to have a full support. And many (though not all) major astronomy databases/data hosts provide VO access, making them directly accessible from within Julia.
In my personal opinion why not? It uses a lot of same techniques as applied in “normal” astronomy. And it is a great use case for outreach of astronomy. I think if we could also capture hobbyist astrophotographers into the Julia ecosystem we will be bound to get an influx in exposure and potentially more contributors.
I think astropy.tables Supports a bit more things especially acting as a Container for Data, Metadata and WCS at once.
Not really hence I described this as overkill. But its the most comprehensive tool and there really is not much good otherwise in the model fitting department in Julia. Except LsqFit.jl, and the super specific Boxleastsquares.jl and LombScargle.jl, which compared to astropy.modeling, or even something like lmfit in python is severely lacking. Granted this is not just an AstroJulia problem.
The rest are some good additions that I will update in the Post here.
@aplavin As we discussed earlier, VirtualObservatory.jl does not provide the functionality to download the data, only to query its availability. For example there is no functionality to download TESS data from the MAST archive. That is the functionality that Astroquery provides.
Would Tables.jl and/or PrettyTables.jl be a better fit here? I assume astroy.tables doesn’t try to be a fully fledged dataframe. I also know that SatelliteToolbox.jl uses PrettyTable output and it looks really nice.
Also, maybe add SatelliteToolbox.jl to the list! The closest Python package I’m familiar with would be sgp4 not astropy, but calculating satellite orbits seems astro-related enough to me.
JAX has the performance, but not the complete set of array features that Julia has. Its sparse arrays are still experimental, while Julia’s arrays, both dense and sparse, just work. Plus you need to rewrite your Python code to use it. For example, there are several spectral fitting applications for X-ray astronomy. The JAX version has the same performance, but it has difficulty accessing and analyzing XRISM data, because of its sparse arrays and JAX only models. The Julia version has none of these problems.
Astrometry.jl seems somewhat similar to skyfield for Python. Is there a Julia equivalent to astrometry.net or the Python package fastrometry for calculating the astrometric properties of an unknown star field?
It definitely provides the functionality to download data, I routinely use it! For now, tabular data is supported almost 100%, while other kinds of data (most notably, images) aren’t really.
And anyway, VirtualObservatory.jl is unambiguously a better fit to list as an astroquery alternative than VOTables.jl in @The_Mastermage’s list – that’s the presumable typo I was pointing out.
Astrometry.jl is meant to be smaller (~few dozen functions) and easier to use (e.g., a single precession function) version of the SOFA astrometric library, which has >500 functions. Hence, the reason for the SOFA submodule is to verify its accuracy. It is also intended to be higher performance when using arrays of objects, coordinates, etc. A Julia package like astrometry.net would use it as a dependency to perform coordinate transformations.
There seems to be some overlap with SkyCoords.jl, stuff like conversion between different equatorial systems. Curious – are these conversions expected to be the same, or more accurate/performant in Astrometry.jl?
This concept may be nontrivial to indicate in a concise table, but is nice to remember.