• Async Cancellation and Panic

    When I last wrote about async cancellation in Rust, I touched briefly on the question of how cancellation interacts with panic. Mostly I left it as an exercise for the reader and left a rough sketch for how I thought it would work. More recently, Boats touched on the issue in a little more detail, but I think there are still a lot of open questions. In this post, I'd like to experiment with unwinding using my cancellation prototype and build on some of the previous work in this area.

    Read more...
  • How to Shrink Rust

    While doing some housekeeping on my blog over the weekend, I can across an ancient post by Patrick Walton. While I didn't realize it at the time, this post embodies what has become one of my core principles in program language design.[^spiky-blob] In re-reading Patrick's post, this quote stood out in particular:

    Language design tends to go in cycles: we grow the language to accommodate new functionality, then shrink the language as we discover ways in which the features can be orthogonally integrated into the rest of the system. Classes seem to me to be on the upward trajectory of complexity; now it’s time to shrink them down. At the same time, we shouldn’t sacrifice the functionality that they enable.

    This cycle of growing and shrinking as a key part of the process in the early days of Rust. Upon reading this section, I found myself asking "how could we shrink Rust today?"

    Read more...
  • Rethinking Rust's Function Declaration Syntax

    We had a fun discussion in #t-lang about possible new syntax for declaring functions in Rust. There were a lot of cool ideas put forward, and while mulling them over I realized a lot of them work nicely together and can be introduced in a backwards-compatible way to give us some cool new capabilities. While these were fresh in my mind and I'm feeling excited about them, I wanted to write them in one place.

    Read more...
  • A Mechanism for Async Cancellation

    One of the items on our Async 2027 Roadmap is to come up with some kind of asynchronous cleanup mechanism, like async Drop. There are some tricky design questions to making this work well, and we need to start thinking about these now if we want to have something ready by 2027.

    In this post, I'd like to explore a low level mechanism for how we might implement async cancellation. The goal is to explore both how an async executor1 would interact with cancellation, as well as to make sure that this mechanism would support reasonable surface-level semantics. You can think of this as a kind of compilation target for higher level features, similar to how the Rust compiler lowers async fn into coroutines.

    Read more...
  • Cancellation and Async State Machines

    If you've been doing async for a while, you've probably heard someone say something like "the compiler takes an async function and converts it to a state machine." I want to dive into this more, since we can think of cancellation as making the state machine more complex. In this post, I'll show how to build a state machine for a simple async function. Then we'll we'll see how the state machine changes if we want to be able to run async code during cancellation. Finally, we'll explore some of the design space around cancellation, particularly what happens if a future that has been cancelled is cancelled again, and see how state machines can suggest several possibilities.

    Read more...
  • Ideas on How to Elect Rust Project Directors

    One of the first tasks for the Rust Leadership Council is to elect new Project Directors. But before we can do that, we need to create a process for doing so. To do this, and in the spirit of delegation from the Leadership Council, we've formed a smaller group to focus on designing this process. This group so far consists of myself, Jane Losare-Lusby, and Ryan Levick.

    We have the beginnings of a proposal, but I wanted to write it up in my own blog to help make sure I understand it. Note that this is a draft proposal at best at this point and nothing is set in stone. I also want to recognize Jane's work in coming up with this process. This is largely based on her initial suggestion and I want to make sure I'm not taking credit for something I didn't come up with. But, any failings in this post should be viewed as my own and not hers.

    Read more...
  • An Exercise on Culture

    A few days ago at work we did an exercise on company culture that got me thinking so I thought I'd share some of those thoughts here. I've been interested in organizational culture for a few years now. Some organizations seem to have a great culture while other organizations have a not so great culture. Sometimes culture is improving, and other times it is declining. The declining case can be particularly frustrating because in my experience everyone can see it's getting worse, everyone wants to change it, but nobody knows how.

    One of the reasons I chose to come work for Microsoft is that they seem to be one of the few examples of a large, established organization that intentionally and dramatically changed their culture. I've been curious how they did that, and what other organizations can learn from that.

    It seems like an important part of it is to have regular conversations about culture, such as by doing exercises like the one I'm going to discuss in this post. So with this background in mind, let's talk about the exercise.

    Read more...
  • I'm Here to Serve

    Today we announced on the Rust Blog that the Leadership Council has been created and is now the top level governance body of the Rust Project. I am the Compiler Team's representative to the Council, so I wanted to share a little more about how I hope to approach this role.

    The Leadership Council is new, and in many ways its first tasks will be to define what it is. We know it's sort of a replacement for the Core Team, but it's also supposed to be significantly different. A lot of our first tasks are going to seem relatively mundane: figuring out when we regularly meet, how to propose items to the agenda, how we communicate what we're working on, etc. After that, we can get on to the "more substantial" questions. One colleague of mine told me once that Rust has at least two years of governance debt, and given that they said that two years ago, at this point we probably have at least four years of governance debt!

    While we figure these things out, I know there are a few things I can say about myself and values, and how I hope I can bring these to the Leadership Council. Keep in mind that these are my own opinions. I'm not speaking for the Leadership Council or the Compiler Team, so the priorities I suggest here will evolve over time.

    Read more...
  • Lightweight, Predictable Async Send Bounds

    The last week or two has been exciting in Rust async land. We're making great progress on one of the open questions around async functions in traits, and I think we're close to being ready to propose something officially. In this post, I'd like to describe the proposal and discuss some of the tradeoffs and open questions with it.

    We've had a couple of ideas going around so far. One of the main ones is Return Type Notation (RTN), which Niko describes in his recent post. In my last post, I suggested that we could infer the necessary bounds in many cases.

    While I was excited about inferring bounds at first, one major shortcoming is that it creates new semantic versioning hazards. The inference depends on the body of the the function you've annotated, which means when modifying the function you could easily add or remove bounds from the signature by accident.

    In the discussions we've had since then, we have been converging on a solution that we expect will work in the common cases, but avoids both the verbosity inherent in RTN and the semver hazards with inferring bounds. This is the solution I'll be describing in this post.

    Read more...
  • Inferred Async Send Bounds

    One of the issues we're working on with async functions in traits for Rust is how to attach Send bounds to futures returned by async methods. Niko Matsakis has been writing on this subject recently, so if you haven't seen his posts, definitely check them out! His first post outlines the problem, while the second post introduces a possible solution: Return Type Notation (RTN). I'm going to write this post assuming you're familiar with those.

    I'm mostly a fan of the proposed return type notation. It's a very powerful feature that gives a solution to the Send bound problem but is also generally useful in other cases. There are some significant shortcomings though, so I don't think it should be the only or even primary solution people reach for to solve the Send bound question.

    In this post I'd like to explore some more implicit approaches that address the issue while using much lighter syntax.

    Read more...
See all posts