Hacker News Reader

Comment by jnordwick | Hacker News Reader

No matter how bad those Learn X in 21 Days books were, I really wish there was something for Rust. Sometimes it seems like Rust moves too fast and docs are always quickly out if date or fail to inclusive enough to be useful.

I often hear "since 1.x you should be doing y with z feature now but that is only in current and the rust book doesn't have a section on it yet"

Rust to me is still very much feels to me a moving target.

View on HN

These days, new features are required to be documented before they're stabilized, so you shouldn't be running into that anymore.

Plus, even with that advice, you can still do y the old way; we don't break things, we add new ones. Idioms are always evolving in every language, though it's true that in new ones, they evolve faster.

At the moment, there are two versions of the Rust book online. One is obsolete and the other is unfinished.[1]

[1] https://doc.rust-lang.org/book/

To be clear about the unfinished status of the new book, it's just becuase we have much, much higher standards this time around. All of the chapters have a draft of some kind, and are basically in various stages of editing, plus I need to finish the appendix. That editing is "by the professional editors at No Starch", so it's a bit of a higher bar than most docs included with open source projects.

The old book is not so much "obsolete" as it is "has significant weaknesses as a text so we re-wrote it"; everything in there still applies, and still works.

> That editing is "by the professional editors at No Starch", so it's a bit of a higher bar than most docs included with open source projects.

How is your experience with No Starch, if I may ask? I have a few eBooks by them that I got in various humble bundles; they're usually decent enough introductions to the subject matter at hand.

I have generally enjoyed the experience. I own a lot of their books. They were one publisher that generally aligned with our open source values. The book is much better because of them.

That is entirely untrue. Releases are regular, big changes are anything but.

Depending on how you define "big changes". For example, I consider the static reference convenience feature described in the 1.21 release announcement to be a small new feature, but it does affect how people write code (that's kind of the point! :P ).

> Depending on how you define "big changes".

The way every reasonable person would. This release being the obvious example.

Responding "this is entirely untrue" to someone who is saying how something feels to them is not only overly harsh, but entirely inappropriate. You cannot dictate people's feelings. You might think they have misconceptions that are leading to how they feel, but that doesn't make how they feel untrue.

I can understand if you feel frustrated because you don't think this feeling is warranted, but this is not a constructive way to express that, nor fix the problem.

I think there was just enough content in his reply to escape the accusation that he was merely gainsaying (which would be dictating feelings, as opposed to providing information that might dispel them.)

     Rust to me is still very much feels to me a moving target.

This is FUD mostly, Rust uses the same release model as Go, or Linux.

1.X is backwards compatible to 1.(X-N), and the releases are on a regular cycle... like Go and Linux (well minus semvar stuff, linux just doesn't break userland). Each release _does_ add new things, but they don't do _break_ old things.

its not just the lang. can't use two random libraries together because one still uses old hyper and another uses new hyper.

DLL hell is far older then Rust.

I think that's missing the point. A language can be a moving target while still being backwards-compatible. The textbook example is C++: A C++17 compiler can compile C++03 code, C++11 code and C++14 code [1], so the language is backwards-compatible. Meanwhile, each new release seems to add so many new features to the language and stdlib that idiomatic C++17 code can be wildly different from idiomatic C++11 code and even more so from idiomatic C++03 code.

[1] Except, probably, for corner cases that I'm not aware of because I don't do C++ anymore.

It's not quite like that in Rust though - in C++ modern features replace older features but in Rust that only happens in the detail. There isn't often an equivalent to unique_ptr/shared_ptr changing how you should to all pointer work.

Reply on news.ycombinator.com