Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Existential types / TAIT: https://github.com/rust-lang/rust/issues/63063 Why: Having a stable, named type for public return values is important to me for libraries, but it can't be done without boxing right now if my return value is also existential. For example, if I want to return a named Future, but one that makes a call internally to some async fn.
Personally, I'm waiting for rustc_codegen_gcc, for better AVR support, and box_syntax, so I don't blow up the stack with large arrays.
For your 3rd point I think the current solution is to use a Sealed trait as a super trait for your public trait. A simple example of this is in reqwest.
The more general 349: Efficient code reuse is still open and seeing discussion though.
An ecosystem of reusable building blocks like Django apps. (I design my websites with first-class support for people who run with JavaScript disabled for improved security and battery life, so the only web stuff I do in Rust is "microservices with HTML interfaces" like the "miniserve but an image gallery" tool I need to get back to working on.)
2) An optional way to formally verify the absence of panics and the functional correctness of functions, handy and very fast like Wuffs (https://github.com/google/wuffs ) but able to prove more things.
I'd like to be able to write runtime agnostic async libs.
Lots of good ones already covered, but Iād love to see placement by return or some other equivalent to placement-new accepted and implemented.