--People are not important --

--There are no people in technology, 
just replaceable components --

(Laughter)

Alright let's do this.

Alright, I'm going to tell
you about what Rust is,

why Rust is a part of Mozilla's work

and when it's going to start 
being a part of Mozilla's work.

Let's begin.

So Rust is a new programming language

that has been created inside Mozilla

and shared with the outside world.

The goal of it

is basically

anytime when you traditionally

as a developer have

reached for C++

because you needed certain guarantees
about performance for example

we want Rust to be a viable alternative

in every single case.

There should be no reason to choose C++

over Rust

in the ideal future.

So it began as a side project

of a Mozillian named Graydon Hoare

back in before 2009.

He started working on it full-time

in 2009

because Mozilla saw the
ideas that he had and said

"We can see how we
could put this into Firefox...

...and make the product better
if we actually had this language".

So that's when we started investing
time and resources into it.

Fast forward a few years

we now have a team under
the Mozilla Research umbrella

who's working full-time
on improving the language

and we released
version 1.0 last year

and every 6 weeks we
now release a new version

so we just released 1.13

and there is a large community

around the language now

so not only do we have developers

working in Mozilla on it

some of those developers are part
of what's called the Core Team

and those are the people that
decide the future of the language

and help shape where
it's going as time goes on

so in addition to our employees

we have volunteers

and employees from other companies

that are now depending on
Rust for their products

and they're helping shape this ecosystem

which then has a large number of libraries

that are being developed by people

who are enthusiastic about the language

it's got a lot of downloads happening
since the last time I gave this talk

there've been 10 million more downloads
and 300 new libraries published

so there's a lot going on,
there's also the friends of Rust

which I'll show you

there is a page showing lots of different
companies that've told us

"Yes, we are relying on
Rust in production...

...we are very excited
about its prospects".

So, lots of cool things going on there.

So the reason for Rust

is that we have in the past

what 10 or more years of using Firefox

and Javascript in Firefox

sorry C++ and Javascript in Firefox

we've come across the fact that

there are some pervasive problems

that are caused by using C++

that is writing code that
makes use of local threads

is very difficult

it's easy to write incorrect code

and it is very easy to write
code which is unsafe

and that translates into

security exploits

things that are stored by governments

and by hackers

all over the world

and used to

steal data from users

and take over their computers

using the browser as a vector.

There's a huge number of these
that are released every year

by security investigators

and there's competitions showing

who can pwn a browser the quickest.

So we looked for ways to address this

by creating a new language

and it turns out

that actually both of these issues

make it difficult to write parallel code

that makes use of modern hardware

and writing code that is
safe and not exploitable

turns out they can both be addressed

by introducing the concept of
Ownership in the language.

So let's talk about what that means.

Ownership encapsulates two ideas basically

it is what the owner of a value is

and whether there are
multiple owners of a value

or mulitple users that are sharing a value

and additionally when that
value is actually valid.

What is the point in the program

in which it's actually safe
to interact with the value.

And so from this we can derive a few rules

that if there is only a
single owner for a value

that value can be destroyed
when the owner goes out of scope

because there are no ways to
reference that value anymore

similarly if a value
has only a single owner

that means that it is legal to mutate it

because no one can observe
the change to that value

and finally

if you have multiple owners

you need to have

something called Borrowing

which is, you still have a single owner

but other people can observe it

but it cant be changed during that time.

So let's talk about an analogy here,

if I've got a colouring book and a marker

and some friends

we can establish some rules

the colouring book and
the marker are my property

so they go with me wherever I go

if I leave no one else can
observe the book

or colour in it

however I am able to loan
the book to someone else

and that means they're
borrowing it from me

that also means that I can't colour
in it while they're borrowing it

because that's rude

so they can also choose to
lend it to people around them

but that means that if
anyone else is borrowing it

they need to give it back
to me before they leave

because it's my property

and only I can leave with it.

Additionally,

if I have the marker

I'm able to colour in the book

if I have the book

I can also give the marker to someone else

and that means they can colour
in the book if they have it

but that means that I'm
no longer able to colour

because there's only a single marker.

And finally,

if I want to leave but I dont actually
have the book in my posession

there's a problem, either I need to wait
until someone gives me the book back

or I need to actually give
it to someone else and say

"OK, it's not my property anymore,
...it's yours to deal with".

So Ownership in Rust.

If we have a type we call a ColouringBook

and it gives us a constructor

that returns a new instance
of a ColouringBook.

We can say OK,

here is a variable called a Book

which we will say

stores this ColouringBook value.

That means that we can now

call this Colour method

which will change the
Colouring Book in some way,

it'll colour in it.

That's fine, we can mutate it

because we only have a single owner.

So what happens if

someone borrows the Book?

We now have another variable
called Borrowed Book

and we use the ampersand

to show that we are borrowing the value

that's stored in this value called Book

