There's a well-known (and frequently encouraged) workaround for the orphan rule: Create a wrapper type.<p>Let's say you have one library with:<p><pre><code> pub struct TypeWithSomeSerialization { /* public fields here */ }
</code></pre>
And you want to define a custom serialization. In this case, you can write:<p><pre><code> pub struct TypeWithDifferentSerialization(TypeWithSomeSerialization)
</code></pre>
Then you just implement Serialize and Deserialize for TypeWithDifferentSerialization.<p>This cover most occasional cases where you need to work around the orphan rule. And semantically, it's pretty reasonable: If a type <i>behaves</i> differently, then it really isn't the same type.<p>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.
I don't think explicit naming of impls is wise. They will regularly be TraitImpl or similar and add no real value. If you want to distinguish traits, perhaps force them to be within separate modules and use mod_a::mod_b::<Trait for Type> syntax.<p>> An interesting outcome of removing coherence and having trait bound parameters is that there becomes a meaningful difference between having a trait bound on an impl or on a struct:<p>This seems unfortunate to me.
Note the use case - someone wants to have the ability to replace a base-level crate such as serde.<p>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.<p>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.<p>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.<p>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.
This is interesting but I wonder if you would accept that this also has the downside of moving at the speed of humans.<p>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.<p>Looking for improvements upstream, even with the absolute best solutions for option 1, has the fundamental downside that you can't unstick yourself.
This is also where I find it surprising that this article doesn't mention Scala at all. There are MANY UX/DX challenges with the implicit and witness system in Scala, so I would never guess suggest it directly, but never have I felt more enabled to solve my own problems in a language (and yes the absolute most complex, Haskell-in-Scala libraries can absolutely an impediment to this).<p>With AI this pace difference is even more noticeable.<p>I do think that the way that Scala approaches this by using imports historically was quite interesting. Using a use statement to bring a trait definition into scope isn't discussed in any of these proposals I think?
This isn't a new discussion it was there around the early rust days too.<p>And IMHO coherence and orphan rules have majorly contributed to the quality of the eco system.
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.
Go: error handling stinks. Generics would be dope.<p>Rust: if you spent 3 weeks understanding the syntax and borrow-checker, here are all of the other problems, and the list keeps growing.<p>Man this cracks me up.
If you think Rust has problems, it is that you've have not understood well Rust.