PART III

Fearless Concurrency with Rust

Asynchronous Concurrency

In parts 1 and 2 of this series, we used multi-threading to hands CPU-bound loads. These are workloads that use all of the CPU-time you can give them, and can be sped up by dividing the calculations between cores in your system. Rust — and Rayon — provide great solutions for this type of workload.

In this part, we’re going to examine another form of concurrency: asynchronous code.

Note that asynchronous code does not mean multi-threaded. It’s quite possible to run an asynchronous program on a single thread and still benefit from its performance boost. Node.js is a great example of this approach.

Why Use Asynchronous Code?

Many workloads — especially in server programs — spend a lot of time waiting for other things. Your code may be waiting for a database to send it results, a file to open and process, or a network request to arrive. It’s certainly possible to spin off a thread for every request — and have that thread wait until a result arrives — but doing so can be very inefficient. Creating a thread requires server resources, and can be a relatively slow operation; the cost is measured in milliseconds, but on a heavily loaded server milliseconds can add-up quickly. You also can’t have more than 63,704 threads active at a time on Linux.

Asynchronous code uses a technique called green threads. Green threads (sometimes known as fibers) aren’t a full operating system thread: they represent a task and store a minimal amount of information about the task — and where it should send its result. Green threads may be (and often are) distributed between operating system threads — but they incur a significantly lower overhead than full threads.

How do Asynchronous Tasks Work?

An asynchronous task is a function marked with the async tag. When it executes, it runs until one of the following occurs:

• The task calls await on another asynchronous task.
• The task completes, optionally yielding a result.

Calling an async function doesn’t run it. It instead returns a Future. This represents a promise to coalesce into a result in the future — once you await the future’s result. When you call await, the future is added to your asynchronous green-thread scheduler, and the calling function sits idle until the future completes execution.

Consider the common scenario of a web user requesting frontpage.html from a server. If the requested page requires some content from a database, and some template application, the request goes through a number of steps:

Each await represents a time that the caller is idle: they are sitting doing nothing until another process completes. If frontpage.html is popular, managing this with a thread-per-task — with each thread spinning while it waits for a child task — quickly explodes into a huge number of threads. Worse, most of the threads would spend their life idling. Idle threads still have to be polled by the operating system scheduler — large numbers of idle threads can consume a surprising amount of CPU time!

Managing with asynchronous futures requires a significantly lower overhead as each task pauses (in a waiting state) until it receives results.

Build a Simple Asynchronous Web Service

Let’s use Rocket to build a simple web service that demonstrates asynchronous execution. There are several popular web frameworks for Rust; Rocket is a simple one to get started.

Create a new Rust project with cargo:

cargo init rocket-async-medium

Add Rocket to your dependencies in Cargo.toml:

We’re importing the json feature to help us mock (pretend to use) some database queries.

Now open src/main.rs and we’ll build a website. We’ll start with a main function, launching Rocket:

Rocket provides a convenient #[launch] macro that creates a main() function and performs initialization for you — before calling your rocket function. That’s all you need to start a basic web server with Rocket.

Loading an Index Template

We still need to define the index function:

There’s a few things to learn here:

• We use #[get("/")] to map the function to the website’s root.
• The function returns a RawHtml type — Rocket will accept a string, and ensure that the HTTP headers contain the correct content type.
• The function loads a file named index.html (we’ll write that in a moment), builds sections of the website with build_menu(), build_news() and build_footer() functions. It then replaces placeholders in the index file with strings returned from these functions.
• build_menu() and build_news() are asynchronous; build_footer is not. You can mix and match, so long as the calling function is itself asynchronous.

That’s a good representation of a typical templating process for a server-rendered website. All that remains is to build the content.

Make a new file named src/index.html and insert the following HTML into it:

If you’re familiar with HTML, this is very straightforward:

• The file is simple HTML.
• A style-sheet is defined inline, providing visual layout for the content.
• Three placeholders are present: !!MENU!!, !!NEWS!! and !!FOOTER!!. In the index() function above you are replacing these markers with site content.

Loading the Menu

Let’s build our menu. The menu will be a simple bar, loaded from a file. Create another file, named src/menu.html:

It doesn’t get much simpler than that! In src/main.rs , create a function to load it:

Again, this is quite simple: it loads the menu from disk and returns it as a string. Notice that it’s asynchronous — we’re using Tokio’s filesystem functions. This approach ensures that the function will quietly wait if there is any delay accessing the file — maybe because the server is busy.

Loading a News Feed

Now, let’s add some site content.

We’re going to pretend that we’re loading a news feed from a database. Instead of asking you to install a complete database system, we’ll store the current news feed in a JSON file. Create a file named src/news.json and paste some news into it:

This is a simple JSON file: it contains an array of objects, each of which contains a title and a summary.

Now go back to src/main.rs and add a function to asynchronously read this data:

We start by defining a structure that matches our news-feed format. Decorating it with #[Deserialize] allows Rocket (which embeds Serde) to decode JSON into NewsItem structures.

The build_news() function loads the news-feed file, and calls Serde to decode it. It then iterates the news array, using map and format! to transform it into HTML. The HTML for all items is then concatenated together with fold.

Finally — the footer. We’re going to always return the same string, and since we aren’t waiting on anything else we’ll make it a regular function:

Congratulations — you now have all of the elements required to run your webserver. Type cargo run and navigate to http://localhost:8000/. You should see your news site:

To recap, requesting this website:

1. Your web browser sends a request to 127.0.0.1 on port 8000.
2. Rocket receives the TCP connection and parses it.
3. Since “/” matches the route for index, Rocket calls your index function and awaits a response.
4. index calls fs::read_to_string to load the index.html template file and awaits a response.
5. index receives a response and calls build_menu (awaiting a response).
6. index receives the menu template and calls build_news (awaiting a response).
7. index combines the results, modifies the template and returns the HTML response.
8. Rocket re-awakens with the response and sends it to your web browser.

This is a lot of steps — but it’s very efficient. Each task pauses when it isn’t needed, consuming very few resources. You could easily serve hundreds of thousands of customers with your exciting news!

Improving Concurrency with Join

You may have noticed that some parts of index could run in parallel. The menu and the news don’t depend upon each other. Why not wait for both at once — Tokio can divide tasks between threads (transparently), so you may get a performance increase.

The join! macro executes all three futures (loading the template, building the menu and news feed) concurrently — and doesn’t wake up until all three have returned data.

