I hope the dependence on nightly will go away for the published version, the ecosystem instability caused by everything depending on some version of nightly seems to be a favorite argument among detractors. And there is half a sentence missing in "Execute rustup install nightly . This enables extra features to ."

Section "1.1.1 Safety": I think the flow of the argument is a bit lacking here. There is no really convicing logical or rhetorical step from the compiler inserting integer overflow checks to "fearless concurrency". I know where it comes from, but it appears quite unmotivated in the actual context of the argument as presented. And it isn't helped by the fact that "imploding" is not the most common metaphor to describe the behavior of programs.

It is also not quite clear what the "similar principle" is similar to, to the fearless concurrency, the degrees of freedom or to the additional runtime checks in debug mode?

There is again something missing in "0..v.len() returns an iterator from the"

And I think this is an unconvincing example with a rather unhelpful error message. For comparision, common C compilers with sensible options will pinpoint the actual issue exactly and suggest appropriate fixes:

$ clang -Wall -Werror assign.c
assign.c:6:9: error: using the result of an assignment as a condition without
parentheses [-Werror,-Wparentheses]
if (a = 10) {
~~^~~~
assign.c:6:9: note: place parentheses around the assignment to silence this
warning
if (a = 10) {
^
( )
assign.c:6:9: note: use '==' to turn this assignment into an equality comparison
if (a = 10) {
^
==
1 error generated.

"mismatched types" can't hold a candle to this from an ergonomics standpoint. One could make a point that it is nice that the compiler doesn't need a special case rule for this error, but that makes it easier for the authors and not the users of the compiler.

The section ends with a reference to "these three principles", which are probably safety/ergonomics/control, but that phrase is followed by three more sentences written in the form of a maxim that are not directly following from the preceeding text. So it is tempting to read the period after "principles" as a colon and the following three sentences as the list of principles referred to by "these three", ending up with two different sets of threee principles guiding the language. And the differences between the sets are different enough to be slightly confusing.

With my deviant reading of the end on 1.1.3 this is the third set of three fundamental things in three pages, this may be overusing the rhetorical figure. Part of it repeats things that have already been said (but then they say that repetition is the mother of all learning, so that may be OK), and part of it may only be convincing (or even understandable) to people who already don't like Python for some very specific technical reasons.

It it also not clear what referencing here refers to, it is most likely the reference counted boxed objects (Rc/Arc), but in the context of rust the word is also used for references (&) to values. So maybe "Rust's reference counted values are implemented as...". And is this even useful knowledge at this part of the journey?

The part starting with "There are design decisions" doesn't completely fit under "Size of the Language", instead it repeats parts of the other "Downsides" subsections (and 1.3.3 itself).

The last four paragraphs read a bit like disconnected factoids, while I think that they were meant to be a coherent argument like this:

Systems languages tend to be powerful, but unwieldy [missing: for example by requiring explicit memory management and careful attention to the types of values. Rust tries to provide the power without this unwieldiness]. Some languages get around the memory management problems by having a GC, but rust solves this differently. And while rust is statically typed, the compiler is smart enough to take away much of the pain.

And I'd qualify it as most of the convenience of a garbage collector, at the end of the day the borrow checker is a pedantic nitpicker which most garbage colletors are not.

267849 wrote:Systems languages tend to be powerful, but unwieldy [missing: for example by requiring explicit memory management and careful attention to the types of values. Rust tries to provide the power without this unwieldiness]. Some languages get around the memory management problems by having a GC, but rust solves this differently. And while rust is statically typed, the compiler is smart enough to take away much of the pain.

This is an extremely helpful suggestion. I certainly want to improve chapter 1. Its a bit of a Frankenstein at the moment. Quite a lot has been pulled together from other writing. Will work hard to smooth things out.

267849 wrote:And I'd qualify it as most of the convenience of a garbage collector, at the end of the day the borrow checker is a pedantic nitpicker which most garbage colletors are not.

Controversial point. From memory, my technical ed actually asked me to remove iOS in favour of macOS. I also had ObjectiveC in there, rather than the current Swift. I believe macOS is the current name though and will better serve future readers.

It it also not clear what referencing here refers to, it is most likely the reference counted boxed objects (Rc/Arc), but in the context of rust the word is also used for references (&) to values. So maybe "Rust's reference counted values are implemented as...". And is this even useful knowledge at this part of the journey?

The part starting with "There are design decisions" doesn't completely fit under "Size of the Language", instead it repeats parts of the other "Downsides" subsections (and 1.3.3 itself).

Agree that the language and structure is fairly muddled in this section. Some editorial surgery will be required to enhance the flow and comprehensibility. Thanks for pointing this out. It's surprisingly obvious when someone quotes your text, but very difficult when one is in the middle of writing a large block of text.

And I think this is an unconvincing example with a rather unhelpful error message. For comparision, common C compilers with sensible options will pinpoint the actual issue exactly and suggest appropriate fixes: ...

This is a fair point. I muddled around for a few hours attempting to think of an example that was concise yet compelling. At the end of the day though, I certainly recall the frustration of using the assignment operator when I meant to be comparing values when learning to code. If I get any ideas over the next few months, I will certainly inject them into the prose!

"mismatched types" can't hold a candle to this from an ergonomics standpoint. One could make a point that it is nice that the compiler doesn't need a special case rule for this error, but that makes it easier for the authors and not the users of the compiler.

I also agree that the error message could be improved.. I wonder if assignment is being used within an expression that will be evaluated by a logical test whether something more direct could be said, "Perhaps you meant == rather than =?"

267849 wrote:I hope the dependence on nightly will go away for the published version, the ecosystem instability caused by everything depending on some version of nightly seems to be a favorite argument among detractors. And there is half a sentence missing in "Execute rustup install nightly . This enables extra features to ."

First of all, apologies for the missing half sentence.

Yes, I am hopeful that nightlies won't be required by the time the book goes to print. It's a difficult choice for me to make. Do I pin to a version, say 1.20, and then make the book seem to be over a year old by the time it comes out? At this stage, I'll go for nightly and reconsider when the bulk of the work is done.

I just ended reading the first chapter and want to give some feedback. But first of all, to put my comments into perspective: I am a Java EE developer with some contact to Scala, a bit of Haskell and others, was working with C quite some 25 years ago. Beside that, I am no native English speaker.

From what I read on the web this may be a not so rare profile for people starting to look into systems programming with Rust.

So on to topic now. While I enjoyed the first chapter in general, I had quite a hard time stumbling over the very first pages (the ones before 1.1.), which I think is a pity and a lost chance to make good initial contact with the reader.

The idea to give a quick first glance onto a short but impressive code snipped is fine. But it should lead more to a 'wow' effect than an feeling of confusion.

What were the issues?
First, we learn about a "Listing 1.1", that is "below", but indeed is relatively far on the next page. As a reader typically reads linear, especially in the introductory section of a book, we are learning too much about the code before actually seeing it.

The next thing: We read "In the example, the web framework asks the compiler ...". Oh hey, I haven't seen any code yet, but there is "the" web framework ?

Next, before even seeing any code yet, we "see the web service in action".
To do this, we have to "Install Rust via rustup.rs" - without any hint so far what that might be and what we are meant to do here. See, in the PDF rustup.rs is underlined and indeed an active link. In the print book there will be no hint about what rustup.rs is, and that this might be a URL to follow. A short mention of the words "online installer" or "installation manager" or so would be helpful.

The second step says: "... and move to the ch1-time-api directory". And now the reader is completely lost! Where now shall that be located, and where shall that come from?

The third step is to execute some code, indeed without the slightest hint for what I am experiencing here. Beside that, the next sentence misses a part "This enables extra features to [text end]".

Finally I see the console output of all that, once again: Before even seeing the code I am supposed to run.

At least we are confronted with the hidden treasure: The Code!
This is accompanied by some unfortunately very sparse explanations, and the feeling, that I as a reader may perhaps be wrong here.

Although all that is indeed meant to be introductory and not deeply explaining (which is left for later), There are some confusing points, some slightly more words could have solved.

(1) "Attributes" - You are -without explanation- introducing a Rust term here, that has a different meaning for people coming from OOP. I had to look back and forth to bring that term into connection with something that might be "compiler directives" (like in C) or "annotations" (like in Java).
(2) "Crates" - another Rust term, is explained with "packages". But that is confusing too, as in Java packages are namespaces, not compile units or libraries. As a non-native speaker I was not certain if the term "crate" should be self explanatory to me or not.
(2) (4) and (5) explain keywords to bring something "into local scope", but it is not clear what that is. One time a "crate", one time "exported members". So what is "this crate" in (4)? I am in a crate here too?
(6) "the serde crate" - is not clarifying without context. After I looked up "serde" to be the serialization-deserialization library, that became clear.
(7) Once again "the web framework". Took me quite some time to realize that this might be named "rocket", which then gave a Heureka regarding the second line and two of the "extern crate" things, as well as the message "Rocket has launched" in the console output, which looked only funny first.

After indeed spending enough time reading the next chapters and googling a bit around, that code snipped looked far less alienating. I think with only few additional words, that example can be a far more comforting introduction experience to readers without any prior Rust background.

That was my main concern for this chapter. I will note some minor issues later. Thanks for writing this book on MEAP.

I just ended reading the first chapter and want to give some feedback. But first of all, to put my comments into perspective: I am a Java EE developer with some contact to Scala, a bit of Haskell and others, was working with C quite some 25 years ago. Beside that, I am no native English speaker.

From what I read on the web this may be a not so rare profile for people starting to look into systems programming with Rust.
....

Thank you so much for taking the time to write this comment! The chapter will certainly be revised and this feedback will help immensely.

TS McNamara wrote: I certainly want to improve chapter 1. Its a bit of a Frankenstein at the moment. Quite a lot has been pulled together from other writing. Will work hard to smooth things out.

Indeed pls do. Going through it, I see a lot of technical (these matter, obviously) and non-technical typos; incomplete sentences; sentences that are just awkward and place the burden on the reader to try to make sense of; ....

If I may add one other point: in section 1.4.5 the example of "file formats" is used as an example of systems programming. I'm not entirely convinced. You could talk about interpreters of, or programs that use, those file formats... but file formats by themselves? Not an example of systems programming imo.

That code should be notifiably marked as C code, to not confuse new readers which skim through the chapter.

2.:

There is a significant issue with the naming of the different kind of brackets '(', '{' and '[', as to non-native speakers teachers try to give some sort of regular naming in school, while there are in practice regional differences in what name means what.
(Please look here: https://en.wikipedia.org/wiki/Bracket)

So in the last to paragraphs of 1.3.4 there is a potential for confusion. I needed again some time to sort things out.

"In C, logical tests do not require brackets"

What you meant here, in my wording, is: The body(!) of a conditional expression (branch with if / loop) does not need to be in curly braces.

On the other hand, the "logical test" of the conditional expression indeed is required to be in parentheses.

And:

"Rust's grammar would have caught the bug. It does not allow logical tests without parentheses"

Well, to my reading it is indeed right the opposite: Rust does not accept parentheses around "logical tests", i.e. the checking part of the expression.

On the other hand, the body of the conditional expression must be in : curly braces!

And the right wording here is indeed essential, as Rusts syntax for conditionals is indeed not common in mainstream C-style languages.

In the middle of the fifth to last paragraph you state about the exclamation mark:

In Rust, it signals the use of a macro. Macros can be thought of as[sic!] sort of fancy functions by now.

Macros were already mentioned, an when the reader looks back, it was in the introducing part before chapter 1.1.

Here it states in note (3) that #[macro_use] indicates that we want to import "macros" from another crate, here serde_derive.

Now seeing later note (6): "#[derive(Serialize)] is provided by the serde crate and automatically generates a string representation of this struct..."

The reader is easy led to believe that there is a typo and the mentioned attribute is provided by the serde_derive crate, and that the #[derive] construct is indeed a macro, as it generates some sort of stuff. Exactly what a macro is meant for, and -because of the #-sign- what a C-Preprocess macro would look like.

Do let me know if this answers your question! If any of the terminology is unclear, I recommend reading through chapters 2 and 3. If things are still unclear - please feel free to ask for more info and I will point you to some more resources