Live data from Hacker News

Rust docs team is no more

blog.rust-lang.org

21–30 of 46 posts

Re: Rust docs team is no more

#21
post #2

An example of a project that is "done?"

I read it to be saying it's 'done' in the sense that their documentation is now in a good state, and so doesn't need special attention. Not to say documentation is exactly 'done', of course.

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.

Re: Rust docs team is no more

#22
Sounds like a situation I've found myself in before. The majority of the work is done, and it's become more work to organize and maintain a team than to simply do it on your own.

Re: Rust docs team is no more

#24
post #10

&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.

Mozilla employs something like .... five? people to work on Rust these days. We usually have a few hundred contribute to any given release https://thanks.rust-lang.org/

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.

Re: Rust docs team is no more

#25
post #8

The headline sounds scary, but the actual change sounds like it's merely an organizational reshuffling formality.

Sort of! We'll see if the teams actually keep up the standards of the docs, or if they slide. They've been doing a good job for a while, but it's also pretty varied across the teams.

Re: Rust docs team is no more

#26

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.

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.

Re: Rust docs team is no more

#27

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.

Those are both core features of Rust, though, so any alternative implementation all but has to have them as that is the first thing anyone using it will be looking for.

Re: Rust docs team is no more

#28
post #18

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…

I think both approaches work well in some circumstances. The main issue with the "docs expert" approach is scalability. It's just harder to get enough of them. While I agree with you that the code author has said familiarity, a good docs person will be able to get that kind of information out of them.

Re: Rust docs team is no more

#29

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.

I don't mean a formal spec. Rust is much too complicated and asymmetric to have a formal spec of the kind that exists for other languages (e.g. Standard ML), at least using current specification methodology. It doesn't even have an informal spec, which would be required to have a real attempt at multiple compatible implementations.

Re: Rust docs team is no more

#30
post #18

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…

Did I read that wrong? It didn't sound like a 'switch'. It sounded more like someone quitting out of frustration and docs now ad-hoc with no clearly organized responsibility
Post reply on HN