Jan. 2nd, 2013

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
On January 2, 2012 I started work at Mozilla as a seasonal employee working on the Rust team. In March, I was offered and accepted a permanent position, and as of today I've been full-time (which is to say, not an intern -- sometimes "full-time" gets contrasted with "contractor/seasonal", in which case my one-year anniversary wouldn't be for 3 more months) for one year. Post-master's-degree, I've had five different full-time jobs including my current one, and three internships including Mozilla, but I've never stayed at any of them for more than ten months other than Mozilla. I guess that says I like it here?

This year was full of more heartbreak, fury, grief, and difficulty than I would have ever expected to experience in conjunction with a job. On the other hand, working with the Rust team has been as much of a pleasure and a joy as I can imagine any compiler engineering job being. There's a change that I'm hoping to make happen early this year that I'm hoping will help me contribute more fully, but in the meantime, I'm just taking a moment to remind myself that I made it. Especially after how I got pushed out of grad school, it's been a relief to work with people who support me. Thanks to Dave, Graydon, Patrick, Brian, Niko, Alon, Donovan, Andrew, Jesse, Lukas, Christie, and everyone I'm forgetting about for the laughs/lunch companionship/collaboration/help/advice/IRC conversations/etc. Also thanks to the summer interns -- Lindsey, Paul, Eric, Brian, Sully, Ben, Margaret, Stephen, Elliott, and (again) everyone else I'm forgetting -- for bringing needed enlivenment to the office :-D
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
For Rust 0.5, which was released two weeks ago, we had a meeting a couple of months ago to set priorities. I can't find the wiki page that resulted from that meeting (I did find a note consisting of our suggested candidate goals, not the list of goals we actually came up with). But I do remember the two issues in the issue tracker that were supposed to be my priorities: pattern reform and labeled break and continue.

Back in November (or something), I decided that the best way to address pattern reform would be to make `let` and `match` share the same codegen path. I thought this would be easy, but it wasn't. Over a month later, I was still working on it. I gave up in frustration when we were getting close to the 0.5 release and I decided to work on blockers instead. So that meant I didn't finish pattern reform.

I sort of finished labeled break and continue, but there's still a bug open on labeled break not working from inside a `for` loop. I don't consider this a huge failure on my part. We implemented labeled break and continue for a very specific reason, which doesn't seem to require labeled break from inside a `for` anyway. From a "no arbitrary restrictions" language-design point of view, it would be good if it worked, but I don't see it as urgent. (The reason why it's hard is that Rust effectively implements `for` loops by desugaring into a call to a higher-order function. So a `break` out of a `for` loop actually jumps to a different stack frame -- hence, involves a `return` -- as opposed to a `break` out of a `while` or `loop` (infinite loop), which is really just a `goto`. The back-end has special cases to handle the unlabeled-`break` case, but I didn't understand the code well enough to extend it to labeled `break`s.) (Also, don't take the word "desugaring" there too literally, since the Rust compiler -- surprisingly for me as an ex-GHC-hacker -- preserves the AST in almost the same shape all the way down to codegen, keeping many higher-level constructs intact.)

Going back to pattern reform, one of the things that was hard about the refactoring I was doing was the need to account for where "cleanups" get introduced. At least right now, Rust uses a combination of automatic reference counting, and "owned" and "borrowed" pointers that don't require reference counting, to manage memory. There is a GC, but it's a last resort. So the codegen has a lot of very fiddly code that inserts "cleanups" that free up memory when the refcount of a shared pointer goes to zero or when an owned pointer's lifetime ends. If you get this code wrong, you get memory leaks, dangling pointers, or both, as I discovered many times. The codegen pass contains any number of undocumented invariants about where the cleanups have to go and when it's safe to cancel them or leave them out. Every time I thought I understood how it worked, I would discover one more case where I didn't understand. There's been some talk of getting rid of reference counting, but in the meantime I'm kind of disappointed in myself that I wasn't more aggressive about pursuing answers (either by reading code or trying to ask questions of the people who wrote it).

I've been wanting to spend some of my time extensively documenting trans (and the rest of the Rust compiler), but that's hard to do without understanding the code in the first place! Lack of documentation shuts out new contributors, especially new contributors who don't feel socially comfortable just jumping into IRC and asking questions. If *I* often feel uncomfortable asking questions about code, as someone who's been working on the Rust project for almost two years and knows everyone else on the core team, what would it be like for an outsider, especially one who isn't a middle-class white English-speaking guy like most of us on the core team?

So that's a summary of my last few months. For the new year, at least as of yet, my calendar seems to be wide open!


tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Tim Chevalier

September 2017

3 4 56789
10 111213141516

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags