Chapter 1: Introducing Rust

Introduction

The chapter introduction welcomes readers and previews the book’s practical Rust projects and systems-programming topics.

1.1 Where is Rust used?

This section shows that Rust is used in a wide range of production systems by both large technology companies and fast-moving startups.

• Rust in production systems: Describe the range of real-world systems built with Rust, using examples from the section rather than treating it as a language used only for experiments.
  Why it matters: These examples establish that Rust is already used for substantial, varied software.
• Rust at fast-moving startups: Explain what the startup examples illustrate about Rust, and give an example of a startup use described in the section.
  Why it matters: Rust’s production use is not limited to large companies with extensive resources.

Key terms: Rust, AWS Lambda, Firefox, startups, Sourcegraph, Figma, Parity

1.2 Advocating for Rust at work

The section describes how engineers have introduced Rust at work through small projects and used those successes to support wider adoption.

• Bottom-up Rust adoption: Explain how engineers have introduced Rust at work by using it to address technical challenges in relatively small projects, then citing those successes to justify more ambitious work.
  Why it matters: A small, successful project can make the case for using Rust more widely.
• Google adoption since 2017: State how the section describes Rust’s position at Google since late 2017, including its sanctioned use in Android and Fuchsia.
  Why it matters: This gives a concrete example of Rust gaining institutional acceptance.

Key terms: bottom up, technical challenges, small projects, Google, Android, Fuchsia, officially sanctioned language

1.3 A taste of the language

Introduces a hands-on taste of Rust using the compiler and a quick program, with full projects reserved for later chapters.

1.3.1 Cheating your way to “Hello, world!”

This section uses Cargo’s generated project to run “Hello, world!” without writing Rust code, then explains the files and build steps involved.

• Cargo Project Creation: Explain that cargo new creates a standard Rust project and identify where its metadata and source code go.
  Why it matters: Recognizing the generated layout helps you find the code and project configuration before changing either.
• Cargo Run Build Sequence: Trace what cargo run does when the generated project has not yet been compiled, and explain why it prints “Hello, world!”
  Why it matters: It explains how you ran Rust code without writing any yourself.
• Generated Build Artifacts: Describe the additional files cargo run creates and the purpose of Cargo.lock.
  Why it matters: It helps you distinguish files you edit from files Cargo manages during builds.

Key terms: cargo new, Cargo.toml, src, .rs, cargo run, debug mode, src/main.rs, Cargo.lock, target/

1.3.2 Your first Rust program

This section walks through creating and running a multilingual greeting program, then explains its UTF-8 strings and the exclamation mark in `println!`.

• Greeting project workflow: Describe how to create the `hello2` project with Cargo, replace `src/main.rs` with the program from listing 1.1, and run it to display three greetings.
  Why it matters: This gives you a repeatable way to try the book’s first Rust example.
• UTF-8 greeting strings: Explain why the program can include greetings in non-English languages.
  Why it matters: It explains why the multilingual text in the example works.
• Print macro notation: Explain what the exclamation mark in `println!` indicates and why the section uses it as an example of a macro.
  Why it matters: It helps you read a conspicuous piece of syntax in the first program without mistaking it for an operation that changes data.

Key terms: cargo new, src/main.rs, cargo run, strings, UTF-8, println!, macro, boilerplate code

1.4 Downloading the book’s source code

The section tells readers where to get the example source code so they can follow along with the book.

• Example source code locations: State that the source code for every example is available on the Manning book page and in the book’s GitHub repository, and that readers can use it to follow along.
  Why it matters: Having the listings lets you try the examples as you read.

Key terms: source code, listings

1.5 What does Rust look and feel like?

The section uses a CSV-processing example to show Rust’s high-level feel, explain several pieces of its syntax, and demonstrate how to run debug and release builds.

• Rust’s Language Feel: Explain how the example illustrates Rust’s high-level, expressive feel alongside its low-level performance, naming a few language features the section points out.
  Why it matters: This is the overall impression of Rust that the example is meant to convey.
• Vectors And Printing Macros: Describe what Vec<_> indicates and distinguish the output destinations of println! and eprintln! in the example.
  Why it matters: These details make the unfamiliar notation and console output in the example easier to read.
• Conditional Parsing With If Let: Trace what happens when the example attempts to parse a field as f32 using if let Ok(length), including what happens on failure.
  Why it matters: It explains how the example processes valid data without processing an invalid field as a number.