- this variable called Book.

This is an Immutable Borrow.

That means that it is not possible

to mutate the original value anymore

because it's borrowed.

So we cannot colour in the book

while it's borrowed by someone else.

This follows our analogy.

The other thing however

is that if someone else is
borrowing the book,

they also cannot colour in it.

They don't have the marker.

In this case they only have
an Mutable Borrow

so they cannot mutate it.

So we can work around this

by using what's called a Mutable Borrow.

This says OK,

give me the book and
give me the marker

and then they have both those elements

necessary in order
to actually colour in it

and mutate it in this case.

So we have the ampersand

followed by the Mute keyword

and this means

give me a Mutable Borrow

to the value that follows.

However the thing to note here

is that we cannot use
the original variable

called Book

in order to mutate it while it's borrowed.

We cannot have two different
people colouring in it

because only one person
can colour at a time.

So let's go back to the
example we had before.

So we've got a Book value

we're allowed to colour in it

because there's no one borrowing it

then on the next line

we have an Immutable Borrow

and we're not allowed to colour

in the original one again

this is fine

it's borrowed

it can't be coloured in.

So let's fix this

this is where we talk about lifetimes

because remember how I said that

we can figure out
when a value is valid?

So this means that if we have a scope here

deliniated by

the curly braces

this means that inside the curly braces

anything that is unique inside there

no longer exists outside of them.

So if we create this Borrowed Book value

and we borrow from the Book value

we have a Mutable Borrow

and that's fine

we can then do something with this

that doesn't require mutating it

we can just look through the
Book, we can investigate it,

and that doesn't mutate it, that's fine.

And so previously calling Colour
on the original Book value

would've been an error

because it was borrowed

but now the borrow no longer exists

because it is only valid within
the scope of these braces.

This is how we can control

the scope of a Borrow.

So finally we can also transfer Ownership.

This is how we talk about giving
away the Book to someone else.

By default we can say OK,

we'll create a new variable called Book 2

and it will have the contents
of the Book variable

and we can now colour in Book 2.

That's fine, it's not a borrow
there's no ampersand there

we are giving control of the value

to another variable

and additionally

if you try to compile this
you'll note that

we can no longer interact
with the Book variable

because we transfered Ownership

it doesn't exist anymore

the compiler knows this and can say

"Nope, that is not safe
what you're trying to do".

And you'll note the link up here
actually goes to a playground

where you can play with the
Rust compiler in your browser

and there's a sample for this code
that you can experiment with there

already prepared for you.

So

we understand Borrowing
a little bit better now

especially with the analogy

but how does this
actually help in practice?

How does this address the two
cases we talked about before?

Using values after they're no longer valid

and writing code that works with
multiple threads at the same time.

So first

with Use-after-free problems

those happen in C++

because you'll have pointers in your code

but the pointers are not associated

with the value they're pointing to.

So you could delete

the memory that they're pointing to

but the pointers are still
pointing at that memory

and so if you aren't careful
you can end up using pointers

that are pointing to invalid memory.

So in Rust

the compiler is actually tracking this

so it doesn't let you write code

that has the potential

where pointers could point at
memory that no longer is valid

and that means that

you're always taking
borrowed pointers to values

where the compiler says

"OK. I know exactly how
long this value is valid for...

...because I know what the owner
is and therefore any pointers to it...

...must no longer exist before
the owner no longer exists"

and additionally

you can also

because the Rust compiler also
tracks outstanding Borrows

you can also say

"OK, we are guaranteed that
there's no way to mutate this...

...while anyone else is borrowing
and trying to look at the value"

and this addresses another case

where this can happen in C++

where you end up changing the value

like reallocating a pointer or something
while other things are trying to point to

memory that it was relying on

and as for parallel code
with multiple threads

the issue arises with Data Races

where you have multiple threads

that are sharing values and
they're also mutating them.

It's the same issue we
just talked about basically

where they're not
coordinated in figuring out

when it's safe to write to a value and
when it's safe to read from a value

because you might get intermediate values

when the write hasn't completed yet.

So Rust addresses this by forcing you
to either transfer ownership of values

that another thread needs to use

so that two threads cannot
share the same value

or

ensuring that any values that you
do share between the threads

abide by certain restrictions

that prevent invalid writes from happening

and invalid reads from happening

so that races can't happen

and it's impossible to write code that
is not actually thread safe.

So

how this actually applies

to what we're doing at Mozilla

is that we've got the Mozilla
Research organisation

and so part of them are working
on improving Rust the language.

However another part of them

are working on building a
brand new web browser

because Firefox is not enough.

This one's called Servo

and so we're building it
from the ground up

and the reason we're doing this is that

there are decisions that were made

design decisions for Firefox

that were made a decade ago

which are very difficult to
change at this point in time

it'd be a huge amount of work

to redesign parts of Firefox
we think could be better

