I feel the same, when I look at Python's list of libraries:
https://pypi.org/
It takes a while to get used to a new eco system. That doesn't mean we can't improve of things - but any large project will take some time to get used to.
Since the line between language and library is blurred (non-existant?) in Racket, it might be harder than usual to see what's "standard" and what's "third party". To some degree that's the point: An Racket user has, due to the module and macro system, just as most power to tweek the language as the "language developers" have.
The best advice (repeated from above) is to search your local documentation first and then compare with the online one. I like to use the online documentation - sometimes you find just the package you need.
I remember looking for something about base64 https://docs.racket-lang.org/search/index.html?q=base64 It's difficult to realize which one is the official one. (probably the one from net/base64 ?) Perhaps add a "verified" checkmark next to the main distribution package? Perhaps be able to select to show "only-main-distribution" or "all-available-packages"?
That was exactly my point. Using "has this been modified recently" as a metric for quality is a mistake. Likewise, twiddling your code in order to attract the gaze of people using "has this been modified recently" as a metric is also a mistake.
Why would you say 'production ready' if what you mean is 'in production'? Anyway, that pushes the question back a level: what's your definition of 'in production'? If I've written a Racket module that automates something on my local system, is that 'in production'? Does it count if I've shared it to a bunch of friends and they all use it? Does it only count if it's in use at a company? Does the size of the company matter?
I'm not trying to be difficult here, I'm trying to point out that you're asking the wrong questions. Lisp in general and Racket in particular has very little commercial presence, so if you want code that is in daily use at a major business, you're not going to find it here. If what you want is code that has a thorough test suite, thorough documentation, and general approval from the community then we can help you with that.
To slightly hijack, I can imagine a process for "graduating" into the inner rings. For some of the "pet"/"my-missing-functionality" libraries, I would imagine that process centered around making sure the added functionality interacts well with existing functionality in said inner ring. This would be useful for pushing some of the non-core "add missing functionality" libraries into racket itself, and/or having a list of "does not blend with X Y Z"
We are not trying to prove a mathematical theorem here so we do not need to be formal and too precise. I think software engineers generally agree on what is production ready - it is something that has come out of beta and is considered mature to be used in production by anyone. Sure, you can advertise your pet/hobby project (which is not ready) as production ready and people will try to use it and it will quickly be shown to be otherwise so that is on you. If a project is already being used by another (larger) project - well, it is already in production (and hence production ready). Yes, these are not precise/exact definitions but for me they suffice.
As for the second portion of the reply that there is little commercial presence - I get that - but on the other hand, I see all this work/time being spent on Racket and I cannot help but think that there is hope that the language would become more popular and used of things other than just academic experiments. I see languages like Scala that go from 0 to 100 in a few years and people are talking about them as if they are really something original or new and they get hyped up and adopt a serious following - so much so that the concept of a monad becomes an interview question that separates the wheat from the chaff and I cannot help but wonder - why can't racket be that language?
Finally, you go to the Racket docs website and you cannot really tell what's what - sometimes there are multiple implementations of the same functionality - how does one discern which one to use? They are all up there pretending they are at the same level of development and almost implying that they are "officially sanctioned" (whatever that means)
It seems like your personal definition is fairly balanced, so that's good to see.
I think people are sometimes wary about terms like "production ready" especially when used by people coming from other language ecosystems, since some (e.g. JavaScript) do have a culture of assuming packages must be continually maintained indefinitely and that therefore any package without updates in the last few months is "dead" and not worth considering. In the JS world, APIs change frequently, so there's an almost never-ending amount of work to keep up with your (probably many) dependencies. In that sense, you start to see why some in that ecosystem look to last update time as a mark of "maturity", even though I think most here agree it's not.
The Racket ecosystem fairs better on these fronts. Most projects preserve a stable API for the long term. A large API change is typically done by creating an entirely new project. Most projects only use a few dependencies. The 2013 talk about the package system from @jeapostrophe is helpful context towards understanding the ecosystem's approach to stability. With all of this taken together, it's far easier for Racket projects to truly reach completion and live on successfully without needing further updates.
Assuming this is true - then the maturity/what to choose as a library is a presentation/organization problem, true? Which is kind of where I started when I asked this question - I am having trouble discerning (from the racket docs website) what is official, what is not, what is ready, what is not...
I have a very simple rule of thumb. If it is in the Racket distribution downloadable from https://download.racket-lang.org/ it is official and ready. This includes many languages, a good IDE, the web server, GUI/graphics framework, network libraries and much much more.
It is important to note that everything in the distribution has had extensive testing and apart from new features mentioned in the release announcement and months or years of real-world use.
If you have to use raco pkg install <package-name> you should check the package to be sure it is something you are happy to install and use.
I’ll give an example. You can check 1d6 - you might be happy to use it for some dice rolling but as it lacks licence metadata you would want to check the LICENCE file before integrating it into your project.
Racket is different to some other languages in that you don’t just install the language, you get a huge set of libraries and tools and at least seven languages (probably more). I’m guessing this is necessary because university IT departments don’t like students (or professors ) installing software on lab computers, so the Racket distribution has to include everything they might need for anything from an introduction to programming class to a higher level course in programming language design & implementation.
All search results are sorted according to their score. E.g., exact matches come before prefix matches. Prefix matches come before partial matches. (this behavior already exists in the current search)
Among search results with the same score, they are sorted according to the package status. Those from base come before those from main-distribution. Those from main-distribution come before everything else.
For equal score and equal package status, the original order from the current search is preserved (which IIUC follows lexicographic order, but I'm not totally sure).
Thanks. The reason I thought of raising it here is that giving precedence to some packages over others might be a contentious subject. But it is definitely the case that we're already doing that with main-distribution and, while I'd like to see us move away from emphasizing main-distribution, this change does seem more helpful than anything!
I'm a bit late to this thread, but, Jay, I thought Ring 0 was conceived (by you?) as broader than just the package "main-distribution" and its transitive dependencies. In that documentation, 11 Future Plans says:
The official catalog server will divide packages into three categories: ring-0, ring-1, and ring-2. The definitions for these categories are:
ring-2 — No restrictions.
ring-1 — Must not conflict any package in ring-1 or ring-0.
ring-0 — Must not conflict any package in ring-1 or ring-0. Must have documentation and tests. The author must be responsive about fixing regressions against changes in Racket, etc.
These categories will be curated by PLT.
Our goal is for all packages to be in ring-1, with ring-2 as a temporary place while the curators work with the authors of conflicting packages to determine how modules should be renamed for unity.
…
In contrast, the ring-0 category will be a special category that authors may apply for. Admission requires a code audit and implies a "stamp of approval" from PLT. In the future, packages in this category will have more benefits, such as automatic regression testing on DrDr, testing during releases, provided binaries, and advertisement during installation.
I like that definition of Ring 0 better than "main-distribution".
I wrote some thoughts about "main-distribution" relatively recently in two Github comments:
A lot of Racketeers believe, and the design of the package system tries to ensure, that main-distribution is not and should not be special: it is just some Racket package, and distro-build can be used to make a Racket distribution with any package or set of packages. This is usually my view, so obviously I find the reasoning persuasive. The main distribution includes a lot of things that are deprecated, and other things for historical or idiosyncratic reasons: because they were there before the package system existed, or, say, libraries for various textbooks, to simplify the first-day-of-class experience for students. It doesn't include some packages I consider gems of the Racket ecosystem, like Gregor or the S-expression syntax for sql.
…
However, from another perspective, main-distributionis special: it's what novice students will download, it's what distribution packages provide, and the examples on the https://racket-lang.org home page need it to run.
Overall, I think the underlying concepts are sound, but the landing page at https://docs.racket-lang.org could certainly use more organization along several dimensions. I'd also be in favor for some sort of process for nominating trusted packages to Ring 0.
Not speaking for the other release managers, but from my point of view, I would think that, if ring-0 (as described above) were something that were working and we were all used to, we should probably distribute the ring-0 pacakges the way we're currently distributing main-distribution (i.e., we keep ring-0 and "what gets distributed" always meaning the same thing, via some mechanism, perhaps via a package called ring-0 instead of one called main-distribution).
If that does seem like a goal we might head towards, we should probably revisit the definition of ring-0 from the view point of the release process steps and see if we need any additional requirements on it to make sure releases run smoothly (specifically, we'll need folks to be responsive at release time for each package to do various checks and participate in various discussions). Or if we feel like something along those lines is good, but ring-0 would have too much stuff, we might also want to do something to be more selective, too.
so we do not need to be formal and too precise. I think software engineers generally agree on what is production ready - it is something that has come out of beta and is considered mature to be used in production by anyone. Sure, you can advertise your pet/hobby project (which is not ready) as production ready and people will try to use it and it will quickly be shown to be otherwise so that is on you. If a project is already being used by another (larger) project - well, it is already in production (and hence production ready). Yes, these are not precise/exact definitions but for me they suffice.
) installing software on lab computers, so the Racket distribution has to include everything they might need for anything from an introduction to programming class to a higher level course in programming language design & implementation.
