heather_pwlconf_captions.srt

1
00:00:05,540 --> 00:00:09,060
So my name is Heather Miller, I'm a professor
at northeastern University, I'm the director

2
00:00:09,060 --> 00:00:14,349
at the Scala center at EPFL so I have one foot in
academia and one foot in industry land.

3
00:00:14,349 --> 00:00:20,759
And, actually, this talk comes out of a course
that I gave last fall at northeastern University.

4
00:00:20,759 --> 00:00:25,650
It was a grad course called programming models
for distributed computing.

5
00:00:25,650 --> 00:00:29,700
And actually, there's even a book that kind
of came out of it that's not totally finished

6
00:00:29,700 --> 00:00:30,950
yet.

7
00:00:30,950 --> 00:00:36,000
But all the students in the course wrote this
book with me, and I have to edit it.

8
00:00:36,000 --> 00:00:37,480
It needs some work.

9
00:00:37,480 --> 00:00:41,650
But it's got a lot of really cool information,
and this is actually -- like this talk is

10
00:00:41,650 --> 00:00:44,020
just about one week of course material.

11
00:00:44,020 --> 00:00:48,780
So one and a half, maybe two weeks of course
material, so there's a lot of interesting

12
00:00:48,780 --> 00:00:52,190
information and a lot of stuff to be found
at this book.

13
00:00:52,190 --> 00:00:54,240
There's a link on the slide.

14
00:00:54,240 --> 00:00:59,239
I'll put links up on the Internet if you look
around afterwards.

15
00:00:59,239 --> 00:01:02,530
But anyway, so that's an aside.

16
00:01:02,530 --> 00:01:09,100
But sort of one of the things that kind of
I really like about not just, you know, research

17
00:01:09,100 --> 00:01:13,150
in general, but about kind of looking back
at sort of the history of things and how things

18
00:01:13,150 --> 00:01:18,350
came to be how they are now is that research,
it's really animated.

19
00:01:18,350 --> 00:01:21,600
It doesn't really look like that, necessarily.

20
00:01:21,600 --> 00:01:23,810
Perhaps from the outside, it looks more like
this.

21
00:01:23,810 --> 00:01:27,290
[Laughter]
You have -- you know, I think people sometimes

22
00:01:27,290 --> 00:01:33,280
look at academic research kind of pessimistically
where research papers are crusty-looking PDFs

23
00:01:33,280 --> 00:01:36,630
with big files that are a pain in the neck
to download and read.

24
00:01:36,630 --> 00:01:41,700
They have way too much pages, too much convoluted
motivational statements that lack any sort

25
00:01:41,700 --> 00:01:45,369
of actual real-world context, and they solve
problems that nobody cares about.

26
00:01:45,369 --> 00:01:48,570
And, you know, this is some guy that's in
a room that has never seen daylight before,

27
00:01:48,570 --> 00:01:51,090
and I think that's what a lot of people think
research is about.

28
00:01:51,090 --> 00:01:54,270
But I think it's a little bit more dynamic.

29
00:01:54,270 --> 00:02:00,860
They have these multiyear evolving and animated
debates where researchers arn the world are

30
00:02:00,860 --> 00:02:03,590
solving similar problems.

31
00:02:03,590 --> 00:02:06,979
And these different ideas and solutions and
things, they're super animated.

32
00:02:06,979 --> 00:02:09,250
If you look at these things over a long period
of time.

33
00:02:09,250 --> 00:02:13,549
And, you really, they're evolving via PDFs,
which people think are ultimately unsexy.

34
00:02:13,549 --> 00:02:19,480
So by the end of this talk, I hope that I
will have communicated to you that something

35
00:02:19,480 --> 00:02:25,139
is going on in research land are not, like,
crusty piles of PDFs sitting around somewhere

36
00:02:25,139 --> 00:02:29,000
describing esoteric things that never went
anywhere.

37
00:02:29,000 --> 00:02:33,049
And instead, we go to, like, a dynamic view
of arguments and designs and languages and,

38
00:02:33,049 --> 00:02:37,159
you know, things just evolving over decades
with many design decisions from some of these

39
00:02:37,159 --> 00:02:41,450
so-called esoteric languages actually becoming
somehow mainstream and then finding their

40
00:02:41,450 --> 00:02:44,230
way into sexier things that you guys use more
often.

41
00:02:44,230 --> 00:02:45,230
So.

42
00:02:45,230 --> 00:02:46,230
Okay.

43
00:02:46,230 --> 00:02:50,669
This is about distributed programming languages,
so can anybody name some distributed programming

44
00:02:50,669 --> 00:02:52,219
languages?

45
00:02:52,219 --> 00:02:53,769
Okay.

46
00:02:53,769 --> 00:02:55,340
You guys know Chris then.

47
00:02:55,340 --> 00:02:58,889
[Laughter]
So Chris is going to be so happy that you

48
00:02:58,889 --> 00:03:02,659
guys said last was a distributed programming
lank.

49
00:03:02,659 --> 00:03:05,219
Clearly, that means it's more widely used.

50
00:03:05,219 --> 00:03:06,219
So we have Erlang.

51
00:03:06,219 --> 00:03:07,219
What else?

52
00:03:07,219 --> 00:03:08,219
There has to be a couple more.

53
00:03:08,219 --> 00:03:09,840
I've never heard of that one.

54
00:03:09,840 --> 00:03:11,049
What is it?

55
00:03:11,049 --> 00:03:12,049
Shapeel.

56
00:03:12,049 --> 00:03:13,049
Cool.

57
00:03:13,049 --> 00:03:18,430
I'm going to look that one up.

58
00:03:18,430 --> 00:03:20,090
Give me one more.

59
00:03:20,090 --> 00:03:21,090
Linda.

60
00:03:21,090 --> 00:03:22,090
Yeah.

61
00:03:22,090 --> 00:03:23,090
Cool.

62
00:03:23,090 --> 00:03:26,730
There's, like, a zillion.

63
00:03:26,730 --> 00:03:27,730
Some you've heard of.

64
00:03:27,730 --> 00:03:31,680
Mirage, Orca, I'm sure you haven't heard of
that one.

65
00:03:31,680 --> 00:03:33,620
But there's a lot.

66
00:03:33,620 --> 00:03:35,989
I can't talk about about every single one
of them.

67
00:03:35,989 --> 00:03:39,589
But I'm going to go way too fast through at
least seven of them, and you're going to hate

68
00:03:39,589 --> 00:03:41,269
me for it.

69
00:03:41,269 --> 00:03:44,980
[Laughter]
So I can't get into a ton of detail, but,

70
00:03:44,980 --> 00:03:47,309
you know, we can just kind of touch on the
big ideas.

71
00:03:47,309 --> 00:03:50,359
So the first paper I'm going to delve into
is one by Barbara in 1988.

72
00:03:50,359 --> 00:03:52,450
It's about a programming language called Argus.

73
00:03:52,450 --> 00:03:57,699
And if you're not familiar with Barbara, you
really should be because she won the touring

74
00:03:57,699 --> 00:03:59,799
award in 2008.

75
00:03:59,799 --> 00:04:03,769
She laid the ground work for a lot of things
in object-oriented programming.

76
00:04:03,769 --> 00:04:09,499
She was known for this language called Clu,
I guess is what some people call it that they

77
00:04:09,499 --> 00:04:15,309
worked on in the mid-'70s, and it introduced
the use of classes with constructors and methods.

78
00:04:15,309 --> 00:04:19,049
It also introduced a little thing called abstract
data types.

79
00:04:19,049 --> 00:04:24,150
I don't know if you ever heard of these things.It
rarities, type safe parameterized types, and

80
00:04:24,150 --> 00:04:30,030
an important definition of subtyping and object-oriented
programming that people commonly use called

81
00:04:30,030 --> 00:04:32,030
the substitution principle.

82
00:04:32,030 --> 00:04:37,540
So she's done a lot of things, and you should
know who she is.

83
00:04:37,540 --> 00:04:42,569
So while she's kind of like a McJagger or
something in the land of object-oriented programming,

84
00:04:42,569 --> 00:04:47,240
maybe you don't know that she made this weird,
wonky language in the '80s called Argus for

85
00:04:47,240 --> 00:04:48,830
distributed programming.

86
00:04:48,830 --> 00:04:52,800
And actually, it was super influential, and
you're going to be, like, what?

87
00:04:52,800 --> 00:04:53,800
Really?

88
00:04:53,800 --> 00:04:59,390
So back in the day, she had this observation,
and I'm just going to read it to you.

89
00:04:59,390 --> 00:05:03,480
Distribution gives rise to some problems that
do not exist in a centralized system or that,

90
00:05:03,480 --> 00:05:06,520
you know, exist in a less complex form in
a centralized system.

91
00:05:06,520 --> 00:05:09,680
For example, a centralized system is either
running, or it's crashed.

92
00:05:09,680 --> 00:05:13,530
But a distributed system may be partly running
and partly crashed.

93
00:05:13,530 --> 00:05:14,530
Okay.

94
00:05:14,530 --> 00:05:15,530
Cool.

95
00:05:15,530 --> 00:05:17,820
So boast the nodes and network may fail.

96
00:05:17,820 --> 00:05:22,690
The network may lose or delay the delivery
of messages or messages may just come out

97
00:05:22,690 --> 00:05:24,030
of order.

98
00:05:24,030 --> 00:05:31,390
Yet, somehow, programs should remain running,
and she had this idea in the '80s.

