This is just a way to get a feel for the community's collective desires. Now that we've hit 1.0, there is no obstacle to people writing long-lasting, useful community libraries.
Re: A-Community-Library tag on Github issues: The nature of writing an issue that is publicly displayed and notifies everyone that there is a new issue means there is a barrier to anyone who merely wants to add a quick "You know what would be cool?" statement. This thread is for library suggestions that have the weight of a comment, not an issue.
One source of libraries which people have asked about in rust is the A-community-library tag on issues in rust-lang/rfcs which denotes a library which at least someone wants to be built for rust. There are probably other sources for this as well (like this thread), but that's one of the current places where library requests are made.
Experience and common abstractions. There's also the perennial problem of "this interface would be so much better with $FEATURE; I'll just wait until that's stabilised."
Would love if someone created an ASN.1 compiler and encoder/decoder. I'd like to move some of my SNMP work over to Rust but the few times I've started digging into ASN.1 it's felt too deep a side project to start right now. I've seen a few starts but they all seem abandoned or very incomplete.
I'm seriously looking for a network library with high performance, multithreading, crossplatform(IOCP and epoll) and I/O async stuff. Something that is similar to boost asio or ACE in C++.
It does not have thread pools by itself, but for the events and asynchronous events, I very much like libev. Making a binding would be interesting. There is this repository, but it is empty :-(.
Also I would like to see a generalized pattern/support-library for language bindings to allow rust to host garbage-collected dynamic languages (e.g. I want to work on some chibi-scheme bindings, and I'm left studying the existing high-level lua and spidermonkey bindings to discover how they're doing various things).
I would really like to see an ergonomic async story: async I/O, interaction with coroutines and/or green threads (+M:N), and channels that can be selected over (both with select! and programmatic registration). I'm currently finding myself spawning way too many threads on resource-constrained systems... The lack of std::sync::mpsc select stability tends to hurt too.
chan has a select macro that works on stable with send/receive operations with a mpmc channel. (Programmatic registration necessarily exists for the macro, but it is an undocumented/inconvenient interface at the moment. Happy to get help iterating on that design.)
[quote="sumproxy, post:19, topic:2234"]
How about a well designed GUI library?
[/quote]What I'm waiting for is the end of object disoriented GUI programming and the move to fully concurrent, CSP or actor styled toolkits.