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.…

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. Naming a project, tool, or concept that you want other people to use is a very hard problem. The most important thing, of course, is that the name sounds cool. Then, significantly less important, but still quite important, is that the name convey useful information to your users. This is where things get tricky. There are tons of different kinds of cool birds and sharks and reptiles we can name our projects after, but only some of those names also convey information to our users.…

A few months ago we introduced the concept of “pinned” references - pointers which “pin” the data they refer to in a particular memory location, guaranteeing that it will never move again. These are an important building block for certain patterns that had previously been hard for Rust to handle, like self-referential structs and intrusive lists, and we’ve in the process of considering stabilizing the API. One thing has always nagged about the API we have right now though: the proliferation of different reference types that it implies.…

Recently, I wrote a little a side project to sign git commits without gpg. When I did this, I decided to use the Rust 2018 edition. I also transitioned an existing library from Rust 2015 to Rust 2018 to see how that tooling worked. I thought I’d write a blog post about my experience using the Rust 2018 preview and the state of things right now. Module changes The main thing I noticed vividly was the new experience of the module system.…

Unlike most git users, I try to sign my commits. Unfortunately, the only way to do this right now is to use PGP signatures, because that is all that git is able to integrate with. This has meant that in practice I have to use GPG if I want to sign my commits, an experience I do not relish. Last week, I wrote a program to replace GPG for that purpose.…