• Debug And Release Runs: Describe how to run the example with cargo and explain why the release run omits the dbg: lines.
  Why it matters: The commands let you reproduce the example and see the practical effect of its debug condition.

Key terms: method syntax, closure, expression-based language, bare-metal performance, Vec<_>, vector, type inference, println!, eprintln!, stdout

1.6 What is Rust?

The section introduces Rust through its compile-time memory safety, its inclusive community, and its usefulness beyond traditional systems programming.

• Compile-time memory safety: Explain how Rust prevents invalid data access at compile time and provides memory safety without runtime checks that slow a program down.
  Why it matters: This explains why Rust presents safety and performance as compatible rather than competing goals.
• Inclusive community practices: Describe how the Rust community puts inclusion into practice through its conduct, messaging, and compiler error messages.
  Why it matters: The section treats the community’s choices as part of what distinguishes Rust, alongside the language itself.
• Usefulness beyond systems programming: Explain why the section says Rust can be useful outside the domain suggested by its systems-programming label.
  Why it matters: It keeps the systems-programming label from being mistaken for a limit on where Rust belongs.

Key terms: invalid data access, compile time, memory-safe, runtime costs, inclusion, code of conduct, compiler’s error messages, systems programming language, safety, productivity

1.6.1 Goal of Rust: Safety

This section illustrates Rust’s safety goal through examples of invalid references, data races, out-of-bounds access, iterator invalidation, and integer overflow.

• Dangling pointer prevention: Explain what a dangling pointer is and why the example with grains does not compile.
  Why it matters: Rust can catch an invalid-reference problem before the program runs.
• Data race prevention: Describe why the two-thread example has an unpredictable outcome and why Rust rejects its attempted writes.
  Why it matters: Preventing competing writes supports the confidence the section calls fearless concurrency.
• Out-of-bounds array access: Explain the buffer overflow example and what happens when its invalid access is executed.
  Why it matters: The example shows that Rust does not let an invalid array access proceed unnoticed.
• Iterator invalidation prevention: Explain why changing letters during iteration is a problem and what Rust does with the example.
  Why it matters: Compile-time rejection prevents a change to the collection from disrupting iteration.
• Debug-mode integer overflow: Describe integer overflow and state when the section says Rust protects against it.
  Why it matters: The debug-mode qualification keeps this safety claim precise.

Key terms: dangling pointer, borrow, moved value, data race, thread, thread::spawn(), fearless concurrency, buffer overflow, fruit[4], iterator invalidation

1.6.2 Goal of Rust: Productivity

The section illustrates Rust’s productivity goal through a compiler-caught assignment mistake and the project utilities provided by cargo.

• Assignment and equality tests: Explain why using = instead of == in the section’s if test fails to compile, and how changing it to == fixes the test.
  Why it matters: The compiler catches a small typo before it becomes a running program.
• Cargo project utilities: Describe how cargo supports the Rust development workflow beyond acting as a front end for rustc, using the commands described in the section.
  Why it matters: Cargo puts common development tasks behind a small set of commands.

Key terms: assignment, equality, unit, (), mismatched types, cargo, rustc, cargo new, cargo init, cargo build

1.6.3 Goal of Rust: Control

This section explains that Rust gives programmers control over data representation and access patterns while treating safety as its first priority.

• Control over data representation: Explain that Rust provides sensible defaults but lets programmers choose how data is stored and accessed when their needs call for different trade-offs.
  Why it matters: This explains why Rust offers several ways to hold even a simple value.
• Safety as first priority: State the safety principle the section gives for understanding Rust’s choices, including immutable-by-default data and a preference for compile-time checks.
  Why it matters: This principle helps explain why Rust makes some choices even while offering programmers control.

Key terms: control, access patterns, runtime characteristics, trade-offs, safety, immutable by default, compile-time checks, zero-cost abstraction

1.7 Rust’s big features

Introduces performance, concurrency, and memory efficiency as Rust features to be discussed next.

1.7.1 Performance

This section explains how Rust pursues performance through compiler optimization, data layout, and static dispatch, while noting its package ecosystem.

• Compiler-driven performance: Explain why faster software must do less work on a CPU of fixed speed, and how Rust places much of that burden on a compiler that optimizes program size and speed.
  Why it matters: It explains what the section means by Rust offering performance despite being a large language.
