As someone who has significantly different beliefs than Peter Thiel, today is likely my second-to-last power of two years alive.

Two years ago, I wrote a post about turning 30, and I pretty much feel the same way. Never enough time, tick tock, tick tock. I have today off (thanks Mozilla!), but am still considering working anyway, because I really care about what I’m working on, and am excited about it. We’ll see.

I feel like I have more to say here, but also don’t. So maybe let’s leave it at that.

A careful reader will note the date of this post; it’s fundamentally in response to this call for blog posts, with a rhetorical device of looking backwards as if my personal plans for Rust came true. If you’re reading this in 2019 or beyond, this may be a work of fiction.

It’s been an exciting year for Rust. Well, it depends on what you mean by “exciting”, exactly. In a word, this year has been about polish. I find this kind of thing exciting! It’s a very different kind of exciting than the “new and shiny” exciting. It’s “take what we have and make it shiny.”

Let’s recap the major achievements of the year.

Rust 2018

First of all, we shipped our first epoch! If you type cargo new today, you’ll see a new shiny entry in your Cargo.toml:

[package]
name = "new-program"
version = "0.1.0"
authors = ["steveklabnik <[email protected]>"]

epoch = "2018"

[dependencies]

What does this...

Today is five years since I first heard of Rust. I wrote a post last year about it. This year, I have something slightly different in mind.

Five years is a long time in tech. It’s also a long time for me to be focused on one specific thing; other than the pizza job I held in high school and college, I’ve never stayed in a single job for five years. (This is true today as well; it’s not like I got a job with Rust the first day I learned of its existence.) I started with Ruby and Rails in 2008/2009, and my final commits to Rails were in August/September of 2013. So at this point, my career has basically been split in half, rather than dominated by Ruby.

Five years ago tomorrow, I registered http://www.rustforrubyists.com/.

Yesterday, I had lunch with someone I’m very honored to call a friend. We talked about a lot of things, but also about Rust’s past, present, and future. One thing...

Every six months, Mozilla gets all of its employees from around the world together in one place, for a week. This morning was the plenary session, with Mozilla leadership talking about our successes this year, as well as plans for the future. I noticed a theme that, while not super overt, I find very interesting, and bodes well for Mozilla’s future.

The words “user agent” kept coming up in various aspects of the plenary. The User-Agent header has a… shall we say storied history. When most people hear the term “user agent”, they mostly think of the “user agent string”. This is passed through the User-Agent header to identify which browser you’re using.

Well, that’s how most people think of it, but that’s not the whole story. If it is supposed to identify which browser you’re using, why is it not the Browser header? What is this “user agent” term anyway?

The concept is a bit more broad...

A few weeks ago, two C++ bloggers initiated a challenge (here and here): use the shiny new features of C++17 to write a small program that manipulates CSV files. The link is to the results; you can see the examples people came up with.

I’ve written a follow-up post too!

I decided to implement it in Rust for fun. You should give it a try, in whatever language you use, it’s a nice sample problem. I held myself to the same constraints as the original contest; no external packages is a bit painful in Rust, but it’s not too bad. Mostly it would let me eliminate boilerplate while also improving correctness, and making the code a bit shorter.

Anyway, here it is:

https://gist.github.com/steveklabnik/ad0a33acc82e21ca3f763e4278ad31a5

I implemented From for everything so I could use ?, but then main just has a ton of unwraps. I normally would remove those too, but the challenge does not...

One of Rust’s major goals this year is to provide mentoring at all levels of the project. This is a goal I’m very on-board with. There’s lots of ways to get involved with Rust, but I’d like to talk about the bit I’m most involved in: documentation.

There’s many ways to contribute to Rust’s docs. Some people contribute occasional PRs, some people end up contributing a lot. No matter what your interest, I’d like to help. But before I get into those details, why should someone get involved with documentation? I have my own reasons, but I also have a pitch for you:

Working on documentation is a fantastic way to learn something in a deeper way.

In order to document something, you have to understand it, even if only a little bit! It’s a good excuse to dig into the details. And I’ve found that many people are eager to help explain something to you in return for you writing that down and...

Rust has had a lot of stuff going on with “macros”. There are a few, interconnected aspects of these features, many different names for the same thing, and a lot of development work going on. This post will give an overview of the past, present, and future of macros in Rust.

Ultimately, macros allow you to write things like this:

let map = hashmap!{
    "a" => 1,
    "b" => 2,
};

or

[derive(Serialize, Deserialize)]
struct S {
    [serde(rename = "a")]
    f: i32,
}

That is, some macros look like functions: foo!, but allow you to write nearly arbitrary syntax inside of the ()s. Some let you control the ability to write custom attributes. Both generate some other kind of valid Rust code for the compiler to interpret. In the first case, the hashmap! macro will expand to a call to HashMap::new and a bunch of insert calls, and the second case, the Serialize and Deserialize traits will...

When I was working with Ruby on Rails, someone once sent me this link:

http://contributors.rubyonrails.org/

In some ways, this link changed my life. You see, I respond really strongly to integers going upwards. I am a sucker for points, hits, whatever. That web page, however, puts that integer towards something useful: open source contributions. It’s fairly well known that open source contribution is a long tail, but that’s also perfect for this kind of gamification. One contribution, as of today, will put you in 2461th place. Your second? 1473! That’s almost a thousand places! Just one more contribution puts you at number 1114. Still three hundred spots. Your forth commit will let you get in the top 900, 893. You get the idea. (I ended up at 47.)

Today, I’m working on Rust. And one of the things that I do is write the release announcements, or at least, their first draft. And one...

My post yesterday got a lot of great responses. Two of them are from people I greatly respect, Dave Herman and Graydon Hoare. You should go read those two posts; this one is in response to them. I’m going to respond to both at the same time by mixing them together.

Graydon says:

Safety in the systems space is Rust’s raison d'être. Especially safe concurrency (or as Aaron put it, fearless concurrency). I do not know how else to put it.

“Fearless concurrency” is a different way to put it! That is, to use Dave’s metaphor, “safety” is the fire flower. But “fearless concurrency” is Fire Mario. This is where I think Dave misses the mark slightly as well. I agree with his metaphor, but disagree with his conclusion.

I’m not saying that we get rid of fire flowers. I’m saying that we focus on “Rust makes you Fire Mario,” not “Rust is made of fire flowers”, when talking to people about Rust.

...

Rust is most well-known for its features around writing low-level code in a safer way than its predecessors. But it’s also a lot more than that. The Rust community is slowly evolving the way that we talk about Rust to people who haven’t yet given Rust a try, but it can take time. But how did we get here?

In Rust’s initial release announcement, Graydon used a phrase that is amazing:

[Rust is] Technology from the past come to save the future from itself

He goes on to elaborate a bit:

Many older languages [are] better than new ones. We keep forgetting already-learned lessons.

This is one of the many things that the “Rust” name evokes. Rust was not intended to be a cutting-edge PLT (programming language theory) research language. It was challenging an assumption that I think many of us hold dear: that “progress” means that things always get better. Reality is a bit more complex than...