Forem: Austin Tindle

Rust in 2021 - Rust for JavaScript developers

Austin Tindle — Wed, 14 Oct 2020 00:00:00 +0000

This post is a response to the Rust core team’s call for blogs. I'm a little late for the official deadline, but this post isn't so much about what I think should be in the 2021 edition of Rust as much as it's about reiterating my thoughts from 2019. Specifically, I think the focus for 2021 should be to continue making learning Rust easier and more accessible for non-systems programmers.

Back in November of 2019 (a lifetime ago, it seems), I wrote up some thoughts on some possible goals for Rust in 2020. The TL;DR of that post: we need more learning resources for newcomers to Rust, specifically resources that aren't the standard long-form writing like books and articles. I think Rust has made some fantastic strides towards this goal this year (and really, it will always be a moving goalpost -- we can always continue to improve), with a plethora of new and exciting projects that serve different groups of newcomers trying to learn the language.

I care about this goal because, back in 2017 when I first started trying to learn Rust, I didn't feel like there were a ton of resources that were made for me. And by me, I mean a web developer with no formal CS background and no real experience doing systems work. Back then the official Rust website supported that sentiment, with the stated goal that: Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. I didn't even really know what a segfault was, and I certainly couldn't tell you what a safe thread looked like. But a few things kept me interested, beyond sheer stubbornness and the words blazing fast.

First off, I'd already all but given up on learning C or C++. After struggling through several different learning resources, I was basically told straight up that with my background, it would be 3-5 years before I was done continuously shooting myself in the foot with C, and could then maybe call myself a novice. C++ looked to be a similar timeline, just to figure out how to write good, clean, modern code without again shooting myself innumerable times in the foot. Coming from JavaScript, I felt like there was too much that I didn't know I didn't know, and I couldn't figure out a good path out of the dark on my own. At that point, Rust seemed like it could be an alternative, even if it was just people on HackerNews who said so.

Another thing, somewhat related to the first, was that I truly didn't feel like a Real Programmer, having spent most of my professional time to that point working with JavaScript and PHP. This sentiment also probably had a lot to do with how often I was on the orange site, but at the time it was something I felt pretty strongly. Languages like Rust and C and C++ felt like doorways into a new world, with crazy things like compilers and pointers and memory and other dangers waiting on the other side, if I could just figure out how to get through.

And for these reasons, at least initially, I kept trying to learn Rust. I bought all 4 books available for sale at the time. I worked through the blog posts and series from others who were kind and industrious enough to publish them. I wrote some (very, very bad) compilers. I learned what a pointer is. But it hasn't been an easy process, and it hasn't been continuous either. I've gotten frustrated and quit more than once in the past 3 years, and those niggling thoughts about not being a good enough programmer were hard to shake at times. Even now, 3 years down the road (ironic, huh?), I still feel pretty novice in some areas, although looking back I can see really just how much I've learned from the process.

All of this to say, I don't think I'm the only JavaScript developer who has tried to learn Rust and struggled with it in the past three years. According to last year's survey, the second most common response to the question "Why not Rust" had to do with the learning curve. Of those respondents, the vast majority were web application developers (read: JavaScript, PHP, Ruby, etc. developrs). Of those who've tried to get over that learning curve, I think many of them were eventually turned away by the lack of diverse learning resources. And like I said before, as bad as 2020 has been for everything else, I think it's been a pretty great year for new Rust educational content. But, we can do better. And I hope we do better in 2021.

And by we, I really do mean we; they say you should build things that solve your own problems. So, I'm putting together a series of screencasts, exercises, and other resources aimed at teaching Rust to JavaScript developers. It's still pretty early on, but I hope to have some parts of it ready soon, with the whole project done sometime in January of 2021. If this is something you think would be awesome to have, just shoot me an email at tindleaj@gmail.com and I'll keep you updated.

A JavaScript Developer's Cheatsheet for Rust

Austin Tindle — Sun, 23 Aug 2020 00:00:00 +0000

Learning a new programming language is a great opportunity to learn new universal concepts and patterns that apply to all languages, not just the one you're learning. However, before you can get a handle on all the new stuff a language provides, first you have to figure out how to write the new language like you would write whatever old language(s) you know.

For the JavaScript developer, Rust offers a plethora of new and sometimes brain-bending concepts that exist in Rust but not in JavaScript. But in order to appreciate those concepts, first you have to get a handle on the basic syntax of the language. To speed up that process, you can use the JavaScript you already know to draw parallels to the Rust equivalents.

This cheatsheet provides some basic comparisons between JavaScript syntax and the parallels in Rust. It purposefully sticks to the basics that have decent parallels, to get you comfortable writing some simple programs in Rust.

Don't let the label of "Systems Programming Language" discourage you. Rust is an incredibly accessible language, in more ways than one. Use what you already know and learn some Rust!

Variables (bindings)

Rust variables are immutable by default. This is sort of like having all varaibles be const in JavaScript. JavaScript const is shallow, but Rust variables cannot be mutated at all unless you declare that variable mut.

// JavaScriptlet value = 10;let greeting = "Hello!";let counter = 0;counter += 1;

// Rustlet value = 10; // Cannot be changedlet greeting = "Hello!"; // Also immutablelet mut counter = 0; // This can be changedcounter += 1;

Printing Output

Rust's println! takes a string argument, which sort of acts like a JavaScript template string.

// JavaScriptlet name = "Austin Tindle";console.log(`Hello ${name}!`);

// Rustlet name = "Austin Tindle";println!("Hello {}!", name);

Functions

The main function in Rust is the entrypoint to the program, and other functions need to be called from main. In JavaScript there is no special entrypoint function.

// JavaScriptfunction weather() { console.log("Sunny!");}weather();

// Rustfn weather() { println!("Sunny!");}fn main() { weather();}

Conditionals

If/Else

// JavaScriptif (true === false) { console.log("Never happens.");} else if (false === true) { console.log("Also never happens.");} else { console.log("Perfection.");}

// Rustif true == false { println!("Impossible!");} else if false == true { println!("Still impossible!");} else { println!("This works.");}

Unlike in JavaScript, Rust does not have "truthy" values. It's strict static typing means that conditional expressions need to evaluate to a bool.

