(spectacular) failure of abstraction, compile times, and toolboxes


Continuing the discussion from Rust beginner notes & questions:

Subtopic on std-lib thick vs thin
Rust beginner notes & questions

Expand the first linked post to see what the discussion is about. Expand the linked posts thereafter to see some replies, and then consider joining the fray. The standard library discussion is continued at this location. For the rest, consider creating and linking new posts if required.


Re: zero: My stance is that even though 0 might be fundamental mathematically, the concept of “zero as an element of many types” isn’t so fundamental in computer science.

Re: compile times: I don’t think the reason for this at all is that we depend too much on macro-generated impls.

Re: simpler vs. complicated languages

Rust is plenty complicated to me. The manuals are thick, and not even everything is documented! I agree that some abstractions are missing in Rust that are present in other languages, but macros seem good enough for now to fill in the remaining gaps.


Toolbox vs. thin stdlib discussion should be here instead:


Edited post heading to remove “vs thin lib.” Lack of toolboxes, i.e missing crates, should remain here or branched off to new linked post.


Isn’t “toolbox” a metaphor for “standard library” here?


:astonished: that’s probably a bad thing?




It absolutely is! But it’s also a reason to not accelerate the pace of language complexification.


Is there a way to collect all the known instances of missing docs?


I don’t think there is.

One example is the trait resolution system. The current implementation has some limitations which are (I believe) not documented in the Book, but the community is also working on a replacement for that part of the compiler. I’m not sure it’s even worth documenting the limitations of the current/old implementation.

Perhaps I misrepresented the state of the documentation somewhat. The vast majority of the language is well-documented. And documenting all the corner cases can mean that the documentation becomes a specification, and people start to rely too much on the behaviour of old versions of rustc.


I see. Hence the use of editions to help align the documentation with the code. Intera-edition the work-in-progress might not get as well documented, only the final result when the next Rust edition comes around?


I think the question is more: do you want to document known bugs and incompletenesses in the code? If the expected resolution time is 1 hour? 1 week? 2 years?

I’m happy enough having this kind of information only available in the GitHub issue tracker.