99
00:05:31,390 --> 00:05:37,420
And one thing that she thought was super important
was that there -- is that data should remain

100
00:05:37,420 --> 00:05:39,640
consistent when these situations happen.

101
00:05:39,640 --> 00:05:41,410
So this is a really big deal.

102
00:05:41,410 --> 00:05:46,030
She was, like, look, if everything crashes
or a bunch of things crash, we shouldn't,

103
00:05:46,030 --> 00:05:48,420
you know, have screwed up bank accounts because
of it.

104
00:05:48,420 --> 00:05:54,780
So we need strong consistency, and she introduced
this idea in the -- you know, in the context

105
00:05:54,780 --> 00:05:59,120
of a programming language, which it hadn't
really been thought of in this context before.

106
00:05:59,120 --> 00:06:07,800
So this paper actually runs through an example
in banking, and she notes a couple of things.

107
00:06:07,800 --> 00:06:09,780
She notes two things.

108
00:06:09,780 --> 00:06:13,191
So on the one hand, concurrent activities
made to interfere with one another, that's

109
00:06:13,191 --> 00:06:14,390
a problem.

110
00:06:14,390 --> 00:06:18,830
And on the other hand, there might be some
kind of failure that occurs.

111
00:06:18,830 --> 00:06:23,450
And these things, we don't really do anything
about programming languages that we use now;

112
00:06:23,450 --> 00:06:24,450
right?

113
00:06:24,450 --> 00:06:26,990
So this object-oriented thing called clu,
other things.

114
00:06:26,990 --> 00:06:32,370
So in the face of these two things, Argus
must provide some kind of strong consistency,

115
00:06:32,370 --> 00:06:34,150
is what she says.

116
00:06:34,150 --> 00:06:39,270
And I'm, you know, I think it's great to kind
of show these people's words rather than to

117
00:06:39,270 --> 00:06:41,590
make up my own myself.

118
00:06:41,590 --> 00:06:43,360
So I would like to just quote her here.

119
00:06:43,360 --> 00:06:49,200
So she introduces Argus to support programs
like a banking system to capture, you know,

120
00:06:49,200 --> 00:06:53,430
always used to be in this object-oriented
context, so she introduces two concepts to

121
00:06:53,430 --> 00:06:54,430
have these things.

122
00:06:54,430 --> 00:07:00,120
One hand, you have a guardian, which is a
special problem that runs procedures and response

123
00:07:00,120 --> 00:07:01,460
to promote requests.

124
00:07:01,460 --> 00:07:08,650
And then introduces another thing in the context
of this language that should make consistency

125
00:07:08,650 --> 00:07:11,110
happen, which are atomic transactions.

126
00:07:11,110 --> 00:07:14,280
So computations should always be organized
as atomic transactions.

127
00:07:14,280 --> 00:07:16,650
And these are sort of the two biggish ideas.

128
00:07:16,650 --> 00:07:23,480
And these guardian things fall into this world
of object-oriented programming; right?

129
00:07:23,480 --> 00:07:26,740
So guardians, like I said, it's like an object.

130
00:07:26,740 --> 00:07:33,070
A special kind of abe extract object whose
purpose is to encapsulate a resource or resources.

131
00:07:33,070 --> 00:07:39,660
Importantly, the state of the resources maintained
in the objects stored in the guardian, so

132
00:07:39,660 --> 00:07:41,639
these things are isolated.

133
00:07:41,639 --> 00:07:46,450
The stuff inside a guardian is not accessible
outside of a guardian.

134
00:07:46,450 --> 00:07:50,540
And the only way that people could actually
manipulate anything inside of one of these

135
00:07:50,540 --> 00:07:55,830
special objects is via a handlers, another
guardian has to call some kind of handle that

136
00:07:55,830 --> 00:07:57,669
affects something inside of a guardian.

137
00:07:57,669 --> 00:07:58,669
Okay?

138
00:07:58,669 --> 00:08:04,890
So the key thing to hold onto here is that
even though what's inside of a guardian is

139
00:08:04,890 --> 00:08:10,330
a dynamic collection of data objects, they're
not accessible directly by anybody.

140
00:08:10,330 --> 00:08:12,850
So that's a guardian.

141
00:08:12,850 --> 00:08:17,050
And this is the very, very beautiful picture
that was in the paper trying to draw a picture

142
00:08:17,050 --> 00:08:19,610
of all of the things that could happen inside
of a guardian.

143
00:08:19,610 --> 00:08:22,720
It's not exactly the best picture.

144
00:08:22,720 --> 00:08:26,380
But the idea here is that you have all kinds
of things.

145
00:08:26,380 --> 00:08:30,590
You've got objects, and you have processes,
and all kinds of stuff going on inside of

146
00:08:30,590 --> 00:08:31,590
this guardian.

147
00:08:31,590 --> 00:08:32,590
And then you have these handlers.

148
00:08:32,590 --> 00:08:35,190
In this case, one is called in cue and one
is called check.

149
00:08:35,190 --> 00:08:36,409
It doesn't really matter.

150
00:08:36,409 --> 00:08:40,279
But this is how you affect the stuff going
on inside of it.

151
00:08:40,279 --> 00:08:45,959
So, yeah, just to summarize guardian and encapsulate
state, it contains a dynamic collection of

152
00:08:45,959 --> 00:08:46,959
objects.

153
00:08:46,959 --> 00:08:51,209
They're like an abstraction over a node or
they're like a microservice or something.

154
00:08:51,209 --> 00:08:56,800
Interestingly, they can be moved and the guardian
can create other guardians dynamically.

155
00:08:56,800 --> 00:09:00,149
So these are kind of what a guardian looks
like, what's inside of one, and kind of what

156
00:09:00,149 --> 00:09:02,380
they can do.

157
00:09:02,380 --> 00:09:06,889
And I mentioned there are these handlers that
-- oh, yep.

158
00:09:06,889 --> 00:09:11,610
A guardian permits its resources to be accessed
by means of these special procedures called

159
00:09:11,610 --> 00:09:12,610
handlers; right?

160
00:09:12,610 --> 00:09:16,610
As I mentioned the way to affect stuff going
on inside of it.

161
00:09:16,610 --> 00:09:17,610
Yep.

162
00:09:17,610 --> 00:09:21,180
And also, handler calls can be location independent,
so you can be on some other node somewhere

163
00:09:21,180 --> 00:09:24,579
and call a handler that affects a guardian
somewhere else; right?

164
00:09:24,579 --> 00:09:26,190
Mamakes some kind of sense.

165
00:09:26,190 --> 00:09:27,190
Cool.

166
00:09:27,190 --> 00:09:30,230
So that's kind of like the high-level picture.

167
00:09:30,230 --> 00:09:34,029
You don't have to actually try to read this
because you definitely can't.

168
00:09:34,029 --> 00:09:37,910
This is just a screenshot from the paper of
what the code kind of looks like.

169
00:09:37,910 --> 00:09:43,139
So this is -- this right here is supposed
to be an entire banking application for one

170
00:09:43,139 --> 00:09:44,139
bank.

171
00:09:44,139 --> 00:09:46,970
So this is, like, one branch of a bank.

172
00:09:46,970 --> 00:09:49,829
And all that really matters here are the colors.

173
00:09:49,829 --> 00:09:55,769
So here you have kind of where this guardian
for a branch starts and where it ends.

174
00:09:55,769 --> 00:09:56,820
So it's like an object again.

175
00:09:56,820 --> 00:09:59,449
It has a bunch of stuff inside of it.

176
00:09:59,449 --> 00:10:03,649
The stuff that's inside of it, so there are
handlers that other guardians can call to

177
00:10:03,649 --> 00:10:05,839
affect all kinds of state that's inside of
it.

178
00:10:05,839 --> 00:10:10,819
And the other things are, like, types and
sort of local data structures inside of it.

179
00:10:10,819 --> 00:10:15,050
So bank account numbers and other things like
a table of banks and bank account numbers.

180
00:10:15,050 --> 00:10:16,050
Okay.

181
00:10:16,050 --> 00:10:17,050
But fine.

182
00:10:17,050 --> 00:10:21,160
The whole is motivation behind this programming
language was, well, partial failure should

183
00:10:21,160 --> 00:10:28,139
somehow be addressed in Argus, so how can
it be addressed by guardians?

184
00:10:28,139 --> 00:10:36,649
So basically, this goes back to this atomic
actions point, so the idea is that, you know,

185
00:10:36,649 --> 00:10:37,829
I'll just go here.

186
00:10:37,829 --> 00:10:44,930
So there are these atomic actions that Argus
makes possible, so all of these calls to handlers

187
00:10:44,930 --> 00:10:47,990
and things, they should be atomic.

188
00:10:47,990 --> 00:10:56,610
And by that, they, you know, they're not separate,
they're one, big action, and if you run a

189
00:10:56,610 --> 00:11:02,360
group of them, they always have to be executed
as if they were run sequentially, and then

190
00:11:02,360 --> 00:11:04,370
they have to be total.

191
00:11:04,370 --> 00:11:08,999
Completes entirely, or it fails entirely,
and it has no visible effect.

192
00:11:08,999 --> 00:11:11,350
So that's the idea.

193
00:11:11,350 --> 00:11:16,480
So serialize ability solves concurrency problem
and totality solves the failure problem and

194
00:11:16,480 --> 00:11:19,119
these things are invisible, they're atomic.