When Tasks Block

All of the functions we’ve called have been async — they cleanly wait for another task to complete. Occasionally, you need to wait for a non asynchronous task — maybe a CPU bound task, or a device that doesn’t provide an asynchronous interface.

Directly calling blocking tasks inside your asymmetric function is a bad idea: the whole “future” pauses while it waits for a result. This can be very bad for performance; if you are running a single-threaded environment it can stall execution completely.

When you can’t avoid a blocking task, you can use Tokio’s spawn_blocking function as follows:

Using spawn_blockingwill spin your task off into its own thread — and pause your future until the thread returns. This approach keeps the other tasks running smoothly while your function executes.

Wrap Up

We’ve reached the end of the “Fearless Concurrency with Rust” series. In these three articles, we’ve covered:

• Using Rust’s threading primitives.
• Using Rust’s safety guarantees to avoid a bug that crept into similar C++ code.
• Using Rayon to make CPU-bound multi-threading easy.
• Using asynchronous execution in servers and other processes that spend most of their time waiting for other systems.

Rust lives up to its promise of fearless concurrency and offers a variety of methods to fit your needs. Please share in the comments how you are using concurrency in Rust.

Herbert Wolverson

Are you a Rust fan? You can save 35 percent on the ebook versions of Herbert’s books with promo code rust_2022 now through October 15, 2022. Promo codes are not valid on prior purchases.

• Rust Brain Teasers
• Hands-on Rust

Fearless Concurrency with Rust: Part 3 — Asynchronous Concurrency was originally published in The Pragmatic Programmers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part II

Fearless Concurrency with Rust

Threading

In part 1 of this series, we discussed how Rust uses lifetimes and the borrow-checker to save you from data races. We even compared a C++ program with a threading bug with an equivalent Rust program — and saw how Rust won’t let the buggy version compile.

In the second part of this series, we’re going to look at ways in which Rust can help with a common design pattern: breaking up a large block of calculations, diving them between CPUs, and combining the results. We’ll continue to use a deliberately inefficient function to find prime numbers in a set of inputs. This isn’t overly useful work, but it’s a good representation of common data-processing tasks. The function we’re using is the same as last time:

For each of the strategies we consider, we’ll require our program to:

• Create a vector containing the numbers 2 through 2,000,000.
• Filter the vector to contain only prime numbers, confirmed with the is_prime function.
• Print the number of prime numbers it found and the time taken to perform the calculation.

I’m running all of these on my work PC. It has a 12th generation Intel Core i7 with 12 physical cores (and 20 logical CPUs), 32 Gb RAM and fast M2 storage.

Single-Threaded Workload

As a baseline, we’ll start with a single-threaded version. We’re using Rust’s iterators to keep it as short and to the point as possible:

Using a single core, the calculation takes 712 seconds in debug mode (cargo run) — and 89 seconds in release mode ( cargo run — release).

That serves as a good baseline, but we can definitely do better than that!

Dividing and Threading with Native Rust

Using only native Rust (no external dependencies), we can make use of some Rust features to help us divide the workload. Let’s hard-code the assumption that I have 12 CPUs (otherwise we’d have to use the num_cpus crate — or equivalent — to discover that in a portable way):

This code starts by creating a vector of the numbers 2 through 2,000,000. It then uses chunks — a built-in function of Vec — to divide the candidates into 12 chunks. We can use into_iter() on the resulting chunks to iterate over each chunk.

chunk.to_owned() isn’t obvious; we “take ownership” of each chunk as we process it. This approach converts it from being a slice of references to candidates to a vector of actual numbers. In release mode, this is essentially free — the compiler optimizes away several memory copies. It’s still not as clear as I’d like.

Now that we have our own personal chunk — we spawn a thread that will return a Result<Vec<u32>> containing prime numbers from that chunk. We return the JoinHandle from each thread. A JoinHandle is a pointer to the thread that will contain the result when it finishes. You can call join on a thread to wait for it to finish.

At the end, we drain our vector of thread handles and combine the results. (Drain removes each item from the vector as it is processed. Since we won’t be reusing the vector, it’s a good way to avoid ownership issues).

This strategy offers a significant speed-up. It finishes in 123 seconds in debug mode and only 15 seconds in release mode.

Using Rayon

Rayon is a popular Rust crate that implements a lot of threading features. It offers a worker-thread pool, work stealing (an idle thread will take work from the pending queue), parallel iterators, and many other features to make multi-threading easy. The downside is that you are adding a dependency to your program.

You can enable Rayon by adding it to your program’s Cargo.toml file:

[dependencies]
rayon = "1.5"

The big advantage of using Rayon is that it greatly simplifies your code. You can make some tiny changes to the original single-threaded version and benefit from an immediate speed-up. Here’s the Rayon version:

Notice that we’re importing two features from Rayon: IntoParallelIterator and ParallelIterator. These are required to transform a range 2..2_000_000 into a parallel iterator and to perform the iteration in parallel. We don’t divide our candidates into chunks or worry about thread joining — Rayon takes care of all of that.

Rayon also retains all of the safety guarantees you expect from Rust.

Best of all? It’s even faster. It completed in 72 seconds in debug mode, and 8 seconds in release mode.

The Results

Let’s compare the results of the three strategies we tested:

In terms of complexity, the single-threaded version is shortest — followed by Rayon. The chunked version is more than twice the size of the single-threaded version.

Surprisingly, despite the added complexity — the chunk strategy is not the fastest. That prize goes to Rayon:

Rayon is only a little faster, but combined with the simplicity of using the library, we can safely say that for iterator-based combinatorial data processing Rayon is the clear winner.

Wrap-Up

Dividing workloads into threads with native Rust is a little complicated, but works very well. It offers a good performance boost over a single-threaded model. At 47 lines of code (including comments), it’s a lot more complicated than the single-threaded model — but you can be certain that it is fast and safe.

If adding a dependency to Rayon is acceptable to you, you can easily combine the simplicity of the single-threaded model with the sheer horsepower of a full-featured concurrency model. It’s even faster than the native Rust version and retains all of the safety features you expect.

In the final part of this series, we’ll look at the other concurrency system built into Rust: asynchronous execution.

Herbert Wolverson

Are you a Rust fan? You can save 35 percent on the ebook versions of Herbert’s books with promo code rust_2022 now through July 31, 2022. Promo codes are not valid on prior purchases.

• Rust Brain Teasers
• Hands-on Rust

