[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?

[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.