An incoherent Rust
boxyuwu.blog
An incoherent Rust
1–10 of 175 posts
Re: An incoherent Rust
#2This 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.
Re: An incoherent Rust
#3This 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.
can you elaborate on how have they contributed to the quality of the ecosystem?
Re: An incoherent Rust
#4There'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 */ }
pub struct TypeWithDifferentSerialization(TypeWithSomeSerialization)
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.
Re: An incoherent Rust
#5I 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.
Re: An incoherent Rust
#6If you think Rust has problems, it is that you've have not understood well Rust.
Re: An incoherent Rust
#7If you think Rust has problems, it is that you've have not understood well Rust.
Brilliant
Re: An incoherent Rust
#8I 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:: syntax.
> 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:
This seems unfortunate to me.
Re: An incoherent Rust
#9There'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 TypeWithDiffer…
The gotcha is what happens when TypeWithSomeSerialization is not something you’re using directly but is contained within SomeOtherTypeWithSomeSerialization which you are using directly. Then things get messy.
Re: An incoherent Rust
#10Note 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.