// Rustlet not\_a\_boolean = "I'm a String";if not\_a\_boolean { // Error: mismatched types expected `bool`, found `&str`}

Switch & Match

Switch statements aren't as widely used in JavaScript as if/else, but match statements in Rust are very popular. They aren't exactly the same, and match statements have a lot of powerful uses not available to JavaScript switch statements.

// JavaScriptlet stone = "Thunder Stone";switch (stone) { case "Thunder Stone": console.log("Jolteon!"); break; case "Water Stone": console.log("Vaporeon!"); break; case "Fire Stone": console.log("Flareon!"); break; default: console.log("Eevee!");}

// Rustlet stone = "Thunder Stone";match stone { "Thunder Stone" => println!("Jolteon!"), "Water Stone" => println!("Vaporeon!"), "Fire Stone" => println!("Flareon!"), \_ => println!("Eevee!")}

Importing Other Code Using Modules

In Rust, any function marked pub can be imported into another file. Any file that is not main.rs or lib.rs automatically gets a namespace based on its source file name. The mod keyword pulls in source files with equivalent filenames.

The use keyword brings nested items into the current scope, sort of like the import {x} from 'y' syntax in JavaScript.

// JavaScript// houston.jsexport default function launch() { console.log("Liftoff!");}export function abort() { console.log("Aborting!");}

// JavaScript// main.jsimport launch, { abort } from "./houston";launch();abort();

// Rust// houston.rspub fn launch() { println!("Liftoff!");}pub fn abort() { println!("Aborting!");}

// Rust// main.rsmod houston;use houston::{ launch };fn main() { launch(); houston::abort();}

Arrays & Vectors

Rust has a data type called 'array', but it's not the type of array we're used to in JavaScript. A growable list is called a Vector in Rust, and is available via

// JavaScriptlet languages = ["JavaScript", "TypeScript", "Rust", "HTML"];languages.pop();console.log(languages[0]);

// Rust// A shorthand macro syntaxlet mut languages = vec!["JavaScript", "TypeScript"];languages.push("Rust");// Full syntaxlet mut alphabets = Vec::new();alphabets.push("Greek");alphabets.push("Roman");println!("{} {}", languages[2], alphabets[0]);

Iterating

// JavaScriptlet utensils = ["Fork", "Spoon", "Spork", "Knife"];for (let utensil of utensils) { console.log(`Eating with a ${utensil}.`);}

// Rustlet utensils = vec!["Fork", "Spoon", "Spork", "Knife"];for utensil in utensils.iter() { println!("Eating with a {}.", utensil);}

Other Resources

Introduction to Rust for Node Developers A project-based intro to Rust.
RustConf 2020 - Rust for Non-Systems Programmers by Rebecca Turner Fantastic talk and an inspiration for this resource.
Rust for JavaScript Developers Blog Series by Sheshbabu Chinnakonda A great intro series on Rust for JavaScripters.

Are you a JavaScript developer trying to learn Rust? Send me an email at tindleaj@gmail.com. I'm working on stuff you'll be interested in.

Introduction to Rust for Node Developers

Austin Tindle — Mon, 22 Jun 2020 15:58:38 +0000

Originally published at tndl.me

In this article we will build a simple command line program that returns the word count of a file. This will essentially be a simpler version of the Unix utility wc, written in Rust. The goal of this article is to give an introduction to some core Rust concepts for readers who might be more familiar with web-focused languages such as JavaScript and Typescript. Therefore, the Rust code examples will be compared to similar code and concepts in JavaScrip or TypeScript. This guide also assumes no prior knowledge of Rust or related tools, but it does assume you have node installed on your machine already.

Notes
Setting up
- Project structure
- Running the project
- Tour of a "Hello World" program in Rust
The miniwc program
- Building a foundation
- Types
- Structures (struct)
- Implementations (impl)
- Enumerations (enum)
- Handling arguments
- Using Iterators
- Handling all Options
- Reading file contents
- Result and expect()
- Counting words
Conclusion
- Additional resources
- For learning
- Other

Notes

A couple of notes and assumptions:

No previous knowledge of Rust is assumed. We'll go over all of the necessary concepts as they come up, and I'll link to relevant content where I think more detail or rigor is needed. I think that knowing how the fundamentals of things work is important, and I think you should as well.
Roughly intermediate-level experience with JavaScript is assumed. If you're just getting started with JavaScript or haven't built anything non-trivial with it, you might want to save this resource for later.

Setting up

In order to get started, first we need to set up a new Rust project. If you haven't yet installed Rust on your computer, you can take a look at the official 'getting started' guide, or the first chapter of The Rust Book.

Once you have cargo available, go ahead and run cargo new miniwc --bin in a suitable directory.

Project structure

The logical next question is "What is cargo?". cargo is a direct parallel to npm in the Node ecosystem, in other words Rust's built-in package manager. You can view popular crates (packages) available at crates.io.

The cargo new miniwc --bin command tells cargo to create a new binary (able to run on our machine) Rust project named miniwc in the directory ./miniwc and set up the basic boilerplate project structure: Cargo.toml, src/main.rs, and a .gitignore.

Cargo.toml: Analogous to Node's package.json. This is where you put project information and declare project dependencies
Cargo.lock: This is a manifest managed by cargo, that tracks exact dependency versions. It is analogous to Node's package-lock.json.
src/main.rs: Our project is a binary project, meaning we can compile and run it on our machine. cargo creates a main.rs file as the default entry point for compiling our source code.
.gitignore: A standard git artifact, tells git what files to ignore from source control.

Running the project

That's it for the project structure, but what about actually running the code? In node, we have npm which allows us to define scripts such as start and test, and then run those commands via npm run start or npm run test. cargo gives us similar functionality. Running cargo run in our project directory will run our boilerplate project. Try it out, and you should see Hello, world! printed to your console.

You may have noticed a new target/ directory appear after you ran cargo run. This is a folder managed by cargo to store build artifacts and other dependencies of the compilation process. For a more detailed guide to cargo and an overview of concepts like the target/ directory, check out The Cargo Book.

Tour of a "Hello World" program in Rust

Let's take a moment to take a look at the auto-generated code within main.rs and draw some basic parallels from the JavaScript world to that of Rust:

File: src/main.rs

fn main() {
    println!("Hello, world!");
}

If we ported the above Rust program to JavaScript it would look like:

function main() {
  console.log('Hello, world!')
}

// Since `main()` isn't a special function in JavaScript,
// we have to invoke it if we want our code to run:
main()

If the distinction between compiled and interpreted languages is a bit hazy for you, take a look at this article for a more in-depth treatment.

fn is the function keyword in Rust, and main denotes to the name of the function. main is a special function name in Rust (as it is in other compiled languages like C) and it lets the Rust compiler know that this is the entry point of an executable program. () is the list of arguments. In this case there are no arguments, so the parentheses are empty.

The body of the main function is declared with { }, and represents its scope. Inside the body of main, we have println!("Hello, world!");. This looks like a function, but in fact is a macro. In Rust macros are denoted by the ! at the end of a keyword.

There is no great parallel for macros in JavaScript, but a simple definition is that macros are code that generate other code when the program is compiled. Rust will replace println! with code for printing to standard out that works for whatever computer architecture you're compiling the Rust code for. In my case this would be code for printing in macOS, but it might be different for you.

With the basic setup and syntax tour out of the way, we can move on to an overview of our miniwc program.

cargo isn't strictly necessary to create Rust binaries, it just provides some convenient tools and a bit of boilerplate to get you started. All you need to compile Rust projects is the Rust Compiler (rustc). Running rustc foobar.rs on any valid and correct Rust program will output an executable binary. Don't believe me? Try it with the code above!

The `miniwc` program

At the end of this article, we will have an executable program that takes a filename as an argument and returns the word count of that document.

Let's get into it.

Building a foundation

Before we can begin tackling the program requirements we've outlined above, there are several Rust concepts that we need to anchor to their counterparts in JavaScript. I'm a big advocate for understanding bedrock concepts, especially as you move past the beginner stage where you know how to get things done, but maybe not why you're doing them that way. I feel that Rust is a great tool to put the effort in and really learn, so before we go ahead and actually write the code for our program, we're going to explore a prelude of necessary concepts, step by step. These include:

The type system in Rust, and how it relates to types in JavaScript
Rust structs, their similarity to JavaScript Objects, and an overview on how to use them to provide structure to our code
Rust impls, the JavaScript Prototypal Inheritance model, and how we can create reusable functionality in our Rust code
A quick note on enumerations (enums)

There are some concepts here that may seem very foreign, but they all map to JavaScript concepts you probably already know and use regularly. If you have a good grasp on the above topics already, feel free to skip the next few sections. Otherwise, let's unpack them one at a time.

Types

Rust is a statically typed language, and therefore it expects explicit type annotations in the places in your code where it isn't obvious what the type of a value is. If you have experience with TypeScript, this concept should be familiar.

Two common ways you'll interact with types in Rust is through argument types and return types:

fn example_function(
  integer_arg: i64,
  string_arg: String,
  other_arg: OurCustomType ) -> String {
    // ---snip---
}

In the above example, we pass three arguments to our example_function, integer_arg with the type i64 (a 64-bit signed integer), string_arg with the type String, and other_arg with the made-up example type OurCustomType. These type annotations are denoted by the colon (:) following the argument name. After the list of arguments, there's an arrow (->) followed by String which signifies that this function will return a String value.

JavaScript is a dynamically typed language, which means all of the type behavior we have to specifically define in our Rust code is handled under the hood by the JavaScript runtime. JavaScript has primitive types like Number and String, but it doesn't require the programmer to be explicit about what types correspond to each value. JavaScript also doesn't allow the programmer to come up with their own types, like the Args type we saw previously in the args function signature. This is both powerful and limiting, depending on the context and use-case.

Structures (`struct`)

With the basics of types in Rust under our belts, let's take a moment to unwrap another fundamental Rust concept that we'll need going forward: struct. Rust, unlike modern JavaScript, has no concept of class and it doesn't have a catch-all, ubiquitous name/value collection like JavaScript's Object type. Instead, Rust allows you to associate fields and related functions using structures, via the keyword struct. This is somewhat similar to how objects are used in JavaScript. Compare the following two examples:

let message = {
  title: "Message title"
  body: "This is a message."
}

struct Message {
  title: String,
  body: String
}

let message = Message {
  title: String::from("Message title"),
  body: String::from("This is a message.")
}

Since Rust doesn't give you an arbitrary bucket of key/value pairs to work with (like JavaScript does with Objects), we first need to define the structure of our Message type, via the struct keyword. Note how in the JavaScript example, we just assign String values to the message and body keys. This is a very common pattern, and in some cases is extremely powerful and simple. In the Rust example, we have to be explicit about the types of values each field (note that in Rust, we call these key/value pairs fields, while in JavaScript they're called properties). Once we've told the Rust compiler what our Message fields will contain, we then can create a new Message with our specific field values.

Implementations (`impl`)

