Live data from Hacker News

An incoherent Rust

boxyuwu.blog

111–120 of 175 posts

Re: An incoherent Rust

#111
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.

Re: An incoherent Rust

#112

I used Rust for ~14 months and released one profitable SaaS product built entirely in Rust (actix-web, sqlx, askama). I won't be using Rust moving forward. I do like the language but it's complicated (hard to hold in your head). I feel useless without the LSP and I don't like how taxing the compiler and LSP are on my system. It feels really wasteful to burn CPU and spin up fans every time I save a file. I find it har…

I have used C++ for 20 years without LSP, but now I wouldn't want to go back to a plain editor.

Re: An incoherent Rust

#113

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…

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

Re: An incoherent Rust

#114

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…

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.

Re: An incoherent Rust

#115
post #80

As a non Rust man, how real are the problems in this article? Does it show up in real word or is it just a edge case? I only program in C17, C++ as C with classes and C#. Anyone can give me a good read what Traits even are?

Another imprecise analogy would be to see traits as operators.

You decide to define the operator "serde::serialize" for "MyType" but then your are stuck because you can't override or select different operators for "MyType" because only one can exists.

That's a regular yet not super common issue with traits (and this is not exclusive to Rust). It's quite irritating because you wouldn't expect this from languages with this degree of modularity.

Re: An incoherent Rust

#116
Re: specialization and the comptime/reflection initiative

Since they allow observing whether a trait is implemented or not in the current crate they would probably become unsound if impls can be declared in downstream crates. They are a partial solution but also make other solutions harder to implement soundly (and viceversa)

Re: An incoherent Rust

#118
post #5

I will never stop hating on the orphan rule, a perfect summary of what’s behind a lot of rust decisions. Purism and perfectionism at the cost of making a useful language, no better way to torpedo your ecosystem and make adding dependencies really annoying for no reason. Like not even a —dangerously-disable-the-orphan-rule, just no concessions here.

[flagged]

> the compiler has no sane answer once both impls are in the graph

but the user could provide an answer.

Julia allows something called "piracy" which is spiritually similar to the orphan rule. and while it is strongly discouraged, the compiler allows it. and when "ambiguities" arise (here called "coherence") it becomes a social problem, not technical, to resolve. and usually package authors are pretty willing to cooperate to resolve it!

Re: An incoherent Rust

#119

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…

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

Re: An incoherent Rust

#120
I've been worried about this before and the problem is real. I don 't know who maintains serde but if that gets hacked its gonna be an epic supply chain attack
Post reply on HN