Fearless Concurrency with Rust, Part 2 was originally published in The Pragmatic Programmers on Medium, where people are continuing the conversation by highlighting and responding to this story.

PART I

Safety

One of Rust’s selling points is Fearless Concurrency. Concurrent programming is often fraught with peril:

• Data races can occur when multiple threads write to the same data without the protection of either an atomic type or a locking mechanism.
• Lifetime issues can occur when a thread outlives a variable declaration. The variable may be destroyed by the parent, while the child thread still relies on it.

Let’s compare some Rust and C++ code, to see how Rust protects you from these issues.

Finding Prime Numbers

There are many ways to factorize a number and detect if it is prime. Some algorithms are very fast — but for this article we’re going to use a deliberately slow approach. A simple algorithm uses more CPU time, better demonstrating the benefits of multi-threading. We’ll use the following function to determine if a number is prime:

is_prime iterates from 2 to half the number and ensures that all of the iterations return a remainder (the % operator) other than zero when the tested number is divided by the iterator.

To be sure that it works, here’s a quick unit test that checks a list of prime numbers under 100:

Here’s an equivalent C++ function:

I kept it simple; range support isn’t in very many shipping C++ compilers yet — using an iota view from the C++20 standard would enable a similar iterator-based approach. The code is functionally equivalent, however.

Single Threaded Prime Detection

The following Rust program counts how many prime numbers it can find between 2 and 200,000:

This program finds 17,984 prime numbers in the range 2 to 200,000.

An equivalent C++ program looks like this:

This program also finds 17,984 prime numbers. So far, so good. Let’s make a data race!

Racing Data

Looking to speed-up our prime counting, we eagerly fire up some C++ std::thread objects to divide our workload between two threads:

This program compiles and runs. Visual Studio (my compiler) doesn’t show any warnings. The code has split the workload in two, spawning two threads — each covering half of the prime counting.

Unfortunately, it doesn’t work. The first time I ran it, it counted 17,983 prime numbers. The second time, it counted only 17,981! Threads are concurrently accessing count. Incrementing a variable is a three-stage process: you read the current value, add one to it, and store the result. There’s no guarantee that all of these steps have been completed independently of other threads — resulting in a data race.

Maybe a Rust version of the same code will work?

The Rust version of the same program won’t compile. It gives two errors:

• counter may not be mutably borrowed more than once.
• counter may outlive it’s borrowed value. A lifetime issue.

Rust has detected that your program is unsafe and prevents you from creating code that inadvertently gives the wrong answer.

Safe Multi-Threading

Here’s a safe version in Rust that both compiles and gives the correct answer:

There are three new concepts in this program:

• AtomicUSize is a special “atomic” type. Atomic types provide automatic protection against data-races. They are typically very fast, mapping directly to equivalent CPU instructions. Whenever you access an atomic type, you have to indicate the synchronization guarantee you need — in this case SeqCst provides the highest level of protection.
• Arc is an “atomic reference counter”. When you wrap a type in an Arc, you can safely clone it and move the clones between threads. Each clone is a pointer to the contained data. Arc guarantees that the underlying data won’t be deleted until every reference is done using it.
• The thread closures (inline functions) move their captured data. They are operating on clones of the counter Arc — so they all point to the same place.

Combining these concepts has protected us against both data-race and lifetime issues:

• Rust’s borrow checker is happy because data is not borrowed between threads: the Arc is cloned, safely sharing a pointer to the counter data.
• Rust’s data-race protection is satisfied that using an AtomicUsize cannot result in a data-race.

The result is a fast program that gives the correct answer every time.

Wrap-Up

Rust’s fearless concurrency guarantees saved us from a data-race! C++ didn’t warn about the error, it just gave incorrect results. Rust saved the day, by refusing to compile the incorrect code. In a large program, this could have saved hours of painstaking debugging.

Rust’s Arc and AtomicUSize types make for complicated-looking code. In the next part of this series, I’ll show you ways to tame the complexity and create fast, multi-threaded code that remains easy to read.

Herbert Wolverson

Are you a Rust fan? You can save 35 percent on the ebook versions of Herbert’s books with promo code rust_2022 now through May 30, 2022. Promo codes are not valid on prior purchases.

• Rust Brain Teasers
• Hands-on Rust

Fearless Concurrency with Rust was originally published in The Pragmatic Programmers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last year, I outlined a few options for Game Development in Rust. Rust is a fast-moving ecosystem; new and exciting options become available all the time. In this article, we’ll take a look at some of what’s new in Rust game development since the last article.

Why Use Rust for Game Development?

Rust is making inroads into the game development world, and some of its strengths are becoming clear. Rust addresses a number of pain points from other languages:

• Rust is a systems language — it runs close to the metal, compiling to fast, native code.
• Rust has no garbage collector — so your game won’t pause unexpectedly while the system cleans up your memory.
• Rust makes memory management easy — many common bugs (use after free, dangling pointers, many overflows) are caught by the compiler.
• Rust offers a consistent build interface and a consistent package user interface.
• Rust interoperates seamlessly with other languages via FFI.
• Rust offers fearless concurrency — data races trigger a compiler error, and thread control is built into the language. It’s easy to take advantage of every core in your CPU. With Bevy and similar engines, your program automatically threads your game logic.

Rust offers a solid foundation for game development — seen in the rapid evolution of new game engines that make use of these advantages.

Rust Game Engines

There’s some exciting news in the Rust game engine world. Let’s start with Fyrox, a powerful 3D engine.

Fyrox

Formerly known as RG3D, Fyrox is a rapidly developing 3D engine. It includes most of the features you expect from a modern 3D engine: an editor, scripting, lightmaps, scene-graphs, serialization, audio and more. It started as the engine for the author’s first-person shooter game — but now includes examples for making roleplaying games and more.

Another popular engine in Rust is Macroquad, focused on simple 2D game development.

Macroquad

Macroquad’s big selling point is that it is simple, efficient and minimal. Macroquad isn’t opinionated: you can store your game data however you like. The engine includes everything you need to make 2D games. It includes optional platformer physics and blazing fast sprite rendering.

Fish Fight is an open source platformer game, written with Rust and Macroquad.

Kajiya

Kajiya isn’t a complete game engine yet, but it’s pushing the bounds of what you can render in Rust. Using RTX, Kajiya offers global illumination and beautiful rendering. If you’re interested in the nuts and bolts of cutting-edge game development, Kajiya is a great place to look.