JavaScript uses an inheritance model called Prototypal Inheritance in order to allow for extending and reusing behavior in your code. Another familiar model that accomplishes something similar is the more traditional class-based model you may have come across in other languages like Java and TypeScript (JavaScript has class syntax, but it's just sugar over its prototypal inheritance model).

For the purposes of this project, you don't need to be super familiar with the ins and outs of Prototypal Inheritance or Object Oriented Programming, but if you're interested in diving in, Mozilla offers an in-depth treatment here. What we're specifically interested in is how JavaScript allows you to implement and reuse behavior, versus how Rust does it. Consider the following JavaScript example:

// Using JavaScript's `class` syntax because
// it's simpler for this example
class Message {
  send(content) {
    console.log(content)
  }
}

class PrivateMessage extends Message {
  send(content) {
    super.send('private: ' + content)
  }
}

var message = new Message()
message.send('hello') // hello

var privateMessage = new PrivateMessage()
privateMessage.send('hello') // private: hello

Here, we've modeled PrivateMessage as a Message. It inherits the send function we defined on Message, but we can change it to be specific for our PrivateMessage class. Rust has a different way of doing things. Let's take a look at the same idea, expressed in Rust:

struct PrivateMessage {}
struct NormalMessage {}

pub trait Message {
    fn send(&self, content: &str) {
        println!("{}", content);
    }
}

impl Message for NormalMessage {} // Use the default `send`

impl Message for PrivateMessage {
    fn send(&self, content: &str) {
        println!("private: {}", content);
    }
}

pub fn main() {
  let message = NormalMessage {};
  message.send("hello"); // hello

  let private_message = PrivateMessage {};
  private_message.send("hello"); // private: hello
}

In this version of the program, we've defined Message as a trait, which can be implemented by our other code. In other words, our PrivateMessage and NormalMessage structsNormalMessage uses the default send implementation that we define in the Message trait, while PrivateMessage implements its own version of send.

Hopefully this sheds a bit of light onto the basics of Rust inheritance (via traits and impl) versus JavaScript (via prototypes). If any of this still feels opaque, take some time to dive-in to the relevant sections in the Rust Book:

Enumerations (`enum`)

If you're familiar with TypeScript, then Rust's enum type is a close parallel. If not, enumerations are relatively straightforward: they define a type that can be one of several variants. For example, we can create an enum that represents the different types of common U.S. coinage like so:

enum Coin {
  Penny,
  Nickel,
  Dime,
  Quarter
}

And we can reference any single variant via:

let penny: Coin  = Coin::Penny;
let dime: Coin = Coin::Dime;

As you can see, both penny and dime are Coins (they have the Coin type), but we can get more specific and state the variant of Coin that each variable holds. In JavaScript

Handling arguments

Now that we've explored the necessary foundational concepts to understand and implement our miniwc program, let's get back to our miniwc program. As mentioned before, our program should:

Be executable
Take a filename as an argument
Return the word count of that document

Currently, our program does none of the things outlined above. When you execute cargo run from the command line, we still just see Hello, world! printed out. Let's take it step by step, and first handle taking a filename as an argument.

In node, one of the global variables made available to our programs during runtime is the process.argv variable. This variable contains all of the arguments passed to your node program. To take command line arguments and print them out using node, we could do the following:

File: main.js

for (let arg of process.argv) {
  console.log(arg)
}

If you save and run that program in the root of the project using node main.js hello, you should get three outputs. The first output is the program running our JavaScript code (in this case node). The second is the filename of the program being run, and the third is the argument we passed in.

Rust does not have a runtime environment like node, so how can we get arguments passed to our program?

Although Rust doesn't have a language-specific runtime environment, the operating system your Rust program runs on is technically a runtime. And luckily for us, the operating system provides a way to inject variables into programs. We won't need to get into the specifics of how that happens (and the potential pitfalls), because the Rust standard library provides an easy way for us to access the arguments passed to our program, via the std::env module. Similar to how process.argv works in node, the std::env module will allow us to get a list of arguments we can then use how we'd like.

In order to make the std::env module more ergonomic to use, we can use it at the top of our program like so: use std::env. The use keyword allows us to bring a module into scope. The std library is already available to our program, so we could just type std::env::foo_function every time we wanted to use something from the env module, but with use we can bring the env module directly into scope. A loose parallel between use to an equivalent in JavaScript would be taking a globally available function like global.console.log and setting it to its own variable for easier use, for example let log = global.console.log. With the env module in scope, we can now use the public function args, which exists in the env module.

This function will return a value with the type of Args. Args implements the trait Iterator, which allows us to iterate over the returned arguments. The function signature for args looks like so: fn args() -> Args.

Except for Iterator and the idea of iterating, these are all concepts we've explored in the last few sections, so now let's put them to work. Once you've added the use statement for std::env, your program should look like this:

File: src/main.rs

use std::env;

fn main() {
    println!("Hello, world!");
}

Let's enhance our program and print out all of the arguments that we pass in from the command line:

File: src/main.rs

use std::env;

fn main() {
  for arg in env::args() {
    println!("{}", arg);
  }
}

If the println! macro call seems a bit strange, you can dive deeper here, but you can also simply think of println! as similar to JavaScript template literals: anything between {} will be replaced with the variable you pass as subsequent arguments. Play around with it a bit to get a more intuitive feel for how it works.

Now let's run the program and pass it some arguments via cargo run -- hello world (we separate the commands passed to cargo and the commands passed to our program with --). You should get the following output:

target/debug/miniwc
hello
world

The first line of our output is actually the name of the program running, by convention. It's target/debug/miniwc because that's the binary created for us by cargo. If you compiled this project for release, or used rustc to compile, then the first item in the args() value would just be miniwc. On the next two lines we see the two arguments we passed in.

Our program now nominally supports passing in arguments via the command line. Now we're ready to do something with them.

Using Iterators

Let's start by binding the value of the first argument passed in by the user (ignoring the program path argument, which comes first) using the nth method on the Args type. Args is the type of the value returned from std::env::args(), and it implements the Iterator type, thereby inheriting all of the methods on Iterator. As per the Args documentation, Args specifically gives us an Iterator whose values are Strings.

One of the methods we get by inheriting from Iterator is nth, which returns the value of the Iterator item at the index given to nth. For example, env::args().nth(1) should give us the value at index 1 of the args_list. You can think of Iterator as sort of giving the properties of a JavaScript Array to any type that implements Iterator. Like Arrays, Iterators come with all sorts of useful methods.

With nth, we should now be able to grab the first argument passed to our program. Let's set that value to a variable, and try to print it out with the following code:

File: src/main.rs

use std::env;

pub fn main() {
    let filename = env::args().nth(1);
    println!("{}", filename)
}

After a cargo run -- hello, we see:

error[E0277]: `std::option::Option<std::string::String>` doesn't implement `std::fmt::Display`
 --> src/main.rs:5:20
  |
5 |     println!("{}", filename)
  |                    ^^^^^^^^ `std::option::Option<std::string::String>` cannot be formatted with the default formatter
  |
  = help: the trait `std::fmt::Display` is not implemented for `std::option::Option<std::string::String>`
  = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
  = note: required by `std::fmt::Display::fmt`

error: aborting due to previous error

An error! What happened?

Handling all `Option`s

The issue with our code is that nth doesn't return a String directly, but instead returns a type called Option. Option is part of an interesting feature of Rust: it has no null primitive type. Unlike most languages which have a null type (and very much unlike JavaScript which has null and undefined), Rust forces you to account for all possible values when working with operations that are influenced by things outside of the program's control, like accepting command line arguments or doing file I/O. To do this, Rust makes use of the Option enum, which can either be Some(value) or None. If the value is None, Rust makes you explicitly handle it, otherwise it will be a compile time error like we saw above. While this may seem overly rigid, this is one of the features of Rust that leads to less error-prone programs.

Let's look at a JavaScript example that illustrates this point:

// Get the first argument passed in by the user
let arg = process.argv[2]

// Do really important stuff
console.log(arg.split(''))

There's a subtle error that will only happen sometimes in this code. Can you spot it? If we pass an argument to our program -- node main.js hello -- then it behaves as expected. However, if we don't pass an argument, we'll get an error that's probably very familiar if you use JavaScript a lot:

console.log(arg.split(''))
                  ^

TypeError: Cannot read property 'split' of undefined

In this case, it's easy to see what went wrong: if we don't pass an argument to our program, we end up setting our arg variable to the value at an array index that doesn't exist. JavaScript defaults that value to undefined, which then causes an error later on in our handleArg function when we try to split() the undefined value.

While this example is trivial to fix, it's very easy to introduce this kind of bug into a larger JavaScript program, where it's potentially much harder to find the original cause of the undefined value. A typical fix would have us check that the value exists before trying to use it, but that requires more code and more diligent programmers.

In cases where we're dealing with input to our program that can be undefined, Rust forces us to handle the potential undefined value with the Option type before the program will even compile. We can see the Option type in action if we tweak our println! call a bit:

File: src/main.rs

use std::env;

pub fn main() {
    let filename = env::args().nth(1);
    println!("{:?}", filename)
}

This solution was hinted at in our error message from before. By adding the :? to the curly brackets, we're essentially telling the println! macro that we want to be more lenient about the types of values we can print to the console (specifically, we've added the debug format trait).

