A recent thread (Rust should have a big standard library and here's why) made me realize that I need to brain dump a little about something that has been on my mind for a while.
There's a lot I love about rust, but there obviously are some annoyances as well. One of the more prominent annoyances for me, when using Rust in certain situations, is that while there are plenty of crates to solve common problems, there's no easy way to determine if there are any important differences between them. Some crate developers write "few or no dependencies", "small", etc, in their crates.io blurb but there's no way to easily isolate those crates.
Here are some concrete things that I have encountered:
- I found a minimal web server that seemed to fit what I wanted to do perfectly, until I happened to stumble upon the phrase "SSL/TLS not supported yet".
- I started developing a minimal proof-of-concept web framework using Rocket to see if we could replace an existing Python-based solution, but quickly noticed that even a release build of a tiny example yielded an executable that exceeded 4MB. (Unfortunately this is for a resource constrained embedded system, so this may cause us some problems down the road).
What I would like to see is some sort of curated collections of crates, Let's call them "freighters" for now, just to have a name. Each freighter have some sort of a manifesto, a mission statement with one or more stated goals. And they maintain a list of crates that have been determined to fulfill the values/requirements stated in the manifest.
Here's some examples of what a freighter could require or focus on (including some more general ones, and some more esoteric ones):
- Maximizing features (no constraint on compliation times or binary size).
- Maximize configurable dependencies via cargo's features
- Minimizing dependency trees
- System level programming crates
- Targeting resource constrained (embedded) platforms
- minimize "unsafe"
- Targeting particular platforms (i.e. collection of platform specific crates)
- Require specific patterns, like "builder".
- async
- Strive to avoid duplication (i.e. only one hashing library)
- Performance
- License types
- Stable only
- Crates that target a specific database backend (like "can use sqlite for storage backend")
- "Works on Windows"
Hopefully this would also cause crate developers to start thinking in terms they perhaps wouldn't otherwise. A crate developer may, for various reasons, want to have their crate be part of specific freighter, but in order for that to happen they may need to make some changes, such as allowing non-critical features to be switched on or off using the features framework.
Another thing that a freighter could do is try to keep track of dependency trees and versions, and strive to make sure we don't get duplicate libraries (with different versions) built.
With something like this one could, whenever a new project is started, simply find an appropriate "freighter" and use their curated crate list as a good starting point.
In my totally unrealistic fantasy world, communities would spawn around these "freighters" to help build and maintain them, much like communities around package managers.
In short, I don't want a Big Standard Library, I want a collection of Semi-Standard Libraries to choose from, depending on my needs for a specific project.
Thanks for listening to my TED talk.