RIrichardwhiuk·Aug 10, 2020
I think (/ hope) that the later was picked up by being homed on GitHub - https://github.com/rust-lang/book
In GitHub Arctic Code Vault: Tech Treerust-lang
book
Rust2016–2025
rust-lang / book
book
The Rust Programming Language
14Distinct people
21Mentions
0Explicit recommenders
18.6KGitHub stars
What to know before exploring
What it is
The Rust Programming Language
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:02:44 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year21 dated mentions
Observed mentions: 2016-01-15 14:43:46 UTC to 2025-12-21 06:13:58 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
3 sourcesRust book is written in Md https://github.com/rust-lang/book as well as plenty other books that I can't remember from the back of my head.
In Show HN: Write.md – a shareable distraction-free Markdown editorI feel for the author. However, I strongly disagree with the conclusions here in practice. A lot of this boils down to "other tools are better," and that's true, but the issue is that it's really, really hard to get people to write documentation, and handing them a perfect but complex tool means they're less likely to actually go through with it.
I've written every kind of documentation in Markdown, and it's not a panacea, but it does work. I'll talk about the article's points first, though:
> Lack of specification
https://commonmark.org/. It's not perfect, but GFM and it are (slowly) unifying. Pick one, document that that's the one you support, and you're done.
> Flavors
See answer 1.
> Lack of Extensibility
While it does not have an extension system, that doesn't mean that you can't do it. As long as you only add things, you should be g
Read the rest
ood to go. Most things you'd want that aren't in the spec proper have some sort of existing extension that will solve your problems.
This is not ideal, but it's also not insurmountable. This is the only true negative I agree with on this list, I just don't think it's the end of the world.
> Lack of Semantic Meaning.
While this is true in a sense, at the same time, CommonMark lets you put any string on a code fence, which means that you can add whatever sematnic you'd like.
> Markdown is now dependent on specific HTML classes, and page design
No more dependent on those classes than on whatever other semantic marker you were trying to do, and if you want to change them, do what you'd have to do with the semantic: configure your tooling to put out something else.
> Document content is no longer portable to other output formats
This problem would still exist if semantics were there; someone has to write the mapping.
> Conversion to other markup tools and page designs becomes much harder
I disagree, but there's also no justification, so it's hard to respond.
> Lock-In and Lack of Portability.
This is a non-issue in practice. It's just like any other format.
-------------------------------------
All of Rust's documentation is in Markdown. We've overcome these challenges in a few ways:
* Choosing CommonMark
* Defining some additional, backwards-compatible with regular Markdown semantics. If you don't use them, you won't get as nice of an output in some cases, but if you do, stuff is a lot nicer. This includes things like "Show an icon to indicate that this does not compile" or "run this code sample as a test" or "this is a summary line and then this is a body."
* Writing Markdown to other format compilers. The Rust book (540 pages for its first printing) was written 100% in Markdown. Our editors don't use Markdown, they use Word. Carol, my co-author, wrote a DOCX to Markdown compiler in XSLT[1]. We write Markdown, compile it to HTML, concatenate it all into one big document, and send it to them. They open it in Word, they leave comments, we take the resulting DOCX, compile it back to Markdown, and address things.
[1]: https://github.com/rust-lang/book/blob/master/tools/docx-to-...