195
00:11:19,119 --> 00:11:24,089
And this is all achieved by your favorite
thing on the planet, which is definitely locking

196
00:11:24,089 --> 00:11:25,449
in synchronization.

197
00:11:25,449 --> 00:11:28,660
I know everybody in this room really likes
this.

198
00:11:28,660 --> 00:11:31,189
Everything is all read, write locks.

199
00:11:31,189 --> 00:11:35,279
And there's this cool way of making a hierarchy
of these things, so things can be organized

200
00:11:35,279 --> 00:11:37,019
in terms of, like, two-phase commits.

201
00:11:37,019 --> 00:11:39,430
It doesn't really matter.

202
00:11:39,430 --> 00:11:46,910
And then if you're part way trying to do something,
and then part of your thing fails or something,

203
00:11:46,910 --> 00:11:53,360
there's a way to recover to roll back to,
you know, to stop this commit from starting

204
00:11:53,360 --> 00:11:57,050
or this -- whatever to stop everything from
being committed.

205
00:11:57,050 --> 00:11:58,559
And this is done via versioning.

206
00:11:58,559 --> 00:12:04,529
And then, of course, communication between
remote guardians is done by RPC.

207
00:12:04,529 --> 00:12:10,220
So it's all synchronized and locked and everything,
and it's, you know, definitely not super performent

208
00:12:10,220 --> 00:12:13,509
but strong consistency, that's cool.

209
00:12:13,509 --> 00:12:18,040
And another thing you might not know about
Argus is promises came from Argus.

210
00:12:18,040 --> 00:12:19,509
I'm not going to go into that.

211
00:12:19,509 --> 00:12:22,660
That's another week and a half of material.

212
00:12:22,660 --> 00:12:28,569
But the idea of promise pipe lining because
you realize RPC can be really slow if it's

213
00:12:28,569 --> 00:12:33,540
all synchronous, hey, we can make it asynchronous
with promises, and they're strongly typed,

214
00:12:33,540 --> 00:12:34,720
and that's really great.

215
00:12:34,720 --> 00:12:40,749
So there's another paper written by Barbara
called promises linguistic support for asynchronous

216
00:12:40,749 --> 00:12:42,959
procedure calls in distributed systems.

217
00:12:42,959 --> 00:12:44,560
I encourage you to have a look at that.

218
00:12:44,560 --> 00:12:47,879
But just note, hey, this is where promises
came from.

219
00:12:47,879 --> 00:12:48,879
Okay.

220
00:12:48,879 --> 00:12:52,350
One short note about how Argus was implemented.

221
00:12:52,350 --> 00:12:58,170
It was just calling random stuff in, like,
a special research kernel.

222
00:12:58,170 --> 00:13:00,699
It was completely coupled with the kernel.

223
00:13:00,699 --> 00:13:01,699
So everything.

224
00:13:01,699 --> 00:13:06,209
Networking, storage, all of that stuff, it,
you know, required special research implementation

225
00:13:06,209 --> 00:13:08,360
of Unix that they were using and, yeah.

226
00:13:08,360 --> 00:13:13,550
I mean, she didn't make any sort of modifications
to this research thing that I think somebody

227
00:13:13,550 --> 00:13:15,579
else is working on, but still.

228
00:13:15,579 --> 00:13:18,670
It was completely coupled to this one version
of Unix.

229
00:13:18,670 --> 00:13:20,560
All right.

230
00:13:20,560 --> 00:13:21,560
That's all I'm going to say about Argus.

231
00:13:21,560 --> 00:13:23,990
Just try to remember all of that.

232
00:13:23,990 --> 00:13:25,589
Okay?

233
00:13:25,589 --> 00:13:29,130
So the next thing I'm going to talk about
is emerald.

234
00:13:29,130 --> 00:13:32,439
Emerald's another programming language from
the '80s.

235
00:13:32,439 --> 00:13:37,269
I'm going to zoom in right here because I'm
pretty sure that this is not a quote from

236
00:13:37,269 --> 00:13:39,690
Andrew Black and all of those people.

237
00:13:39,690 --> 00:13:45,199
This is definitely a compote from Chris Meiklejohn in 2017, even though it says it's from

238
00:13:45,199 --> 00:13:50,399
Emerald in 1987, they say while distributed
systems are now commonplace in 1987, obviously,

239
00:13:50,399 --> 00:13:53,050
they were.

240
00:13:53,050 --> 00:13:56,699
The programming of distributed applications
is still somewhat of a black art.

241
00:13:56,699 --> 00:14:01,350
Definitely not a black art anymore; right?

242
00:14:01,350 --> 00:14:05,309
We believe that the complexity of distributed
applications is heightened by the lack of

243
00:14:05,309 --> 00:14:08,290
programming language support for distribution.

244
00:14:08,290 --> 00:14:11,680
I swear Chris said that, like, two days ago;
right?

245
00:14:11,680 --> 00:14:14,459
I don't know if he's copying it out of the
paper or what.

246
00:14:14,459 --> 00:14:16,699
Anyway, these are some of the guys that wrote
the paper.

247
00:14:16,699 --> 00:14:18,970
This is back when they put people's pictures
in the paper.

248
00:14:18,970 --> 00:14:20,370
Isn't this cool?

249
00:14:20,370 --> 00:14:25,839
I know a few of them, and they're much older
now, but I like that they have these pictures,

250
00:14:25,839 --> 00:14:26,839
you know?

251
00:14:26,839 --> 00:14:27,839
It's really cool.

252
00:14:27,839 --> 00:14:28,839
Okay.

253
00:14:28,839 --> 00:14:29,839
That's a silly point.

254
00:14:29,839 --> 00:14:33,999
Anyway, the goal of Emerald was language support
for distribution.

255
00:14:33,999 --> 00:14:35,059
Yay.

256
00:14:35,059 --> 00:14:37,759
So this actually all started in other languages.

257
00:14:37,759 --> 00:14:39,730
Actually, a few other languages.

258
00:14:39,730 --> 00:14:46,449
One called Eden, which was in itself and another
language called concurrent Euclid.

259
00:14:46,449 --> 00:14:50,970
And basically, they took concurrent Euclid
and they were, like, let's take RPC to this

260
00:14:50,970 --> 00:14:54,040
thing and make it distributed. That'd would be so cool.

261
00:14:54,040 --> 00:14:57,759
But as a result of doing that, they ended
up with two different versions of objects.

262
00:14:57,759 --> 00:15:00,760
And they thought that was ugly, you know?

263
00:15:00,760 --> 00:15:05,869
So on the one hand, you had these mobile objects
implemented in Eden, but they were extremely

264
00:15:05,869 --> 00:15:08,199
expensive to use and nobody used them.

265
00:15:08,199 --> 00:15:13,709
Instead, developers snuck around and then
reused concurrent Euclid objects, and then

266
00:15:13,709 --> 00:15:17,100
they would communicate through shared memory
instead of RPC.

267
00:15:17,100 --> 00:15:18,230
Like they were supposed to.

268
00:15:18,230 --> 00:15:19,869
Obviously, that's bad.

269
00:15:19,869 --> 00:15:23,029
I mean, assuming this was all on the same
note, by the way.

270
00:15:23,029 --> 00:15:24,029
They're doing shared memory.

271
00:15:24,029 --> 00:15:28,070
And then if it's -- you're trying to talk
to somebody else in another node, then you're

272
00:15:28,070 --> 00:15:29,070
in trouble.

273
00:15:29,070 --> 00:15:32,339
In any case, they're, like, let's try to fix
these things.

274
00:15:32,339 --> 00:15:37,269
Let's try to unify this object system because
it's pretty bad and also, you know, not very

275
00:15:37,269 --> 00:15:41,570
performent, so let's make Emerald to address
these issues.

276
00:15:41,570 --> 00:15:47,319
So I'm going to read two more quotes to you
because I'm sure you love it.

277
00:15:47,319 --> 00:15:53,079
We believe that distributed applications is
heightened for programming support for distribution.

278
00:15:53,079 --> 00:15:55,420
That was Chris.

279
00:15:55,420 --> 00:15:59,379
The rest is Andrew Black and his friends.,
for example, most distributed applications

280
00:15:59,379 --> 00:16:06,130
are implemented by calling operating system
communications primitives, such as send and

281
00:16:06,130 --> 00:16:11,720
receive and the programmer's responsible for
the target explicitly packaging parameters

282
00:16:11,720 --> 00:16:12,850
and so on.

283
00:16:12,850 --> 00:16:16,709
That really sucks liked it you're in a programming
language, and I just have to, like, go down

284
00:16:16,709 --> 00:16:21,769
to the operating system and then package everything
up, make packets myself, send stuff around,

285
00:16:21,769 --> 00:16:22,939
that's horrible.

286
00:16:22,939 --> 00:16:29,149
So emerald, we want to go beyond simple sin
tactic support, we want to address some of

287
00:16:29,149 --> 00:16:32,320
the fundamental semantic problems of distribution.

288
00:16:32,320 --> 00:16:36,879
So note this fundamental problem of distribution,
what are they?

289
00:16:36,879 --> 00:16:39,850
Obviously, it's objects.

290
00:16:39,850 --> 00:16:42,619
Because programming language designers are,
like, if it's an ugly objects system, this

291
00:16:42,619 --> 00:16:43,619
is bad.

292
00:16:43,619 --> 00:16:46,230
This is the most important thing to distribution.

