Rust Made Easy – Part 1

Edited on 2013-04-03: This page is outdated.

Rust is a prospective language which just had its version 0.1 released, and coming from a background that does not hail from C or C++, learning it seemed quite daunting. Starting off writing Java in college and digesting Python in my free time helped, but just a little. Since I previously had some time on a plane and not really sleeping, I’ve been looking at ways to simplify learning Rust, and hopefully by guiding you, as a reader, along the way will help us share our experiences and enhance learning opportunities for all.

But seriously, what is Rust? You can find a short write-up here, along with things like not allowing null pointers (Yay! no more null crashes). Various other technical bits are way above me now. Nonetheless, follow the instructions to obtain your Rust compiler. In the following examples, save the code snippets in a test.rs file, renaming “test” to whatever you like as long as it still ends with .rs, compile it with the Rust compiler “rustc test.rs” and then execute the compiled file “./test”.

Alright, so let’s dive into Rust. To print a statement, let us understand that we first have to import a standard library or a module, known as std.

use std;

It’s like including iostream.h in C++.

Once we’ve done that, we can now print a statement:

use std;
fn main() {
    std::io::println("Hello World!");
}

to get:

Hello World!

(In Python, it is the equivalent of “print ‘Hello World!”)

In Rust, it is necessary to have a main function. The double colons “::” mean that it is calling println within module io within the std module. It’s similar to System.out.println in Java. Note that semicolons “;” at the end of the lines seem to be necessary most of the time — there are special circumstances where “;” is not needed at the end, but let’s leave that for later.

How about a number? I would like to create a local variable, which is a number, and print it. In this case, we use `let`:

use std;
fn main() {
    let x: int = 8;
    std::io::println("Our number is: " + int::str(x));
}

Two new things here. One is “let x: int = 8;”, which means create a local variable x of the type int, and set its value to 8. Again, there will be situations in the future where you leave out specifying the type, and in those cases the type will be inferred (the compiler will “guess” the type).

Second, note that we cast x to a string before printing it. In Rust, we cannot print a number without first changing its type to a string. This is done by calling str from the int module and passing in x, so we have “int::str(x)”.

You should get the output:

Our number is: 8

You may have noticed that Rust uses shortened keywords, such as “fn” for a function. It also uses “ret” for returning values. We will see more of this as we go along.

Next up, let’s construct a separate function instead of cramming everything up in main, and have it print our favourite number again:

use std;
fn fav_number(n: int) {
    std::io::println("Our number is: " + int::str(n));
}
fn main() {
    let x: int = 8;
    fav_number(x);
}

You may notice that the fav_number function accepts an integer variable n, and this is reflected by “n: int”.

What if we want to pass in our favourite number as a command-line argument? This is done by:

use std;
fn fav_number(n: str) {
    std::io::println("Our number is: " + n);
}
fn main(args: [str]) {
    fav_number(args[1]);
}

Run this with “./test 8” and you should get the same output as above:

Our number is: 8

Remember to run it with a number as an argument – if you leave out the number, you will get an error:

rust: upcall fail ‘bounds check’, test.rs:6
rust: domain main @0x22a1a50 root task failed

Examine this example more closely and you will realize that there is no casting involved. This is because we are taking in the argument (number) as a string, and merely printing it out again.

Fuzzing at Mozilla brown bag on January 30, 1pm PT

Fuzzing [1], a form of randomized testing, it is an integral portion of the testing process at Mozilla. Crashes, hangs, assertions and various security problems, such as memory safety problems, are discovered through fuzzing [2].

Thousands of bugs in Mozilla applications have been found using fuzzers. In particular, 3 of the fuzzers have been responsible for more than a third of critical security bugs.

Drop by on Monday, January 30, at 1pm Pacific Time in 10 Forward, where we will host a brown bag session sharing a high-level overview on how fuzzing is used to discover these issues and how you can help us find more bugs.

