logoalt Hacker News

WhyNotHugotoday at 11:23 AM3 repliesview on HN

The Rust ecosystem does a lot of what I like to call "inverse dependency injection".

If a Rust library needs support for TLS, typically that library implements a feature for each existing TLS backend, and keeps first-class integration which each one. The obvious thing would be to have a TLS Trait, and have each TLS library implement that trait (i.e.: dependency injection).

Because of to the orphan rule, such a trait would likely have to be declared in a small self-contained library, and each TLS library would implement that trait. I don't see any obvious impediment (aside from the fact that all TLS implementations would have to expose the same API and set of behaviours), but for some reason, the Rust ecosystem has taken the path of "every library has first-class integration with every possible provider".

This makes it really tricky to build libraries which rely on other libraries which rely on a TLS library, because your consumers can't easily select, for example, which TLS implementation to use. Libraries end up having lots of feature flags which just propagate feature flags to their dependencies.


Replies

ozgrakkurttoday at 12:39 PM

Curious if they could just choose one and move on. It is really toxic to do this on every layer.

For example how bad would it be if reqwest only supports rustls and is able to have less traits/generics and compiles faster

TrueDualitytoday at 11:30 AM

The article itself covers the specific reasons that has led to that exact problem and the potential solutions available in the ecosystem with their various trade-offs.

hu3today at 11:29 AM

It's due to the path of least resistance. One solution could be to have common traits versioned in the standard library.