293
00:16:46,230 --> 00:16:51,709
So basically, they wanted a single object
model that is performent's and used for both

294
00:16:51,709 --> 00:16:55,579
programming in the small and the large can
be used for local objects as well as remote

295
00:16:55,579 --> 00:16:56,899
ones.

296
00:16:56,899 --> 00:16:59,230
That was a very important concern for them.

297
00:16:59,230 --> 00:17:02,160
They thought abstract types were important.

298
00:17:02,160 --> 00:17:03,880
I'll talk about that in a second.

299
00:17:03,880 --> 00:17:07,030
That turns out to be much more important.

300
00:17:07,030 --> 00:17:10,390
And then this specific note of object location
and moveability, so you should be able to

301
00:17:10,390 --> 00:17:12,590
move your objects around.

302
00:17:12,590 --> 00:17:17,560
So the three things that they offer with this
programming language, you know, these objects

303
00:17:17,560 --> 00:17:20,830
that I mentioned before.

304
00:17:20,830 --> 00:17:27,380
Emeraldons objects, which offers euphemism
sin tact taxic.

305
00:17:27,380 --> 00:17:31,450
Can communicate between each other, via message
passing, and they're mobile; right?

306
00:17:31,450 --> 00:17:33,010
They can be moved around the network.

307
00:17:33,010 --> 00:17:40,060
They have a few things, identity, they have
some way of operations, some way of processing

308
00:17:40,060 --> 00:17:45,790
these things but more importantly, they have
these other strange attributes.

309
00:17:45,790 --> 00:17:49,790
One is location and the other one is that
an object can be immutable.

310
00:17:49,790 --> 00:17:51,430
That's interesting.

311
00:17:51,430 --> 00:17:58,790
So, you know, actually, turns out that immutability
was kind of like a marker, not really immutable.

312
00:17:58,790 --> 00:18:00,830
But whatever.

313
00:18:00,830 --> 00:18:01,850
Details.

314
00:18:01,850 --> 00:18:03,880
And location.

315
00:18:03,880 --> 00:18:07,390
So you should be able to, like, location should
be part of your object.

316
00:18:07,390 --> 00:18:08,390
Okay.

317
00:18:08,390 --> 00:18:10,150
That's interesting.

318
00:18:10,150 --> 00:18:11,550
And then, yeah.

319
00:18:11,550 --> 00:18:15,450
So it doesn't really -- this is maybe a less
important detail is that multiple objects

320
00:18:15,450 --> 00:18:19,410
actually exist inside of this thing and are
selected by the compiler to make things more

321
00:18:19,410 --> 00:18:22,540
efficient, so you don't have that funny thing
where programmers are using the wrong kind

322
00:18:22,540 --> 00:18:24,000
of object for the situation.

323
00:18:24,000 --> 00:18:25,750
They're trying to be in.

324
00:18:25,750 --> 00:18:28,490
So the compiler selects the right kind of
object for you.

325
00:18:28,490 --> 00:18:30,740
But you see all kind of one object; right?

326
00:18:30,740 --> 00:18:34,390
But what's more important to me or what I
think is a bigger deal are abstract types.

327
00:18:34,390 --> 00:18:40,740
So the idea that abstract types are statically
typed, but they argue that.

328
00:18:40,740 --> 00:18:41,740
Okay.

329
00:18:41,740 --> 00:18:47,460
Well, static typing has advantages, you know,
and the big deal here at this time in 1987

330
00:18:47,460 --> 00:18:53,740
was that it enables better error notification
and by better, them better than small talk.

331
00:18:53,740 --> 00:18:59,780
So that was the motivation, which I think
is cute and great.

332
00:18:59,780 --> 00:19:03,210
But turns out that abstract types were more
important than design contribution because

333
00:19:03,210 --> 00:19:05,720
they were designed to be used in so-called
open systems.

334
00:19:05,720 --> 00:19:09,650
They use the word open systems where objects
may be added to a writing system, so you need

335
00:19:09,650 --> 00:19:14,460
some kind of interface, and then you can swap
in a different implementation for that interface.

336
00:19:14,460 --> 00:19:18,660
So they wanted abstract types to be able to,
like, these interfaces to be defined in them

337
00:19:18,660 --> 00:19:23,710
to be able to allow old code to invoke new
objects, basically.

338
00:19:23,710 --> 00:19:25,490
That was the idea.

339
00:19:25,490 --> 00:19:27,230
Which that's super cool; right?

340
00:19:27,230 --> 00:19:32,150
This is an awesome thing.

341
00:19:32,150 --> 00:19:37,770
The next thing is so-called distribution support,
and this is super messy.

342
00:19:37,770 --> 00:19:40,960
What's under this, like, subsection here.

343
00:19:40,960 --> 00:19:42,170
It's a ton of things.

344
00:19:42,170 --> 00:19:49,030
But to try to keep it short, you know, this
is about concurrency having multiple nodes,

345
00:19:49,030 --> 00:19:55,280
having object location baked into these objects,
you know, sort of encapsulating all of this

346
00:19:55,280 --> 00:20:02,630
stuff, and then to let people actually manually
move objects around if they feel like they

347
00:20:02,630 --> 00:20:03,630
should.

348
00:20:03,630 --> 00:20:08,780
And whatever, that's -- it's actually extremely
involved how this works.

349
00:20:08,780 --> 00:20:13,950
And then they had to introduce a few interesting
things called, like, call by move semantics

350
00:20:13,950 --> 00:20:17,799
for, you know, arguments that are on different
machines or something.

351
00:20:17,799 --> 00:20:18,980
This gets super messy.

352
00:20:18,980 --> 00:20:21,790
In any case, this is a support for distribution.

353
00:20:21,790 --> 00:20:22,790
Okay?

354
00:20:22,790 --> 00:20:27,040
All of these things to try to make these mobile
objects work.

355
00:20:27,040 --> 00:20:30,900
And I'm just going to say, again, how is Emerald
implemented?

356
00:20:30,900 --> 00:20:35,670
So let's try to remember where each of these
languages implemented point.

357
00:20:35,670 --> 00:20:38,980
So it was implemented in a very pain-staking
way.

358
00:20:38,980 --> 00:20:43,330
The compiler, again, was very closely coupled
to the kernel, it actually defined an interface

359
00:20:43,330 --> 00:20:47,660
with the kernel so that operations could be
either performed by the kernel, the compiler,

360
00:20:47,660 --> 00:20:50,600
or even compiler-generated code, like, it's
super baked into it.

361
00:20:50,600 --> 00:20:55,020
And even more interestingly, emerald was the
only thing that could run on that kernel.

362
00:20:55,020 --> 00:20:57,300
Nothing else allowed.

363
00:20:57,300 --> 00:21:02,800
So this was super tightly -- must have taken
a zillion years to try to make this thing

364
00:21:02,800 --> 00:21:03,800
work.

365
00:21:03,800 --> 00:21:04,800
Okay.

366
00:21:04,800 --> 00:21:08,540
We all know Erlang, I'm going to spend around
30 seconds actually talking about it since

367
00:21:08,540 --> 00:21:12,570
it's not such a foreign concept to most people
here.

368
00:21:12,570 --> 00:21:15,820
I say Erlang came out in the 1990, its first
public release was 2000.

369
00:21:15,820 --> 00:21:17,960
The paper was written in 1990

370
00:21:17,960 --> 00:21:23,700
This one that you see here was 2010 by Joe
Erlang. I'm sorry, Joe Armstrong in the CACM.

371
00:21:23,700 --> 00:21:24,840
He could be Joe Erlang.

372
00:21:24,850 --> 00:21:27,230
That's a pretty cool name.

373
00:21:27,230 --> 00:21:29,710
But I think we know most of these things;
right?

374
00:21:29,710 --> 00:21:31,980
So I'm just going to run through a quick summary.

375
00:21:31,980 --> 00:21:34,330
So it's a fundamental programming language.

376
00:21:34,330 --> 00:21:40,910
It's made up of lightweight processes, which
is the main thing that Erlang offers.

377
00:21:40,910 --> 00:21:45,160
So the idea is that, like, how you should
write Erlang programs is that processes are

378
00:21:45,160 --> 00:21:47,710
typically created for a short period of time.

379
00:21:47,710 --> 00:21:52,050
They live long enough to do one, simple thing,
to handle one, simple request, and then they

380
00:21:52,050 --> 00:21:54,220
can just go away, you don't have to worry
or care about these things.

381
00:21:54,220 --> 00:21:59,100
So that allows there to be a zillion processes
to be happening at the same time.

382
00:21:59,100 --> 00:22:04,010
Of course, everything communicates via messaging
processing.

383
00:22:04,010 --> 00:22:10,930
Things are immutable, signs can't be changed
and the most exciting thing to me is this

384
00:22:10,930 --> 00:22:14,140
very cool, dynamic VM.

385
00:22:14,140 --> 00:22:17,500
So you have hot swapping is allowed, which
is really neat.

386
00:22:17,500 --> 00:22:21,240
The idea is then you can upgrade applications
while they're running without stopping them.

387
00:22:21,240 --> 00:22:23,190
Super cool.

388
00:22:23,190 --> 00:22:27,821
And you can't really Tauber language without
mentioning OTP, which is a bunch of I would

389
00:22:27,821 --> 00:22:32,790
say just libraries that are on top of Erlang
that define all kinds of things.

390
00:22:32,790 --> 00:22:37,110
One thing that use a lot are these supervisors,
so you can have processes watching over processes