If this doesn't make much sense, don't worry about it for now. In general, the Rust compiler is very helpful, and you can usually rely on its suggestions to fix your code if you've gotten stuck. In this case, let's follow its advice and see what we get.

After a cargo run -- hello, you should see:

Some("hello")

There it is! Since we passed in an argument to our program, env::args.nth(1) contains Some value. Now, try running the program without an argument. This time you should've gotten the None variant, just as we expected.

Now that we understand a bit about what's going on with Rust's Option type, how do we actually get to the value inside Some? Conveniently, Rust offers us a shortcut for grabbing values we are pretty sure are going to exist in our program:

File: src/main.rs

use std::env;

pub fn main() {
    let filename = env::args().nth(1).unwrap();
    println!("{}", filename) // we no longer need the ':?'
}

unwrap() is a method available on Option, and it's pretty straightforward. If there is Some(value), then return the value. If not, then panic (error out). unwrap() also serves as a sort of "TODO" flag, because it signals that you should replace it before releasing your program into the world.

When we run our program with at least one argument now, we should get that argument printed to the console. If we run it without any arguments, we should get a panic along the lines of:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value'

With that brief foray into Rust Options out of the way, let's next move on to actually reading text files from the system.

Reading file contents

The Rust standard library contains a module for filesystem operations. This module is very similar in functionality to the fs module in the Node standard library. In Node, we could use the contents of a file like so:

const fs = require('fs')

fs.readFile('words.txt', 'utf8', function(err, data) {
  console.log(data)
})

The readFile() function takes a file, an optional encoding and a callback to handle either an error or the returned contents. The Rust std::fs::read_to_string function does something very similar, taking a file path and returning a Result<String>.

`Result` and `expect()`

Result is similar to Option in that it can either produce a value or something else (None being the 'something else' for Option). In the case of Result, the results are either:

Ok(T), where T is an arbitrary type, or,
Error if the operation fails.

In the case of fs::read_to_string, the Ok result is Ok(String), since on a successful "read this file to a string" operation, the value we want back is a String.

Let's add a simple text file to our project and test it out. Add the following text to a file called words.txt in the root of the project:

File: words.txt

This is a file containing words
There are several words on this line
This one is short
The end

Now let's use read_to_string to read words.txt to a variable:

File: src/main.rs

use std::env;
use std::fs;

pub fn main() {
  let filename = env::args().nth(1).unwrap();

  let file_contents = fs::read_to_string(filename).expect("Error reading file to string");

  println!("{}", file_contents)
}

Here we use expect(), which is very similar to unwrap except it allows us to pass a custom panic message. If we run our program and pass it the argument the path of our text file (cargo run -- words.txt), we should see our text printed to the console.

Now that we've successfully read our text file and put its contents in a variable, we can complete the final step of counting the words in that file.

Counting words

Simple text manipulation like counting the number of individual words (separated by whitespace) is a great way to explore the power behind one of Rust's core philosophies, that of zero cost abstractions. The gist of this idea is two-fold: first, you shouldn't pay (in performance or size) for any part of the programming language that you don't use, and second, if you do choose to use a language feature then it will be just as fast (or faster) than if you wrote the feature yourself. By following this simple philosophy, Rust places itself as a prime choice for writing programs that need to be mindful of space and speed considerations.

To illustrate this point, let's take another example from JavaScript. A JavaScript implementation (node, the browser, etc), has to include a garbage collector in order to manage memory the program uses. Even if all you do is console.log('Hello World'), the entirety of the JavaScript runtime, including the garbage collector have to be there. In Rust, when you println!, the only code that gets compiled and run is the code specifically needed to print things.

It is worth noting that sometimes we don't really care that much about speed or size of our programs, and in those cases Rust doesn't have much of an advantage over JavaScript or any other language. But, when we do care about those things Rust really comes into it's own. In many cases with Rust you get the flexibility and expressive power of a super high level programming language while also getting near-unmatched performance. Let's look at an example:

use std::env;
use std::fs;

pub fn main() {
  let filename = env::args().nth(1).unwrap();

  let file_contents = fs::read_to_string(filename).expect("Error retrieving file");

  let number_of_words = file_contents.split_whitespace().count();

  println!("{}", number_of_words)
}

Here we've added a single line to our program, changed another, and essentially achieved our desired functionality. Let's take it step-by-step.

