On this page:
Building Extensible Systems

Building Extensible Systems


Over the past few years, Mozilla has developed Rust, a new systems programming language. Mozilla is about to release the alpha version of the language. In this course we will jointly study and explore the Rust language.

Rust aims to make systems-level (C/C++) programming safe. Here safety means both memory safety and concurrency safety. That is, programs can manipulate memory almost as freely as C-level programs but cannot accidentally corrupt memory, and programs can spawn parallel threads but cannot suffer from race conditions. Both goals are achieved with a sophisticated type system.

The challenge is whether programmers can understand and work with this type system to build systems or modify existing ones. This course is the first university-level attempt to answer this question. [Don’t worry, you are not alone. Several companies have already used Rust in production code, including for game servers, operating systems, and web browsers.]

Students are expected to know some C/C++, Java, and the fundamental differences between these two languages. The course will also rely on basic memories from Fundamentals I, II, and Logic.

The course will involve a significant writing component.



Fri Apr 10 13:41:01 EDT 2015

For your final project presentations, we recommend you spend your 25 minutes as follows:
  1. explain the purpose of the existing code base and the original goal of your project; if you had to cut back or change goals, say so [1min]

  2. recall the functionality of the existing code base, how to use it, and briefly demonstrate it [4min]

  3. demo what you accomplished [5min]

  4. describe the pre-existing code base, focusing on those modules with which your Rust code has to interface and/or the Rust code replaces [5min]

  5. show-case your Rust extensions

    Do not simply walk us through the code line by line.

    Start with an overview of the key pieces—relating them to bullet 4—and then focus on those parts of the Rust code that posed problems—both in terms of integration and performance [10min]

The ordering is approximate as is the suggested timing. In particular, you may wish to move the third part to the end of the presentation if this simplifies the flow. Similarly, you may wish to cut time from the second bullet and shift it to the last one.

Do keep in mind that we will have a guest who knows Rust but does not know what your projects are about and what your plans were.

Also, think of the request to repeat some of your initial presentation as a chance to improve your presentation skills.











Kelly & Nimick





Furtado & Ukani









Corbett & Lin





Coates & Silva







Cheung & Jensen





Bower & Kolek









Boehman & Tran





Good bye, grades

The breaks are for slippage, set-up, and technical problems with overhead projections, etc. Do not plan on these extra minutes for your presentation.

Fri Apr 3 09:55:51 EDT 2015

Please see addendum at bottom of Reflective Essay.

Wed Apr 1 21:23:46 EDT 2015

As announced in class, here are the basic changes to the syllabus:
  • On Monday, we will wrap up the Rust-C interaction segment. We will reserve some time for general questions on Rust topics that have come up while you have been working on your project.

  • The new due date for submitting the project is April 10.

  • Use the additional time to get further feedback on your memo. Some of you need this feedback more than others; you know who you are.

  • You will present the projects on April 13 and 20. Instructions on how to present the projects will appear here.

  • I have also rewritten the last homework (Reflective Essay). Take a look.

The changes are also reflected on the relevant individual pages.

Thu Mar 26 10:12:42 EDT 2015

Reminder: tomorrow is the deadline for turning in drafts of your project memo to Ms. Biron. Submission of an electronic copy is fine. If you need an extra 24 hours, sending in the draft by late Saturday is acceptable.

Please hand in your draft together with (a copy of) the marked-up copy of your original project memo.

Following the outline of last week’s presentations, here is how your memo should revise and extend the memo on the chosen code base:
  • a description of the purpose of the code base;

  • the original goal of your project;

  • a description of the organization of the code base, as relevant to the changes that you are implementing;

  • a write-up of your accomplishmentsDo not write up a history of your activities; assess your successes and failures., that is, what you actually did;

  • a description of your failures, that is, discrepancies between your goals and achievements.

Do not address the short-comings of Rust unless they critical contribute to a substantial failure.

Fri Mar 13 17:14:08 EDT 2015