391
00:22:37,110 --> 00:22:38,610
and handling their failures.

392
00:22:38,610 --> 00:22:44,120
Oh, another thing I didn't mention in the
blue part or the dark part of the slide is

393
00:22:44,120 --> 00:22:48,500
also that you have this ability to, like,
do linking.

394
00:22:48,500 --> 00:22:52,560
So one process can be notified if another
process fails or disappears or something;

395
00:22:52,560 --> 00:22:53,560
right?

396
00:22:53,560 --> 00:22:54,560
So that's also very important.

397
00:22:54,560 --> 00:22:59,250
Because then you can, you know, you know of
somebody died or something was failed.

398
00:22:59,250 --> 00:23:03,400
Again, we all kind of know Erlang a little
bit, so I'm not going to say anything more.

399
00:23:03,400 --> 00:23:06,970
So just remember Erlang for a second.

400
00:23:06,970 --> 00:23:10,250
And it's a virtual machine, basically.

401
00:23:10,250 --> 00:23:17,000
Compiled that for Windows and I'm sorry Unix
and Windows runs most places without issue.

402
00:23:17,000 --> 00:23:18,340
Super concurrency focused VM.

403
00:23:18,340 --> 00:23:24,000
It's, I guess, the nicest way to describe
it as a process VM, so there's no actual connection

404
00:23:24,000 --> 00:23:25,770
to the OS processes running underneath.

405
00:23:25,770 --> 00:23:28,200
Instead, the VM manages all of that itself.

406
00:23:28,200 --> 00:23:34,390
And it can manage millions of processes, so
you can -- yeah, you can have really a million

407
00:23:34,390 --> 00:23:37,790
processes sitting on top of just on S process.

408
00:23:37,790 --> 00:23:39,730
And have one thread per core, basically.

409
00:23:39,730 --> 00:23:44,550
And, of course, it has this really cool garbage
collector that independently collects all

410
00:23:44,550 --> 00:23:48,460
process, since all of these are independent,
they can't share memory and whatnot, so they

411
00:23:48,460 --> 00:23:49,520
have their own heaps.

412
00:23:49,520 --> 00:23:53,400
That's neat and, of course, this hot code
reloading thing.

413
00:23:53,400 --> 00:23:54,790
So this is Erlang; right?

414
00:23:54,790 --> 00:23:56,530
Just footnote.

415
00:23:56,530 --> 00:23:58,260
Linda.

416
00:23:58,260 --> 00:24:02,210
Has anybody heard of Linda?

417
00:24:02,210 --> 00:24:04,370
I think somebody mentioned Linda here?

418
00:24:04,370 --> 00:24:08,600
You've heard of tupal spaces.

419
00:24:08,600 --> 00:24:13,080
They're really out of this world spacey, I
have no idea.

420
00:24:13,080 --> 00:24:14,080
Weird things.

421
00:24:14,080 --> 00:24:15,080
Okay?

422
00:24:15,080 --> 00:24:21,440
So I'm going to just kind of run through the
idea of what what these spaces are, but the

423
00:24:21,440 --> 00:24:25,810
main point to remember here is that tupal
spaces were introduced as an alternative to

424
00:24:25,810 --> 00:24:27,900
message passing.

425
00:24:27,900 --> 00:24:31,140
So the argument is, well, message passing
is no good.

426
00:24:31,140 --> 00:24:35,610
It's a coordination model that arises directly
from the architecture of networks.

427
00:24:35,610 --> 00:24:36,610
That's horrible, you know?

428
00:24:36,610 --> 00:24:37,680
We don't want that.

429
00:24:37,680 --> 00:24:40,950
Yet, the use of distributed data structures
in a logically-shared memory is natural.

430
00:24:40,950 --> 00:24:45,680
It's a naturally-understood way to approach
paralleled programming; right?

431
00:24:45,680 --> 00:24:53,150
So, guys, the principle argument here is that
distributed shared memory is inefficient.

432
00:24:53,150 --> 00:24:57,690
So if that's really all you have to say about
it, I have an idea.

433
00:24:57,690 --> 00:24:59,480
We can -- whoops.

434
00:24:59,480 --> 00:25:04,120
We can come up with a scalable and efficient
implementation of shared memory.

435
00:25:04,120 --> 00:25:09,710
And, you know, we shouldn't be building all
of our applications around message passing

436
00:25:09,710 --> 00:25:16,100
because it's developed to some consequence
of the fact that this complaint that, you

437
00:25:16,100 --> 00:25:18,030
know, distributed shared memory is inefficient.

438
00:25:18,030 --> 00:25:19,610
Like, so why do we have to -- what?

439
00:25:19,610 --> 00:25:24,530
Now we have to change how we think about everything
and how we approach all problems just because

440
00:25:24,530 --> 00:25:25,530
of this one thing?

441
00:25:25,530 --> 00:25:27,910
Let's fix that; right?

442
00:25:27,910 --> 00:25:28,910
Okay.

443
00:25:28,910 --> 00:25:32,280
I still think it's a little crazy but whatever.

444
00:25:32,280 --> 00:25:35,080
So Linda comes in, and they're, like, look,
we're going to make this efficient.

445
00:25:35,080 --> 00:25:36,080
Okay?

446
00:25:36,080 --> 00:25:37,750
We're going to solve this problem.

447
00:25:37,750 --> 00:25:45,370
So they introduce the tuple spaces, which
is virtual associative and logically-shared

448
00:25:45,370 --> 00:25:46,460
memory.

449
00:25:46,460 --> 00:25:52,190
It's like when you take things out of a cloud,
basically.

450
00:25:52,190 --> 00:25:55,770
You don't know how it works.

451
00:25:55,770 --> 00:26:00,060
[Laughter]
So surprisingly, tuple spaces contain tuple

452
00:26:00,060 --> 00:26:04,770
spaces, which is an order answer of data.

453
00:26:04,770 --> 00:26:08,350
And, I mean, this is what they look like.

454
00:26:08,350 --> 00:26:10,000
I took this from the paper.

455
00:26:10,000 --> 00:26:15,750
This is a Tuple, so you put data into a little
thing with commas between data.

456
00:26:15,750 --> 00:26:25,770
You just insert that into your Tuple space.

457
00:26:25,770 --> 00:26:26,870
Either serially or in parallel.

458
00:26:26,870 --> 00:26:33,030
So you have to create these things, this data,
and then insert it into this Tuple space.

459
00:26:33,030 --> 00:26:40,620
So use this outmethod so it creates data and
inserts it one by one, like, you know, it

460
00:26:40,620 --> 00:26:44,210
serially goes through the arguments here,
like, vaults them and then inserts the whole

461
00:26:44,210 --> 00:26:52,640
thing into the Tuple space and the parallel
way, it's a little bit different, so the idea

462
00:26:52,640 --> 00:26:59,710
is that all arguments to evaluate in parallel
in separate processes while the original process

463
00:26:59,710 --> 00:27:02,880
that started this continues immediately.

464
00:27:02,880 --> 00:27:06,370
So it's kind of a -- and then the thing goes
into the Tuple space.

465
00:27:06,370 --> 00:27:07,890
So that's the idea.

466
00:27:07,890 --> 00:27:12,490
You have, like, a sequential and parallel
way of doing it.

467
00:27:12,490 --> 00:27:14,810
So there's no addresses.

468
00:27:14,810 --> 00:27:19,390
If you want to pull something out of the this
associative memory, you know, the idea is

469
00:27:19,390 --> 00:27:23,560
that you retrieve things on the basis of the
combination of their field values.

470
00:27:23,560 --> 00:27:28,580
So if I want to get something out of a Tuple
space, I have these weird patterns, and I

471
00:27:28,580 --> 00:27:35,950
can either read things via these patterns,
or I can find a Tuple via a pattern, or I

472
00:27:35,950 --> 00:27:38,310
can read it.

473
00:27:38,310 --> 00:27:39,550
That's the idea.

474
00:27:39,550 --> 00:27:48,830
So this example here, this little RD thing,
that's the way to just read a Tuple.

475
00:27:48,830 --> 00:27:55,130
This is how you say, well, this, you know,
I want, for example, a Tuple ABCD.

476
00:27:55,130 --> 00:27:56,900
Wait, ABCDE.

477
00:27:56,900 --> 00:27:57,900
Whatever.

478
00:27:57,900 --> 00:28:02,410
And, you know, I'm looking for A, basically.

479
00:28:02,410 --> 00:28:06,900
So I can pull it out by A. Does that make
some kind of sense?

480
00:28:06,900 --> 00:28:08,460
It's a little weird.

481
00:28:08,460 --> 00:28:14,150
So to read a five hive element Abcde, you
can write this ARDA and then the question

482
00:28:14,150 --> 00:28:19,160
marks for the other parameters that you want
to match against and, you know, you'll get

483
00:28:19,160 --> 00:28:23,110
something back, basically.

484
00:28:23,110 --> 00:28:25,350
And interestingly, you know, if there are
multiple things that match, you just get an

485
00:28:25,350 --> 00:28:31,290
arbitrary one, or it blocks some weights until
something matches that it can give you.

486
00:28:31,290 --> 00:28:34,450
Surely, that's not a problem.

487
00:28:34,450 --> 00:28:39,570
[Laughter]
And therefore, Tuple spaces are good, obviously.

488
00:28:39,570 --> 00:28:46,560
And this is the documentation for why Tuple
spaces are better.