The brown bag should be available on the public Air Mozilla ( https://air.mozilla.org/ ) and archived here.

See you there!

Gary Kwong
Mozilla Security Research and Testing

[1] http://en.wikipedia.org/wiki/Fuzzing
[2] http://www.squarefree.com/categories/fuzzing/

How one learns from his students in his very own class..

The third semester of teaching CS3108 (Mozilla) is coming to an end. For those of you new to the course, it is one that I guide students at my school, National University of Singapore, where I am currently finishing my third year of undergraduate studies. (Kudos to Professor Lee Wee Sun for supporting me over the many months, as well as others I haven’t mentioned)

Over the past semesters, I have welcomed student feedback on how I can make the course better and more exciting, at the same time remaining its flexibility in allowing students to fulfill their dreams at working on a large open source project.

Some of the feedback have been interesting. The first two batches came back with the opinions that each lesson have an overview of what the lesson should be about (I’m getting better at this, doesn’t seem to be a problem this semester), while there have consistently been queries asking about the CAP (GPA in other countries) required to take the course (which there isn’t).

As for the latter, my professors have been noting the trend that half the students in the first lesson of the course seem to disappear after hearing about the expectations. I am of the opinion that only the independent survive, because I am a student myself, I do not possess the opinion that the students be spoonfed material. I merely guide them along, in return for some wonderful projects that have happened over the past courses. To be honest, by the second half of the course, the students are usually much more well-versed than I am in their own area of interest.

Of course, I could always do better. This semester, there has been thought about how to obtain a student-project more easily, and this in fact has recently been mitigated with the introduction of the `student-project` keyword a while back. Interestingly, the students are also suggesting to give homework, not in the form of overly tough laboratory work, but rather short little quests. Such quests could involve writing a simple mozmill test to open a new tab, or even to use the DOM Inspector and find out the id of the Go button in Firefox, for example.

I thoroughly enjoy my classes at school. It is a great opportunity for the students to learn about the open source world, as well as a place where I can also learn from the students themselves, especially since some of their technical coding skills may be better than my very own. It brings forth the message of humility, where no one is above anyone else. I always encourage them to refer to the classes as “sharing sessions”, and to call me by name rather than “Professor”, “Lecturer”, or “Sir”, especially since I am none of the former.

I will continue to teach the course for another two semesters, till I graduate. Hopefully by then someone will take over, but till then I will continue to teach the class even though it does occasionally get tiring on top of my own university work. I thank my professors (Professor Dave Humphrey included), past and present students and members of the Mozilla community who patiently help out the students as they swim their way out of the deep end. The course has helped both the community (they get fixes) and the students (they get the experience – one past student did enough to get his name in official credits, another made use of the experience to set up his company, and a third finally may have found enough confidence to apply for a Google Summer of Code project).

CS3108 (Mozilla) will count as one of the biggest achievements that I am proud of, during my university days. I sincerely hope both the students and myself will benefit from this experience as we begin to look for jobs after graduation and step out into the real world.

NUS Student Projects – finalized for AY 09/10 Semester 2

This time, three students from National University of Singapore are taking on Mozilla projects across various disciplines, in no particular order:

Feel free to say hi to them if you spot them on IRC!

HOWTO: Edit Mozilla code in 5 minutes – make a simple change and see the results instantly

A few days ago, one of my professors at National University of Singapore asked me if I could provide a screencast of making a change to Mozilla (Firefox) code and seeing the change post-re-compilation, for a CS2103 course (that I didn’t have to take due to it not being part of my module requirements). I happily obliged though, and here is the screencast:

Screencast in swf (just under 4 minutes)

(Created using Jing, and I have no idea how to convert it to Theora, so apologies for that.)

Free for educational purposes only, please contact for other requirements.

NUS in Mozilla map of students around the world

Mark Surman has an interesting post over at his blog, where he maps the list of students working on Mozilla around the world. It’s amazing how Mozilla just started off in the education area not too long ago – and already encompasses ~14 schools worldwide now, from the North America to Europe, from Asia to Oceania. Kudos especially to humph for his great work linking up folks around the world.

National University of Singapore (NUS) has just finished CS3108 (Mozilla) a few weeks ago (the 4 folks being Yuen Hoe, Yaoquan, Hendrik and Tony), it will be taking a break over the next semester as I head overseas for an exchange program. I look forward to more students stepping into Mozilla development in the future.

Before I end here, I would especially like to mention that it really reaps returns and satisfaction of the highest quality, when students transform from someone totally lost to someone capable in their own right in the world of open source, within mere weeks, guided by folks around the world, with different timezones, different cultures.