I have to admit that Rust is now one of my favorite languages, especially as I was learning it simultaneously to taking CS: 212, rated the most challenging CS class at Stanford, where I had to implement a Unix kernel (threads, syscalls, virtual memory, file system, cache, etc.) in C. While a really challenging project that I should write about at another point, there was many instances where I could simply compile code that to a certain extent looked like this:

struct thread* main_thread = malloc(sizeof(struct thread));
// setup the thread!
char* name = thread->name;
free(thread);

// time passes
printf("thread %s", name);

Ouch. Kernel panic.

Every time I debugged a simple semantic misunderstanding I had with the compiler like this, I would ask myself why the compiler would let me do this to myself, simultaneously muttering

“Rust would never let me do that.”

The rust compiler became the invisible mother that would scold me every morning that I didn’t make my bed. It made me think about the code I was writing, before I even hit the build button. I knew I would get hit by the proverbial red-error flip-flop.

The paradigm of ultra-strictness and genuine helpfulness that the compiler offers has made be grateful for the deep insights that modern compilers give to developers and makes me genuinely look over each warning (both in C and in Rust).

I also underestimated how beneficial a type system can be for not just memory safety, but also in functionality. For example, the serde package quickly allowed for the serialization/deserialization of most structs I made by simply tagging the definition with a #[derive(Default, Deserialize, Serialize)] macro. This enabled me to parse HTTP requests with ease, only needing a few lines of simple, readable code. On the other hand, the solution to serialization and deserialization is a non-obvious solution in Python or Javascript; everything is just some object, and its up to you as a developer to ensure exactly what object that is. Of course, there are ways to serialize and deserialize in all languages, but in Rust the solution is obvious, practical, and simple.

I hope to keep seeing the Rust community grow and hope that the growth of the language keeps pushing the frontier of development (especially for async/await ). I really hope I can do more web development with Rust in the future, building robust micro-services that can perform well with limited resources, and scale to infinity. Cheers to Rust in 2023!

Sometimes bleeding edge really does mean bleeding

The biggest issue I encountered with Rust is in the async department. One of the primary goals of my development this quarter was building a way to separate the frontend GUI from the backend data source providing the logging details and metadata. This would allow a server with a larger memory pool to be able to load a multi-gigabyte log into memory for quick access but leave the frontend with a smaller memory footprint, small enough to be quickly loaded as a wasm web-app. This meant creating a datasource that was able to make HTTP requests to fetch data. Easy enough, right? Rust has plenty of production-ready networking libraries like actix (our server framework), reqwest (our initial frontend framework), tokio, hyper, or even the built in http module.

I quickly scaffolded out a prototype implementation of our DataSource trait (keep this word in mind) that would simply make an HTTP request, and then serialize the response into our data types using the serde package. We utilized the blocking feature of reqwest to create a synchronous HTTP request. This should not be utilized for a real world workload for multiple reasons:

Since we only have a single thread in our application, any blocking requests we make will stall all other code from running, including the renderer that is responsible for generating the next frame.

Users with a slow internet connection would experience multi-second lag between each frame that made a request, and there are many requests! ❌ Unacceptable solution ❌

I only tested the client/server dimension of our app through localhost which essentially provides a 0-latency, infinite bandwidth fabric between services, I experienced simultaneous frame renders that I couldn’t distinguish from the data-native version of the app.

Given this situation, it made since to try to implement an async approach to data loading. Sure enough, all the HTTP libraries already use the async approach by default (blocking was a feature I added), so it made since for a datasource to produce a Rust Result which is similar to a Promise in JavaScript. However, as soon as I tried to return a Result, I got a blaring error from the compiler: error[E0706]: trait fns cannot be declared async

Sure enough the official docs confirmed this:

Currently, async fn cannot be used in traits on the stable release of Rust.

Ouch. I quickly looked for workarounds but the two options were either:

• use a hacky external dependency with a macro #[async_trait to apply a wrapper to the trait functions.
• Upgrade to the nightly version of the rust toolchain, which has just added (November, 2022) support for async functions in traits.

