Marijn Haverbeke - The Rust That Could Have Been

This talk will describe a number of language concepts and features that were in the pre-1.0 Rust language at some point but were ultimately abandoned, such as typestate, garbage collection, structural types, and a more or less classical object system. I’ll go over the reasons they were abandoned, and try to convince you that the Rust we have now is the best Rust yet.

---
For more go to https://rustfest.eu or follow us on Twitter: https://twitter.com/rustfest

[ applause ]

Yeah, I'm glad so many people
still showed up

at the very end of the conference.

So yeah, I'm going to be talking about
mostly a number of features

that were part of the Rust language
at some points,

but no longer are.

And, why this is the case
and usually why this is a good thing.

So, as [Ryan?] said I'm Marijn Haverbeke.

If you are into Javascript,
you might have seen my name before.

Rust has been under development
for a while:

about ten years now, I think.

First - long stretch - was just
Graydon working in isolation and...

Who knows what kind of ideas and
experiments he abandoned at that point.

There's not even a like code repository
from that time public.

so it's like the prehistory.

And then, at some point,

Mozilla adopted the project
and assembled a team.

From a little before that point,
we do have Git history,

and at that point,
everything was discussed in issues

and mailing lists, and there's...

lots of records.

I was part of this pretty much -
the initial team - where we...

Moved from the original OCaml-based
compiler to a Rust-based compiler,

and we got a bunch more people
involved in the language.

This was a period of...

like, the first real experience
with the language

and a bunch of people
from different backgrounds...

giving their opinions on the language

and trying to push it
into their favorite direction.

And, we had a lot of like
experiments and dead ends

and overhauls and false starts and...

just lots and lots of churn.

We would sometimes come up with
a breaking change in the morning,

and then have a patch ready
in the afternoon

and then convince someone
to merge it later on and then...

Because there was only one codebase,
we'd just fix everything right away

and people could continue working.

There was some...

some trickiness with actually
getting like a compiler...

that compiles the current code
after you'd make a breaking change,

so you'd first change the compiler,
then upload a snapshot,

then change the code,
and then you could -

everyone could - proceed with
the new snapshot.

And then, of course,
a year and a half ago - I think -

the team [cut] version 1.0,

and then the process changed entirely,
so now it's like...

everything stays backwards compatible.

It's impressive how seriously they have
been taking backward compatibility.

Experiments moves like -
[RFCs??] move very slowly

and there has to be a wide consensus

and it has to fit
within the current codebase.

So, that's a whole different stage again.

I'm going to be mostly talking about
the period where I was part of the team.

which was 2011-2012,

and which was probably
the wildest period

in terms of features cut,
features changed - stuff like that.

So, it may seem a bit ridiculous

that we put so much time into
really complicated features

just to end up dropping them again.

But, I think it's kind of an essential
part of getting a complex design

like a programming language right that,

unless you're a super-genius,
you won't really see in advance

what the implications
and the interactions between

the various parts of the system are
and you have to try it and see

how well you can make it work
and how well it fits into the system,

and sometimes
you later have to just...

abandon it again.

I think that's part of
a healthy design process for like...

mere mortals who need to
actually see how something works

before they can evaluate it.

I'm structuring this talk about...
around a number of visions

that were part of the language
and then dropped again.

And, I'll try to explain why I think that,
in every case,

it was a real good decision to drop them.

But, it's still interesting to see

what the original visions were
and what we did end up with.

So, these are typestate,
a structural type system and

lightweight processes,
and finally, garbage collection.

Let's start with typestate.

Typestate is... it was actually

an important point in initial
announcements of the language.

and people were very excited about it.

What typestate does is basically
allow you to...

allow the compiler to know
more about value than just its type.

So, an example would be...

This is something of type [sockets],

but we also happen to know that it's open
or this is something of type array,

but we happen to know...
or say vector in the current terminology,

but we happen to know that
it's not empty.

Something like that allowing you to add

more safety to your program -
more static guarantees.

So, when you're programming,
you usually have some mental model

of why the thing you are doing
right now is...

is valid - is not going to crash -

like if you're not just making
random changes

and seeing if the [tests pass],
you will have

some mental model of your... program.

And, to a certain degree,
depending on the language,

you can tell the compiler
about this model

and the compiler can then check

whether you are applying
your model consistently.

So, the simple case is just types -
that you're actually passing the type

that you think you are passing somewhere.

And, if you don't,
then, instead of finding out at runtime,

you find out at compile time -
and this is nice.

There's a kind of...

this computer does not have the fonts
that my computer had but...

Imagine arrowheads on both sides.

There's a kind of spectrum
on which languages fall

in terms of how much

you can actually communicate
to the compiler,

so down on one side,
there's Javascript

and it's like... syntactically correct.

Okay, let's go ahead - let's run it.

And then, there's like,
on the... way on other side,

there's language like Coq,
which require you to actually construct

a formal proof that your program does
what it's supposed to do -

that it does so in bounded time,
in bounded space,

which means you're making
a lot less mistakes.

But, on the other hand,
it's like a major...

a major project to write a small program
in such a language.

And, there is a reason that
not everyone is writing their web servers

in Coq or whatever.

And, Rust kind of falls in the middle.

It does have quite a bit
of static guarantees

and it helps quite a lot.

But, it still aims to be ergonomic,
like easy to [program in],

where you don't have to

spend too much time
working on these things.

And I... one way to see the history
of programming languages is kind of...

one aspect of it at least is

that we've been finding better
and better vocabulary to...

to describe these things we know about
our program to the compiler

in a way that's actually convenient.

So, if you have a really terrible
type system,

that's often worse than
no type system at all.

If I have to choose to write something
in Java or Javascript,

I'll just take Javascript,
thank you very much.

But, we're getting better at this,

and Rust is making
a big contribution here,

and like bringing a real,
modern type system

to the systems programming space.

And the ownership model is - I think -

just really, really good.

I unfortunately wasn't on the team
anymore when this was introduced,

so I can't take any credit for it, but..

I think that this is
the most exciting part of Rust

and it's exactly this kind of thing
where you...

where the compiler knows
what you're trying to do and

tells you when you're
violating your model.

So, back to typestate.

It looked somewhat like this.

You could define [predicates],

which is this "pure function not empty"
at the top

The extra information
that the compiler had about your values

came in the form of this predicate [ ... ]

But, these were actually just predicates
written in normal Rust code

that were supposed to be pure.