Julia enthusiasts are always pitching the language to colleagues, and despite various technical arguments, we often fail to show how the language can concretely impact scientist’s productivity.
Given this context, I am starting this thread to collect concrete evidence that the language enables state-of-the-art package ecosystems.
Goal
The ultimate goal is to collect comparison tables between Julia package ecosystems and alternatives written in other languages. These tables can be worth 100 pitch talks if potential users have specific software demands.
Instructions
Please add a single table per comment
Paste the table/figure directly for posterity
Add a source link where the (updated) table is available
Aftermath
We plan to add a link to this thread in the Julia manifesto if the number of tables is representative of the Julia experience across various scientific fields:
I will start adding tables I am aware of in the comments below.
I don’t think it’s possible to be unbiased. In fact, it’s a very good reason to implement new software because previous approaches didn’t provide the entirety of what the developers believed were good features. It’s possible for other people to look at the same things as unnecessary or even bad features. I think the way to go is to make lists that are in touch with the field as much as possible but acknowledge it’s ultimately the developers’ opinion on a good toolset. That shouldn’t be too difficult, most READMEs state the intent of the library, so the table can just reflect that. I’d argue that the Julia package’s checklist should always go first so it’s a clearer implication that the list is the developers’ opinion, and it’s easier to see the to-do list of the package when we don’t care about other libraries.
If you are considering replying to the “universal human bias issue” raised by @adienes above, please try to not derail the goal of this thread, which is to collect tables. People can judge biases by themselves.
I hope this won’t become yet another debate on Discourse with endless back and forth of what is right or wrong…
I do see those a bit critical, because usually the author of a table is the one who wants to present their own package best, but that is for the detailed thread probably
We gave that a try in comparing manifold features and available manifolds in our paper on Manifolds.jl, but since external links were said to be unwished for, here are screenshots, but you can also get the TeX code from arxiv
Manifold features
Note that the last version of the preprint is one-element-off; Riemannian Hessians were only available when the Galleys arrived and we did not update the arXiv
I am confused why the OP asked for this. I would say having the source of the tables is a pre-requisite for posting these anywhere. Please do provide the source for the tables for future reference and for robustness.
But yeah, I would take this with a grain of salt because it is outdated. I think Mesa is now in v2. Not sure how much genuinely new stuff this brought in to be honest though.
EDIT: Forgot the second part of the table that showed the performance comparison:
Here’s the symbolic regression feature table for SymbolicRegression.jl (listed under “PySR” which is the more well-known Python frontend). This is from our paper.
Heads up: The paper is from May 2023, so the landscape (and our package!) has evolved. For instance, PySR/SymbolicRegression.jl now can handle high-dimensional inputs and plug into differential equations – features not fully reflected in this older snapshot. In retrospect I might also add a couple other rows which PySR/SymbolicRegression.jl does not yet have, like arbitrary arity operators, or being able to evolve a Turing complete DSL.
Regarding the table itself: you might notice PySR/SymbolicRegression.jl has a in nearly every row. While skepticism is understandable for a scenario like this, here, this broad feature coverage was the main goal of creating the package, so it is expected. Many of the other excellent tools listed are geared more towards exploring specific research ideas rather than being comprehensive software products. i.e., this isn’t a statement on their inherent value, but rather reflects where development efforts were focused.
(And of course, we found Julia’s ecosystem made achieving this breadth of features significantly more manageable than, say, if we had started with C++! So it still can safely be used as a statement about ease of Julia development)
Inspired by this thread, I’ve put together a comparison table for the readme/docs of my newest package Trash.jl. I had some fun picking emojis that seem self-explanatory to me.
in nearly every row. While skepticism is understandable for a scenario like this, here, this broad feature coverage was the main goal of creating the package, so it is expected. Many of the other excellent tools listed are geared more towards exploring specific research ideas rather than being comprehensive software products. i.e., this isn’t a statement on their inherent value, but rather reflects where development efforts were focused.