The second option seems good right? Async is relatively new for Rust so it would make since that the core developers are still working on supporting everything. However there was one major caveat: If we apply this new toolchain and its new #![feature(async_fn_in_trait)] macro, we wouldn’t be able to create a dyn DataSource object, which is a way of telling the compiler that the size of a trait is not known at compile time. To be able to apply dyn, a trait must be “Object-safe”, but the new macro voided the object safety that our app needed to function. It seems like the bleeding edge of Rust killed this feature, (for now).

Wasm Troubles

You might ask:

“Well synchronous isn’t that bad, right? It still WORKS!”

Sure, however I ran into an immediate issue when trying to compile prof-viewer with the target platform being WebAssembly.

When compiling I got vague errors of HTTP libraries missing or using unsupported and after doing some quick research, I immediately saw why: Many Rust libraries only support their async functions in Rust through the WASI interface. This is because the WASI interface enables HTTP through the fetch interface in native JavaScript. If you recall, fetch is an asynchronous function, and therefore is also an async function when ported through WASI. Ouch, I am back at the same problem I walked through above. Well maybe there is a way I could spin up a separate thread to handle the async request, and then apply the returned response in an independent fashion from the synchronous render thread. The issue: threads are complicated/non-existent in Rust as well. The traditional idea of a thread does not exist at all in Rust. In JavaScript, the tangential idea of a thread is a “web worker” which enables asynchronous execution of code, independent from the main JS thread. This is supported through the WASI interface, but provides an extremely complicated and low-level abstraction for developers trying to integrate this into their WASM-compatible codebase.

