For now, I'm using this subdomain due to some issues with deploying to GitHub Pages. Personally, I prefer using a dark theme and increasing the font size in Firefox for better readability. However, I encountered some difficulties setting a dark theme as the default, so the site currently uses the default white theme.
Please note that there is no guarantee of complete accuracy at this stage. Proofreading is ongoing, and I may add a few more chapters in the coming months.
In Section 6.1.2, I think that the comparison with C is confusing because it doesn't match what the Rust code does:
let s1 = String::from("hello");
let s2 = s1; // s1 is moved to s2
// println!("{}", s1); // Error: s1 is no longer valid
println!("{}", s2); // Outputs: hello
vs.
char *s1 = malloc(6);
strcpy(s1, "hello");
char *s2 = s1; // Both s1 and s2 point to the same memory
free(s1);
// Using s2 here would be undefined behavior
return 0;
The move to s2 does not free s1, it just invalidates s1 as a pointer to the heap.
I gather your intent was to compare idiomatic Rust with idiomatic C instead of showing matching code. But it would be clearer and more instructive to do the latter.
For your critics about the misleading C equivalent I have still no good solution. The problem is, that C has no move semantics which makes access to the source invalid. Personally I think that the C example is not that wrong, but perhaps I should just remove it. Just because the current title of the book is "Rust for C Programmers" does not mean, that we need for each Rust construct a C equivalent, and the title should only indicate that the book is not dedicated to absolute beginners.
Perhaps you have noticed that I added a chapter "10 Enums and pattern matching" and "11 Traits, generics, and lifetimes". But both topics are not that easy and I might have to continue improving them. Maybe I will ship the text to GitHub, so readers could easily post comments...
I have not looked at your book yet but the title "Rust for C programmers" is a very good idea.
I would not expect every Rust example to be an exact equivalent of what you can write in C. After all if it were every example would have to be unsafe from top to bottom !
However, with such a title, I think it would be important to point out why it's different and most importantly how Rust stops one making dangerous mistakes in C and what an advantage that is. Also how Rusts anti-aliasing rules enable optimisations that C cannot make. I feel that is the "pitch" we have to make to C programmers.
Actually, I am not fully happy with the title. It might repel people, who have already some experience in programming, but not that much in C, or who do not like C that much. But I have currently no idea for a better title.
Also how Rusts anti-aliasing rules enable optimizations that C cannot make.
That is an interesting point, I have still to learn more about that.
My feeling is that there are programmers from all kind of backgrounds and experience and that likely there are different books with different approaches or emphasis required for each. I'm sure that, for example, introducing Rust to people who have only been doing Javascript front ends for years requires a lot more "hand holding" in terms of how machines work, stacks, heaps, caches, all that, than a hard core C programmer. Certainly showing a lot of C examples in comparison to Rust might be expecting too much of someone who only ever worked in Python. A Rust book for those who never programmed before would require yet another approach.
Also it is said that one should have an audience in mind when writing. Having a narrowly focused title like that should help thinking about what one writes and keep it on track and coherent.
In varadic functions, you could note that the C loop you describe iteratively composes the string to print at runtime, whereas Rust proc macros and macros by example evaluate at compile time
Also, regarding struct and enum layout, you have a section on enum layouts, but you could elaborate on Rust and C differences in enum and struct layout guarantees, particularly since C has a stable ABI. For instance, you could draw the parallel to C tagged unions (like in RFC 2195 Really Tagged Unions), distinguish the size of enums (C classless enums default size is 4 bytes and are constants in the file namespace, Rust can customize discriminant size), or note that Rust struct layouts are deliberately undefined so fields can be reordered to minimize size.
Thanks, all that are good ideas, I will consider them carefully. However, I think I should not try to discuss too many details. I recently added a short section about too many detail to the introduction of the book, see
This book aims to present the most important aspects of the Rust language while deliberately omitting content that the average programmer may rarely need. It also avoids delving into Rust internals that are irrelevant to most users and might change in future releases. Given Rust's complexity, an overload of details could easily overwhelm or confuse the reader.
One example is Basic enums - Rust for C-Programmers where I describe assigning specific integer values to enums, casting to integers, and using enums as array indices. First I regarded that an interesting topic, but later I had the feeling that this is too much information for the reader and useful only in special use cases.
The chapter about iterators is now also available. Was not that easy as expected, even with some help from More fun with iterators.
I think the basic, introductory part is now mostly complete, so that I might take a longer break. But I hope I might provide a few more chapters in the next 12 months.