This actually goes to the root of why this project exists.
There is a pretty deep tension in the way that Rust deals with stability. That is, the project itself takes stability very seriously, and as such, has to minimize, to some degree, what things we accept as official, because we need to be able to maintain them. So what tends to happen is, stuff happens in the ecosystem, and then, if it makes sense, moves slowly into the project itself. Furthermore, because being blessed by the project commands some weight, if we refer to something, it'll get used. But if we want the ecosystem to explore the design space and develop solutions, endorsing something in the midst of that process could cut it short.
This also means that the documentation, generally, doesn't refer to any external projects. We need stuff to be solid and foundational, but some random package can change at whatever pace they'd like. We also don't want to interfere with the community development process by picking winners.
But you, as a Rust developer, programming something, need to know how to get stuff done. And that very often will mean interacting with the ecosystem. That's a good thing! But that comes in tension with the docs provided by the project. Because you won't learn about serde from reading the book.
---------------
There is a second issue here, which is the kind of documentation provided by the project. We have good beginner documentation. We have good expert documentation. But how do you get from point A to point B? It's a bit less clear. Additionally, our beginner documentation tends to be focused on doing, and our expert documentation tends to be focused on more abstract theory or implementation details.
Where we are weakest is "okay I read the book... now what?"
---------------
One method of resolving these tensions is the Cookbook. The idea was to provide a resource based around helping intermediate Rust developers solve specific tasks. The usual guidelines around referring to packages is relaxed a bit. It wouldn't be pointing to the absolute latest fancy stuff, but it would be allowed to refer to packages that have mostly settled out. If you're doing serialization, you may not use serde, but you probably are, and nobody is going to be surprised if you do. So on some level, we want to provide a resource to folks that are saying "Hey I need to deserialize this JSON, what should I do?" and be able to say "Use serde."
This may mean that the cookbook would need changing if the ecosystem shifts significantly. There's an art to doing this enough to be useful, but not enough to cause constant churn.
----------------
Unfortunately, a lot of folks put a lot of effort into the cookbook, but then moved on to other things. It's needed some revitalization for a while, and never quite made it over the hump from "in-progress work" to "thing we're willing to publish and promote." It got close! It's still really good in many places! It's also out of date in places.
----------------
Anyway, that's a really long way of saying "because real world programs don't tend to use Result<T, Box<dyn Error>> except at the exploratory phase."
There is a pretty deep tension in the way that Rust deals with stability. That is, the project itself takes stability very seriously, and as such, has to minimize, to some degree, what things we accept as official, because we need to be able to maintain them. So what tends to happen is, stuff happens in the ecosystem, and then, if it makes sense, moves slowly into the project itself. Furthermore, because being blessed by the project commands some weight, if we refer to something, it'll get used. But if we want the ecosystem to explore the design space and develop solutions, endorsing something in the midst of that process could cut it short.
This also means that the documentation, generally, doesn't refer to any external projects. We need stuff to be solid and foundational, but some random package can change at whatever pace they'd like. We also don't want to interfere with the community development process by picking winners.
But you, as a Rust developer, programming something, need to know how to get stuff done. And that very often will mean interacting with the ecosystem. That's a good thing! But that comes in tension with the docs provided by the project. Because you won't learn about serde from reading the book.
---------------
There is a second issue here, which is the kind of documentation provided by the project. We have good beginner documentation. We have good expert documentation. But how do you get from point A to point B? It's a bit less clear. Additionally, our beginner documentation tends to be focused on doing, and our expert documentation tends to be focused on more abstract theory or implementation details.
Where we are weakest is "okay I read the book... now what?"
---------------
One method of resolving these tensions is the Cookbook. The idea was to provide a resource based around helping intermediate Rust developers solve specific tasks. The usual guidelines around referring to packages is relaxed a bit. It wouldn't be pointing to the absolute latest fancy stuff, but it would be allowed to refer to packages that have mostly settled out. If you're doing serialization, you may not use serde, but you probably are, and nobody is going to be surprised if you do. So on some level, we want to provide a resource to folks that are saying "Hey I need to deserialize this JSON, what should I do?" and be able to say "Use serde."
This may mean that the cookbook would need changing if the ecosystem shifts significantly. There's an art to doing this enough to be useful, but not enough to cause constant churn.
----------------
Unfortunately, a lot of folks put a lot of effort into the cookbook, but then moved on to other things. It's needed some revitalization for a while, and never quite made it over the hump from "in-progress work" to "thing we're willing to publish and promote." It got close! It's still really good in many places! It's also out of date in places.
----------------
Anyway, that's a really long way of saying "because real world programs don't tend to use Result<T, Box<dyn Error>> except at the exploratory phase."