An example of a project that is "done?"
I found the post a bit unclear, but my interpretation was that they're officially ending the 'Rust docs team', and will be reducing their focus on documentation, maintaining it in a more ad-hoc way.
21–30 of 46 posts
An example of a project that is "done?"
I found the post a bit unclear, but my interpretation was that they're officially ending the 'Rust docs team', and will be reducing their focus on documentation, maintaining it in a more ad-hoc way.
&tldr; The docs team created filled in the gaps where they were needed when it was created. Now, the teams making the code changes handle their own docs and doc changes. There is no longer a need for a docs only team. So, instead of having a dedicated team for docs the load has shifted to the teams responsible for the code. Sounds like a reorg more than anything.
Out of curiosity, how many people are working on Rust as permanent employees or otherwise paid by Mozilla? I thought Rust is mainly developed by individual contributors but "load has shifted to the teams responsible for the code" and "reorgs" sure sounds like there's some kind of hierarchical leverage and long-term planning in place.
I left Mozilla over a year ago, this change isn't really super relevant to it other than I was a full time docs person and now there are no full time docs people. One person isn't a team, though, and the team had these issues even when I was employed.
The headline sounds scary, but the actual change sounds like it's merely an organizational reshuffling formality.
Earlier quoted context omitted.
We can hope that the language itself is similarly declared "done" at some point. That would be in contrast to C++ for example, where it's the job of a bunch of people to keep making changes ad nausium until it starts to crumble.
Would a Rust spec that actually allows multiple compatible implementations actually be simpler than the C++ spec? There has only ever been one real Rust implementation, and a lot of Rust behaviors are just arbitrary implementation decisions, especially with subtyping in the type system and the borrow checker.
Earlier quoted context omitted.
We can hope that the language itself is similarly declared "done" at some point. That would be in contrast to C++ for example, where it's the job of a bunch of people to keep making changes ad nausium until it starts to crumble.
Would a Rust spec that actually allows multiple compatible implementations actually be simpler than the C++ spec? There has only ever been one real Rust implementation, and a lot of Rust behaviors are just arbitrary implementation decisions, especially with subtyping in the type system and the borrow checker.
To get good documentation, you can either take a documentation expert (they exist and they're worth their weight in gold) and teach them the relevant part of the code base, or take the code author and teach them to write good docs. In my opinion, the second approach is best because the code author has the nuanced familiarity necessary to provide high-level context to an end-user. This switch by Rust seems in line wit…
Earlier quoted context omitted.
Would a Rust spec that actually allows multiple compatible implementations actually be simpler than the C++ spec? There has only ever been one real Rust implementation, and a lot of Rust behaviors are just arbitrary implementation decisions, especially with subtyping in the type system and the borrow checker.
mrustc has implemented a significant portion of the language, without a formal spec. It's at least advanced enough to compile the compiler. The biggest feature missing is borrowcheck.
To get good documentation, you can either take a documentation expert (they exist and they're worth their weight in gold) and teach them the relevant part of the code base, or take the code author and teach them to write good docs. In my opinion, the second approach is best because the code author has the nuanced familiarity necessary to provide high-level context to an end-user. This switch by Rust seems in line wit…