Once we have the file contents from our words.txt file bound to a variable, we take thatfile_contents String and split it up on any Unicode whitespace via split_whitespace. This returns an Iterator value. This would be roughly the equivalent of using the split() method on a String in JavaScript, for example:

let exampleString = 'This is an example'
console.log(exampleString.split(' ')) // Array(4) [ "This", "is", "an", "example" ]

Once we've done that, we can consume the Iterator with count() to get the number of items in it. A similar approach in JavaScript would be to use the length property of the returned Array from before.

Finally, we print the resulting count to the console. And that's it! Run cargo run -- words.txt to see the number of words in our text file.

Conclusion

This program is very simple, but it illustrates a plethora of core Rust concepts. It also leaves out some other very important tools and ideas. For example:

We could handle the Error and None cases in our argument-handling and I/O functionality using match
We could have counted the individual words using Vectors and loops
We could have opted for a more object-oriented approach and contained our functionality to structs and impls
And lots more

If you've made it this far, thanks so much for reading! Writing this article has been a learning process for me, and I still very much consider myself a Rust beginner. If you spot any mistakes, or see any grievous infractions of best-practices, please reach out at tindleaj[at]gmail[dot]com or @tindleaj If you're interested in learning more Rust, there are a ton of other great, free, and current resources to do so.

Additional resources

For learning

The Rust Programming Language - official, incredibly well written, definitely should be your first stop
Rustlings - awesome interactive learning tool
Rust for Node developers - a big inspiration for this article
Rust by Example - says it right on the tin
A Gentle Introduction to Rust - a tour through some of the great Rust features
Exercism.io - more small, interactive projects

Other

Writing an OS in Rust - incredible project, I aspire to one day be this good
IntermezzOS - more operating systems
Roguelike Tutorial - In Rust - I haven't gone through this one yet myself, but I've heard really good things
Read Rust - great source for Rust related news and happenings

Finding Freelance Work as a New Developer

Austin Tindle — Wed, 03 Jun 2020 00:00:00 +0000

I had someone reach out recently about advice for new programmers who want to freelance, given that finding clients is even harder right now than it would otherwise be. Specifically how does a new freelancer find opportunities for contract work? My response got long enough that I figured I'd post it, so here it is.

Finding contract work as a brand-new freelancer is tough. My first year or so of doing freelance web development, I reached out to small local businesses, friends and family, and organizations, looking for the lack of a website to guide me to paying customers. I found a decent number of people who wanted websites, but not very many (read: none) who wanted to pay me to build them. Given that I didn't need to support myself at the time, that was ok. But, if you're a new freelancer and you want to make money, you'll need a better approach.

After a few years of stumbling down several fruitless avenues in search of freelance clients, I ended up finding the most success by doing two things: I charged more than I thought I was worth, and I reached out to people in smaller, professional communities.

The first point is pretty simple. Charge more. The point of this isn't a greedy cash grab; if I were to sort my past clients by how great they were to work with, the ones at the top would also be the ones that paid me the most.

If you're worried about being inexperienced and not being able to justify charging more, then do pro-bono work, or personal projects. Or just don't worry about it, and charge more anyway. The Imposter Syndrome never really goes away, so you might as well start learning to ignore it now. I worked the hardest and burned myself out the fastest working for people who paid me the least. Don't do that.

An arbitrary rule of thumb here is to do some research, decide on an hourly rate for yourself, then double it. Or, if you're charging a rate for the whole project, double that too. One caveat for project-based rates that I ran into early on is that it's hard to know how long a project will take you when you don't have a ton of experience, and so you could end up charging too much or too little. Finding what works for you will require getting some projects under your belt, but I've found that being very up-front and transparent about my rate and my estimates has worked well in the past.

If you opt for a flat rate for your project, being abundantly clear that estimates are hard, and adjustments might need to be made to the rate as the project progresses are good safety measures. Even better, breaking the project into several distinct milestones where payments are made after each deliverable lets you more easily adjust for any scope creep or previously unknown obstacles incrementally instead of having to get it right all at once, at the outset of the project.

Finding niche professional communities is a little more nebulous. The key here is you have to find communities that are both:

Small enough that you can connect directly with people who might need your services, and,
Are made up of individuals willing/able to pay you for your services.

I started out by spending time on reddit communities like r/forhire, and the monthly HackerNews hiring threads, and then gradually branched out into other communities where the focus wasn't necessarily just about 'finding work', but still had members who I could connect with and who might have projects they'd be willing to pay my rate for. The IndieHacker community comes to mind as a niche community that potentially fits this bill (although I've never personally looked for freelance work there).

Once you've found a suitable community, all that's left is reaching out to people and starting a dialogue.

In my mind, the biggest differentiator for any professional programmer is their ability to communicate effectively through writing. Freelancers especially need to spend time working on being clear, consistent, and persuasive. Your first interactions with a client will usually be written. Many clients won't be programmers themselves, so written updates will be a necessary deliverable once you do have the contract.

As a freelancer, your written communication needs to be:

Clear. You have to be able to explain the details of your work, technical and otherwise, to your client.
Consistent. This has been one of my most common freelancing failures. There's almost no such thing as too much communication with your client, but too little communication is a project killer. Even if it's to report roadblocks or unforeseen issues, regularly communicating is critical
Persuasive. Part of being a freelancer is to be constantly articulating your value to your client. It doesn't matter if your code will be 100x faster than what's already there, your client won't care unless you sell them on the value of that speedup. In my experience, persuasive writing is brief, backed by facts/data, and draws upon your industry experience to add context to your decisions.

And that's it. My freelancing advice basically boils down to charge more, find communities of people who will pay you, and focus on well written communication with those people.

If you're interested in more advice on freelancing, DaedTech is a blog that dives into freelancing topics with lot more depth, and I've found a lot of Eric's content to be super useful.

Do Significant Work

Austin Tindle — Thu, 28 May 2020 00:00:00 +0000

The Stripe Press just published a beautiful reprint of Richard Hamming's The Art of Doing Science and Engineering, which led me (and quite a few others, I imagine) to read some of his work for the first time. The written form of his lecture, "You and Your Research", is chapter thirty of the book (go read it if you haven't).