Bevy 0.6

The Bevy engine has released a new version! Bevy is a data-driven game framework. Everything is stored in a fast, easy-to-use entity component system. It features great 2D rendering, increasingly powerful 3D rendering, audio and a powerful plugin system for extending the base engine.

Bevy 0.6 includes a lot of changes. In particular, you no longer need to add .system to the end of every system when you are building your scheduler. The 3D engine now supports better, faster lighting with full shadows. Many bugs have been fixed. Bevy is moving towards a more regular release schedule. The full list of improvements is huge.

Rust in Godot

Rust’s interoperability with other languages (via FFI) is proving to be a killer feature. In the business world, Rust is seamlessly sliding into existing workflows — replacing the dangerous parts with safe, high-performance code. In the game world, Rust’s FFI support makes it easy to work with existing game engines.

The Godot-Rust plugin makes Rust a first-class citizen of the Godot infrastructure. Easily write heavy-duty scripting in Rust and attach it to your project in the Godot editor. Ideal for projects that require heavy computation behind the scenes, while still using Godot’s excellent framework.

More About Rust Game Development in 2022

I recently gave a talk about Rust Game Development to the Rust Wurzburg Meetup, which you can watch here:

Are you a Rust fan? You can save 35 percent on the ebook versions of Herbert’s books with promo code rust_2022 now through May 30, 2022. Promo codes are not valid on prior purchases.

• Rust Brain Teasers
• Hands-on Rust

Articles by Herbert Wolverson:

• How Long Is a String?
• Rustle
• Five Reasons I Love Rust
• Run Your Rust Games in a Browser
• Game Development with Rust
• Rust Structure Packing
• Hands-on Rust Bonus Content
• Trying Out the Rust Bevy Engine

What’s New in Rust Game Development? was originally published in The Pragmatic Programmers on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Rust Brain Teaser

Guess the output of the following program:

Try to guess what the output is before moving to the next section.

The program will display the following output:

Halló heimur is 13 characters long.

Discussion

Your eyes aren’t deceiving you — “Halló heimur” contains 12 characters (including the space). Let’s step back and take a look at how Rust’s String type works. The internal struct definition of a String is quite straightforward:

Strings are just a vector of bytes ( u8), representing Unicode characters in an encoding named UTF-8. Rust automatically translates your string to UTF-8. The encoding looks like this:

Your original string, “Halló heimur” consists of 11 ASCII characters (including the space) and one “Latin-1 Supplement” character: the ó. ASCII characters require 1 byte to encode, Latin supplements require two bytes.

Rust’s string encoding is smart enough to not store extra zeroes for each Unicode character. If it did, String would be a vector of char types. Rust’s char is exactly 4 bytes long — the maximum size of a single Unicode character. Char variables don’t represent a single ASCII character; instead, they represent a Unicode scalar value. The scalar value can represent a single glyph or modification to another glyph.

String Length

String.len() counts the number of bytes in the string’s backing vector. If a String was storing every character as a char, you’d expect Halló heimur to occupy 48 bytes of memory. Rust’s String isn’t storing characters; it’s storing a byte array representing just the bytes needed to output the stored text.

Not all UTF-8 characters require all 4 bytes to render. For example, a space requires only 1 byte (0x20) , while most Latin Extension characters use 2 bytes. The first byte ( 0xC3) indicates that the character uses the Latin Extension character region, and the second byte ( 0xB3 for ó) identifies the character.

The string Halló heimur contains 11 ASCII characters — each using 1 byte of memory — occupies 11 bytes. Add two bytes for the “ó” and your string occupies 13 bytes of memory.

Counting Characters

You can correctly count the characters in Halló heimur with the following code:

When you call my_str.chars() , you’re requesting an iterator that returns each element of the string represented as a char. Rust correctly deduces that there are a total of 12 glyphs — or Unicode scalar values — making up the string. The iterator passes each of them to your consumer as a 4-byte char. Even if a glyph only requires 1 or 2 bytes of memory, Rust will allocate all 4 bytes for the char type. Traversing the iterator uses very little extra memory. If you call collect() on the iterator — to create a vector of char data — the vector will consume 40 bytes of memory.

Use my_str.chars() to access individual characters in a String. It’s an iterator, so you can use nth, for_each and other iterator functions to find what you’re looking for. For example, you can access the 4th character in a string with my_str.chars().nth(4).

Impact of UTF-8 Sizing

Unicode string sizing can be confusing at times, which can lead to surprising results in your code. You need to be aware of the distinction between characters and bytes:

• When you’re validating string length, know what counts and what doesn’t. For example, if you only accept usernames that are 10 characters or less, you need to decide if you mean glyphs or bytes.
• When storing strings in databases, you need to remember to allocate enough space for non-English character set strings.
• When transmitting or receiving information to/from a remote API, you need to agree on a length standard for encoding strings in transit.
• If you’re writing a program for a memory constrained system, parsing Unicode string character by character can consume a lot more memory than you expected. The string love: ❤ is 7 characters long, requires 12 bytes of storage in a String — and 32 bytes of memory when processed as individual characters. This may seem like a small amount of memory, but if your reader enters the entirety of War and Peace into your program’s input box, per-character parsing may require more resources than you expected.
• When accessing individual characters in a string, it’s much safer to use chars as opposed to directly accessing the byte array. Characters are aware of Unicode boundaries — bytes are not. Printing the first 6 bytes of “Können” will only print “Könne”. Printing the first 6 characters will output the entire word.

Further Reading

• Characters
• String Length
• Unicode Symbol Reference
• Wikipedia UTF-8
• String Source Code

You’ll find this puzzle and more in Rust Brain Teasers from The Pragmatic Bookshelf. You can save 35 percent on the ebook versions of Herbert’s books with promo code rust_2022 now through April 30, 2022. Promo codes are not valid on prior purchases.

• Rust Brain Teasers
• Hands-on Rust

Articles by Herbert Wolverson:

• Rustle
• Five Reasons I Love Rust
• Run Your Rust Games in a Browser
• Game Development with Rust
• Rust Structure Packing
• Hands-on Rust Bonus Content
• Trying Out the Rust Bevy Engine

How Long Is a String? was originally published in The Pragmatic Programmers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Build a Wordle Clone in Rust

If you’re on social media, you’ve probably seen lots of Wordle results. Wordle is a simple, addictive game — and many people wish they could play more often. Let’s indulge our word-guessing cravings and build Rustle: a Wordle clone written in Rust.