489
00:28:46,560 --> 00:28:53,560
Because you have loose coupling amongst loose
processes and message passing, on the other

490
00:28:53,560 --> 00:28:58,770
hand, you actually have to know what, you
know, other actors or whatever things are

491
00:28:58,770 --> 00:29:04,390
in a system, you have to actually address
a message to them in a point to point system.

492
00:29:04,390 --> 00:29:07,670
And this, you don't have to know anything
about your network, you don't have to know

493
00:29:07,670 --> 00:29:12,030
about other people in your system, you just
put your stuff into this big cloudy thing

494
00:29:12,030 --> 00:29:17,390
called a tuple spaces, and you get stuff out,
and you hope it's the thing that you wanted.

495
00:29:17,390 --> 00:29:18,430
So that's good.

496
00:29:18,430 --> 00:29:20,360
It's considered to be a win.

497
00:29:20,360 --> 00:29:25,290
Producers of Tuples also don't have to coexist
at the same time.

498
00:29:25,290 --> 00:29:30,080
Like, you don't have to have two actors live
at the same moment, so you have a process

499
00:29:30,080 --> 00:29:34,370
putting into a Tuple space and three years
later someone taking it out.

500
00:29:34,370 --> 00:29:38,100
So Tuples remain in this space until they're
removed.

501
00:29:38,100 --> 00:29:40,930
Also considered to be a good thing.

502
00:29:40,930 --> 00:29:44,410
So Linda was actually implemented as a language
intention.

503
00:29:44,410 --> 00:29:46,460
So there's two variants of it.

504
00:29:46,460 --> 00:29:49,300
Linda and FORTRAN Linda.

505
00:29:49,300 --> 00:29:54,490
And the thing to note here is that it was
written in some kind of base language, in

506
00:29:54,490 --> 00:29:56,920
this case either C or FORTRAN.

507
00:29:56,920 --> 00:30:01,830
Sorry, it was a compiler of C or foretrain.

508
00:30:01,830 --> 00:30:08,460
And it will automatically generate required
auxillary routines and incorporate different

509
00:30:08,460 --> 00:30:13,970
optimized kernel libraries, you know, for
that platform and that target and whatever

510
00:30:13,970 --> 00:30:16,940
to support the Linda operations that run.

511
00:30:16,940 --> 00:30:21,720
So that's how it was put together.

512
00:30:21,720 --> 00:30:23,270
Okay.

513
00:30:23,270 --> 00:30:25,690
I'm going to -- this is another, like, two-second
one.

514
00:30:25,690 --> 00:30:29,150
So Scala is a library, and that's a big deal.

515
00:30:29,150 --> 00:30:40,490
So back in 2005 or '06, we were, like, hey,
Erlang is a cool thing but the JVM, it would

516
00:30:40,490 --> 00:30:47,020
be cool if we had this lightweight processes
on the JVM, that would be cool.

517
00:30:47,020 --> 00:30:50,010
But these JVM threads, what do we do?

518
00:30:50,010 --> 00:30:55,120
So let's do some of that process management
like Erlang does but as a library with a thread

519
00:30:55,120 --> 00:30:56,460
pool.

520
00:30:56,460 --> 00:30:58,950
We can map it all down JVM threads.

521
00:30:58,950 --> 00:31:01,000
And it turns out it worked.

522
00:31:01,000 --> 00:31:09,280
You can have these lightweight... I wouldn't call them threads, processes, whatever, ala Erlang. Actually implemented on top of a fork-join pool,

523
00:31:09,280 --> 00:31:11,380
and this is actually a really huge deal.

524
00:31:11,380 --> 00:31:12,620
Had a big impact.

525
00:31:12,620 --> 00:31:18,360
Akka later came out of this project called Scala
actors and then it was started by this guy

526
00:31:18,360 --> 00:31:19,970
here called Phillip.

527
00:31:19,970 --> 00:31:25,600
Anyway, so it was a big deal and a lot of
people jumped on using the actor model and

528
00:31:25,600 --> 00:31:28,630
the JVM due to this actually working.

529
00:31:28,630 --> 00:31:36,330
And it was all implemented on a Scala library
ran on a JVM and the same thing is true today.

530
00:31:36,330 --> 00:31:41,640
And you have Martin doing a happy dance because
he's, like, yeah, look at that.

531
00:31:41,640 --> 00:31:44,720
If you go back to this little example here,
you can't really see it very well.

532
00:31:44,720 --> 00:31:47,340
But there's this React thing, which is the
message handler.

533
00:31:47,340 --> 00:31:50,170
You know, that's really neat because it looks
like it's, like, a key word in the language.

534
00:31:50,170 --> 00:31:52,750
It looks like it's built into the language,
but it's just library.

535
00:31:52,750 --> 00:31:58,581
So my language is awesome because it can support
that stuff and also, it can emulate this thing

536
00:31:58,581 --> 00:32:02,710
that required an entire VM; right?

537
00:32:02,710 --> 00:32:06,059
So that's, you know, the Scala.

538
00:32:06,059 --> 00:32:13,120
Cloud Haskell appeared a few years later and
was, like, hey, you know what?

539
00:32:13,120 --> 00:32:18,500
I think there are a lot of different parallel
programming paradigms in practice.

540
00:32:18,500 --> 00:32:22,380
And the difference is really the cost model.

541
00:32:22,380 --> 00:32:25,870
I'm not a believer of the one-size-fits-all
story about parallelism.

542
00:32:25,870 --> 00:32:29,670
I think we can't escape the idea that we will
need to write parallel applications using

543
00:32:29,670 --> 00:32:34,610
different paradigms, and I would like to build
a language or language ecosystem where you

544
00:32:34,610 --> 00:32:40,860
can use lots of different parallels in the
same application where you can have bits of

545
00:32:40,860 --> 00:32:45,360
data parallelism and bits of message passing
all in the same application.

546
00:32:45,360 --> 00:32:51,900
So it's, like, hey, Haskell, kind of, like,
it would be cool if we had some of these Erlang

547
00:32:51,900 --> 00:32:53,190
message passe actor things.

548
00:32:53,190 --> 00:32:57,050
That would be really great.

549
00:32:57,050 --> 00:33:01,710
So Simon not stopping there believes, look,
we can do much better than just having these

550
00:33:01,710 --> 00:33:02,710
actor things.

551
00:33:02,710 --> 00:33:03,950
You guys don't have types.

552
00:33:03,950 --> 00:33:05,090
We can fix that.

553
00:33:05,090 --> 00:33:06,950
And everything is immutable also.

554
00:33:06,950 --> 00:33:10,650
[Laughter]
And our functions are potent.

555
00:33:10,650 --> 00:33:16,780
Obviously better and the reason why it's better
is if something crashes, you can run it somewhere

556
00:33:16,780 --> 00:33:18,230
else, you can reconstruct things.

557
00:33:18,230 --> 00:33:20,880
Clearly better.

558
00:33:20,880 --> 00:33:23,270
And you can separate pure and effectful code.

559
00:33:23,270 --> 00:33:24,940
Also better.

560
00:33:24,940 --> 00:33:28,820
So I think we can improve on this situation
as sort of the basic idea.

561
00:33:28,820 --> 00:33:33,550
So you have processes in Haskell that are
like actors.

562
00:33:33,550 --> 00:33:37,330
They're blessed with this ability to send
and receive messages, they're all lightweight

563
00:33:37,330 --> 00:33:40,030
and don't require much overhead.

564
00:33:40,030 --> 00:33:46,370
Messages as well, which are basically the
way that this works is the actual -- well,

565
00:33:46,370 --> 00:33:48,670
so these things all have to be serialized,
which is complicated.

566
00:33:48,670 --> 00:33:49,860
Don't worry about that.

567
00:33:49,860 --> 00:33:57,520
But the point is that basically one of these
processes can receive another message, which

568
00:33:57,520 --> 00:34:00,540
doesn't have a explicit type associated with
it.

569
00:34:00,540 --> 00:34:02,670
And then it uses type inferences to figure
out what it is.

570
00:34:02,670 --> 00:34:08,629
There are also exist channels, which is a
data structure to send a message of exactly

571
00:34:08,629 --> 00:34:11,119
one type to exactly one node.

572
00:34:11,119 --> 00:34:16,500
So whereas every single node can simply receive
messages of any type automatically and figure

573
00:34:16,500 --> 00:34:20,860
out what is supposed to be, be it the methods
or whatever you're doing with it or functions

574
00:34:20,860 --> 00:34:25,360
that you're using with it, nodes must be given
an explicit send port structure that allows

575
00:34:25,360 --> 00:34:27,169
them to send a message of one type to a channel.

576
00:34:27,169 --> 00:34:31,310
So you have basically, like, kind of any message
that you want, and then, like, these type

577
00:34:31,310 --> 00:34:32,310
channels.

578
00:34:32,310 --> 00:34:33,429
And then they have special closures.

579
00:34:33,429 --> 00:34:37,669
So these are super restrictive closures that
only allow certain things to be in the environment,

580
00:34:37,669 --> 00:34:41,290
and you have to say how everything is serialized
to send it.

581
00:34:41,290 --> 00:34:46,030
So this is what cloud Haskell provides in
the shortest possible description.

582
00:34:46,030 --> 00:34:49,950
And it's implemented as a library.

583
00:34:49,950 --> 00:34:54,480
As a domain-specific language with a little
bit of template Haskell mixed in there.