• Cache-friendly data layout: Describe the section's data-oriented programming example: Rust programs usually hold data in arrays rather than deeply nested pointer-created trees, providing cache-friendly data structures by default.
  Why it matters: Performance depends not only on compiler optimization but also on how programs arrange their data.
• Static method dispatch: Explain that methods use static dispatch unless dynamic dispatch is explicitly requested, allowing the compiler to optimize calls and sometimes eliminate their cost.
  Why it matters: It gives a concrete example of a Rust default that helps the compiler optimize performance.
• Cargo package access: State that cargo makes it easy to use many open source packages, whereas the section describes large C and C++ projects with many dependencies as typically difficult to build.
  Why it matters: It distinguishes the section's tooling claim from its claims about how generated code runs.

Key terms: compiler, optimizes, performance, cache-friendly data structures, arrays, data-oriented programming, static dispatch, dynamic dispatch, methods, cargo

1.7.2 Concurrency

The section presents Rust’s approach to concurrency as extending safety across threads without a global interpreter lock.

• Safety across concurrent threads: Explain why concurrency is difficult and what the section means by Rust’s “fearless concurrency”: independent threads can interfere destructively when programmers make serious mistakes, while Rust emphasizes safety across thread boundaries without a global interpreter lock constraining a thread’s speed.
  Why it matters: It explains why the book calls Rust’s approach “fearless concurrency” without claiming that concurrent programming becomes effortless.

Key terms: fearless concurrency, threads of execution, global interpreter lock (GIL)

1.7.3 Memory efficiency

This section explains how Rust supports low-memory programs while keeping high-level constructs inexpensive at runtime.

• Memory control with low overhead: Explain how Rust can support programs that use minimal memory: fixed-size structures let programmers know how every byte is managed, while iteration and generic types incur minimal runtime overhead.
  Why it matters: Memory efficiency does not require giving up every high-level language feature.

Key terms: fixed-size structures, iteration, generic types, runtime overhead

1.8 Downsides of Rust

This introduction cautions that Rust’s appealing claims do not make it a cure-all and sets up a discussion of its disadvantages.

• Rust’s merits and limitations: Explain why Rust should not be treated as a cure-all: its appealing claims can be overstated, and it has disadvantages despite its merits.
  Why it matters: This keeps the discussion of Rust’s strengths in perspective.

Key terms: panacea, disadvantages, slogans

1.8.1 Cyclic data structures

This subsection identifies cyclic data structures as difficult to implement in Rust and advises newcomers to postpone them.

• Cyclic data structure difficulty: Explain that Rust’s safety checks can make cyclic data structures, such as arbitrary graphs and doubly-linked lists, difficult to implement, and state the advice given to newcomers.
  Why it matters: It sets realistic expectations for an early Rust project without suggesting that cyclic structures are impossible.

Key terms: cyclic data, arbitrary graph structure, doubly-linked list, safety checks

1.8.2 Compile times

This subsection explains why Rust can compile more slowly than peer languages and the optimization tradeoff involved.

• Rust compilation tradeoff: Explain why Rust can be slower to compile than peer languages: its compiler toolchain is complex, and it compiles whole crates rather than individual files, enabling whole-of-crate optimization but requiring whole-of-crate compilation.
  Why it matters: It helps explain both Rust’s compile-time cost and what its crate-level compilation makes possible.

Key terms: crate, module, whole-of-crate optimization, LLVM

1.8.3 Strictness

This section presents Rust’s strict compiler as a short-term inconvenience that can catch mistakes before users encounter crashes.

• Compiler strictness and early errors: Explain why Rust’s strict compiler can be frustrating while programming but beneficial to users: a program must compile before it runs, so mistakes such as misnamed variables can be caught before they cause crashes.
  Why it matters: The strictness that slows you down during development can spare users from avoidable crashes.

Key terms: compiler, strict, compile, dynamic language

1.8.4 Size of the language

Rust’s size makes it challenging to learn, so the book introduces the language gradually.

• Language size and gradual learning: Explain why Rust can have a steep learning curve and describe the section’s recommended way to manage it.
  Why it matters: You do not need to master all of Rust before you can start using it.

Key terms: rich type system, steep learning curve, minimal subset

1.8.5 Hype

This subsection cautions against treating Rust’s popularity as proof that it can solve every software problem.

