⊕ Update 1 July 2019: fixed bugs in EscapingWriter and as_reader examples.

Update 8 July 2019: fixed a new bug in as_reader example.

Hey there everyone!

It has been literally years since I last posted to this blog. I have been doing a bunch of Rust compiler work. One big feature has been deployed: Non-Lexical Lifetimes (hereafter denoted “NLL”).

The motivation for this blog post: The next version of Rust, 1.36, is going to have NLL turned on for the 2015 edition. Going forward, all editions of Rust will now use NLL. That is a big change. It is mostly a change that empowers developers; but it also is a change that will cause some existing code to break.

This post is going to talk a little bit about what NLL is and why you as a Rust developer should be excited about it as a feature (because it enables programmers to express themselves more directly).

However, even though the main feature of NLL is to increase the set of programs that Rust accepts, the vast majority of this post will focus on cases where the switch to NLL has caused the compiler to start rejecting ⊕Rejecting unsound code is also a Rust feature that I value highly; but it often fails to excite developers, especially when it causes their legacy code to stop compiling. code that it used to accept erroneously.

This is the second in a series of posts will discuss why garbage collection is hard, especially for Rust, and brainstorm about solutions to the problems we face.

The previous post wrote down some criteria for integration. Now I want to delve into why satisfying those criteria is hard, at least in Rust as it stands today.

I have had some thoughts on what privacy is used for in programming languages, and how it differs from the notion of dependence between modules (or at least compilation units) in a language like Rust. And I thought I should share.

Learn how I hacked the SCSS for my blog to get tables to look right, without breaking everything else (I hope).

This post: I describe some changes to my blog’s presentation format, and how I hacked them in by cherry-picking from the shoulders of giants.

This is the first in a series of posts will discuss why garbage collection is hard, especially for Rust, and brainstorm about solutions to the problems we face.

The relationship between garbage collection (GC) and the Rust programming language has been an interesting one.

GC was originally deeply integrated into the language, complete with dedicated syntax (good old @T …). Over time the team found ways to lessen the dependency on GC, and then finally remove it from the language entirely.

However, we still want to provide support for garbage collection.

To explain why, I need to define the actual problems we seek to solve. So let us explore the problem space.

This post is a prequel to a series of posts discussing why garbage collection is hard, especially for Rust, and brainstorming about solutions to the problems we face.

The goal of this post is to provide the background foundational material about Garbage Collection that the other posts will then build upon.

This is a post discussing a couple different ways to draw pictures, mostly those of graphs (nodes and edges, i.e. circles or boxes, and lines between them).

The technology covered by this post is viz.js, a Javascript library for rendering graphs specified via the DOT language.

Executive summary: type = unsized ⊎ sized, so we should use type as our generalization marker, not unsized.

I decided this morning to write a blog post related to Rust. I have not posted to this blog in months, and in the meantime I had upgraded this computer at home to Mac OS X Mavericks (10.9.2).

So of course my existing set of commands for Octopress workflow did not work.