Take a photo of a barcode or cover
A review by beaconatnight
The Rust Programming Language by Steve Klabnik, Carol Nichols
5.0
If you've installed Rust using the official `rustup` installer, The Rust Programming Language is included as part of the package. The Second Edition was written by Steve Klabnik and Carol Nichols and complemented by members of the Rust Community. Given this background it won't surprise that the document reads like advertisement that praises the many merits of the Rust Programming Language.
I have to admit, I was quickly turned into a believer. Everything appears to be very well thought-through and well-rounded. I cannot judge whether the language is as secure as its maintainers claim it is, even if many professionals seem to think so. But what the introductory book does is to convincingly explain the pitfalls that the design principle try to avoid.
The motivation for the particularities at hand are occasionally given with reference to perceived (and often widely acknowledged) problems of other popular language. The dangers of buffer-overruns are a case in point:
"In C, attempting to read beyond the end of a data structure is undefined behavior. You might get whatever is at the location in memory that would correspond to that element in the data structure, even though the memory doesn’t belong to that structure."
Another common issue of languages with a garbage collector or manual memory allocation are double free errors: "Freeing memory twice can lead to memory corruption, which can potentially lead to security vulnerabilities." Rust's most defining feature, its ownership system, overcomes this issue. Teaching the ideas of ownership, references, and borrowing are a main concern in the early chapters. Noteworthy also is that Rust attempts to prevent data races.
In other cases, Rust's language design is motivated by the belief that bugs are best prevented early – even if this will be frustrating for beginners. Here is one example:
"It’s important that we get compile-time errors when we attempt to change a value that’s designated as immutable because this very situation can lead to bugs. If one part of our code operates on the assumption that a value will never change and another part of our code changes that value, it’s possible that the first part of the code won’t do what it was designed to do. The cause of this kind of bug can be difficult to track down after the fact, especially when the second piece of code changes the value only sometimes. The Rust compiler guarantees that when you state that a value won’t change, it really won’t change, so you don’t have to keep track of it yourself. Your code is thus easier to reason through."
The requirements of the type system belong in this context, too, even though there are some comfort features like type inference.
If you are an absolute beginner, worries about performance probably won't be too readily on your mind. Nonetheless, the writers address questions of relevance to a wider audience. For instance, we learn early on that "Rust will never automatically create 'deep' copies of your data [i.e. the same data is stored at different locations of the heap]. Therefore, any automatic copying can be assumed to be inexpensive in terms of runtime performance."
In the chapter on Rust programming in accordance with a functional paradigma the authors express the language's strive for zero-cost abstractions. The reader is introduced to iterators whose purpose is to abstract away from some non-substantial details when going through the elements of data structures. In this way we avoid boilerplate and thereby highlight what is of actual relevance. But it's natural to wonder whether the abstraction comes with a price of performance when compared with the more lower-level loops that other language use for this purpose. Surprisingly, benchmarks are cited that appear to be solid evidence that this is not actually the case.
The goal of exposing bugs early on can lead to puzzling results, especially when something isn't as simple as you thought it would be. Strings are the prime example. It's not only that there are two types of strings, collections (vectors of bytes) and string slices (that include string literals). If you come from a different modern language you'll almost certainly be nonplussed to find that the creators of Rust decided against string indexing.
At first sight this seems unnecessarily cumbersome. The first character of the string "hello" is clearly 'h', so why wouldn't "hello"[0] be 'h'? I was amazed by the reasoning we are confronted with. Most importantly, and contrary to what you might expect, the characters in the popular UTF-8 encoding are not all one byte long. The Russian "Здравствуйте", for instance, takes up 24 bytes of space. Moreover, there are diacritics that combine with proper letters to form single characters; however, they take memory space of their own. So, when counting the length of a string we have to think of grapheme clusters. To screen these details from the user may feel convenient – but it does lead to problems and bugs when dealing with the writing systems of many natural languages. Rust takes this seriously by counting string length in terms of bytes rather than in terms of proper characters – and given the argument the reader will be convinced that this is the way to go.
To me reading other introductions to programming was often a frustating experience. I have this directory, `Projects` (`Repositories`, whatever), and within this directory I have a subdirectory named after the application I'm developing. But now what, where would you put your files? You often come across names like `src`, `bin`, `lib`, but how should you structure your projects?
With Cargo it became increasingly difficult for me to separate my excitement about the quality-of-life improvements that it promises from how I felt about the book that is telling me about it. "There’s a place for everything, and everything is in its place." I'm an order-loving librarian at heart, so hooray for structure and system! I felt virtually elated when reading the numerous chapters on the built-in package manager.
In this context I was impressed by how clearly the book explains the concepts of modules and submodules, crates (library and binary), crate roots, packages, workspaces, paths, and how they are connected with each other and with ideas like scope and privacy. Additional structure comes from separating modules onto different files, a practice also explained in detail. It even provides you with the Modules Cheat Sheet, "a list of rules for easy reference when you’re organizing your code in the future".
Throughout more advanced concepts are used, but always with reference to the chapters where they are elaborated on in detail. Some topics are actually quite advanced and subtle. The introduction warns us about common misconceptions and mistakes that new Rustaceans (as the community calls its members) tend to make. This brings me to what I easily liked the most about the introduction, the exceptionally illuminating examples.
At first I was suprised to find that there are more examples that won't compile than ones that actually do work. I think what makes people quit programming is the frustrating experience of an endless series of errors. Even if you are able to fix things, often your program still doesn't work. Rust has a reputation of being particularly unforgiving. The book demonstrates heart and empathy when it verbalizes what it is that learners are getting wrong or why they make the mistakes they are making. I think this is a very important skill that many teachers completely lack.
So we often go through many iterations of the same program. If you write code with no regard for potential complications of course you end up with a result that is more simple and more concerned with the problem-solving at hand. I think this is one reason why it's often good to first discuss a listing that is not actually compiling. Sometimes more advanced techniques are necessary to make things work; didactically, it's more motivating to think through a version you fully understand. You get a sense of this being code that would work, if only you had known better. Incidentally, the error messages are so amazingly descriptive, they point you in the right direction even if you've never heard of the terms before.
Of course even if your code compiles, there is often still room for improvement. I was absolutely blown away about the refactoring in Chapter 12. Our `minigrep` is quickly established, but it was seriously awesome to see in how many ways it could be improved. For instance, it is explained how the main function should interact with library crates; for this reason we refactor our functions out of the main file where they were initially defined. In the past I often wondered about the best practice to define an argument parser; here I was amazed by the interplay of functions and how to use a Config struct to make clear the relationship between the configuration variables. New functionality is developed following a test-driven approach. Later loops are replaced by iterators. It's the kind of real-world advice that I think makes you more confident in the code you write.
Overall, The Rust Programming Language is easily among the best programming introductions I've read. It's hands-on and you won't be bogged down in technical details, yet the level of complexity and advancement are steadily improved to give you a solid understanding of how people in the real world write code in Rust. No book will make you an experienced programmer in any language – but the Rust Community gives you a very solid foundation.
Rating: 5/5
I have to admit, I was quickly turned into a believer. Everything appears to be very well thought-through and well-rounded. I cannot judge whether the language is as secure as its maintainers claim it is, even if many professionals seem to think so. But what the introductory book does is to convincingly explain the pitfalls that the design principle try to avoid.
The motivation for the particularities at hand are occasionally given with reference to perceived (and often widely acknowledged) problems of other popular language. The dangers of buffer-overruns are a case in point:
"In C, attempting to read beyond the end of a data structure is undefined behavior. You might get whatever is at the location in memory that would correspond to that element in the data structure, even though the memory doesn’t belong to that structure."
Another common issue of languages with a garbage collector or manual memory allocation are double free errors: "Freeing memory twice can lead to memory corruption, which can potentially lead to security vulnerabilities." Rust's most defining feature, its ownership system, overcomes this issue. Teaching the ideas of ownership, references, and borrowing are a main concern in the early chapters. Noteworthy also is that Rust attempts to prevent data races.
In other cases, Rust's language design is motivated by the belief that bugs are best prevented early – even if this will be frustrating for beginners. Here is one example:
"It’s important that we get compile-time errors when we attempt to change a value that’s designated as immutable because this very situation can lead to bugs. If one part of our code operates on the assumption that a value will never change and another part of our code changes that value, it’s possible that the first part of the code won’t do what it was designed to do. The cause of this kind of bug can be difficult to track down after the fact, especially when the second piece of code changes the value only sometimes. The Rust compiler guarantees that when you state that a value won’t change, it really won’t change, so you don’t have to keep track of it yourself. Your code is thus easier to reason through."
The requirements of the type system belong in this context, too, even though there are some comfort features like type inference.
If you are an absolute beginner, worries about performance probably won't be too readily on your mind. Nonetheless, the writers address questions of relevance to a wider audience. For instance, we learn early on that "Rust will never automatically create 'deep' copies of your data [i.e. the same data is stored at different locations of the heap]. Therefore, any automatic copying can be assumed to be inexpensive in terms of runtime performance."
In the chapter on Rust programming in accordance with a functional paradigma the authors express the language's strive for zero-cost abstractions. The reader is introduced to iterators whose purpose is to abstract away from some non-substantial details when going through the elements of data structures. In this way we avoid boilerplate and thereby highlight what is of actual relevance. But it's natural to wonder whether the abstraction comes with a price of performance when compared with the more lower-level loops that other language use for this purpose. Surprisingly, benchmarks are cited that appear to be solid evidence that this is not actually the case.
The goal of exposing bugs early on can lead to puzzling results, especially when something isn't as simple as you thought it would be. Strings are the prime example. It's not only that there are two types of strings, collections (vectors of bytes) and string slices (that include string literals). If you come from a different modern language you'll almost certainly be nonplussed to find that the creators of Rust decided against string indexing.
At first sight this seems unnecessarily cumbersome. The first character of the string "hello" is clearly 'h', so why wouldn't "hello"[0] be 'h'? I was amazed by the reasoning we are confronted with. Most importantly, and contrary to what you might expect, the characters in the popular UTF-8 encoding are not all one byte long. The Russian "Здравствуйте", for instance, takes up 24 bytes of space. Moreover, there are diacritics that combine with proper letters to form single characters; however, they take memory space of their own. So, when counting the length of a string we have to think of grapheme clusters. To screen these details from the user may feel convenient – but it does lead to problems and bugs when dealing with the writing systems of many natural languages. Rust takes this seriously by counting string length in terms of bytes rather than in terms of proper characters – and given the argument the reader will be convinced that this is the way to go.
To me reading other introductions to programming was often a frustating experience. I have this directory, `Projects` (`Repositories`, whatever), and within this directory I have a subdirectory named after the application I'm developing. But now what, where would you put your files? You often come across names like `src`, `bin`, `lib`, but how should you structure your projects?
With Cargo it became increasingly difficult for me to separate my excitement about the quality-of-life improvements that it promises from how I felt about the book that is telling me about it. "There’s a place for everything, and everything is in its place." I'm an order-loving librarian at heart, so hooray for structure and system! I felt virtually elated when reading the numerous chapters on the built-in package manager.
In this context I was impressed by how clearly the book explains the concepts of modules and submodules, crates (library and binary), crate roots, packages, workspaces, paths, and how they are connected with each other and with ideas like scope and privacy. Additional structure comes from separating modules onto different files, a practice also explained in detail. It even provides you with the Modules Cheat Sheet, "a list of rules for easy reference when you’re organizing your code in the future".
Throughout more advanced concepts are used, but always with reference to the chapters where they are elaborated on in detail. Some topics are actually quite advanced and subtle. The introduction warns us about common misconceptions and mistakes that new Rustaceans (as the community calls its members) tend to make. This brings me to what I easily liked the most about the introduction, the exceptionally illuminating examples.
At first I was suprised to find that there are more examples that won't compile than ones that actually do work. I think what makes people quit programming is the frustrating experience of an endless series of errors. Even if you are able to fix things, often your program still doesn't work. Rust has a reputation of being particularly unforgiving. The book demonstrates heart and empathy when it verbalizes what it is that learners are getting wrong or why they make the mistakes they are making. I think this is a very important skill that many teachers completely lack.
So we often go through many iterations of the same program. If you write code with no regard for potential complications of course you end up with a result that is more simple and more concerned with the problem-solving at hand. I think this is one reason why it's often good to first discuss a listing that is not actually compiling. Sometimes more advanced techniques are necessary to make things work; didactically, it's more motivating to think through a version you fully understand. You get a sense of this being code that would work, if only you had known better. Incidentally, the error messages are so amazingly descriptive, they point you in the right direction even if you've never heard of the terms before.
Of course even if your code compiles, there is often still room for improvement. I was absolutely blown away about the refactoring in Chapter 12. Our `minigrep` is quickly established, but it was seriously awesome to see in how many ways it could be improved. For instance, it is explained how the main function should interact with library crates; for this reason we refactor our functions out of the main file where they were initially defined. In the past I often wondered about the best practice to define an argument parser; here I was amazed by the interplay of functions and how to use a Config struct to make clear the relationship between the configuration variables. New functionality is developed following a test-driven approach. Later loops are replaced by iterators. It's the kind of real-world advice that I think makes you more confident in the code you write.
Overall, The Rust Programming Language is easily among the best programming introductions I've read. It's hands-on and you won't be bogged down in technical details, yet the level of complexity and advancement are steadily improved to give you a solid understanding of how people in the real world write code in Rust. No book will make you an experienced programmer in any language – but the Rust Community gives you a very solid foundation.
Rating: 5/5