584
00:34:54,480 --> 00:34:57,980
And it looks a lot like Erlang.

585
00:34:57,980 --> 00:35:00,100
Just to show you a little bit of code.

586
00:35:00,100 --> 00:35:02,150
This is Haskell on the top and Erlang on the
bottom.

587
00:35:02,150 --> 00:35:05,230
Same ping-pong language.

588
00:35:05,230 --> 00:35:06,230
And I have two more things.

589
00:35:06,230 --> 00:35:10,620
I showed you I'm already getting close to
run out of time.

590
00:35:10,620 --> 00:35:11,890
So the next thing is bloom.

591
00:35:11,890 --> 00:35:14,710
Have you guys heard of bloom?

592
00:35:14,710 --> 00:35:15,710
Wahoo.

593
00:35:15,710 --> 00:35:25,220
So I'm really sad that I'm already close to
the end of my time slot because I'm -- so

594
00:35:25,220 --> 00:35:30,320
it's by a group called -- a guy named Peter,
which I hope you guys have all heard of.

595
00:35:30,320 --> 00:35:36,050
It came from a systems group at Berkeley,
and was attempting to indicator to the paramount

596
00:35:36,050 --> 00:35:39,960
issues in the system community that typically
escape the PL community.

597
00:35:39,960 --> 00:35:44,990
So namely, these are issues surrounding things
like coordination and data consistency that

598
00:35:44,990 --> 00:35:49,250
really nobody seemed to care about so much
since Argus and these things should be dealt

599
00:35:49,250 --> 00:35:51,650
with at the level of the programming model.

600
00:35:51,650 --> 00:35:55,940
So that's kind of the why behind Bloom.

601
00:35:55,940 --> 00:35:58,660
I don't have a lot of time to actually read
the quotes.

602
00:35:58,660 --> 00:36:01,571
I'm going to put the slides up afterwards
so you can have a look at this.

603
00:36:01,571 --> 00:36:02,571
This is really cool.

604
00:36:02,571 --> 00:36:09,570
Basically, he's saying acid is slow, let's
have less coordination with things as things

605
00:36:09,570 --> 00:36:12,310
become more and more distributed, basically.

606
00:36:12,310 --> 00:36:18,600
And we have this calm principle that kind
of, you know, let's us reduce coordination

607
00:36:18,600 --> 00:36:21,300
and maybe we can put this into a programming
language.

608
00:36:21,300 --> 00:36:22,580
It's kind of the idea.

609
00:36:22,580 --> 00:36:24,480
And we do this in a declarative language.

610
00:36:24,480 --> 00:36:29,950
So it's a declarative language that uses program
analysis techniques, which enable both static

611
00:36:29,950 --> 00:36:37,000
analysis and run time annotations on consistencies,
so you can make sure that consistency is -- you

612
00:36:37,000 --> 00:36:40,780
can say something about consistency with,
like, you know, by giving somebody a certain

613
00:36:40,780 --> 00:36:45,670
programming model and then analyzing the code
that they write.

614
00:36:45,670 --> 00:36:51,930
So in this analysis like you said, it's based
on this calm principle, which is a type -- this

615
00:36:51,930 --> 00:37:02,290
builds a tight relationship between consistency
and logical monotonicity, under any interleaving

616
00:37:02,290 --> 00:37:10,190
delivery and computation, so basically, the
idea is, you know, you can deliver messages

617
00:37:10,190 --> 00:37:13,270
in any order or whatever and the idea, you
know, is that you should have the same result.

618
00:37:13,270 --> 00:37:16,110
And that result should somehow, monotonic.

619
00:37:16,110 --> 00:37:22,230
So by contrast in monotonicity is requirement
of synchronization points.

620
00:37:22,230 --> 00:37:27,190
So if you have nonmonotonic programs.

621
00:37:27,190 --> 00:37:31,580
So it's, like, well, monotonicity is important.

622
00:37:31,580 --> 00:37:33,780
It's important consistency.

623
00:37:33,780 --> 00:37:39,481
So therefore, because monotonicity is a big
deal, bundles of declarative statements.

624
00:37:39,481 --> 00:37:45,750
Statements are defined with respect to these
weird time stamps and there's no immutable

625
00:37:45,750 --> 00:37:49,970
state, no side effects and things happen in
any order.

626
00:37:49,970 --> 00:37:57,140
They argue that organized assumptions based
on this traditional vector that sort of informed

627
00:37:57,140 --> 00:37:59,760
all of imperative programming, that's the
problem.

628
00:37:59,760 --> 00:38:01,630
So therefore, we need no order at all.

629
00:38:01,630 --> 00:38:03,660
Order is gone.

630
00:38:03,660 --> 00:38:06,960
And then we just -- then we can do all kinds
of analysis to make sure things are monotonic

631
00:38:06,960 --> 00:38:10,110
and think about where synchronization would
have to occur.

632
00:38:10,110 --> 00:38:11,110
That's the idea.

633
00:38:11,110 --> 00:38:16,380
I'm going to skip over the, you know, some
of the operations.

634
00:38:16,380 --> 00:38:20,330
But the cool thing is that you have a bunch
of statements that operate on these weird

635
00:38:20,330 --> 00:38:23,830
time steps, and then you get higher functions.

636
00:38:23,830 --> 00:38:28,760
So you kind of reason in terms of these weird
time steps, and then you have high order functions

637
00:38:28,760 --> 00:38:31,190
to, like, do more interesting things with.

638
00:38:31,190 --> 00:38:32,540
So just a note.

639
00:38:32,540 --> 00:38:35,470
And Bloom is implemented in Ruby, actually.

640
00:38:35,470 --> 00:38:39,110
A Bloom program is just a Ruby class definition.

641
00:38:39,110 --> 00:38:42,860
I'm telling you why this whole implementation
point because you should be notifying a pattern

642
00:38:42,860 --> 00:38:44,350
over time.

643
00:38:44,350 --> 00:38:46,190
The next one is Lasp.

644
00:38:46,190 --> 00:38:52,110
I'm going to go since everybody think so that
Lasp is the most well-known distributed programming

645
00:38:52,110 --> 00:38:53,110
language.

646
00:38:53,110 --> 00:38:56,270
[Laughter]
I mean really, guys.

647
00:38:56,270 --> 00:39:03,010
Lasp appeared because, you know, it's the
future, it's 2015 when it was created.

648
00:39:03,010 --> 00:39:04,490
Everything is somehow distributed.

649
00:39:04,490 --> 00:39:08,640
You got mobile games and add counters and
this Internet of whatever you want to call

650
00:39:08,640 --> 00:39:10,120
these things.

651
00:39:10,120 --> 00:39:12,010
I would use a different word.

652
00:39:12,010 --> 00:39:13,430
But whatever.

653
00:39:13,430 --> 00:39:16,820
So you have a bunch of things that are connected,
and you have all of these services being called

654
00:39:16,820 --> 00:39:19,450
all the time and really stupid small programs.

655
00:39:19,450 --> 00:39:21,940
Lots of things are happening.

656
00:39:21,940 --> 00:39:26,810
And synchronization gets a little ridiculous
when one app has to make a call to three dozen

657
00:39:26,810 --> 00:39:28,210
other services during its usage.

658
00:39:28,210 --> 00:39:31,510
So got to somehow reduce synchronization,
yes.

659
00:39:31,510 --> 00:39:35,869
And also, we can't get away from the idea
that state has to be replicated somehow.

660
00:39:35,869 --> 00:39:40,930
I can come up with a silly example of a game
where, you know, you're fighting with some

661
00:39:40,930 --> 00:39:46,180
other character having a sword fight, and,
you know, you each have health, like, health

662
00:39:46,180 --> 00:39:50,020
counters, whatever, but you can see each other's
health counter because that's a replicated

663
00:39:50,020 --> 00:39:53,940
state and if you're fighting this guy with
a sword, and you go into a tunnel because

664
00:39:53,940 --> 00:39:58,630
you're on a train and doing it on your phone,
you've got to somehow continue playing or

665
00:39:58,630 --> 00:40:01,980
doing whatever, and then you both have to
arrive at the same state.

666
00:40:01,980 --> 00:40:02,980
Either you died or he died.

667
00:40:02,980 --> 00:40:04,500
One of you died.

668
00:40:04,500 --> 00:40:10,050
So that's a situation where, you know, it's
obviously extremely important, most important

669
00:40:10,050 --> 00:40:15,300
situation you would ever need replicated state,
obviously.

670
00:40:15,300 --> 00:40:24,120
And CRDTs are a thing that basically make
it easier to reason about -- reason about

671
00:40:24,120 --> 00:40:26,119
replicated state in a distributed system.

672
00:40:26,119 --> 00:40:28,790
And last, build CRDTs into the language.

673
00:40:28,790 --> 00:40:33,270
I would love to talk a lot about CRDTs, but,
again, related to monotonicity and all of

674
00:40:33,270 --> 00:40:40,310
these things, the idea that you can do a number
of updates in any order but two replicas of

675
00:40:40,310 --> 00:40:45,050
the same sets should always arrive -- should
always arrive at the same result.

676
00:40:45,050 --> 00:40:48,520
Should always have -- should converge to the
same state.

677
00:40:48,520 --> 00:40:50,270
It's the basic idea; right?

678
00:40:50,270 --> 00:40:53,060
So eventually consistent.

679
00:40:53,060 --> 00:40:57,330
And then you can take this model of a CRDT
and implement different data structures like