• Limits of Rust enthusiasm: Explain why enthusiasm for rewriting software in Rust should be tempered: Rust software can still have security problems and is not a cure-all for software engineering.
  Why it matters: It helps you evaluate claims about Rust without assuming that choosing the language removes every risk.

Key terms: hype, security problems, panacea

1.9 TLS security case studies

The section introduces two SSL/TLS security cases to show that Rust may help prevent serious errors but cannot eliminate them all.

• Limits of Rust safety: Explain that Rust might have helped prevent the security issues associated with Heartbleed and goto fail;, but Rust code can still have similar issues.
  Why it matters: This distinction keeps Rust’s safety benefits from being mistaken for a guarantee of security.

Key terms: Rust, memory safety, Heartbleed, goto fail;

1.9.1 Heartbleed

Explains how reusing an uncleared buffer can leak earlier users’ data and why Rust’s protections do not prevent every security flaw.

• Uncleared buffer data leaks: Explain how reusing a buffer without resetting it can expose information from an earlier use to a later one, including when processing secrets from multiple users.
  Why it matters: It shows how an ordinary memory-reuse decision can become a security problem.
• Performance motive and safety limits: Explain why programmers reuse buffers and distinguish the resulting logical error from the protection Rust provides.
  Why it matters: Rust’s safety protections do not remove the need to check whether a program handles sensitive data correctly.

Key terms: Heartbleed, buffer, leak, performance, logical errors, security issues

1.9.2 Goto fail;

This section uses the goto fail; security bug to show how C syntax can let a programmer’s mistake skip cryptographic checks, while explaining how Rust would help without making mistakes impossible.

• Goto fail verification failure: Explain that a programmer error, coupled with C’s allowance for logical tests without curly braces, caused a function intended to verify a cryptographic key pair to skip its checks.
  Why it matters: A small control-flow mistake can defeat a security check.
• Rust safeguards and limits: Describe why Rust probably would have caught this specific bug and why the section does not claim Rust makes similar mistakes impossible.
  Why it matters: Language safeguards help catch mistakes, but they do not replace careful programming.

Key terms: goto fail;, logical tests, curly braces, cryptographic key pair, Rust’s grammar, unreachable

1.10 Where does Rust fit best?

1.10.1 Command-line utilities

This subsection explains why Rust is well suited to command-line utilities: quick startup, low memory use, and easy deployment.

• Quick utility startup: Explain why Rust command-line utilities can begin work quickly compared with programs that require an interpreter or virtual machine.
  Why it matters: Startup time is especially noticeable in utilities that run briefly.
• Memory-efficient utility programs: Describe the memory-use advantage identified for Rust utilities and what zero-sized types contribute to it.
  Why it matters: The distinction between a compiler hint and runtime storage helps explain the section’s low-memory claim.
• Static binary deployment: Explain how the section connects Rust’s default static binaries to easier distribution of utilities.
  Why it matters: Fewer prerequisites make a command-line utility simpler to give to someone else.

Key terms: startup time, interpreter, virtual machine, bare metal language, memory-efficient, zero-sized, static binaries, shared libraries, deployment

1.10.2 Data processing

This section explains why Rust is useful for data processing, from text filters to high-throughput pipelines.

• Data processing performance: Explain how Rust’s memory control and type system help data-processing programs achieve high throughput with a low, stable memory footprint, and why fast startup benefits smaller programs.
  Why it matters: These are the practical advantages the section gives for choosing Rust for data-processing work.
• Embedded filter programs: Describe how small Rust filter programs can fit into larger data-processing frameworks.
  Why it matters: Rust programs need not stand alone; they can serve as small parts of larger data-processing systems.

Key terms: data wrangling, type system, high throughput data pipelines, memory footprint, filter programs, Apache Storm, Apache Kafka, Apache Hadoop streaming

1.10.3 Extending applications

This section explains why Rust is useful for extending applications written in dynamic languages and gives two examples of its use.

• Safer Dynamic Language Extensions: Explain why Rust is suited to extending programs written in dynamic languages, including the risks associated with tightly integrated C extensions.
  Why it matters: It shows why Rust can be appealing even when the rest of an application uses another language.
• Real World Rust Rewrites: Describe how Sentry and Dropbox used Rust in existing applications and what benefits they reported.
  Why it matters: These examples show that Rust can improve particular components without replacing an entire application.

Key terms: dynamic language, JNI, C extensions, Erlang/Elixir NIFs, memory leak, Sentry, Dropbox, CPU-intensive components, file synchronization engine, correctness