Getting Started

To get started, we’ll create a new project and set up some dependencies.

Create a New Project

Open a terminal/command prompt, and cd to your preferred directory for creating new Rust projects. Enter the following to create a new project:

cargo new rustle

Cargo will build an empty “Hello, World!” project for you.

Set Up Some Dependencies

Rustle will require two dependencies:

• bracket-random will be used to generate random numbers. It’s a friendly wrapper over the rand ecosystem.
• colored will be used to print terminal text in multiple colors. Colored makes it easy to print colorful text on your terminal. For example "this is blue".blue() will automatically add the ANSI commands to the string to render the string in blue — and correctly restore your default color afterward.

In your newly created rustle project, open Cargo.toml and add these dependencies:

[dependencies]
colored = "2.0"
bracket-random = "0.8"

Let’s make these dependencies available within our program. Open src/main.rs and add the following to the top:

You can now access the colored’s commands (such as red()) directly by name. RandomNumberGenerator is available without qualifying it with a full path. We’ve also included HashSet from the Rust standard library — we’ll need it later.

Build a Word List

There are lots of word lists for games available for free, online. We’ll use one commonly found in a lot of different Scrabble-like games: https://www.wordgamedictionary.com/twl06/download/twl06.txt

Download the words file, and save it as src/words.txtin your project directory.

Take a quick look at the file:

TWL06 Scrabble Word List

aa
aah
aahed
aahing
aahs
(continues, there are 178693 lines!)

Notice a few things:

• Not all of the words are five letters long
• The top of the file contains a heading and an empty line
• The words are all in lower-case

All of that’s ok — there are plenty of valid words in there, and we’ll filter the words when we load them.

Let’s start by embedding the word list into our Rust program. Open src/main.rs. At the top of the file, add:

This line creates a constant — a variable that cannot change. It is loaded with the include_str! macro (built into Rust). include_str! loads the named file at compile-time, and embeds it into your source code. This step lets you ship the resulting executable file without also having to include the text file.

Sanitizing Input

Next, we need to create a function named sanitize_word. It’s never a good idea to trust user input (whether typed or from a word list), so we’ll perform a few steps to ensure that a string is a valid Rustle word:

This function operates as a function chain — each function reads the results of the previous function, gradually building a result:

1. trim() removes any spaces and non-printing characters (such as \n indicating the end of a line). It’s always a good idea to trim input — you never know what hidden data may be in there!
2. to_uppercase() converts the word to capital letters (U.S. English).
3. chars() creates an iterator over the string, returning each character in turn. Rust strings may contain Unicode, so it isn’t guaranteed that each character is of a fixed length. For that reason, it’s preferred to iterate over chars() rather than accessing the underlying data directly.
4. We call filter with a test that each character is_ascii_alphabetic. This step ensures that if some Kanji, Cyrillic, numbers of other characters have slipped into the input — they will be ignored.
5. Finally we collect the results back into a String and return it.

Now that we can sanitize potential words, let’s read them into a word list.

Building a Word List

It’s possible that you would prefer a Wordle-like game that uses a different length of word. Let’s support that! Next to the const you just created in src/main.rs, create a new constant specifying the desired word length:

Let’s make a function that examines every line in the word.txt file and returns a list of possible words in a vector:

This function also operates as a function chain: each line takes the result of the previous line and operates on it:

1. We start with ALL_WORDS — the entire words.txt file.
2. Split creates an iterator over the string, divided by a delimiter. We’ve picked \n — the newline marker. Subsequent calls are iterating over each line in the words.txt file.
3. We use skip to pass over the title and empty line at the beginning of the file.
4. Map is used to transform data. Calling map(sanitize_word) calls sanitize_word on every word we’re iterating. This step ensures that they are valid words.
5. We then filter with a closure (inline function). Filter retains entries for whom the closure returns true — in this case, if the sanitized word length equals our WORD_LENGTH constant.
6. Finally, collect places all of the remaining words into a vector of strings. Rust is able to deduce the type of vector Vec<String> from the function signature.

This function builds an entire list of valid words. If you’re sticking with the default of 5, it will build a list of 8,938 possible words.

Customize Your Rustle Game

You may not want to play strictly by the Wordle rules. Maybe you’d like more guesses or words of a different length. Let’s accommodate this feature by adding a few constants to define the game parameters:

You can change these values and recompile the game to play Wordle according to your own rules.

Building a RustleGame Type

We’ll encapsulate much of the Rustle game inside its own type. Let’s start by defining the type itself, which needs to hold the data we’ll need for the game logic:

This is a pretty straightforward structure. It contains the dictionary (available words), the chosen word, a set of guessed letters, and a list of all of the guesses the player has tried so far.

Setting Up the Game

Let’s create a constructor for RustleGame that sets up a dictionary and selects a word. You’ve already written the functions required to make this work; this step wraps them and sets up the RustleGame state:

This function creates a RandomNumberGenerator from bracket-random. It then builds the dictionary, using the word_listfunction you created earlier. A word is randomly selected from the dictionary and placed into the word variable.

Displaying Guesses

One of the joys of Worlde is the clear, attractive set of colored blocks that display your progress as you try to guess the chosen word. Some simple rules are applied to guesses:

• Letters that are both in the chosen word, and in the correct location are displayed in green.
• Letters that are in the word, but are not in the correct place are displayed in yellow.
• Letters that aren’t in the word are printed in grey and added to the list of letters you don’t need.

The following function (part of RustleGame) accomplishes this:

This function starts by iterating all of the stored guesses (from self.guesses). It uses enumerate to add numbering, and each display line starts with “1:” to indicate the guess number.

Each guess is then broken into characters with char, and each character is evaluated. If the word is in the right place (checked by using nth against the selected word), it prints in green. If it is in the word but not in the right place (evaluated with any), it prints in yellow. Otherwise, it prints in regular console colors.

Letters that aren’t in the target word are added to guessed_letters. Because this is a HashSet, you don’t need to worry about duplicates: the set stores a given value only once.

Printing the List of Wasted Letters

Wordle helps you out by showing you which letters you’ve used that aren’t in the target word. Since we’re storing these in guessed_letters, we can do the same. Add this function to RustleGame's implementation:

This function starts by checking if there are any invalid letters. If there aren’t, it does nothing — there’s no need to display an empty list. Otherwise, it prints a list of letters from the guessed_letters set.

