baby steps

This post examines a particular, seemingly simple problem: given ownership of a Rc<Vec<u32>>, can we write a function that returns an impl Iterator<Item = u32>?

One of the long-standing issues that we’ve been wrestling with in Rust is how to integrate the concept of an “uninhabited type” – that is, a type which has no values at all.

I consider Rust’s RFC process one of our great accomplishments, but it’s no secret that it has a few flaws.

I’ve been getting a lot of questions about the status of “Non-lexical lifetimes” (NLL) – or, as I prefer to call it these days, the MIR-based borrow checker – so I wanted to post a status update.

Ever since the Rust All Hands, I’ve been experimenting with an alternative formulation of the Rust borrow checker.

This is the second in a series of posts about Rust compiler errors.

I’ve decided to do a little series of posts about Rust compiler errors.

So aturon wrote this beautiful post about what a good week it has been.

I’ve been thinking a lot about persistent collections lately and in particular how they relate to Rust, and I wanted to write up some of my observations.1 What is a persistent collection?

In my last Chalk post, I talked about an experimental, SLG-based solver that I wrote for Chalk.

As part of #Rust2018, I thought I would try to writeup my own (current) perspective.

So, as you likely know, we tried something new at the end of 2017.

For the last month or so, I’ve gotten kind of obsessed with exploring a new evaluation model for Chalk.

In my last post about chalk queries, I discussed how the query model in chalk.

I’ve been hard at work the last month or so on trying to complete the non-lexical lifetimes RFC.

For my next post discussing chalk, I want to take kind of a different turn.

I recently participated in the GNOME / Rust “dev sprint” in Mexico City.

In my previous post, I talked over the basics of how unification works and showed how that “mathematical version” winds up being expressed in chalk.

We just released Rayon 0.7.

So in my first post on chalk, I mentioned that unification and normalization of associated types were interesting topics.

For some time now I’ve been interested in better ways to construct LR(1) parsers.

In my previous post, I outlined a plan for non-lexical lifetimes.

At the recent compiler design sprint, we spent some time discussing non-lexical lifetimes, the plan to make Rust’s lifetime system significantly more advanced.

I want to have a tool that would enable us to answer all kinds of queries about the structure of Rust code that exists in the wild.

This last week we had the rustc compiler team design sprint.

In a previous post, I talked about a proposed approach to drafting the unsafe code guidelines.

Over the last year or two (man, it’s scary how time flies), I’ve been doing quite a lot of thinking about Rust’s trait system.

While I was at POPL the last few days, I was reminded of an idea regarding how to bring more struture to the unsafe code guidelines process that I’ve been kicking around lately, but which I have yet to write about publicly.

This post is the (long awaited, or at least long promised) third post in my series on Rayon’s parallel iterators.

This post is a continuation of my posts discussing the topic of associated type constructors (ATC) and higher-kinded types (HKT): The first post focused on introducing the basic idea of ATC, as well as introducing some background material.

This post is a continuation of my posts discussing the topic of associated type constructors (ATC) and higher-kinded types (HKT): The first post focused on introducing the basic idea of ATC, as well as introducing some background material.

Hello.

So for the end of last week, I was at Rust Belt Rust.

If you visit the site today, you’ll notice it looks quite a bit different.

In my previous post, I talked about how we can separate out specialization into two distinct concepts: reuse and override.

I spent a really interesting day last week at Northeastern University.

For the past year or so, I and a few others have been iterating on some tutorial slides for learning Rust.

In my previous post, I started discussing the idea of intersection impls, which are a possible extension to specialization.

As some of you are probably aware, on the nightly Rust builds, we currently offer a feature called specialization, which was defined in RFC 1210.

I’ve been thinking about the unsafe code guidelines a lot in the back of my mind.

A little while back, I wrote up a tentative proposal I called the “Tootsie Pop” model for unsafe code.

In my previous post, I spent some time talking about the idea of unsafe abstractions.

The unsafe keyword is a crucial part of Rust’s design.

This is the third post in my series on non-lexical lifetimes.

In my previous post I outlined several cases that we would like to improve with Rust’s current borrow checker.

Over the last few weeks, I’ve been devoting my free time to fleshing out the theory behind non-lexical lifetimes (NLL).

For the last couple of weeks, my mornings have been occupied with a pretty serious revamping of LALRPOP’s error message output.

This post is the second post in my series on Rayon’s parallel iterators.

Since giving a talk about Rayon at the Bay Area Rust meetup, I’ve been working off and on on the support for parallel iterators.

Over the last week or so, I’ve been working on an update to Rayon, my experimental library for data parallelism in Rust.