It opens with Hamming admitting that the lecture could just as easily be called “You and Your Engineering Career,” or even “You and Your Career". He suggests that we should try to do significant things in our careers, rather than insignificant things. Hamming means 'significant' in the 'significant to mankind' sense, what he says applies to the 'personally significant' just as well. To do significant things, we need to:

Focus on the most important problems you can try to solve
Work at those problems consistently
Be excellent in our work

Not everyone can chose to work on they believe to be the Important Problems. Being able to do so is definitely a sort of privilege. However, there will always be problems that are the most important within your ability to solve. Hamming says to work on those.

You can apply this recursively. What's the most important piece of the important problem you're solving? Focus on that. It sounds simple, but is everyone you know working on the problem most important to them? Are you?

Being consistent, determined, driven -- that's harder to change. Everyone has some minimum they can do consistently. Hamming talks about finding that minimum, and then growing from there. Everyone can be consistent to a different degree, but we can all improve.

The final point is the one that resonated with me the most. Be excellent. So much of the field I work in is filled with bloat, workarounds, hacks, "good enough", and crumbling towers of complexity. The reality is that excellence isn't a prerequisite for generating profit. Excellence is, however, a prerequisite for doing significant things. This is the clearest goal, and yet the hardest to achieve. We all know what excellence looks like -- some even make a habit of excellence already. But it's easy to do mediocre work, and in some ways it's even easier to do good work. Excellent work is usually hard work.

Hamming concludes on the point of excellence. For him, the most important thing about the work we do is how we do it:

"... it is nice to end up where you wanted to be, but the person you are when you get there is far more important. I believe a life in which you do not try to extend yourself regularly is not worth living—but it is up to you to pick the goals you believe are worth striving for."

You're not ready. Do it anyway

Austin Tindle — Wed, 27 May 2020 00:00:00 +0000

In Surely You're Joking Mr. Feynman, Richard Feynman talks about spending a summer at Caltech to "Just try out biology", a field he was completely untrained in and unfamiliar with:

"After the war, every summer I would go traveling by car somewhere in the United States. One year, after I was at Caltech, I thought, ";'This summer, instead of going to a different place, I'll go to a different field.'

...I went over to the biology lab to tell them my desire, and Bob Edgar, a young postdoc who was sort of in charge there, said ... "You'll have to really do some research, just like a graduate student, and we'll give you a problem to work on." That suited me fine."

Feynman goes on to do work in the field and even contributes some non-trivial new findings to biology. Later in the book he sums up his experience with:

"I always do that, get into something and see how far I can go."

I read this memoir in the last year or so, and this section made me think some uncomfortable things about my own mindset when it comes to growing in one way or another. I realized that I've approached new and interesting things as a collector, excited about a topic or field or tool, but never quite ready to go beyond a superficial exploration of that topic. I've piled up bookshelves with resources on all kinds of things I'd love to learn about, but never seem to find the time for. Months, or even years later, I've looked at some of those books and said to myself, "Wow, I thought I'd know all about that by now".

My rationales for not being ready have been pretty straightforward: "I have to learn some more of the basics before getting to that", or "I need to learn this other thing before that'll make sense".

Reading about Feynman's detour into biology made me think about that rationale a little more critically. And after some thought, it started to crumble. You can't really be 'ready' for much of anything. Now I've been thinking, if you ever find yourself 'ready', that's probably a good indication that you could go a bit farther, dig a bit deeper, try something even more novel.

So now, I'm getting into some things. We'll see how far I can go.

Learn, Apply, Teach, Repeat: Guidelines for Technical Learning

Austin Tindle — Wed, 18 Dec 2019 03:12:34 +0000

This article was originally posted on my Medium account here.

I'm very interested in improving my ability to learn technical concepts efficiently. In this article, I'll go over the heuristics I've found that work well for me: Read actively, use multiple sources/formats, work at memorizing, apply the concepts, and finally teach.

It all started with the observation (one I'm sure many of you are familiar with) that I have an interest in learning many things, but only some of those things stick after trying to learning them. I'd read a book, or watch a video lecture, only to then run into roadblocks. Some of the content I would be able to pick up easily, only to forget it later. Other content would be too opaque for me to make much progress with. The worst was content I thought I had learned, but would then struggle with when it came time to write down my thoughts on the subject or to talk about it with others. This is all extremely discouraging: what's the point of learning in the face of all these issues?

Before getting into it, a couple of notes:

The following heuristics represent my current personal strategy, and I have no idea if they'll work for you. I think they're all pretty useful, but I'm sure they'll continue to change as I learn more.
Where applicable I'll link to the resources that have inspired these points or that I've found useful.
Most of the content I've been trying to learn recently has been technical/programming concepts, including the Rust programming language and fundamental computer principles.

And with that, my heuristics for learning effectively:

Read with intent

Most of the learning you'll end up doing will probably be via reading. This is because most content is written, especially the niche or advanced stuff. Even so, this guideline also applies to things like video lectures. The problem that lot's of people fall into, or at least that I've fallen into, is that there are two distinct modes for reading: active and passive. Passive reading is the easy kind of reading, and it's the default mode. This is the way I've found myself reading most novels and shallow content like blog posts and social media. You can't read to learn like this. You have to instead read actively. You have to focus on the main ideas, pause on topics you don't understand until you can find a way to understand them, and also give your brain time to digest new material (don't cram). These are all parts of what it means to read actively.

Active reading is something that has been in sort of the periphery of understanding for me. In other words, it's something that I knew was there but didn't know how to do the right way. I probably still don't know how to do it the right way, but reading the book How to Read a Book really changed the way I practice actively reading. There's a good tldr; of the book made by the University of Michigan that expands on the principles above.

