book

al documentation [0]? And that being said, I don't think a language needs an official spec to make a promise. As far as most programmers are concerned, I'm pretty sure the promises made in language/implementation docs are good enough. K&R was generally good enough for most C programmers before C had a spec, after all (and arguably even after to some extent) :P > Sometimes, it comes from the authority of the Rust compiler developers themselves []. Just look at any talk given by them, or any post made on any forum Does it? At least from what I can remember off the top of my head I don't think I've seen such claim from official Rust devs speaking in their capacity as such. Perhaps you might have links to such? > or, most importantly, the many instances where such statements are made on the Rust book Are there "many instances"? `rg 'compiles.*it.*works` turns up precisely one (1) instance of that statement in the Rust book [1] and slight variations on that regex don't turn up any additional instances. What the book says portrays that statement in a slightly different light than you seem to think: > Note: A saying you might hear about languages with strict compilers, such as Haskell and Rust, is “If the code compiles, it works.” But this saying is not universally true. Our project compiles, but it does absolutely nothing! If we were building a real, complete project, this would be a good time to start writing unit tests to check that the code compiles and has the behavior we want. I wouldn't claim that my search was comprehensive, though, and I also can't claim to know the Rust Book from cover to cover. Maybe you know some spots I missed? > which is not an official spec for the language, but it is the closest thing we have I believe that particular honor actually goes to the Rust Reference [2]. > Also most public speakers who were extremely vocal about Rust and made cookie cutter and easy to digest content for beginner programmers were dead set on selling the language through empty promises and some weird glorification of its capabilities, bordering the behaviour of a cult. Cue in, No Boilerplate, Let's Get Rusty, etc... all of these people have said many times the "if it compiles, you know it works!" statement, which is very popular among Rust programmers, and we all know that that is not true, because anyone with any experience with Rust will be able to tell you that with unsafe Rust, you can shoot yourself in the foot. Again, I don't think what unrelated third parties say has any bearing on what a language actually promises. Rust doesn't owe me a unicorn on my birthday no matter how many enthusiastic public speakers I find. [0]: https://doc.rust-lang.org/stable/ [1]: https://github.com/rust-lang/book/blob/39aeceaa3aeab845bc451... [2]: https://doc.rust-lang.org/stable/reference/index.html

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