Asking the User to Make a Guess

Let’s create a function that asks the user to make a guess at the word. It needs to check that a guess is of a valid length and in the dictionary. Add the following to RustleGame's implementation:

The function begins by prompting the user to enter a word of WORD_LENGTH letters. It’s always a good idea to prompt the user before waiting for input; otherwise, they may sit and stare at the program unsure of what to do.

Then the function calls the display_invalid_letters function we created above. We’re not constraining the user’s ability to reuse letters, but this should give them a useful hint.

Next, we loop on valid_guess. We’ll set the variable to true when a guess is of the right length and in the dictionary. We use stdin().read_line to read a guess from the terminal and immediately call sanitize_word on it. Finally, we check that the sanitized word is of the correct length — and in the dictionary. If those are true, we set valid_guess to true and continue; otherwise, we ask the user to try again.

Did We Win?

Our last function in RustleGamewill determine if the game is over:

The is_game_over function returns true if the game is over, and false if it should continue. It checks to see if the most recent guess is correct, and congratulates the player if they won. If the player has run out of tries, it ends the game with a message telling the player the correct word. Otherwise, it returns false.

The Game Loop

Finally, let’s make our main function glue all of this together:

We use a loop and break out of it if the game is over. The loop is running the functions we’ve built: it displays the guess board, asks for a guess, and checks to see if the game is over.

Run the game with cargo run and you can play Rustle!

Not bad for 120 lines of code! This game is a good example of how Rust’s iterator function and function chaining can help you create a fun game with very little code.

The full source code for the game is:

🧩 Have fun playing Rustle!

If you enjoyed this article and want to learn more about Rust, pick up Herbert Wolverson’s books from The Pragmatic Bookshelf. You can save 35 percent with promo code rust_2022 now through March 31, 2022. Promo codes are not valid on prior purchases.

• Hands-on Rust
• Rust Brain Teasers

Articles by Herbert Wolverson:

• Five Reasons I Love Rust
• Run Your Rust Games in a Browser
• Game Development with Rust
• Rust Structure Packing
• Hands-on Rust Bonus Content
• Trying Out the Rust Bevy Engine

Rustle was originally published in The Pragmatic Programmers on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Language That Addresses Pain Points of Modern Development

📚 Connect with us. Want to hear what’s new at The Pragmatic Bookshelf? Sign up for our newsletter. You’ll be the first to know about author speaking engagements, books in beta, new books in print, and promo codes that give you discounts of up to 40 percent.

I began my Rust journey after spending years writing C++. After finishing a particularly difficult project, I went looking for a solution to that project’s pain points. I’d heard about Rust, and tried using it to make some simple games. Several open source projects, a tutorial and two books later — I haven’t looked back.

Rust is built by developers, for developers — and works hard to provide both a consistent, useful systems language and a development ecosystem that addresses the pain points of modern development.

One: Dependency Management

C and C++ have many solutions for managing dependencies — Vcpkg, Conan, Hunter, and so on. All have their perks — but mixing and matching between them becomes a chore. In particular, sharing a project with others can require that recipients be willing to take the time to set up your favorite package manager — or manually install dependencies.

Rust’s Crates system provides a unified package management system across platforms. You can add dependencies as lines in your project’s Cargo.toml file — and the system does the rest:

[dependencies]
wgpu = "0.12"

This line downloads wgpu, a full-featured graphics system that supports DirectX, Vulkan, Metal, and WebGPU. It works on Mac, Windows, Linux, and other platforms.

A few other things that can make Rust dependency management great:

• Dependencies are statically linked — no DLL or library packages to ship/install with your project.
• Crates (packages) can compile C/C++ libraries and make them available to your Rust program.
• Semantic versioning is enforced, and you can easily pin your dependencies — and not worry about an update breaking your code.
• Your dependencies don’t have to come from the Rust Crates ecosystem. Cargo integrates with filesystem paths, git repositories, vendored dependency libraries, and more.

Rust makes it easy to stop re-inventing the wheel and benefit from premade packages in your projects. Rust also makes it easy to keep your dependencies up-to-date.

Two: Easy and Consistent Build Tooling

Another common complaint among C++ developers is the lack of a standardized build system. Many projects use CMake — which is very powerful, and quite intimidating.

Other projects use autotools, make, ninja, msbuild, meson, and so on. C++ has a plethora of choices, and everyone has their favorite. The C++ ecosystem works but can make switching platforms or collaborating with other developers painful.

Rust’s Cargo provides a powerful, consistent build tool:

• cargo new lets you create new application or library projects. It even defaults to setting up a git repository with a .gitignore file ready to use.
• cargo build compiles your project. You can specify --release to enable optimizations.
• cargo run runs your application. Again, --release enables optimizations.
• cargo check performs a quick build, finding errors.

Cargo’s build system revolves around a Cargo.toml manifest for your project. This is the same file that handles dependencies — the build system is highly integrated. Here’s an example that includes the complete Bevy game engine:

[package]
name = "bevy_mesh_example"
version = "0.1.0"
edition = "2021"

[dependencies]
bevy = "0.5"

Despite its simplicity, Cargo builds can be very finely controlled. You can gate dependencies behind feature flags, customize your build based on target platform, and patch dependencies to use source from Github or other repositories. Here’s an example of a dependency that compiles only if the target platform isn’t Web Assembly:

[target.'cfg(not(any(target_arch = "wasm32")))'.dependencies]
glutin = {version = "0.27.0", optional = true }

Coming from CMake, Cargo was a breath of fresh air. It’s easy to get started — and the features you need to ship a complex, cross-platform library are included out of the box. Cargo can even handle cross-compilation to other architectures.

Three: Safety First

Rust turns several classes of C/C++ bugs into compilation errors:

• Rust doesn’t have null pointers. You can wrap values in Option types if they may or may not exist, but if a variable promises to point somewhere — it will. Say goodbye to null-pointer exceptions/crashes.
• Rust tracks ownership of variables. Use after move bugs are impossible in safe Rust. Dangling pointers — where you’ve handed out a reference to an object and later deleted it — are also compilation errors.
• Rust protects against data races by enforcing synchronization across threads.
• Rust enforces RAII (Resource Acquisition is Initialization) automatically. A structure that creates data will free it when it is destroyed — unless you explicitly say otherwise. Memory leaks aren’t impossible (there are even commands for creating them, should you need to release memory/resources without deallocating them) — but the default is safety.
• Rust can be used to create potentially-dangerous code. This possibility is inevitable: you may need to interact directly with some hardware, may need to work with APIs from a less-safe language, or may need to use a mechanism that isn’t provably safe. Rust code can avoid many of the safety checks when wrapped in unsafe{ .. } tags. This tag is a good thing: you aren’t sacrificing potential usability, but you can isolate the potentially risky code to self-contained — and well-labeled — areas of code.