The tldr; of the tldr; (just read it, it's 11 pages with lots of pictures) that you should read the same material multiple times. The first read to skim and understand the main concepts, another to deeply understand the specifics of the material, and a third to synthesize that material with other related material. It also goes into some specific techniques for how to outline and extract important content from a written resource. I've found these techniques super useful, especially when combined with tools for memorization, the next learning heuristic I'll outline in this article.

Commit your learning to memory

The basic prerequisite for any learning is that you have to have a baseline understanding of whatever the topic or content is. Once you have that, you then have to remember it. Accomplishing this part might seem a bit opaque, and it is -- without the right tools. The right tool definitely seems to be Spaced Repetition Learning. The details of that concept are very interesting, and you should definitely look it up if you're inclined, but it boils down to the idea that if you review material right before you're about to forget it, you can go longer and longer times between reviews without forgetting. Eventually, you'll never have to review it again, you'll just remember it forever.

Tools like Anki and Mochi help you do this pretty easily. My current workflow is to identify main points or vocabulary (via highlighting or written notes), then to distill those into Anki cards which I then review. I also constantly delete and update existing cards to keep the my decks free of stale information. This happens as my understanding on topics becomes more nuanced or I decide a particular concept isn't worth remembering any more. An important part of using spaced repetition is that you have to be consistent: committing to reviewing cards regularly is a necessary part of the process.

Spaced repetition and Anki in particular have been written about by people more experienced than I. In particular I've learned a lot from The Janki Method by Jack Kinsella and Augmenting Long-term Memory by Michael Nielsen.

Vary your learning resources

This heuristic is pretty straight forward, but I think it adds a lot to the learning process. For very niche or advanced topics this might be harder, but ideally you should find multiple resources on the same topic, and consume them in parallel. I've found that having a written resource like a book or series of articles, along with a video-based resource like lectures or a MOOC class works very well. This guideline becomes especially helpful when I get stuck on a particular concept as it's presented by one resource. For example, I had a hard time understanding referencing and dereferencing values in Rust as it's presented by the Rust Book until I watched a YouTube lecture on that specific topic.

How you vary your learning resources is up to you. I've found that I learn really well by mixing textbooks and MOOC courses, but you could also explore audio books, in-person classes, or finding a mentor. For programming, I've also used interactive learning resources like Codeacademy and rustlings, to name just two.

Make something

The previous three points are roughly half of the battle (in my mind) when it comes to gaining a real understanding of a new topic. The other half is all about having context and purpose around your topic of choice. If you aren't doing anything with what you're learning, then what's the point?

It can be helpful to have a project/goal in mind before you start learning at all, but that's not always the case. I've definitely run into situations where I had an abstract interest in a topic, but didn't really know enough about it yet to come up with a project. However, I think at some point you have to anchor the academic thought-stuff of whatever you're learning in the messy reality of a project. For me, most of my recent learning has centered around programming, and so most of my projects have been programs.

For non-programming topics this applied portion of the learning process will obviously be different. Som possibilities are a physical creation, artwork, blog post, etcetera, etcetera. The important part is that you apply what you're learning.

Teach

The real test for whether you really grok a subject: can you teach it to someone else? Even if you can't that's usually OK too. I've found that the process of trying to instruct someone else on a topic serves two purposes. It both reinforces my previous learning, and clearly highlights the gaps in my own understanding. The reinforcement is useful, but getting a better idea for what you don't know is even better. It's fine to take a shot at teaching something you're still learning yourself. It's part of the learning process, and you'll be surprised by the number of insights you can provide for others even if you don't have a perfect grasp yourself.

Teaching can take numerous forms, but it doesn't all have to be the stand-in-front-of-the-class, draw-it-on-the-whiteboard variety. Most of the time, "teaching" can just consist of a conversation with a colleague or friend, or an article about the subject you're learning.

Notes

Notably, these guidelines shouldn't necessarily be done in the order I've presented here. There are constant feedback loops between comprehension, memorization, application, and instruction, and you should find yourself switching between them fairly regularly. Also note, it's best to go without too much rigid structure (at least that's how I've been doing it).

Everything I've written here has been written or said by someone else before me. There's nothing groundbreaking about any one of these points, but it's taken me a while to distill these ideas and make them applicable to how I learn. Hopefully some of you will find the distillation useful.

Thanks for reading.

Rust's `slice::windows` is really cool

Austin Tindle — Mon, 17 Jun 2019 02:58:02 +0000

Cover photo by Gordon Williams on Unsplash

This post is one of several that outline my perspective on learning Rust as someone who primarily uses JavaScript. You can find the rest here.

Rust has a lot of powerful features associated with its primitives and standard library. A cool one I just came across is the method slice::windows. This method returns an iterator over a slice. The iterator length can be specified. It lets you iterate over a slice and have a window of a specific size on each pass. For example:

// windows.rs

let slice = ['w', 'i', 'n', 'd', 'o', 'w', 's'];

for window in slice.windows(2) {
  &println!{"[{}, {}]", window[0], window[1]};
}

// prints: [w, i] -> [i, n] -> [n, d] -> [d, o] -> [o, w] -> [w, s]

This is pretty cool, and doesn't really have a parallel in JavaScript. The closest that I can come up with to achieve the same is this:

// windows.js

let slice = ["w", "i", "n", "d", "o", "w", "s"];

slice.forEach((char, index) => {
  if (index === slice.length - 1) return;

  console.log(`[${slice[index]}, ${slice[index + 1]}]`);
});

The JavaScript approach is definitely less ergonomic, and I really like the concept of windows as an abstraction for use with iterators.

Thanks for reading.

Forem: Austin Tindle

Rust in 2021 - Rust for JavaScript developers

A JavaScript Developer's Cheatsheet for Rust

Variables (bindings)

Printing Output

Functions

Conditionals

If/Else

Switch & Match

Importing Other Code Using Modules

Arrays & Vectors

Iterating

Other Resources

Introduction to Rust for Node Developers

Notes

Setting up

Project structure

Running the project

Tour of a "Hello World" program in Rust

The miniwc program

Building a foundation

Types

Structures (struct)

Implementations (impl)

Enumerations (enum)

Handling arguments

Using Iterators

Handling all Options

Reading file contents

Result and expect()

Counting words

Conclusion

Additional resources

For learning

Other

Finding Freelance Work as a New Developer

Do Significant Work

You're not ready. Do it anyway

Learn, Apply, Teach, Repeat: Guidelines for Technical Learning

Read with intent

Commit your learning to memory

Vary your learning resources

Make something

Teach

Notes

Rust's `slice::windows` is really cool

The `miniwc` program

Structures (`struct`)

Implementations (`impl`)

Enumerations (`enum`)

Handling all `Option`s

`Result` and `expect()`