## Async/Await V: Getting back to the futures

Two posts ago I proposed a particular interface for shipping self-referential generators this year. Immediately after that, eddyb showed me a better interface, which I described in the next post. Now, to tie everything together, its time to talk about how we can integrate this into the futures ecosystem. Starting point: this Generator API To begin, I want to document the generator API I’ll be using in this post, which is roughly what followed from my previous post: [Read More]

## Async/Await IV: An Even Better Proposal

I did not plan to write this blog post. I thought that the fourth post in my series would explain how we could go from the generator API in my previous post to a futures API in which you don’t have to heap allocate every async call. But eddyb surprised me, and now I have to revisit the API in the previous post, because we can implement everything we need from immovability with a safe interface afterall. [Read More]

## Async/Await III: Moving Forward with Something Shippable

In the first post, we looked at the relationship between generators and a more general notion of self-references. In the second post, we narrowed down exactly what problem we need to solve to make generators work, and talked about some solutions that we’ve considered but don’t feel like we could ship in the near future. In the original post, I promised that I would have a near term solution by the end of this series. [Read More]

## Async/Await II: Narrowing the Scope of the Problem

Last time we talked about the broader problem that generators with references across yield points represent: self-referential structs. This time, I want to narrow in on the specific problem that needs to be solved to make generators work, and also discuss some ideas for solutions that I think are false starts. (I still don’t have a proposal about what to do in this post, but it will come soon enough! [Read More]

## Async/Await I: Self-Referential Structs

This is the first in a series of blog posts about generators, async & await in Rust. By the end of this series, I will have a proposal for how we could expediently (within the next 12 months) bring generators, async & await to stable Rust, and resolve some of the most difficult ergonomics problems in the futures ecosystem. But that proposal is still several posts away. Before we can get to a concrete proposition, we need to understand the scope & nature of the problem we need to solve. [Read More]

## Announcing a new project: configure

Hi :) I’ve been working on a project called configure, which is intended to create a uniform way to load configuration variables from the environment of the program. Specifically, the goal is to create something that libraries can rely on to allow applications to delegate decisions about how configuration is loaded to applications, without those applications having to write a lot of bespoke configuration management glue. Storing configuration in the environment “The 12 Factor App” has this very good advice about managing configuration: [Read More]

## My Goals for Rust in 2018

The Rust project has requested blog posts about the project’s goals for 2018. I found myself in pretty much complete agreement with Nick Cameron’s post, so I thought instead I would write about my own personal goals for Rust in 2018. I am fortunate enough to work on Rust full-time; modulated by the work that needs to get done to accomplish larger team goals, these are some things that I’m individually very motivated to make progress on in 2018. [Read More]

## Unsafe Abstractions

Unsafety in Rust is often discussed in terms the primitive operations that can only be performed inside of unsafe blocks (such as dereferencing raw pointers and accessing mutable statics). I want to look at it from a different angle from these primitive operations, and instead focus on the capability to produce unsafe abstractions. The general concept of unsafe abstractions An unsafe abstraction is a new abstraction which requires the unsafe keyword to apply to some context (this is an intentionally “abstract” definition, because as we will see there are several highly divergent forms of unsafe abstraction supported in Rust). [Read More]

## Not Explicit

Oftentimes when I am conversing about the design of Rust with other users - as on RFCs or the internals forum - I witness a peculiar remark about “explicitness.” It usually goes something like this: I do not like Feature Design X because it is too implicit. Magic is okay in Other Language Y, but Rust is supposed to be an explicit language, so we should go with Feature Design Z instead. [Read More]

## Failure 0.1.1 released

I’ve just published failure 0.1.1 to crates.io. It’s mostly some incremental improvements to failure that have been suggested since the first release two weeks ago. Improvements to the derive A big change in version 0.1.1 is that the derive can be used without depending on the failure_derive crate separately. All that needs to be done is tagging the extern crate statement with #[macro_use]: // No direct dependency on failure_derive #[macro_use] extern crate failure; #[derive(Fail, Debug)] #[fail(display = "An error occurred. [Read More]