Coming from C++, I spent my first week with Rust cursing the borrow checker — the mechanism that enforces many of these safety features. After getting used to arranging my code to be borrow-checker friendly — I realized that the code was often clearer for it. Now, I instinctively find myself writing C++ with Rust idioms. Learning Rust has made my C++ safer!

Four: Fearless Concurrency

Rust promises fearless concurrency, promising to help you unleash the power of your CPU. Part of this capability comes from data-race protection: Rust enforces synchronization (and provides great synchronization primitives to use), making the most common threading bugs into compiler errors. For example, multiple threads that write to a shared variable are possible in both C++ and Rust. Rust will fail to compile if you don’t protect the shared object with an appropriate locking mechanism.

Rust also provides a great ecosystem for concurrent programming:

• The Rayon crate provides a work-stealing thread pool with support for job-based scheduling. Rayon offers great support for parallel iterators that can turn normal iterator-based code into multi-threaded performance monsters.
• Tokio and Async-Std provide very high-performance promise/future based asynchronous support for powerful servers.
• Many game libraries, such as Legion and Bevy, integrate Rust’s first-class multi-threading into their Entity-Component Systems architecture. I wrote my first Rust game without realizing that I’d enabled multi-threading support!

🔮 Rust concurrency is a large topic — I’ll publish an article examining Rust’s fearless concurrency claims in the near future.

Five: First-Class Iterators

Iterators are Rust’s great, unsung hero.

Similar to LINQ in C#, or the new C++ Ranges, iterators make it easy to ingest large amount of data — filter, map, and process it — and output it in the form you need.

Unlike iterators in some other languages, Rust’s iterators are deeply embedded into the language. The following code snippets do the same thing:

// Use a for loop
for i in my_collection.iter() { .. }

// Use for_each
my_collection.iter().for_each(|i| .. }

Add Rayon to the mix, and you can automatically add parallel processing (and benefit from the compiler telling you if you forgot to lock a shared variable):

my_collection.par_iter().for_each(|i| .. )

Iterators are designed to be chained together. For example:

let bug_summaries : Vec<BugSummary> = all_bug_reports.iter()
     .filter(|i| i.type == BugReport)
     .map(|i| BugSummary(i))
     .collect();

There are a lot of iterator functions available out of the box — enough to handle the majority of processing needs. Count, sum, map, fold, zip iterators (combining two data streams), reverse iterators —they’re all there. If you need more, Rust makes it easy to create your own iterators.

Wrap-Up

Rust is a very productive language. The Rust ecosystem makes it easy to work with dependencies and consistently build projects across platforms. The language protects you from the most common types of memory bugs and makes it easy to unleash the full power of your multi-core CPU. Iterators make crunching large amounts of data a breeze. Rust deserves StackOverflow users’ votes for “Most Loved” language.

6️⃣ Bonus perk six: the Rust community — they are a helpful, welcoming bunch. I was overwhelmed by their willingness to assist me while I made my first steps into Rust-land.

📣 Add your voice to the story. Tell everyone what you love about Rust in the comments.

If you enjoyed this article and want to learn more about Rust, pick up Herbert Wolverson’s book from The Pragmatic Bookshelf. You can save 35 percent with promo code rust_2022 now through March 1, 2022. Promo codes are not valid on prior purchases.

Hands-on Rust

Also by Herbert Wolverson:

• Run Your Rust Games in a Browser
• Rust Brain Teasers
• Game Development with Rust
• Rust Structure Packing
• Hands-on Rust Bonus Content
• Trying Out the Rust Bevy Engine

Five Reasons I Love Rust was originally published in The Pragmatic Programmers on Medium, where people are continuing the conversation by highlighting and responding to this story.

📚 Connect with us. Want to hear what’s new at The Pragmatic Bookshelf? Sign up for our newsletter. You’ll be the first to know about author speaking engagements, books in beta, new books in print, and promo codes that give you discounts of up to 40 percent.

One of the great things about using Rust and bracket-lib is that you can compile your games for the web.

Rust natively supports compiling to WebAssembly (WASM).

With a little bit of automated work to map WebAssembly bindings to native JavaScript, you can run your games in your browser.

🐉 Here’s Flappy Dragon in a Browser (Requires Chrome, Firefox, or Edge).

What Is WebAssembly?

WebAssembly began life as Emscripten, a project to build C++ for the web. Emscripten compiled your C++ programs into a binary format readable by JavaScript. A simple JavaScript run-time then ran your compiled code in the browser. Emscripten could wrap your C/C++ functions in a JavaScript header, allowing you to call high-performance functions from inside JavaScript. You could also use Emscripten to write full games.

Browser developers realized that Emscripten had the potential to extend the capability of browser apps and added back-end code to make WebAssembly run even faster. After a few rounds of development, WebAssembly was formalized as a compilation target. LLVM included it as a back-end, and Rust was one of the first platforms to provide first-class WASM support.

WASM does come with limitations:

• Threading works differently in a web browser and was largely disabled in response to the Specter line of vulnerabilities. So you can’t take advantage of the multi-threading built into Legion (and similar ECS systems). Your game will run in a single thread.
• Not every browser runs WASM well — it works great in Chrome and Firefox, but not so well in Safari.
• Large games can take a while to download.
• WASM doesn’t have a native filesystem, so loading assets from your web server is difficult. You can alleviate this issue by embedding your assets into your program.
• You need a web server. The server can be running locally, but most browsers refuse to execute WASM programs loaded locally with file: links.

So with those caveats in mind, let’s get started making your Rust games work in your web browser.

Making Rust Games Work in a Browser

Making Rust Games work in a browser requires several steps. We’ll need to do the following:

• Update bracket-lib
• Install the WASM toolchain
• Install the wasm-bindgen program
• Compile
• Embed assets for filesystem dependencies
• Build and bind
• Create a webpage

Update Bracket-Lib

The latest version of bracket-lib includes some changes to make WebAssembly programs run better. Update your dependency in Cargo.toml to read:

Now run cargo update to update your crates.