For example, the simplest web-worker WASM example I could find (source: https://www.tweag.io/blog/2022-11-24-wasm-threads-and-messages/) is 4 months old (this is also bleeding edge for WASM)

// A function imitating `std::thread::spawn`.
pub fn spawn(f: impl FnOnce() + Send + 'static) -> Result<web_sys::Worker, JsValue> {
  let worker = web_sys::Worker::new("./worker.js")?;
  // Double-boxing because `dyn FnOnce` is unsized and so `Box<dyn FnOnce()>` is a fat pointer.
  // But `Box<Box<dyn FnOnce()>>` is just a plain pointer, and since wasm has 32-bit pointers,
  // we can cast it to a `u32` and back.
  let ptr = Box::into_raw(Box::new(Box::new(f) as Box<dyn FnOnce()>));
  let msg = js_sys::Array::new();
  // Send the worker a reference to our memory chunk, so it can initialize a wasm module
  // using the same memory.
  msg.push(&wasm_bindgen::memory());
  // Also send the worker the address of the closure we want to execute.
  msg.push(&JsValue::from(ptr as u32))
  worker.post_message(&msg);
}

#[wasm_bindgen]
// This function is here for `worker.js` to call.
pub fn worker_entry_point(addr: u32) {
  // Interpret the address we were given as a pointer to a closure to call.
  let closure = unsafe { Box::from_raw(ptr as *mut Box<dyn FnOnce()>) };
  (*closure)();
}

Followed by an equivalently opaque, polyfill-esque JavaScript code to import the WASM binding:

importScripts("./path/to/wasm_bindgen/module.js")
self.onmessage = async event => {
  // event.data[0] should be the Memory object, and event.data[1] is the value to pass into child_entry_point
  const { child_entry_point } = await wasm_bindgen(
    "./path/to/wasm_bindgen/module_bg.wasm",
    event.data[0]
  )
  child_entry_point(Number(event.data[1]))
} 

Only to imitate the native version of channels in Rust (which is the traditional way of sharing messages across multiple threads):

let (to_worker, from_main) = std::sync::mpsc::channel();
let (to_main, from_worker) = std::sync::mpsc::channel();
spawn(move || { to_main.send(from_main.recv().unwrap() + 1.0); });
to_worker.send(1.0);
assert_eq!(from_worker.recv().unwrap(), 2.0);

Yikes! Hundreds of lines of low-level code simply to share an int between JavaScript and Rust asynchronously. The two kickers? You can’t code yourself out of this situation. First, you must compile your Rust project with many extra flags:

RUSTFLAGS="-C target-feature=+atomics,+bulk-memory,+mutable-globals" cargo build --target=wasm32-unknown-unknown --release -Z build-std=panic_abort,std

Then, you must

configure your web server with some special headers, because shared WASM memory builds on SharedArrayBuffer

This train of requirements doesn’t seem practical for your average Rust developer to have to juggle on top of the many other components of their stack they have to understand.

While these are my main roadblocks when working on this project, I had many smaller speed-humps with the Rust compiler. For example:

Some expressions like some_func(another_funcs_return()) would  give errors, saying that the value returned from another_funcs_return would be out of scope before the function returned. I would have to move this code into something like

let val = another_funcs_return();
some_func(val);

to satiate the compiler. While I am sure the compiler has a valid reason for this that is beyond my knowledge, it seems odd that the compiler forces this level of verbosity on developers.

I also ran into issues with lifetimes and mutexes. This is because the idea of a pointer is more opaque in Rust, as everything in Rust is abstracted into references and lifetimes. In this way, I wasn’t able to easily pass data between functions in different threads as I would have liked to.

Again, there is probably a good reason the compiler was complaining, but the solution as a beginner Rust developer was not obvious and seemed like a roadblock at times.

My last gripe has to do with the disk space required for development. I was extremely happy to hear about Yarn's Plug N' Play functionality that eliminates the need for node_modules/ because that would make a large chunk of repeated downloads and files for each NodeJS project I would work on. Cargo uses a similar structure to the Plug N' Play feature that creates a global environment cache for pacakges. This keeps directories clean and backups simple, however, I noticed that debug builds with Rust made node_modules look TINY.

A debug build would take about 1.5 GB for a mid-size project and a release build would be about 700 MB. If I were to be working on multiple projects simultaneously, my already filled-to-the-brim 256GB M2 Macbook Air would be complaining constantly. To solve this, you can easily run a cargo clean in each project. Or just get more storage (I am too cheap to pay $200 for 256 more gigs of storage). I wonder what the break down of those files are, but thats a topic for another post.

Garbage Collection

Because of Rust’s guaranteed memory safety, ownership model, and robust checks from the compiler, the language has no need for a garbage collector.

A garbage collector is a program that automatically frees up memory that is no longer being used by a program. It identifies and removes objects that are no longer needed, allowing the program to reclaim memory that can be used for other purposes. Garbage collection is used in Java and Python to manage memory automatically, but it can come with performance costs; ever so often, the program must be paused to reclaim memory that is not in use. Especially in a graphics context, that small delay may be unacceptable. If we are rendering frames to create a smooth view for the user and a garbage collector decides to pause even for a few milliseconds, our app may hitch around, which is obnoxious. Even if the garbage collector is in a different thread, this adds more overhead to the consumers CPU and uses more energy.

Search

In the context of prof-viewer, an expensive computation that I was afraid would cause bottlenecks was search.

Every time a user adds a character to the search box, I have to recompute the entire search state of the app. While it would be acceptable to have a small delay in the search and add a smaller loader / skeleton while the computation and search was being performed, this wouldn’t be as simple to create as if we were in event-driven model. I wanted to see what Rust was capable of so I decided to shoot for a 60+ FPS target even while searching through 100,000+ elements in state. That’s 6 million string searches a second! I ended up implementing search using the Aho-Corasick algorithm to build a finite-state machine based on the patterns that we wanted to match (i.e. each word the user was searching for).

This state machine would then be applied on each of the metadata strings for each task, detecting the number of matches in the state-machine. This allows us to run each title search in O(n) time. With this algorithm, Rust was able to provide a near instantaneous search for an entire profile with a large number of tasks on a single thread, all while rendering the GUI too. Mighty impressive!

TL;DR

Imagine if yarn, make, and a cousin of package.json merged into one behemoth of a stack. Welcome to cargo

This article is framed  as beginner guide to installing a basic Rust project as this process will expose most users to the most prominent and useful features of the Rust ecosystem.

Toolchain

First and foremost is the Rust toolchain, rustup. I mentioned this briefly in Week 3, but to add the toolchain to your computer, you can use a command like brew install rustup-init to install and setup the default toolchain.

Build Tools

With rustup comes rustc and cargo . The other language equivalents would be python and pip for Python, and node and npm for NodeJS (but neither are a compiled language like Rust). rustc is the native compiler for Rust and simply put, turns code into an executable. You can pass flags to enable optimizations and debugging symbols, just like in other compilers. You will not need to invoke rustc manually in most cases, as this is the job of cargo ! Cargo is the native package manager and build tool for Rust. A key component of the rust ecosystem are packages called “crates”, which represents projects written in rust that can be compiled. Every crate has a single Cargo.toml which is the equivalent to a package.json in a javascript project. Here is an example of a Cargo.toml:

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

[dependencies]
actix-web = "4"
clap = "2.33"
csv = "1.1"
derive_more = { version = "0.99", default_features = false, features = ["add", "display", "from"] }
flate2 = "1"
nom = "7"
num_enum = "0.5"
rayon = "1.5"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
legion_prof_viewer = { path = "/Users/adam/legion/prof-viewer"}

[profile.dev]
opt-level = 2
debug-assertions = true

In this .toml file, you can see that we define a crate metadata under the header [package]  such as the name, version, and schema. We also declare the dependencies of our crate, which utilizes a registry called crates.io (or can point to a local path, to link local development).

One notable feature of Rust crates is that they are compiled statically, which means that all of their dependencies are included in the final binary or library. This makes it easy to distribute and use Rust code without worrying about version conflicts or external dependencies.

One of the benefits of interpreted languages is that dependencies are loaded at runtime (i.e. Node just looks up a module every time you run your program). In a compiled language like Rust, dependency management becomes more complex, however Cargo does a great job of optimizing builds by only rebuilding the components that have changed since the last build. This saves a great deal of time since you don’t have to recompile 300+ crates in a medium-sized project every time you change a line.

Crate Features

Another feature of Rust crates is that they are typically designed to be highly composable. This means that they can be easily combined with other crates to create larger, more complex programs. A feature that I enjoyed about crates is it’s use of “features”. A feature is an optional include that you can make on a dependency to enable extra features. This is extremely useful for reducing the dependencies of your project. For example, a perfect use case of this feature was splitting server-side code from the frontend egui viewer. In the same crate, we provide both the server-side rendering features that a server would need (along with all the dependencies associated with that) as well as the egui GUI that we built. Cargo is smart enough to detect the dependencies that only exist under a feature and therefore not include them if the feature is not requested.

Neat Features

• Cargo.lock this lock file represents the dependency tree needed to build a project, and saves cargo vasts amount of computation and network lookups to download all the dependencies needed to build a project.
• Cargo manages multiple versions of the same crate to prevent conflicts.
• cargo test executes native Rust tests on a crate. TDD is baked into Rust!
• cargo doc generates static html documentation pages very similar to Python package documentation.
• Cargo can create a new project template with cargo new.
• Cargo has a built-in system for managing and publishing crates to the crates.io registry.
  

Once you have finished development on your product, deployment is the easiest part. You already are executing debug binaries locally to test your app, so you can simply bundle everything together with production-level optimizations with cargo build --release and you now have a working executable.

To deploy to a specific target (MacOS in my case), I found cargo-bundle to be extremely useful.

I was able to deploy prof-viewer as 5.7 MB a native .app. A more traditional way of deploying a desktop app would be Electron, which utilizes a chromium base to simply render a webpage as an app. This can lead to a several-hundred megabyte binary that users have to download for each app they download that includes Electron. Rust on the other hand is much more portable.

What’s E-gooey?

Egui is a lightweight, immediate mode GUI framework for Rust that is designed to be fast and easy to use. With 14,000+ stars on Github, Egui offers an impressive toolset of graphics tools for developers wanting to create graphical user interfaces with minimal effort.

I first found out about Egui from Elliott as that was what the base framework was for the existing prof-viewer codebase. After looking through the examples, I could see how the framework was especially useful for our “custom” needs as the rendering model is unique, the API was extensive, and the widget ecosystem had plenty of baked in features that we could use.

One of the most appealing features of Egui is its performance. Unlike traditional GUI toolkits, Egui does not rely on an event-driven model. Instead, it uses an immediate mode approach, which means that the user interface is rebuilt every frame. This approach has several advantages, including lower memory usage and faster rendering times.

Immediate Mode?

While most people are familiar with the DOM and JavaScript’s event-driven design, immediate mode might be a new concept, as it was for me. In the eye’s of JavaScript’s creators, the web-page was meant to be both static and interactable.

 99% of the time, the content and layout of a webpage stay the same, whereas the other 1% of the time is the user clicking, dragging, swiping, or adding some input the webpage. Only in the 1% cases does the website need to react and change. This reactive philosophy has driven web development for years (Ever heard of “React”?) and largely suits the needs of web developers.

On the other hand, more performance driven applications, like ours, needed the ability to render many frames quickly. This is even more so the case for game developers or visualization tools that need to make the screen appear as smooth as possible to it’s users (rather the jittery loading of a webpage).

We found that the typical JavaScript web libraries, while very well-supported, did not providing the flexibility we needed to handle stateful, GUI-like menus/buttons, and other desktop app-like features that we needed with a 60+ FPS view. Immediate mode + a high performance runtime like Rust, helps us deliver anywhere from 200-400 FPS while doing most activities inside prof-viewer. Sweeet!

This performance is able to carry over to the web as Egui supports WASM deployment (To learn more about WebAssembly, check out Week 5’s post).

Another advantage of Egui is its simplicity. The API is designed to be easy to use and understand, even for developers who are new to Rust or GUI programming. The framework provides a set of basic widgets, such as buttons, text boxes, and sliders, as well as more advanced features like layout management and event handling. Having to write immediate mode code, helped me think out of the box when rendering GUI layouts.

For example, when building an editable text field for the interval to display, I realized that I couldn’t simply apply the change to the interval each time the textbox changed.

If I want to set the start interval to “100 ns”, an immediate-mode approach would try to render every change: “1”, “10”, “100”, “100 “, “100 n”, “100 ns”. Every state but the last is invalid, so how do you program around this?

You can use buffers to store a temporary state as a user is writing something, then only apply the new state when the user is done modifying (i.e hit enter, lose focus on the textbox, etc.) The idea of buffering input while still re-rendering the page hundreds of time a second with old state was an interesting paradigm to pick up and made me think deeply about how this applies to user input validation in any input-driven context (e.g web form, search bar, etc.).

During our exploration of Egui, we found that the framework was well-documented and had an active community. The official website provides detailed tutorials and examples, and there are several third-party libraries and tools available for Egui development. Overall, we found Egui to be a promising Rust GUI framework that offers a balance of simplicity and performance. While it may not feel like it has every feature I would want, the codebase was very easy to jump into (especially thanks to the vscode rust plugin, rust-analyzer), and had enough flexibility in the desing of the API to craft our own widgets for our specific needs. Its lightweight approach and ease of use make it a good choice for many projects.

Under Elliott Slaughter, I am working on tooling for the Legion project which is a HPC programming system written to be used on large-scale supercomputers. With a supercomputer comes the overhead of debugging a supercomputer, which is where a large effort in collecting and visualizing terabytes of logs comes into play.

“Terabytes?” you ask. 100% I say, as you must consider the massive amount of scale a cluster can run at. Even if a single GPU produced 1MB of metadata/logs over the course of an hour, if you scale to 10000 GPU’s, you now have produced 10GB. You can also factor in that the GPU is not the only device running on a cluster, you also will have the CPU running tasks, memory channels being constantly rewritten to and flushed, framebuffers driving computational display output, etc. To throw an even larger wrench into the works, imagine a job running for a whole week instead of a whole hour. This create a multi-dimensional visualization task for the engineers that need to inspect, understand, and optimize the performance of such behemoth clusters. That’s where prof-viewer comes in. Originally a javascript based visualization tool, prof-viewer emulated the likes of a multi-device flame graph

Flame graphs are a way of visualizing dependent tasks on a timescale for the purpose of identifying bottlenecks, loops, and other code anomalies that may be unintended or ill-performing.  The goal of prof-viewer is to give an engineer a large magnifying glass to be able to zoom in on the state of a cluster running a job and inspect exactly how tasks behave across different machines.

Here’s a sample view of what prof-viewer looks like.

An engineer is able to get rich metadata on each task running with a tooltip hover, but are also able to stay zoomed out when understanding a jobs runtime.

The system is entirely built from Rust from the backend that takes raw log output and produces a proprietary format for displaying logs to the graphical user interface (which I will discuss next week, in Week 6). A primary feature that I worked on was developing a search feature that would allow the ability to quick find tasks pertaining to a certain keyword, and highlight them in the viewer. Since there can be a lot of data on the screen at once, it is important to have an accordion-style expansion of panels to hide the massive amount of 2D space tasks can take up. Regardless, a search should be able to query outside the bounds of your eye sight to give you clues towards a related task you are thinking about. The sidebar gives you a quick way to jump through the large hierarchy of nodes and devices that a task could be under.

It was really exciting to dive into a relatively verbose codebase that allowed for hands-dirty access to the UI and data structures that represent both the logs and the interface. Even though the features may be simple and intuitive to an end user, there was plenty of thought that went into the design of the data structures and querying/layout of the tasks to increase performance and reduce load on the backend.

If you have never heard of WebAssembly, maybe the best way to explain it is from the group that created it:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications. - source

Wow, that’s a mouthful, but also a really succinct way of describing the vast use cases and application of wasm. Let’s break this quote down.

• binary instruction format:  You may have guessed from the “Assembly” in its name, wasm is a compiled instruction format. Sweet, that means it can be deployed just about anywhere: supercomputer clusters, servers, browsers, Raspberry Pi’s, tiny microchips, etc. It also means that it can work with any instruction set: ARM, RISC, x86. This means you can access rich features of instruction sets, such as SIMD.
• for a stack-based virtual machine: Whenever I think of a VM, I think Docker, hypervisors, and kubernetes. However, you and I are probably forgetting the most popular VM in the world: your browser. As JavaScript is not a compiled language, it must be interpreted at runtime. Modern JavaScript engines use a JIT (just-in-time) compiler to run JavaScript whenever you load a webpage. These instructions are then executed inside of a virtual machine for every tab you have open. While JITs are extremely fast these days, nothing can beat feeding instructions directly to a CPU, which is exactly what WebAssembly gives a browser to execute.
• enabling deployment on the web for client and server applications: There are many interesting applications for WebAssembly outside of a zippy-fast environment for the web. For example, a popular wasm runtime for cloud native applications called WasmEdge claims to be "100x faster at start-up and 20% faster at runtime” than Linux containers. Consider the application of this fast startup for serverless functions, i.e. a literal “function” of code that runs as a webhook or API call that receives a request and returns a response all within one body of code. You could redesign a serverless datacenter to simply be a reverse proxy and a registry of executable wasm binary. When a request routes to a certain function, the proxy simply executes the binary function and returns the result.

So what does WASM look like?

The cool part is that WASM can be written in most compiled (and JIT!) languages: C/C++, Rust, Python, Go, Java, and more! Let’s look at an example:

At WasmFiddle, we can try out an online compiler for wasm. In this case, it is in C.

int main() { 
  return 42;
}

The compiled output should look familiar (that is, if you have seen assembly before).

wasm-function[0]:
  sub rsp, 8                            ; 0x000000 48 83 ec 08
  mov eax, 0x2a                         ; 0x000004 b8 2a 00 00 00
  nop                                   ; 0x000009 66 90
  add rsp, 8                            ; 0x00000b 48 83 c4 08
  ret                                   ; 0x00000f c3

The main reason behind using WebAssembly is performance and portability. However, to be portable (and also practical), WebAssembly must support native operations in whatever platform it is being deployed on. For example, in my use case, I was needing to create a REST API interface inside of a client that would be compiled to wasm. This is where the idea of WASI comes in. WASI stands for WebAssembly System Interface and allows for native bridging between non-wasm functionality, i.e threads, networking, filesystems, etc. and wasm binary. I was impressed with the fact that most HTTP libraries in the Rust ecosystem support WASM through a WASI interface (in my case, the interface was through the JavaScript fetch API). However, this system is not without it’s limitations, which I will discuss in more detail in Week 9.

Baby Steps

Installing any new tool or language is my first step in learning it locally. That way, any examples I find can be modified in an environment that enables my curious mind to comment out lines, refactor code to see if it still works, or allows me to interact with a compiler/debugger sooner rather than later.

That being said, my first step was to install the Rust toolchain. As a Mac user, I am blessed to have Homebrew which enables easy access to a rust installer:

brew install rustup-init

This command installs Rust Up which is the pseudo-official way of installing the official toolchains published by the Rust team. While I will dig more into Rust tooling in Week 7, this installer has given you access to 3 important tools:

• rustup: Lets you update, install, delete, and switch your default rust toolchains.
• cargo: Rust's package manager and build tool. Think npm, but for Rust.
• rustc: This is the rust compiler. You will learn to love/hate it. It's the equivalent of gcc to c.

Education

Since Rust is relatively new, the documentation for it is both a blessing and a curse. The blessing is that the Rust team has put together many "books" walking you through literally every part of the Rust language. The books are easy to read, straightforward, and instructive. However, it is also a curse because each chapter of the book is so descript and encompassing that even a tiny portion of a language, like variables, can take an hour to read and fully understand. For those with less time, there is also Rust By Example, an official book with a learn-by-example approach:

• Many coded examples.
• Great comments and annotations.
• A handy crab that explains why things don't compile.

This book is where I found a lot of use in copying and modifying examples in my local environment, which helped me understand why something would or wouldn't compile.

Let's walk through a basic example written out in Rust By Example to see what parts of Rust are unique at first glance! While hello world is trivial in Rust, let's bump up our example to the classic FizzBuzz:

// Unlike C/C++, there's no restriction on the order of function definitions
fn main() {
    // We can use this function here, and define it somewhere later
    fizzbuzz_to(100);
}

// Function that returns a boolean value
fn is_divisible_by(lhs: u32, rhs: u32) -> bool {
    // Corner case, early return
    if rhs == 0 {
        return false;
    }

    // This is an expression, the `return` keyword is not necessary here
    lhs % rhs == 0
}

// Functions that "don't" return a value, actually return the unit type `()`
fn fizzbuzz(n: u32) -> () {
    if is_divisible_by(n, 15) {
        println!("fizzbuzz");
    } else if is_divisible_by(n, 3) {
        println!("fizz");
    } else if is_divisible_by(n, 5) {
        println!("buzz");
    } else {
        println!("{}", n);
    }
}

// When a function returns `()`, the return type can be omitted from the
// signature
fn fizzbuzz_to(n: u32) {
    for n in 1..=n {
        fizzbuzz(n);
    }
}

Source: https://doc.rust-lang.org/rust-by-example/fn.html

We can see that there is many similarities to other languages you may have learned! Pheww, what a relief that you do not have to relearn all your keywords, conditional syntax, and import mechanics!

Let’s dig into a few lines of code in particular:

fn is_divisible_by(lhs: u32, rhs: u32) -> bool { 

• We can declare functions (in any order!) with the keyword fn (def in Python)
• -> leads to the return type, in this case a boolean, bool (Same as in Typescript)
• Variables and arguments have types. In this case, the variable lhs is a 32-bit unsigned integer, u32 .

if is_divisible_by(n, 15) {

• Conditions without any explicit need for conditional operators (e.g. && or || ) do not need to be wrapped in parentheses, however the body of a conditional or function is delimited by curly braces (just like in C).

    for n in 1..=n {

• For loops use the in syntax (just like Python), but have an interesting dot notation to identify ranges: .. for a non-inclusive suffix range, and ..= for an inclusive range (similar to Julia).

It is so interesting to see a new language like Rust build off of the best (IMO) parts of other languages that I already use and love. As a busy developer learning a new language for work or a student having to learn a new language for a class quickly, it’s reassuring to jump into the language and feel like you already have a large tool belt full of battle-hardened idioms that other languages pioneered decades ago. This is how I felt coming to Rust, and I quickly got up to speed on the functionality built into the base language.

There are more dimensions of Rust than I have room in this article to write but here are some other unique topics in Rust that a beginner might want to explore

• Traits
• Structs / Enums
• References, borrows, and lifetimes
• advanced control flow: match, collections, iterables
• Basic data structures: str, String, vec, etc.

Resources

I found these resources super helpful in learning Rust. Sometimes I needed to have a topic explained in a different format or context to truly see the intricacy and necessity of some of Rust’s features.

• The official Rust book
• The official “Rust By Example”
• The (un)official Rust book directories
• Doug Milford’s Rust Intro series on YouTube (extremely useful for more advanced topics)

So, hi! I'm Adam Siwiec, 21 years old and a senior studying computer science at Stanford University. I am originally from Rogers, Arkansas, where I grew up running cross country, lawn-mowing, and writing poetry. I grew fond of computers early, whether through playing Battlefield 2 with dad, witnessing my uncle's Flash website, or inspecting the code of Yahoo! Finance's graph to see if I could make my favorite stock (AAPL) go any higher. I quickly grew into an entrepreneurial mind, building websites for my P.E. coach and myself. I started a successful lawn-mowing business that offered me expendable income to build a P.C. ("mom, I will do homework on it too!"). I grew into scripting in my favorite video game (Team Fortress 2) and became interested in game-server hosting and Linux.

Soon enough, I was in high school competing in programming competitions and hackathons, studying Java and C++ in class, and working with NodeJS to host projects at home. I was (and still am) super interested in networking and virtualization, so I invested in an old Dell R610 1U server and an enterprise network card. I built up a home lab from scratch. Starting with a hypervisor, I built up a whole stack of network services ranging from routing my entire home's internet to running the Christmas tree limits from school.

While I love many things outside of tech, for the sake of brevity (and  topics for future posts!), I will teleport us to college. My passion for technology fueled my application to Stanford, and it was the paramount moment of my life so far to be able to attend. The access to a top-tier education, uplifting and ferociously curious colleagues that I can call friends, and adjacency to opportunities in industry and research have pushed me to pursue excellence in my craft and help hone what the bleeding edge of technology is. At Stanford, I study systems, ranging from distributed systems, parallel computing, and networking to A.I., blockchain, and cybersecurity. Most of my in-class programming work is in C/C++ and Python. C and C++ were thoroughly drilled into our heads early on to demonstrate fundamentals in a confined, "safe" environment, where as Python has been the primary tool for tackling more abstract, theoretical concepts in higher-level elective classes like CS 246: Mining massive datasets and implementing ray-tracing in C.S.: 148. Working in operating systems and higher-level systems classes has given me experience in exploring Assembly, implementing filesystems and threads, and creating stack-overflow exploits. While truly useful for learning, these projects tended to feel set up and dumbed down to limit time spent setting up and debugging.
On the other hand, I interned with a tech company every summer between high school and now, giving me a much more creative and open-ended way of pursuing software development. My first job was at J.B. Hunt, a Fortune 500 logistics company, where I helped build out a mobile app for their truck drivers to help automate logistics paperwork using geofencing, chatbots, and a voice assistant inside of React Native. The following year, I worked on modernizing an order and load processing system that scheduled tens of thousands of truckloads moving across the country daily, streaming data from multiple microservices to feed an Elasticsearch cache for faster order lookup, all in Java and Spring. During my sophomore and junior summers, I worked at NVIDIA, where I helped build projects inside of NGC (Nvidia GPU Cloud), a competitor to AWS/Azure in providing compute to companies and scientists needing enterprise A.I. infrastructure. Here I also got the full-blown Java experience, helping write and deploy microservices in Spring, but I also got an exceptional experience in testing, deploying to production with service-level dependencies, and business development. All these enterprise experiences helped me employ the sys-admin'y skills I've kept within the basement walls.

The combination of the two sides of my experiences in school and at work have led to that itch I mentioned in Week 1: I wanted to find a middle ground where I could build interesting and practical tools from scratch but without the low-level complexity, age-old idioms, and the slow-paced development lifecycles of the traditional languages I am learning at school. Rust, are you love at first sight?