DEV Community: Joe Clay

Why Did Rust Pick the 'If Let' Syntax?

Joe Clay — Tue, 12 Jan 2021 21:46:30 +0000

One of my favourite features of Rust is that it has excellent support for pattern matching. This is usually done through match expressions, but there is also a shorter syntax that can be used if you only need a single branch, which is called if let.

If you're unfamiliar, a match expression looks like this:

let x = Some(123);

match x {
    Some(y) => {           // This matches if `x` is `Some`.
        println!("{}", y); // This prints '123'.
    }

    _ => {}                // This matches all other values.
}

And the equivalent if let expression looks like this:

let x = Some(123);

if let Some(y) = x {   // This matches if `x` is `Some`.
    println!("{}", y); // This prints '123'.
}

This shortcut syntax, useful as it is, can be quite confusing to new Rust developers. I commonly see people asking things like:

Why is that if statement 'backwards'?
Why is there a let in that conditional?
Why do I have to use = instead of ==?

I had similar questions when I started learning Rust, and to answer them, we need to take a step back and look at the plain old let syntax. It's relevant, I promise!

In most cases, you see let being used to declare a simple named variable, like this:

let x = 123;

What might not be apparent at first glance is that the left side of a let isn't just a name - it's a pattern, the same as what you'd use in the arm of a match expression!

This means that we can actually do pattern matching when declaring variables, like so:

enum Example {
    Data(i32),
}

let x = Example::Data(123); // Wrap the data.
let Example::Data(y) = x;   // Unwrap ('destructure') the data via a pattern.

println!("{}", y);          // This prints '123'.

There is, however, one important restriction here compared to when you're using match - in a let statement, you can only use patterns that are 'irrefutable'. In simpler terms, this means that you can only use a pattern which will match for every possible value of the type that you're matching against.

We can see what happens when this isn't the case by adding an extra variant to our Example enum:

enum Example {
    Data(i32),
    Oops,
}

let x = Example::Data(123);
let Example::Data(y) = x;

println!("{}", y);

This gives us an error which looks like this:

error[E0005]: refutable pattern in local binding: `Oops` not covered
 --> src/main.rs:8:9
  |
2 | /     enum Example {
3 | |         Data(i32),
4 | |         Oops,
  | |         ---- not covered
5 | |     }
  | |_____- `Example` defined here
...
8 |       let Example::Data(y) = x;
  |           ^^^^^^^^^^^^^^^^ pattern `Oops` not covered
  |
  = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
  = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html

So if we can't use let for this pattern, what can we use? This is where we circle back to if let!

enum Example {
    Data(i32),
    Oops,
}

let x = Example::Data(123);
if let Example::Data(y) = x {
    println!("{}", y);
}

Notice that this example is almost identical to the previous one that didn't compile - the only changes are the extra if, and the extra block to mark which code should only be run if the pattern matched.

This is the reason that if let looks the way it does - it's an extension of the existing let syntax (which only supports irrefutable patterns) to support all kinds of patterns!

Once I started thinking about it this way, the syntax started to feel a lot more natural, and I hope this post helps make the relationship between let and if let click for other people too.

Simple HTTPS Domain Redirects with Netlify

Joe Clay — Tue, 07 Jul 2020 11:23:14 +0000

This week, a website that I help maintain ran into some issues with their domain names. I stumbled upon a quick (and free!) solution which I thought was worth sharing, in case it helps anyone else out of a jam.

TL;DR: You can use a Netlify _redirects file to redirect both HTTP and HTTPS traffic from one domain to another, without paying for server hosting or an SSL certificate.

The Problem

Are We Game Yet? is a website which lists resources for game developers in the Rust community. It's hosted on Github Pages, and historically it's been available via https://arewegameyet.com. We also had simple HTTP redirects set up on http://arewegameyet.rs and http://arewegameyet.org.

Since the .rs domain makes it a bit clearer that the website is Rust-related, we decided that it'd be good to make this the new primary URL. But that led us to a bit of a conundrum: pretty much all of the existing links to the site, including the ones on Google, point at https://arewegameyet.com.

GitHub Pages doesn't support multiple domains, and our domain providers only support simple HTTP redirects unless we pay through the nose for a VPS and/or a SSL certificate. So for a while, it looked like we wouldn't be able fix these URLs without moving our hosting or increasing our expenditure, neither of which would be ideal.

The Solution

Netlify is a web hosting service that's targeted at static sites. They have an extremely generous free tier, which I'm currently using to host both this blog and Tetra's documentation, and I'll basically tell anyone who'll listen about how they're the best thing since sliced bread.

One of the really cool features of Netlify is that they allow you to specify redirect rules as part of your static deployment. You provide a file called _redirects, and their servers will handle mapping the URLs. It's similar to an Apache .htaccess file, but without having to actually manage the server itself.

I've seen a lot of cool tricks done with _redirects files before; for example, Kent C. Dodds has used them to create his own URL shortener. So I was curious whether they could be applied to this problem - and as it turned out, thanks to splat redirects, they can!

First, we created a dummy index.html file, as Netlify didn't seem to want to deploy a site without one present. Then, alongside it, we created a _redirects file with only two lines:

/* https://arewegameyet.rs/:splat 301!
/  https://arewegameyet.rs        301!

The ! at the end is important, as it prevents files in the deployment from shadowing the redirects.

We deployed these two files to Netlify, added our .com and .org domain names to the project, and activated HTTPS via Netlify's Let's Encrypt integration.

And that's it! Now both domains redirect all of their traffic on both HTTP and HTTPS to the corresponding page on https://arewegameyet.rs, and we didn't have to pay a penny.

Hopefully this is useful to other people who find themselves in a similar situation!

How Lua Avoids Semicolons

Joe Clay — Tue, 03 Apr 2018 19:02:17 +0000

My current pet project outside of work is developing a little programming language called Ein. I decided fairly early on in development that I didn't want Ein to have semicolons, so I've spent a fair chunk of the past week investigating how other languages make this work.

Lua's solution to this problem is (in my opinion) fairly nifty, so I thought I'd write about it on the off-chance that someone else will find it as interesting as I do 😄

The Problem

First, some background - why is getting rid of semicolons tricky? Can't we just remove them from our language's grammar and be done with it?

The answer to this question can be summed up in one snippet of pseudo-code:

let x = 1 // Does the statement end here?
- 1       // Or does it end here?

How does our language's parser decide whether this should be one statement (let x = 1 - 1) or two (let x = 1 followed by -1)? In the parser's eyes, they're both perfectly valid!

The (Potential) Solutions

There's several ways that languages try to get around this problem. Some make the whitespace in their language significant, like Python. Others, like Go, try to insert the semicolons for you behind the scenes based on a set of rules.

Personally though, I'm not a fan of those solutions. Making whitespace have meaning rubs me the wrong way for reasons I don't quite understand, and automatic semicolon insertion feels like placing too much trust in the compiler to 'guess' where I meant for the statements to end.

How Lua Does It

Lua's syntax is unambigous, even if you leave out all the semicolons and nice formatting, and the main way it achieves this is by dropping a feature a lot of us take for granted - expressions-as-statements.

In most languages, it's perfectly valid to use an expression (a piece of code that can be evaluated to get a value, like adding two numbers together) in the same place that you would use a statement (a piece of code run for its side effects, like a variable declaration).

Lua takes a much more hardline stance on this - programs are a list of statements, some statements may contain expressions (like the condition of an if), but expressions are not allowed to be used as statements.

Let's go back to our original example, translated to Lua:

local x = 1 -- Does the statement end here?
- 1         -- Or does it end here?

In Lua, a variable declaration is a statement, but -1 is an expression - therefore, the only valid way of interpreting this code is local x = 1 - 1!

What's The Catch?

Ah yes, there's always a catch, and in this case it's a fairly obvious one: what if I want to run an expression for its side effects?

For example, a lot of the time you'll want to use the return value of a function, but sometimes you'll just want to run it. Lua caters for this scenario by making an exception to the rule, allowing function calls to be used both in statement and expression position.

This is one of the only places that Lua bends the rules, however. In some languages, you can use the short circuting behavior of the logical AND/OR operators as short and sweet control flow statements:

// JavaScript
isActive && doSomething();

The equivalent in Lua isn't valid unless you assign the result to a temporary variable:

local _ = isActive and doSomething()
-- _ has no special meaning - just a common Lua 
-- naming convention for throwing away variables!

Conclusion

Thank you for reading! I hope I didn't bore you to death rambling on about semicolons for $x words! ❤️

If you're interested in this kind of thing, I'd recommend taking a look at the full grammar for Lua from its reference manual - it's really short and really clean, and there's a lot of really interesting design decisions in there which I'm interested in digging deeper into.

What makes you want to stick with a programming language?

Joe Clay — Wed, 28 Mar 2018 15:17:05 +0000

My previous post generated a load of really interesting comments, so I'm back with another language design question - albeit this time a bit more of an abstract one!

What factors make you want to keep investing time into a programming language beyond writing "Hello, world"? Or conversely, what things make you drop a language like a ton of bricks and run back into the warm, inviting arms of ${FAVOURITE_LANGUAGE}?

For me, the biggest thing that keeps me motivated through the early stages is documentation - in particular, well written guides/tutorials, rather than simple API docs. I've noticed there's been a bit of a trend in recent years towards languages coming with a 'book' which goes through all the features of the language, and I'm a really big fan of that concept! The prime example of this is The Rust Programming Language, which is so good I might order the print copy when it comes out <3

On the opposite end of the spectrum, I think the main thing that puts me off a language is bad tooling (package management, command line tools, editor extensions, etc.). It's enough to put a damper on my enthusiasm for otherwise wonderful languages - I love Lua's design, but I find myself really missing code completion whenever I use it!

How about everyone else?

How do you feel about braces and semicolons?

Joe Clay — Mon, 26 Mar 2018 14:08:52 +0000

I'm (slowly) working my way through Crafting Interpreters, and trying to put together a design for my little interpreted language. Thinking about the syntax has got me curious - do you prefer for a language to have:

Braces and semicolons (C, JavaScript, Rust)
Braces and no semicolons (Go, Wren)
Semicolons and no braces (I'm not actually sure anyone does this?)
No braces and no semicolons, with significant whitespace (Python)
No braces and no semicolons, with no significant whitespace (Lua)
Some other wacky design I've not thought of...

Personally, I tend to prefer the explicitness of option 1, but at the same time I don't really like that {} has a double meaning (is it a scope, or is it an object literal?). How about everyone else?