Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next Iteration of “The Rust Programming Language” Book

rust-lang.github.io

Post reply on HN
Print view View original

81–90 of 111 posts

Re: Next Iteration of “The Rust Programming Language” Book

#81

Post by Dowwie »

jventura wrote: post #51
carols10cents wrote: post #42

Earlier quoted context omitted.

We actually had someone say that the new version is so much better than the old book, even though it's incomplete, that it's like a medical trial where the treatment is going so well it'd be unethical to keep people on the placebo. A bit hyperbolic, yes, but so is "this doesn't help anybody".

Although I have some years of practice in programming, I always prefer to learn new languages using some kind of practical tutorial that introduces the topics as we go along. I've just finished the guessing_game tutorial and really understood the general idea of cargo, externs, associated functions, etc. Congratulations, and I hope that the rest of the book is as practical on introducing the following concepts as the…

I agree. With that given, this week, I published a rust tutorial based on my first completed project:. http://daringordon.com/rust_tutorials

Re: Next Iteration of “The Rust Programming Language” Book

#82

Post by steveklabnik »

JasonSage wrote: post #79

Something I'm curious about is why this next iteration of the Rust Programming Language book has been developed relatively hidden away from new folks, who have to continue using the old book unless they stumble upon the new one somehow. I would think that if the content of the new book does a better job at educating new users of the language, you would want that to be in front of everybody as absolutely soon as possi…

> relatively hidden away from new folks,

We talk about it quite a bit on IRC, on Twitter, in the forums/Reddit, and elsewhere. I've specifically put the text out in front of new people to get feedback.

> why is the strategy to complete the new book entirely before moving over?

This is not _strictly speaking_ true, but it's been blocked on some other things. We haven't been able to use mdBook, the tool we use for the new book, inside the Rust repository until two days ago[1]. This was due to a number of factors that had nothing to do with the book.

Soon[2], we'll be able to actually present both books on the website, and so this will be messaged a bit better.

> If the new one has such big gaps that it can't stand on its own,

Well, I mean, we started from scratch. The full first draft isn't even done yet! When's the right time for this, after one chapter is done? Two? Five? It's a tough question, but the actual nuts and bolts of the build process made that question moot, and now that it's 75% done by chapter count, it's all just kind of working out.

Does that all make sense?

1: https://github.com/rust-lang/rust/pull/39633#issuecomment-27...

2: https://github.com/rust-lang/rust/issues/39588

Re: Next Iteration of “The Rust Programming Language” Book

#86

Post by projektir »

beebob wrote: post #45

I'm currently starting to learn rust (previous java and go developer). But at the moment it feels like the good old times where I was developing with an editor and api doc side by side. What is the current editor of choice for rust projects? I tried intellij-rust and atom with the racer plugin. Both seem to be in a somewhat early stage of development regarding the auto completion. Regarding the book: I like it. Has b…

There's a plugin for IntelliJ: https://intellij-rust.github.io/

Re: Next Iteration of “The Rust Programming Language” Book

#87

Post by kbenson »

ben_jones wrote: post #12
purple-again wrote: post #3

Sigh. Looks like it's time for round 5 of time to learn Rust(my personal failing, not meant as a slight against the language at all). Has the pace of sweeping changes to the language slowed down in the past year? I rode the Ember train from 1.4 to now and it was an extremely ehausting process to get to 2.0 with nearly every version requiring frustrating architectural rewrites. The upgrade from 2.0 to 2.8 took like 15…

It's been, god, 3 years now since I've started writing large Golang applications and I've yet to look back on a project ~6 months later without noticing flaws in design/architecture/intuitiveness. You are not alone in your hurdles.

On the bright side, that's am easy way to measure your growth. Look at it this way, if in six months or more if you look back on code you're writing now that's non-trivial and you can't think of a single thing you would do different what's more likely, that you were lucky/good enough to design it perfectly, or that you didn't actually learn anything from the experience (even if it's what assumptions about projects in that industry you shouldn't make going forward)?

I dread the day I no longer see progress. I suspect it's also about the time I'll really find programming no longer fun.

Re: Next Iteration of “The Rust Programming Language” Book

#88

Post by kbenson »

Ygg2 wrote: post #30
cgh wrote: post #21

Earlier quoted context omitted.

Lifetimes can be confusing as hell, especially declaring them correctly. It looks like section 10.3 in this new book improves things.

Here is something, that might ease things: https://rufflewind.com/2017-02-15/rust-move-copy-borrow

Reading that, and the little blurb about move and copy semantics below the infographic, it occurred to me that borrowing is actually rather easily described as real like sharing (which is unfortunately already a loaded term in much of CS due to multiprocessing).

When you share something that is not copyable (such as a pen), you give it to the person borrowing it until they return it when done.

When you share something that is copyable (and idea, some software, a joke), you give someone their own copy to do with as they please. There is no return required.

Borrowing, which is from the receiver's perspective, implies returning, while sharing, from the sender's perspective, may or not mat imply a later return of something.

I wonder how much the conceptual baggage of the terminology affects how people learn them.

Re: Next Iteration of “The Rust Programming Language” Book

#89

Post by carols10cents »

indolering wrote: post #85

As a technical documentation nerd, I hope we can get a rudimentary JS (or WASM) IDE and compiler worked out and A/B test everything on Khan Academy for version 3.0. One impossible task at a time : )

How about you lead that effort ;)

Re: Next Iteration of “The Rust Programming Language” Book

#90

Post by cpeterso »

cgh wrote: post #21
lacampbell wrote: post #7

I'm reading the section on ownership. Valgrind usually thinks my 'modern C++' code is leak free, and when it complains I understand why, so I'm not a complete stranger to systems programming. But for whatever reason I have always run into a brick wall with rusts strange compiler messages regarding lifetimes. I read the previous books bit on ownership. I'm not sure if this new version is better written or I've come ac…

Lifetimes can be confusing as hell, especially declaring them correctly. It looks like section 10.3 in this new book improves things.

As a C++ programmer, I understand ownership and borrowing, but I find the lifetime syntax impenetrable. It clutters the code with annotations that seem like they could be deduced by the compiler.

For example, a variable's lifetime is relative to another variable or function. Why must we create a placeholder name like 'a instead of referring to the other variable by name? Take this example from section 10.3:

  fn longest(x: &'a str, y: &str) -> &'a str {
      x
  }
Why couldn't we write it as something like the following?

  fn longest(x: &str, y: &str) -> &'x str {
      x
  }
Or instead of requiring lifetimes everywhere, the compiler could use conservative defaults but allow optional lifetime annotations to reduce the lifetime if needed or to release memory sooner. For example, in this struct from section 10.3, why is 'a necessary when config is a non-mut reference and thus must outlive a struct App instance? There is a Rust issue filed for this: https://github.com/rust-lang/rfcs/issues/1532

  struct App {
      name: String,
      config: &'a Config,
  }
Post reply on HN