[Serow225]

There is one tangential thing that I’ve thought about before—it would be nice if there was some way to encode this into the library ecosystem (ie crates.io) I have no idea how this would be realistically possible though—it’s pretty clear that you can rely on categories that are statically verifiable like “no-std/no-alloc”. But what mechanism could be used to allow library consumers to distinguish between things like “laser focus on high perf/low-alloc” vs “prioritizes API over perf-at-all-costs” vs “this package is an experiment/Baby’s First Crate/shitpost” ?? They’re all valid choices for different consumers or usecases.

[steveklabnik]

Yeah, there is something in this space for sure. I think one of the issues is time; code can start off as a fun experiment, but transform into one that's not, which maybe just means that it is metadata associated with a specific release, yadda yadda, but there's a lot here to think about. For sure.

I recently have been accepting some PRs to some Ruby code that I wrote ten years ago that ended up being still in-use today. "Shitpost" or "baby's first crate" isn't accurate, but "hey I was very serious about this before but now it's not as high priority for me but that doesn't mean I abandoned it" is a tough thing to encode.

[evntdrvn]

Absolutely true re evolution. That's why it would have to probably be crate keywords rather than categories, I'm thinking.

This whole space about encoding library non-technical aspects like intent and status seems like it has a lot of possibilities. I wonder if there's prior art in other language ecosystems?

[steveklabnik]

Perl has the Acme namespace for expressly silly projects, that’s the first thing that comes to mind…

[lcall]

Maybe defining the interesting axes (for each, one for whether it is considered a goal, the other for whether it has in fact prioritized that goal in practice; not saying whether it succeeded in others' eyes), and for each axis give a number 0-10 (or whatever) rating it, in the author's view. Then maybe users of the library can give similar ratings as they compare it with others.

Or not.

[lcall]

I replied just below, to another comment, with an idea. Not fleshed out well, but oh well.

[tialaramex]

I think documentation is the right layer to express what is or is not a goal for the crate. Whether you met the goal is not something you as author can judge reliably.

https://crates.io/crates/misfortunate - is not intended to be used seriously. A redditor pointed out that arguably my Double (a smart pointer where the mutable and immutable references point to separate things and you can swap their places) might actually be useful! But I don't want you to depend on misfortunate::Double in your real software project - if that is useful (and maybe, with careful documentation, it is) you should give it a name suiting its purpose and include it in a crate of stuff that's intended to be used, not as something like a practical joke or thought experiment.