but it's also difficult

to verify whether that would be

a worthwhile use of time
without actually doing it

so we compromise by creating
a brand new browser

where we can actually try out new ideas

and give ourselves a playground
to experiment with things

we could do better in Firefox
and if they work out great

we can then start transferring them
back into Firefox and integrate them

and additionally

this means that we can experiment

with letting out pages

doing that in parallel

rather than all other browsers today

which do them sequentially
and single-thread

we can do things

like experiment with the way

that we

redraw things to the screen

and do it more like a computer game

we can do things like change the way

that we're managing memory

for the parts of the web page

so that it's more integrated
with the garbage collection

that the Javascript code

ends up ineracting with

so all of this are things
that we're doing in Servo

and we're getting some great results

and some of them are already

being integrated back into Firefox.

So we're already shipping foot code today

in Firefox that's written in Rust.

For example we have parts
of our Media Stack where

we have code that's just responsible
for reading parts of video files

which has been a source of security
vulnerabilities in the past

and there's no reason
that should be the case

so we rewrite it in Rust

and we get safety by default.

So that's shipping in Firefox today.

We've also got a project called Oxidation

which is a list on the wiki

of all the pieces that
we're in the process

of writing in Rust in Firefox today

some of the most challenging ones

that I mentioned previously

the Rendering Engine

the Style System and Layout

those are being integrated
into Firefox today

as part of the Quantum Project

and so you can basically expect that

the amount of Rust code in Firefox

will increase over time

there's been a lot of really good
results panning out so far

especially for areas where

they shouldn't be security sensitive

that they need to be high performance

those could be great places

for integrating Rust code

because you've got those by default

so if you'd like to know more about Rust

and Mozilla

you can check out the Rust
Playground I mentioned earlier

that allows you to experiment
with writing Rust code

in your browser

we've got a nice introductory book

that covers everything you need
to know about the language

called The Rust Programming Language

which is accessible from the language
website and we've got IRC channels

which are designed for both beginners
who like to interact with other people

who really want to answer
your questions right there

as well as a huge community
in the Rust channel

who really adore asking
and answering questions.

That's all.

Thank you very much.

[Applause]

Any questions?

Yes

What would be a good way to
start contributing or participating?

There's a few ways

so if there are

let me see

if there are libraries that you
would like to use from Rust

that don't exist yet

writing either libraries
from scratch in Rust

to scratch that itch

very handy

publishing that for the community

or if there are libraries
written in C which already exist

which would give you functionality
but don't exist in Rust yet

then writing bindings in Rust

around a C library

is very useful

because that allows you to
build safer abstractions

on top of things that would
otherwise be potentially unsafe

but is really easy to
integrate with C code

which is one reason why it's working
out so well to integrate Rust in Firefox.

There's lots of other suggestions
on the Rust website

of ways to participate in
the Rust Community

if that's what you're asking.

Yes Lucy?

What are the most compelling
reasons for someone to learn

the language and potentially start
participating and contributing?

One thing I've heard
is that actually people

who don't already have what's called

systems programming experience

so a lot of experience
using C++ for example

one of the lower level languages

people coming from a web
development background

people writing a lot of 
Javascript, Ruby, Python

what I've heard is that people
coming from those languages

are actually getting
their first experience

doing low level programming stuff

but in a way which is much less daunting

than C or C++

where they know that the
compiler has their back

in ways that the compilers
for C++, for example, don't

and it will tell you when
you're making mistakes

and it won't let you make those mistakes

which is pretty exciting.

There are two people who I know

who come from Ruby

Javascript backgrounds

who are now putting together

a series of tutorials

for teaching people how to do
kernel programming using Rust

with the intention that other
people are coming from those

high level backgrounds

and trying this out for the first time

so there's a lot of ways to experiment
with things that traditionally has been

rather unapproachable

for large segments of the
developer population.

Pretty compelling reason really

and even if you do have
experience doing C++

and lower level things like that

I find that not having to worry
about whole classes of problems

you can make

as a developer in those languages

makes a huge difference

it allows you to reason
about your code better

it allows you to be more
adventurous with your code.

(Inaudible audience discussion)

So the questions was

one of the things people have talked about

is that Rust should be able to make
the process of refactoring your code

easier, safer, generally less complicated

and less uncertain

and has there been talk of that

has there been evidence of that

and yes

there's actually a really great blog post

in the past couple weeks

of someone who was

refactoring their code

and the compiler kept pointing out
ways in which it would not be safe

to refactor it in that certain way

because it was shared between threads

like he would fix that thing

and it would go down the 
rabbit hole a little bit further

and say "Oh now this isn't safe anymore".

and was this very compiler
guided refactoring session

which he wrote about

and documented top to bottom

and it's great, it seems to just

verify the premise

that this does prevent you
from making mistakes.

Alright let's call it there.

Thank you for attending everybody

[Applause]