Here is what we expect from your project introductions in bullet form:
  1. present your code base from a client perspective:
    • what does it do, overview

    • how do I use it, concrete examples, demo if possible

    • what kind of role do I play when I use it

  2. what does the code base look like from the inside:
    • what are the key modules, architectures

    • how do they collaborate, process

    • which ones do we need to know about from the perspective of this project?

  3. what do you wish to add to this code base? abstractly, examples, like bullet 1 above

  4. how will you go about it? Which modules does my extension hook into? How?

Dedicate about three quarters of your time (20 minutes) to the first two bullets and the remaining time to the last two.

Thu Mar 12 17:40:18 EDT 2015

Here are the code snippets from the concurrency lectures:

Thu Feb 26 10:02:32 EST 2015

See below for String.

Wed Feb 25 19:22:05 EST 2015

Here are the most obvious rules of Rust program design:
  • Any place you could return a new array, an iterator is probably better. (Think of iterators as optimizing arrays for one-pass access.)

  • Methods should take arguments (except for small Copy types) by reference, except when they actually need to take ownership. The only reasons to take ownership of an argument are to send it to another thread, to store it in a data structure for later, or to destructively consume it (à la into_iter).

  • Methods should take immutable references unless they actually need to mutate.

  • The difference between &mut String and &mut str is that the former is a string buffer with dynamic size, whereas the latter has fixed size. Methods should take the latter unless they need to change the size, because the former can always be viewed as the latter by the client.

    (There's no use for &String for which &str isn’t better. [The exception is String::capacity(&self).])

    As the manual says for std:str, ``String is used for an owned string.''

  • Clone when you need to both retain and give away ownership of something. (Typically this creates two copies of its mutable state.)

    Cloning is the caller’s job, not the callee’s.

  • Boxes are for recursive data structures and owned trait objects, not for passing arguments or returning them.

  • Use generic types whenever possible. For example, if your method takes a &mut BufferedReader<StdinReader>, but the only method used is lines(), then have it take &mut B where B: Buffer instead.

Mon Feb 23 15:19:18 EST 2015

You will receive the graded project memos tonight. The grade consists of three components:
  • the proposed project

  • the organization and content, i.e., the description of the project and its code base

  • and style items, ranging from sentence organization to choice of words, from grammar problems to layout.

Each part is worth 5 points for a total of 15.

A project memo should have the following organization:
  1. The opening specifies the project that you wish to extend, describes its purpose, and indicates how you wish to modify its functionality.

  2. The middle supplements the project description. It also explains how the project’s code base is organized.

  3. The third part identifies a missing piece of functionality. It should list its purpose and sketch its workings.

  4. The last part sketches how you will go about adding the functionality to the code base, making references to terms introduced in step 2.

The four parts may or may not correspond to four paragraphs. For example, for some projects, it is possible to collapse parts, especially the first two.

Here are some common small problems with your memos:
  • Leave a one-inch margin all around. It makes the page readable.

  • Add a noun to uses of "this" and "these." Otherwise the reference remains unclear.

  • Avoid "there is" and "there are". Certainly don’t pile them up.

  • Use colons ":" to introduce enumerations.

  • Reserve "you" for the recipient of the memo.

    Note I understand that, outside of computer science, the word "user" is reserved for consumers of illicit drugs. But the usage is common now, so get used to it, too.

  • The word "however" is used to switch a paragraph’s line of argument from support for its thesis to a different/opposite point you wish to make in the following paragraph.

  • An m-dash consists of three hyphens and is attached to the surrounding words.

  • Replace "they" with "he/she" if you wish to accommodate the gender police. Otherwise you are likely to write sentences whose subject will fail to match the verb in numbers.

Thu Feb 19 19:20:44 EST 2015

As announced, we will hold a

make-up class tomorrow (Friday) evening at 6pm in WVH 166

Thu Feb 19 19:20:44 EST 2015

As announced, we will hold a

make-up class tomorrow (Friday) evening at 6pm in WVH 166

Wed Feb 18 13:27:26 EST 2015

Someone asks:

What’s a letter?

We answer:

At the information level, let’s define letter as a .. z and A … Z. At the data level, choose the natural representation.

Someone else asks:

And in this context, how should we deal with apostrophes?

We answer:

Consider them as word terminators.

Fri Feb 13 10:09:19 EST 2015

Keep those dates open.

To: All Faculty

From: Stephen W. Director, Provost & Senior Vice President for Academic Affairs

Date: February 13, 2015

RE: Options for making up classes cancelled due to snow closings

As a result of winter weather conditions, classes on the Boston campus have been cancelled five times this semester, including two Mondays, two Tuesdays and one Wednesday. Because there are a number of Monday holidays during the Spring Semester, cancellation of Monday classes due to snow has had the greatest impact on the educational program. We appreciate the efforts of many faculty members who have already begun to make accommodations to assure that students learn all that was planned within each course.

While a number of courses have already scheduled make-up class sessions and course activities on an ad hoc basis, we will be using both Patriots Day (April 20, 2015) and Reading Day (April 23, 2015) as opportunities to schedule missed classes. To schedule a time for your class to meet during either of these days, or at another time that may work for you and your students outside of your assigned class hours, please use the Special Room Request Form found at www.neu.edu/registrar/schedfrms.html. The Registrar’s office will respond quickly to requests but will give preference to those classes that would have normally been scheduled on a Monday.

We recognize that the unprecedented snowfall has created a strain on all of our programs and there is no one solution to address this strain that will satisfy everyone. However, after a number of discussions with the academic deans, we feel this is the best alternative and we do appreciate everyone’s patience.

Thu Feb 12 09:42:53 EST 2015

Most of you came to see Jesse and me and got feedback on your proposed project. For the memo that is due tomorrow, please drop off the paper copy but also send Ms. Biron an electronic copy (PDF, Doc, etc) so that she can mark that up in case the weekend storm really comes through.

Recall that the primary purpose of the memo is to
  • specify the chosen code (external purpose statement),

  • describe its internal organization, and

  • state the goal of your Rust extension.

Convince the reader that you have thought through this project and that it is a good choice—via descriptive language, not unjustified subjective adjectives.

For those of you who are still struggling with this choice, the ideal project is something people can download, run, and interact with (e.g., piping files into it, text console, or GUI interface). Your Rust extension should provide some additional functionality to such a project that becomes optionally visible. Typically this goal calls for small changes to the C code base, a Rust module, and a carefully constructed interface between the former and the latter.

Tue Feb 10 16:39:49 EST 2015

We have blocked out four hours for you to consult with us on your current ideas about a project:

tomorrow (Wedn. Feb 11) from 3pm to 7pm in WVH 308b

Please make use of this time to discuss your ideas with us so that the draft memo and revision step can be productive.

Mon Feb 9 22:24:28 EST 2015

During Friday’s lecture I mentioned a paper on turning profiling information plus information from the depth of the compiler into a useful tool. For those of you who wish to find out more, here is a pointer to the paper:
As a teaser, Mozilla has adapted the idea and is in the process of integrating an optimization coach into their SpiderMonkey JS engine.

Also note, if the T is running again on Wednesday, I will run an "open house" for advice on your project selection. Please watch this space for specifics.

Sat Feb 7 15:30:05 EST 2015

As requested, I have asked Systems to install Rust and Cargo on their Linux systems, and they have already done so. When you see a Systems guy, thank him for the group’s prompt services.

Thu Feb 5 2015

As announced, we will hold a

make-up class tomorrow (Friday) evening at 6pm in WVH 366

Wed Feb 4 2015

Jesse has type-set his lecture notes on lifetimes and borrowing.

Here is a question related to the one from yesterday.

Given this code snippet,

  use std::collections::HashMap;


  fn main() {

      let s = & String::from_str("hello");

      let h = create_string(s);





  fn create_string<'a>(s : & String) -> HashMap<&'a str, usize> {

      let mut hm : HashMap<&str,usize> = HashMap::new();


      return hm;


Why does this fail with a message about "not being able to infer the correct life time?"


The answer is that

You can see that the life time parameter a shows up in the result type but not in the argument. So, how can s can possibly be used to create a string slice that survives long enough?All string constants are string slices with a static life time. That is, the compiler hoists them out and creates a unique pointer for them—like for symbols in a Lisp-style language.

Now fortunately, the compiler provides a rather suggestive error message and following this message corrects the mistake:

  fn create_string<'a>(s : & 'a String) -> HashMap<&'a str, usize> {

      let mut hm : HashMap<&str,usize> = HashMap::new();


      return hm;


If you combine the two questions (the one from yesterday and the one from today), you get a rather confusing error message.

Tue Feb 3 2015

Someone asks:

Also, apparently our selection of the final project is due on Friday? I’m not really sure what the criteria is for what we select. The three projects you listed don’t particularly interest me, but if I wanted to find another, what sort of attributes should we be looking for?

We answer:

We welcome any project
  • whose source is in C (or C++ if you know enough to read the relevant part of the source),

  • that appeals to you in some way, and

  • for which you can think of some functionality that you would like to add.

Someone else asks why Rust complains about the following snippet of code:

  fn parse_lines<'a, R: Reader>(mut reader: BufferedReader<R>)

                     -> HashMap<&'a str, usize> {

      let mut wordcounts: HashMap<&str, usize> = HashMap::new();



The short answer is

that the string slices that get stuck into the hash map are created within parse_lines. By using String instead, this function gets through the borrow checker.

Sat Jan 31 2015

Last night we did not get to code-walk my conventional-looking solution for Counting Words. Please do take a look just so you understand that you can code in Rust in a style close to the one you know from courses using C or C++—even though Rust is a language that emphasizes functional over imperative programming. (That’s not news to PL researchers; years ago people started publishing books on "functional programming in C" but old-fashioned academics and overbearing industry habits revert even the best-trained graduate into a 1970’s coder.)

Thu Jan 29 2015

As announced via email on Monday, we will hold a

make-up class tomorrow (Friday) evening at 6pm in WVH 366

Sun Jan 25 2015

After grading the memos/essays, I have added a section on Notes on Writing to the course site. It includes suggested readings, notes on how I evaluate your writing, and a sample essay on my favorite language. I urge you to read these hints because the remaining writing tasks are of a similar nature.

Note that the grade is primarily a judgment of how well you can articulate your points, how well you can organize them, and how directly you can support the chosen points. Secondary are flow/style, grammar/typos, and content, though if you call something "red" when it is completely "blue" I will deduct points.

Obviously the grade is completely independent of your choice of favorite language. When I ask you to pick and describe your favorite language, I will not call into question what you choose.If you ask me for my opinion about your reasoning, I will explain to you why you are wrong. In case you are curious, essays on both Ruby and Python received 10/10 grades as well as failing grades—so no, the grade also doesn’t depend on which language you choose.

Oh yes, and do read course announcements.

Sat Jan 17, 2015 Ms. Biron shared some snippets with me:
  • "Python is like a tupperware container, you can put soup or a chicken sandwich in it."

  • "Javascript is clay, she has borne children, she flirts."

These kinds of comparisons are not what your manager would look for. We are looking for descriptions of languages, which may contain an occasional "poetic" comparison but those must be kept concise and not used as thesis statements.

Wed Jan 14, 2015

Someone asks:

For our Building Extensible System’s essay assignment, are you expecting something that sway’s more towards the "poetic" side (for the average reader) or do you want it to be purely technical.

We answer:

The choice is yours as long as the essay is descriptive not judgmental. "The car is red" is good, "the car has beautiful curves" is bad. Okay?

Sat Jan 10, 2015


Please reflect on all the programming languages you have experienced in the past. Then pick your currently favorite language and make sure it is installed on your laptop. Bring (1) a letter-size sheet with the name of your chosen language and (2) your laptop to the first meeting. Fold the sheet and place it front of you on your table/desk/chair in class. We will conduct live-coding sessions in these languages.