We all know that classic aphorism: Year comes to an end, Rust blog post press send. This is mine. There are lots of cool technical improvements to Rust that I want the project to achieve this year, and a few in particular that I’m definitely going to be putting a lot of time into. But this blog post is going to talk about none of them. Instead, I want to talk about organizational debt, and how badly the Rust project needs to deal with it in 2019.…

This blog post is about a project called Romio that I’ve been working on over the past two or three weeks. Romio is a port of a small part of the Tokio project to the newer futures APIs. I started the project to get some experience porting code from the old futures API to the new API. However, we realized that this code could also be useful to other people who want to experiment with networking code using the new async/await syntax, so with the help of others we polished it up during the RustFest Rome “impl days” and now its being released for people to experiment with.…

One thing we’ve left as an unresolved question so far in the matter of async/await syntax is the exact final syntax for the await operation. In the current implementation, awaits are written using a compiler plugin: async fn foo() { await!(bar()); } This is not because of any technical limitation: the reason we have done this is that we have not decided on the precise, final syntax for the await operation.…

Rust 2018 is almost out the door, but there is one big decision the language team has yet to make. It has to do with the modules and paths system, so of course it is a very easy decision that no one has a strong opinion about. ;-) In Rust 2018, we’ll be making some big changes to how paths work to try to create a more consistent experience. The “lodestar” (if you will) of these changes is an idea we call “1path:” the idea no matter where you are in your project, whether in a use statement or normal code, a path is interpreted the same way.…

The post before this one covered how shifgrethor handles rooting: how we track for the garbage collector that this object is alive. That isn’t sufficient for implementing a tracing garbage collector though: the idea of a tracing garbage collector is that we can trace from rooted objects through all of the objects they reference. That way, instead of having to root everything you use, you can only root a few objects from which all of the live objects can be traced.…

After the digression in the previous post, it’s time to get back to what I promised in the first post: a look at how shifgrethor handles rooting. Shifgrethor’s solution is somewhat novel and takes advantage of some of Rust’s specific features, so I want to start by looking briefly at some of the other options. How to root a GC’d object There are two broad categories of rooting strategies that are common among precise, tracing garbage collectors:…

In the previous post I said that in the second post in the series we’d talk about how rooting works. However, as I sat down to write that post, I realized that it would be a good idea to back up and give an initial overview of how a tracing garbage collector works - and in particular, how the underlying garbage collector in shifgrethor is implemented. In the abstract, we can think of the memory of a Rust program with garbage collection as being divided into three sections: the stack, the “unmanaged” heap, and the “managed” heap.…

I’m really excited to share with you an experiment that I’ve been working on for the past 5 or 6 weeks. It’s a Rust library called shifgrethor. shifgrethor implements a garbage collector in Rust with an API I believe to be properly memory safe. I’ll be going through all of the technical details in future blog posts, so I want to kick this series off with a high level overview of the project’s purpose and design decisions.…

Evan Czaplicki, the creator and maintainer of the Elm project (a project that I love by the way) gave a great talk at Strange Loop last month called “The Hard Parts of Open Source.” I really enjoyed and valued this talk, and I encourage everyone who is involved in open source to watch it. You can find on YouTube here.

In particular, I got a lot of value out of his identification of three specific harmful patterns of behavior in the open source community, and of his geneological work tracing the origins of those behaviors through the history of the “hacker” subculture. I think I’m going to be utilising these patterns a lot when trying to understand unpleasant interactions I have in connection with my open source work.

In case some readers decide not to watch Evan’s talk, I want to highlight those three patterns here:

1. “Why don’t you just..” People sometimes propose solutions to problems that are very obvious, but have nuanced and non-obvious problems. Often, these proposals are made with an intonation that the project maintainers - who have thought about the domain a great deal more than the person making the proposal - have completely overlooked this obvious solution.
2. “On whose authority?” People sometimes will attempt to subvert and undermine the authority of project leadership. Sometimes they go as far as suggesting ulterior, untoward motivation for decision-making (usually having to do with the project’s financial sponsor). Sometimes they undermine the competence and capabilities of people leading the project.
3. “All discussion is constructive.” While the previous two patterns were forms of outright attack on project maintainers, this pattern is more subtle. It is the attitude which ignores the negative externalities of discussion, the way that producing more discussion content can be harmful to the project’s goals. Sometimes it goes so far as to say that discussion containing negative behavioral patterns is still constructivebecause behind the attacks there might be good ideas.

As I’ve said, I think Evan’s talk is quite good and worth watching, but I do have an objection, which is why I’ve written out this whole blog post. In the final segment of the talk, it shifts from disecting these social phenomena into a sketch of a proposed discussion platform designed with the goal of producing more positive discussions.

…

Today I realized a new crate called pin-cell. This crate contains a type called PinCell, which is a kind of cell that is similar to RefCell, but only can allow pinned mutable references into its interior. Right now, the crate is nightly only and no-std compatible. How is the API of PinCell different from RefCell? When you call borrow_mut on a RefCell, you get a type back that implements DerefMut, allowing you to mutate the interior value.…