680
00:40:57,330 --> 00:41:01,390
sets, accounts, registers, dictionary, graphs,
et cetera.

681
00:41:01,390 --> 00:41:07,460
And last, piggybacks on this idea of a CRDT,
and it's, like, guys, we could build really,

682
00:41:07,460 --> 00:41:13,670
like, rich computations up by composing operations
on these CRDTs.

683
00:41:13,670 --> 00:41:18,170
So these are data structures, we can kind
of have functional, like, high-order functions

684
00:41:18,170 --> 00:41:20,619
and compose stuff, and it would be really
cool.

685
00:41:20,619 --> 00:41:26,520
So last number of APIs, this functional one,
theoretic one, and then core API, which does

686
00:41:26,520 --> 00:41:31,359
basic stuff, like, binding and updating, things
that you would expect.

687
00:41:31,359 --> 00:41:36,650
And what's most important is, you know, this
is what it looks like.

688
00:41:36,650 --> 00:41:40,240
You have -- I know what you all Lasp users,
so I know I shouldn't show you pictures of

689
00:41:40,240 --> 00:41:41,280
what the code looks like.

690
00:41:41,280 --> 00:41:44,200
It's really boring, I guess.

691
00:41:44,200 --> 00:41:46,720
So it's all implemented on top of Erlang.

692
00:41:46,720 --> 00:41:48,270
It's just an Erlang library.

693
00:41:48,270 --> 00:41:53,661
Just Ayer language library, and it's built
on top of Reac, which provides a certain type

694
00:41:53,661 --> 00:41:59,050
of CRDT and all implemented in Erlang, basically.

695
00:41:59,050 --> 00:42:00,050
Okay.

696
00:42:00,050 --> 00:42:04,450
So that was seven programming languages, guys.

697
00:42:04,450 --> 00:42:06,040
So where did all the distributed languages
go?

698
00:42:06,040 --> 00:42:08,470
That was the whole point of this talk.

699
00:42:08,470 --> 00:42:12,110
And what I hope to argue right now is that
they didn't go anywhere, actually.

700
00:42:12,110 --> 00:42:15,460
All of these distributed languages are just
DSLs now or libraries or whatever you want

701
00:42:15,460 --> 00:42:16,460
to call them.

702
00:42:16,460 --> 00:42:19,869
So at some point, I say, well, you have to
ask yourself what the hell is a programming

703
00:42:19,869 --> 00:42:20,869
language anyway?

704
00:42:20,869 --> 00:42:26,430
Do I need to implement an entire run time
system to count it as a language?

705
00:42:26,430 --> 00:42:32,030
And honestly I believe is that we should probably
stop calling some of these languages, languages

706
00:42:32,030 --> 00:42:35,940
and instead, we should just call them programming
models.

707
00:42:35,940 --> 00:42:43,440
Haskell, Scala, Erlang, Java, all of these
things have proven to be good languages to

708
00:42:43,440 --> 00:42:49,970
because he had entirely new smaller languages
or paradigms for doing distributed computation

709
00:42:49,970 --> 00:42:50,970
in.

710
00:42:50,970 --> 00:42:55,510
And, you know, there's really no harm in piggybacking
on the entire mountain of work that somebody

711
00:42:55,510 --> 00:43:07,640
else has done to with some kernel or to do
some kind of portability out of some underlying

712
00:43:07,640 --> 00:43:09,640
system.

713
00:43:09,640 --> 00:43:15,820
So this DSL approach, I think is actually
where a lot of these distributed programming

714
00:43:15,820 --> 00:43:16,890
languages are going.

715
00:43:16,890 --> 00:43:23,640
They're actually becoming new programming
models implemented inside of another language.

716
00:43:23,640 --> 00:43:30,160
And I'm going to end on this one sort of,
like, funny summary, in my view, of kind of

717
00:43:30,160 --> 00:43:31,980
how I look at research.

718
00:43:31,980 --> 00:43:36,869
I started this conversation -- or this talk
about, hey, research is actually, like, this

719
00:43:36,869 --> 00:43:41,240
fast-moving thing if you zoom out in time
a little bit, and it's like people arguing

720
00:43:41,240 --> 00:43:42,430
about stuff.

721
00:43:42,430 --> 00:43:46,850
So you have this really funny, dynamic conversation
going on over the course of many decades where

722
00:43:46,850 --> 00:43:50,270
you have Argus is, like, hey, guys, consistency
is super important.

723
00:43:50,270 --> 00:43:52,610
Also, we should worry about partial failure.

724
00:43:52,610 --> 00:43:58,170
I'm pretty sure it's going to be a big deal.

725
00:43:58,170 --> 00:43:59,170
1988.

726
00:43:59,170 --> 00:44:00,170
And you know what?

727
00:44:00,170 --> 00:44:04,400
RPC is a good way to do requests and to make
requests to do response.

728
00:44:04,400 --> 00:44:06,930
Should do RPC and promises are great.

729
00:44:06,930 --> 00:44:10,780
One language came up with, like -- well, they
didn't come up with RPC but, you know, fought

730
00:44:10,780 --> 00:44:11,780
for it.

731
00:44:11,780 --> 00:44:14,350
Put all of these ideas, like, in one language,
which was pretty cool.

732
00:44:14,350 --> 00:44:18,320
And then you have Emerald who pops up and
is, like, hey, objects, objects, objects,

733
00:44:18,320 --> 00:44:21,040
they should be unified, mobile, efficient.

734
00:44:21,040 --> 00:44:23,400
I agree definitely efficient.

735
00:44:23,400 --> 00:44:25,130
Abstract types too.

736
00:44:25,130 --> 00:44:26,300
Erlang appears.

737
00:44:26,300 --> 00:44:30,650
Message passing is king, processes should
be light and totally independent.

738
00:44:30,650 --> 00:44:31,770
Okay.

739
00:44:31,770 --> 00:44:36,350
That was kind of some of the ideas that Argus
also fought for.

740
00:44:36,350 --> 00:44:40,410
Linda somewhere out in a corner field.

741
00:44:40,410 --> 00:44:44,080
Guys, message passing is totally crazy.

742
00:44:44,080 --> 00:44:46,000
Shared memory model is definitely more natural.

743
00:44:46,000 --> 00:44:47,720
Like, this is how we think.

744
00:44:47,720 --> 00:44:50,840
So Tuple spaces, we can make them efficient.

745
00:44:50,840 --> 00:44:52,750
You know, that's going to be the solution.

746
00:44:52,750 --> 00:44:56,119
And then you have a Scala and Haskell appearing
here.

747
00:44:56,119 --> 00:44:57,950
Like, man, Erlang is kind of sexy.

748
00:44:57,950 --> 00:44:59,430
We like Erlang a little bit.

749
00:44:59,430 --> 00:45:03,220
Do you think we could because he had this
Erlang stuff around language?

750
00:45:03,220 --> 00:45:06,630
Scala is, like, hey, we don't need a whole
VM to manage these processes.

751
00:45:06,630 --> 00:45:08,350
We can do it as a library.

752
00:45:08,350 --> 00:45:09,570
Awesome.

753
00:45:09,570 --> 00:45:11,500
Same kind of idea in Haskell.

754
00:45:11,500 --> 00:45:13,800
But we can also do better.

755
00:45:13,800 --> 00:45:15,520
Types and yay.

756
00:45:15,520 --> 00:45:16,650
Channels.

757
00:45:16,650 --> 00:45:21,180
Bloom appears, like, guys.

758
00:45:21,180 --> 00:45:22,790
Programming language people.

759
00:45:22,790 --> 00:45:25,680
Really, you guys forgot about the most important
thing.

760
00:45:25,680 --> 00:45:26,900
Totally left consistency.

761
00:45:26,900 --> 00:45:30,380
Everything that you're doing submarine monotonic
because you have no idea what order things

762
00:45:30,380 --> 00:45:34,660
are going to happen in and make sure that
your parts of your program are monotonic so

763
00:45:34,660 --> 00:45:36,160
you can move coordination.

764
00:45:36,160 --> 00:45:42,230
Everything is great and programming languages
people are, like, whoa what -- I don't even

765
00:45:42,230 --> 00:45:43,480
know what that is.

766
00:45:43,480 --> 00:45:48,940
[Laughter]
They know what data log is.

767
00:45:48,940 --> 00:45:52,650
And last appears is, like, hey, consistency
is important but so he so is compossibility,

768
00:45:52,650 --> 00:45:54,690
so let's put this into the language.

769
00:45:54,690 --> 00:46:01,300
Let's compose this, you know, these monotonic
things together and, you know, make this available

770
00:46:01,300 --> 00:46:02,800
to people in a programming model.

771
00:46:02,800 --> 00:46:07,930
That would be way more easy to reason about
than a data loggy thing.

772
00:46:07,930 --> 00:46:11,660
So these are really conversations, and I hope
you see that at the end of this.

773
00:46:11,660 --> 00:46:15,619
And it at that point, I'm sorry that I'm,
like, rambling for so long.

774
00:46:15,619 --> 00:46:20,050
I'm going to say thank you for coming, and
you should probably come ask me questions

775
00:46:20,050 --> 00:46:24,320
instead of raising your hand and doing questions
now.

776
00:46:24,320 --> 00:46:27,440
You should also run to the keynote because
I definitely went over time, and I'm sorry.

777
00:46:27,440 --> 00:46:27,940
[Applause]