This is just me thinking aloud. Most crates are currently carefully manually designed by the author, with carefully designed ownership and borrowing correspondence for values, types, and function boundaries, which is awesome.
I'm with you so far.
However I'm thinking about something in larger scale. In data processing applications and many other applications, we are often processing data following some kind of external specification, written in schema or some other form. These specifications are sometimes very large. Examples are MS OOXML specifications and many others.
For that you'd probably use a "type that is less typed". For example, an general XML tree type instead of having a specific type for a specific XML DTD.
However, to achieve ergonomics the more specialized API needs to be created. It's no fun for downstream crates to deal with the general types.
woahhh that's a bit of a leap maybe
Imagine i'm writing a docx format report generator, with a xml dom library and xml writer library, theorically it's enough.
There's a lot of schema information that should be mapped to API surface.
And focusing on your exact needs lets you cut a lot of corners. For example you don't need to support 100% of XML to parse a lot of XML description files, you can usually get away with like a 200 line module that as a super simple API.
Yes, that's right. However it seems to me it's just delaying the problem, "i'll add what i need now and leave the rest to the future".
having every feature ever in every crate ever is just a way to summon code bloat.
There's a lot of reasons people don't like
rand, and one of them is "I can't even tell how to make the dumb thing go"
I think you're right, but there're different scenarios. I think in many businesses you can't tell the customer "i'll add the missing features when you need it", things like that.
Well, sure, in most businesses you can say "I'll add the missing feature never.", but maybe more nicely somehow, like "We value your feedback and will work to improve on our core mission".
Oh, i mean sometimes the delivery is one-shot. The source code and maintenance will be transferred to another party when it's "code complete".
Maybe that's not a recipe for awesome software, but it's reality sometimes.
Sure, there's a lot of scenarios. If you're trying to attract users then having more features is good. If you're trying to finish on time then focus is good. And many places in between.
So in short, i think i'm seeking ways for "mass production" of rust code, that will enable its use in more business scenarios.
Designs and tools to deal with the "uninteresting but large part" of the system.