Install the WASM Toolchain

Rust’s cargo system natively supports cross-compilation. Cross-compilation allows you to compile programs for a platform other than the one you are currently using. For example, you can make Linux builds of your game without leaving Windows. WASM is supported as another platform, so you cross-compile your programs into WASM format. The official name of the WASM platform is: wasm32-unknown-unknown.

The Rust install tool (rustup) can install toolchains for you. Install wasm support on your computer with the following command:

rustup target add wasm32-unknown-unknown

Rust will download and install the current wasm32-unknown-unknown toolchain support for you.

Install Bindgen

Compiling to WebAssembly isn’t quite enough to make your programs work in your browser. You also need some JavaScript to connect your WASM program to the browser’s execution engine. You could create this by hand, but it’s really tedious. Instead, the wasm-bindgen program can do the work for you.

Note that when you update your Rust setup, you’ll want to repeat this process to get the newest wasm-bindgen tool.

You can install bindgen with the following command:

cargo install wasm-bindgen-cli

Compile Your Programs

You can now compile your programs to WASM with the following command:

cargo build --target wasm32-unknown-unknown --release

This step will download all of your dependencies, and compile them — alongside your program — into WASM format. The binaries will be optimized and almost ready to use. You still have a couple of steps remaining: handling filesystem dependencies and making some HTML to actually run your program in a browser.

Embed Assets for Filesystem Dependencies

WASM doesn’t provide direct support for your filesystem. Overall, that’s a good thing — you don’t want random programs on the Internet gaining access to your private files! It does make life a little more difficult when you need to load resources to support your program. bracket-lib helps get around this by providing a kind of embedding system: you can embed resources directly into your program, including them at compilation time. This process makes compilation take longer (and produces larger binaries), but it removes the need to create a web-based asset loading system.

bracket-lib automatically embeds terminal8x8 and vga8x16 fonts for you. The basic bracket-lib demos will work unchanged because of this, as will the ASCII version of Flappy Dragon. However, you probably need more than the built-in font files! You can add fonts with a two-step process.

In your main.rs file, outside of the main function, you can embed resources with the embedded_resource! macro provided by bracket-lib. This macro is a thin wrapper over the built-in include_bytes! macro. The path you provide must be the path Cargo will see when it runs the build. For example, the following line of code embeds flappy32.png from the FlappyBonus project:

This step includes your file in the program’s compiled output. The last step is to tell bracket-lib to include the file as a resource. At the top of your main.rs function, you need to link the resource (this step adds it to bracket-lib’s font system). Remove any .. from your path: this step uses the final path stored in the resource build. For example, to link the flappy32.png file we embedded a moment ago you would use:

Build and Bind

Now that your asset embedding is in place, build your project:

cargo build --target wasm32-unknown-unknown --release

Now create a directory named wasm-help (off of your project directory, next to src and in the same directory as Cargo.toml). You don’t have to name the directory that, but the examples in this article will assume that you did so. It’s time to create the JavaScript linking your program to the web browser. Run the following command (you may need to adjust the path to match your target directory if you are using workspaces):

wasm-bindgen target\wasm32-unknown-unknown\release\flappy_bonus.wasm --out-dir .\wasm_help --no-modules --no-typescript

If you look in your wasm-help directory, you’ll see that some files have appeared:

• flappy_bonus.js which contains JavaScript bindings for your program.
• flappy_bonus_bg.wasm which contains your WASM compiled code.

All that remains is to create a webpage to execute your program.

Create a Webpage

I typically copy/paste the following skeletal HTML into a file named index.html in the wasm-help directory and edit the text to match the game name:

This file loads the JavaScript file created for you and loads your WASM once the page has finished downloading. This step creates a sort of canvas on which the game can render. Upload your wasm-help directory to a web server (even a local one), and you can play your game in a browser.

Preparing the Hands-on Rust Dungeon Crawler — WASM Edition

The Dungeon Crawler from Hands-on Rust requires a few more changes: Legion needs to be put into single-threaded mode; you need to embed your tile graphics; and the later chapters that use data-driven definitions need to load the data from embedded resources.

We’ll work on the loot_tables example to get the finished game onto the web.

Make Legion Single-Threaded

Open your Cargo.toml file and find the dependency for Legion. Replace it with the following:

legion = { version = "=0.3.1", default-features = false, features = ["wasm-bindgen", "codegen"] }

This code disables Legion’s multi-threading and enables compatibility with wasm-bindgen.

Embed Tile Graphics

Just like you did with Flappy, you need to embed the graphics files. In main.rs (above fn main()) include the following:

embedded_resource!(TILE_FONT, "../resources/dungeonfont.png");

At the top of fn main() include:

link_resource!(TILE_FONT, "resources/dungeonfont.png");

Otherwise, your main function is the same:

Notice how the function is using terminal8x8but you don’t link it? The image is embedded by default in bracket-lib.

Load Data Files

In the Loot chapter of Hands-on Rust, you learn to use TOML files to define your data. Loading the definitions from disk offers great flexibility, but isn’t very WASM friendly — you need to embed the file in your program. Fortunately, Rust provides an include_bytes! macro to embed files in your code. You can combine this with a from_bytes function from the RON deserializer to include the file as part of your WASM build.

Open src/spawner/template.rs and replace the load() function:

The template.ron file will now be embedded in your WASM file, and the reader will load it from there.

Build the Dungeon Crawler

Next, you need to follow the same steps you used for Flappy. Create a wasm-help directory and add an index.html file to it:

Then build your WASM file:

cargo build --target wasm32-unknown-unknown --release

Now you can publish your wasm_help directory to your web server.

Here’s the Loot Tables example from Hands-on Rust, running in your browser:

Wrapping Up

WebAssembly is a great way to publish your games on the web. Rust has all the tools you need, and bracket-lib is designed to help you with the process. Now you can publish your game, too.

🏓 Be sure to send me a link if you publish your game to the web—I’d love to see what you come up with.

If you enjoyed this article and want to learn more about Rust, pickup Herbert Wolverson’s book from The Pragmatic Bookshelf:

Hands-on Rust

Also by Herbert Wolverson:

• Rust Brain Teasers
• Game Development with Rust
• Rust Structure Packing
• Hands-on Rust Bonus Content
• Trying Out the Rust Bevy Engine

Run Your Rust Games in a Browser was originally published in The Pragmatic Programmers on Medium, where people are continuing the conversation by highlighting and responding to this story.