1.10.4 Resource-constrained environments

This subsection explains why Rust is appealing for network-connected devices with limited resources.

• Rust for constrained devices: Explain why Rust is a promising choice for IoT firmware: network-exposed devices face attacks on input-parsing code, firmware updates are infrequent, and Rust can add safety without runtime costs.
  Why it matters: It connects Rust’s safety and low runtime cost to the practical risks faced by IoT devices.

Key terms: Internet of Things (IoT), input parsing code, firmware updates, runtime costs

1.10.5 Server-side applications

This section shows that Rust is used for server-side applications and for services that support them, with examples from registries, databases, and search.

• Rust server-side uses: Describe the kinds of server-side software written in Rust, including applications that serve web traffic or support business operations and services such as databases, monitoring, search, and messaging systems.
  Why it matters: It shows that Rust’s server-side role extends beyond web applications to the infrastructure they rely on.

Key terms: server, services, databases, monitoring systems, search appliances, messaging systems

1.10.6 Desktop applications

This subsection explains that Rust can be used to build user-facing desktop software.

• Rust for user-facing software: Explain that nothing inherent in Rust’s design prevents its use for user-facing software, and give Servo or games as an example.
  Why it matters: Rust’s systems-programming focus does not rule out applications people interact with directly.

Key terms: user-facing software, Servo, games

1.10.7 Desktop

This subsection explains why Rust may appeal to desktop application developers and predicts how its adoption could grow.

• Rust’s desktop application appeal: Explain why the author sees Rust as promising for desktop applications and who is expected to adopt it first.
  Why it matters: It connects Rust’s qualities to a practical kind of software that remains challenging to build.

Key terms: desktop applications, deployment, rigor, ecosystem

1.10.8 Mobile

This subsection explains how Rust can run on phones through the native-application interface rather than a platform’s usual development path.

• Rust on mobile platforms: Explain how Rust applications can run on phones despite the platforms’ usual development paths.
  Why it matters: Rust can be an option for phone applications without adding runtime overhead through this interface.

Key terms: native applications, C++, runtime cost

1.10.9 Web

This section presents WebAssembly as a way to bring Rust projects to the browser.

• Rust in the browser: Explain how WebAssembly could enable Rust projects to run in browsers and how much additional command-line work the section says porting requires.
  Why it matters: It shows why the browser is a potential destination for Rust projects, despite JavaScript’s established role there.

Key terms: WebAssembly (Wasm), compiler target, Rust

1.10.10 Systems programming

This subsection presents systems programming as a central use of Rust, illustrated by substantial software projects and industry efforts.

• Rust in systems programming: Explain why systems programming is presented as a central use of Rust, and give examples of substantial programs or projects built or explored with it.
  Why it matters: These examples show the scale and kinds of systems work for which Rust is used.

Key terms: systems programming, compilers, operating systems, low-level components

1.11 Rust’s hidden feature: Its community

The section presents Rust’s welcoming community as an important part of the language’s success.

• Rust’s welcoming community: Explain why the section calls Rust’s community a hidden feature: growing a programming language takes more than software, and the Rust team has fostered a community marked by courtesy and respect.
  Why it matters: The people around a language shape the experience of learning and using it.

Key terms: community, courtesy and respect

1.12 Rust phrase book

Defines five common Rust phrases that express the community’s values and the language’s promises about performance, concurrency, compatibility, and abstraction.

• Inclusive systems programming: Explain what “Empowering everyone” means in the Rust community.
  Why it matters: This phrase captures who the Rust community wants to include.
• Speed without runtime penalties: Explain the claims behind “Blazingly fast” and “Zero-cost abstractions” as stated here.
  Why it matters: These phrases express the section’s claim that Rust’s safety and features need not come at the expense of speed.
• Fearless concurrency promise: Explain what the phrase “Fearless concurrency” claims about concurrent and parallel programming.
  Why it matters: The phrase identifies error prevention as the reason Rust describes concurrency as less daunting.
• Long-term code compatibility: Explain the intended compatibility promise behind “No Rust 2.0.”
  Why it matters: This phrase expresses Rust’s intended reliability for code maintained over decades.

Key terms: Empowering everyone, Blazingly fast, Zero-cost abstractions, Fearless concurrency, No Rust 2.0, semantic versioning, backward-incompatible

1.13 Summary