Discussion

An Incoherent Rust

dathinab: This isn't a new discussion it was there around the early rust days too.And IMHO coherence and orphan rules have majorly contributed to the quality of the eco system.But I think

grougnax: If you think Rust has problems, it is that you've have not understood well Rust.

nmilo: 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.

ekidd: There's a well-known (and frequently encouraged) workaround for the orphan rule: Create a wrapper type.Let's say you have one library with: pub struct TypeWithSomeSerialization { /* public fields here */ } And you want to define a custom serialization. In this case, you can write: pub struct TypeWithDifferentSerialization(TypeWithSomeSerialization) Then you just implement Serialize and Deserialize for TypeWithDifferentSerialization.This cover most occasional cases where you need to work around the orphan rule. And semantically, it's pretty reasonable: If a type behaves differently, then it really isn't the same type.The alternative is to have a situation where you have library A define a data type, library B define an interface, and library C implement the interface from B for the type from A. Very few languages actually allow this, because you run into the problem where library D tries to do the same thing library C did, but does it differently. There are workarounds, but they add complexity and confusion, which may not be worth it.

MeetingsBrowser: can you elaborate on how have they contributed to the quality of the ecosystem?

Animats: Note the use case - someone wants to have the ability to replace a base-level crate such as serde.When something near the bottom needs work, should there be a process for fixing it, which is a people problem? Or should there be a mechanism for bypassing it, which is a technical solution to a people problem? This is one of the curses of open source. The first approach means that there will be confrontations which must be resolved. The second means a proliferation of very similar packages.This is part of the life cycle of an open source language. Early on, you don't have enough packages to get anything done, and are grateful that someone took the time to code something. Then it becomes clear that the early packages lacked something, and additional packages appear. Over time, you're drowning in cruft. In a previous posting, I mentioned ten years of getting a single standard ISO 8601 date parser adopted, instead of six packages with different bugs. Someone else went through the same exercise with Javascript.Go tends to take the first approach, while Python takes the second. One of Go's strengths is that most of the core packages are maintained and used internally by Google. So you know they've been well-exercised.Between Github and AI, it's all too easy to create minor variants of packages. Plus we now have package supply chain attacks. Curation has thus become more important. At this point in history, it's probably good to push towards the first approach.

tekacs: This is interesting but I wonder if you would accept that this also has the downside of moving at the speed of humans.In a situation where you're building, I find the orphan rule frustrating because you can be stuck in a situation where you are unable to help yourself without forking half of the crates in the ecosystem.Looking for improvements upstream, even with the absolute best solutions for option 1, has the fundamental downside that you can't unstick yourself.

dathinab: there is no good way to handle colliding implementation, both from parallel crates and over timewithout it you can have many many additional forms of breakage, worse you can have "new" breakage between two 3rd party crates without either of them changing due to some impl in a common ancestor changing (e.g. std) and this affecting two wild card implementations in each now leading to an overlap.When you have an overlap there are two options:- fail compilations, but as mentioned this now can happen when std does in non breaking change on two distinct dependencies you have, so not really a good option- try to choose one of them, but that now gets very messy in a) which impl. to choose when and b) the user knowing which is chosen and c) overlap with interactions with stuff like double dispatch, thread local variables, and in general side effects. Issue here are similar to specialization and why that is stuck in limbo, but a magnitude more complex as specialization is only (meant)for optimization while this can be deeply different behavior. Like `foo.bar()` with the same `use Bar as _;` might in one context return an `u32AFIK overlapping impl have been considered/discussed but deemed a very bad idea.