I don't agree with some points, but I share the feeling in terms of "failed promises".
The fact that most well-known Rust crates are becoming huge bloat are becoming a problem to me, which is something that has been critized years again by the community itself.
As an example, I still do not understand why simple HTTP crates require more than 50 to 70 dependencies to execute a simple GET call...
> As an example, I still do not understand why simple HTTP crates require more than 50 to 70 dependencies to execute a simple GET call...
Looking at ureq [0], for example, its direct non-build/non-dev dependencies are (counting duplicates):
- base64
- flate2 (4 transitive dependencies)
- log
- percent-encoding
- rustls (26 transitive dependencies)
- rustls-pki-types (1 transitive dependency)
- ureq-proto (7 transitive dependencies)
- utf-8
- webpki-roots (2 transitive dependencies)
The vast majority of the raw dependency count comes from Rustls and related crates, and I'd imagine reimplementing a TLS stack would be somewhat out of scope for an HTTP crate. I'm not sure there's much room for substantial reductions in dependency count otherwise.
So let me get this straight. You want the benefit of being able to re-use other peoples' codebase by using an HTTP crate you didn't write. But you don't want those people to also use that benefit of depending on other crates.
Insisting that you should depend on code which itself has no dependencies is a bit hypocritical if you ask me. If you want a simple HTTP crate that doesn't have dependencies, you should follow your own philosophy of not using other crates and write it yourself.
I think this is rather hostile. There is moderation from not using dependencies or from using too many dependencies. I don't think GP is advocating for no dependencies, either. Even vendoring and pinning dependencies provides benefits.
I think it's the perfect amount of hostility. People shouldn't complain about things given to them for free built by amateurs in their spare time. Including fewer dependencies adds more time to developer's effort. Including packages into std requires more work from the Rust team (mostly volunteers). If top comment isn't satisfied with the stuff given to them for free, they can make their own software.
Time functions are a prefect example of somewhere there should be expanded support for in the STD. I'm also of the opinion that there should be a generic and reasonable async runtime in STD, since having `async` in the language, but to direct way to use it without a crate or writing your own executor is awkward.
Then there are things like serialization and logging, which I like the idea of having promoted crates which are essentially just better advertised for newcomers. (Maybe included in the distribution already in some way).
But what if we did that 5 years ago? Oops. And even Java's API has problems too. Why not let it be provide by the ecosystem where it can qctually evolve?
It lacks a hybrid duration type. Instead, it splits durations into calendar and time durations and conflates the length of a `day` depending on whether it's in `Period` or `Duration`. And AFAIK, it doesn't support time zone aware duration rounding. And I don't see a way to compute a `Period` from two `ZonedDateTime` values in a way that respects time zone transitions.
To be clear, it's good. But there are mistakes that the Temporal project learned from and fixed.
(Temporal's single `Duration` type does have pros and cons, so I don't mean to frame having two distinct types as a strict negative. But it's very clunky.)
No, I think the idea of blessing a set of crates (with versions!) is better. The stdlib has a high burden of maintenance, and ideally should only be added to if changes are always backwards compatible. A blessed set is more flexible but still provides a high degree of reliability, unlike the present situation.
The fact that most well-known Rust crates are becoming huge bloat are becoming a problem to me, which is something that has been critized years again by the community itself.
As an example, I still do not understand why simple HTTP crates require more than 50 to 70 dependencies to execute a simple GET call...