I’ve seen this discussion, but it doesn’t seem to bring forth a solution. The problem:
When I (or anyone) wants to select a Julia package for a task, it’s difficult to choose, because:
We don’t know how well it has been tested (doubts on reliability).
You may say we could have a look at the number of stars on the respective GitHub projects, but that’s not how trust is built.
The suggestion:
Could we have a team of core Julia developers (perhaps paid developers) who select Julia libraries and make it part of a “recognized” libraries list? It’s important to provide users with a guarantee that a library would be:
Secure and safe to use (security audits would help).
Have the guarantee that it will be maintained in the long run and bugs would be fixed quickly.
Have the guarantee that it is already tested for being accurate and taking care of various boundary conditions so that it does not fail (this would even apply to plotting libraries that ensure that labels, legends and ticks don’t overlap).
When I introduced my professor (who is now in a top administrative position in a well known college) to Julia two years ago, he said he was very happy, because he was looking for an alternative to Matlab and Octave, but Matlab had verified, trusted libraries as part of its ecosystem. Also, Julia wasn’t as widely adopted in the industry. Hope things will improve soon.
I mean technically we could I guess but it seems exceedingly unlikely that we ever would, unless you are willing to do this and/or fund it. In any case I don’t think it would ever be a good idea to have core Julia developers do this because their time is much too valuable given there is a limited set of people in a position to push forward core improvements to the language which are arguably much more valuable than any sort of curated list of packages (apart from the fact that - without offence to the core devs - there are probably many areas in which Julia is used and packages are being developed which the Julia core devs know little to nothing about).
It also seems to me that this kind of thing doesn’t generally exist outside the world of paid for software, so it strikes me as unlikely that this is a major drawback of Julia versus, say, Python, R, C++, FORTRAN, etc. Even in Matlab (which tbf I haven’t used in about 10 years) I recall it being quite common that people use “untrusted” code from the Matlab file exchange or whatever it was called.
One benefit of open source code is that you can inspect the code and tests of a package. You can also look up the credentials of the package developers to get an idea of their expertise and qualifications. Those are some of the criteria I consider when deciding to use a package. I don’t think you can do that with most proprietary software.
look if a package is maintained, are there any commits in the last 6 to 12 months
what is the quality of the documentation and the examples
is there more than one committer (well, very specialized packages often have only one committer, nothing you can do about it unless you yourself or your company become a committer, too)
how good is the test coverage (well, I know this does not tell the whole truth, but it is an indication)
if there are similar packages you could use ask on discourse about the advantages and disadvantages
run your own tests
Furthermore you can look if the package belongs to an organization like https://sciml.ai/ , and what is the funding and reputation of that organization.
I think in most cases you can find a good packages for a given task using this approach, and if not you have to pay a developer yourself.
That is a very strange criterium to me. I have the impressions that packages, with time, become more and more stable, thus we should expect that a package that has some functionality and does that well should progressively be less messed up. Of course this kind of boring stability is unlikely for huge packages in core parts of the ecosystem and in the forefront of the user interface, but for many more specifically-purposed packages, it is what I would expect.
This is what I think should be mostly suggested. In any package or library, or routine, in any language. Learning the usage of a package (running examples) is part of the testing, thus this is coupled with the quality of the documentation.
Apart from that, other guarantees can only be obtained by paid support. Anyone, in principle, could create a organization to provide support for a selected set of Julia packages, charging for it, of course. It maybe even a good business.
Theoretically yes, but tooling changes once in a while so git repos that have not been touched for years are a red flag in most cases. Eg a while ago a lot of packages migrated from Travis to Github actions for CI.
In addition, compat entry changes and similar should generate occasional activity.
Otherwise, we do have a general registry of packages all of which are effectively backed up. If a package went rogue, we could delist it or redirect it.
We also have organizations such as JuliaIO · GitHub where multiple individuals, some of whom are paid and some whom are volunteers, collectively maintain some packages.