1
00:00:06,660 --> 00:00:08,620
- Data-oriented Design.

2
00:00:08,620 --> 00:00:10,770
Before we get into data structures in Go,

3
00:00:10,770 --> 00:00:12,790
I really want to share some information

4
00:00:12,790 --> 00:00:14,020
around data-oriented design.

5
00:00:14,020 --> 00:00:16,790
It's a really important aspect, I believe,

6
00:00:16,790 --> 00:00:18,880
of the language, and one of these things

7
00:00:18,880 --> 00:00:19,713
that you're going to have to kind of

8
00:00:19,713 --> 00:00:21,530
start switching your brain into

9
00:00:21,530 --> 00:00:24,140
away from object-oriented design.

10
00:00:24,140 --> 00:00:28,220
Now, I've said a few times
already in this training material

11
00:00:28,220 --> 00:00:30,510
that what data-oriented design is about

12
00:00:30,510 --> 00:00:34,160
is the understanding that
every problem you solve

13
00:00:34,160 --> 00:00:35,600
is a data problem.

14
00:00:35,600 --> 00:00:38,660
We are all data scientists
at the end of the day.

15
00:00:38,660 --> 00:00:40,070
Integrity comes from the data,

16
00:00:40,070 --> 00:00:41,769
our performance is going
to be coming from the data,

17
00:00:41,769 --> 00:00:43,920
everything we do, our mental models,

18
00:00:43,920 --> 00:00:45,950
everything's going to
be coming from the data.

19
00:00:45,950 --> 00:00:47,700
If you don't understand the
data you're working with

20
00:00:47,700 --> 00:00:50,130
you don't understand the
problem you're trying to solve,

21
00:00:50,130 --> 00:00:53,170
because all problems
are specific and unique

22
00:00:53,170 --> 00:00:55,210
to the data that you are working with,

23
00:00:55,210 --> 00:00:57,260
and data transformations are at the heart

24
00:00:57,260 --> 00:00:59,720
of everything we do, every
function, every method,

25
00:00:59,720 --> 00:01:01,880
every encapsulation is really

26
00:01:01,880 --> 00:01:06,610
around the data transformations
that we're working on.

27
00:01:06,610 --> 00:01:07,810
But here's a big part of it,

28
00:01:07,810 --> 00:01:09,800
everything we do right now
that we've been talking about

29
00:01:09,800 --> 00:01:11,080
is in the concrete.

30
00:01:11,080 --> 00:01:12,750
Our problems are solved
in the concrete data,

31
00:01:12,750 --> 00:01:14,730
our manipulations, our memory mutations,

32
00:01:14,730 --> 00:01:16,290
everything is in the concrete.

33
00:01:16,290 --> 00:01:17,400
But here's the problem.

34
00:01:17,400 --> 00:01:19,860
When the concrete data is changing,

35
00:01:19,860 --> 00:01:21,640
then your problems are changing,

36
00:01:21,640 --> 00:01:23,600
and if your problems are
changing, guess what,

37
00:01:23,600 --> 00:01:25,470
your algorithms have to change.

38
00:01:25,470 --> 00:01:26,830
There's nothing wrong with that

39
00:01:26,830 --> 00:01:29,560
except we start to fall into these areas

40
00:01:29,560 --> 00:01:32,240
where, once the data's changing
and our algorithms change,

41
00:01:32,240 --> 00:01:35,500
sometimes that creates
changes, cascading changes

42
00:01:35,500 --> 00:01:38,790
across an entire code base,
and there's a lot of pain.

43
00:01:38,790 --> 00:01:40,650
This is when we start to start focusing

44
00:01:40,650 --> 00:01:44,470
on how do I decouple the
code from these data changes

45
00:01:44,470 --> 00:01:46,830
so these cascading changes are minimized?

46
00:01:46,830 --> 00:01:49,030
We will be talking
about that in this class

47
00:01:49,030 --> 00:01:50,930
when we start getting into
methods and interfaces

48
00:01:50,930 --> 00:01:52,330
and things like that.

49
00:01:52,330 --> 00:01:53,640
But here's the thing,

50
00:01:53,640 --> 00:01:56,400
if you're abstracting in a general way,

51
00:01:56,400 --> 00:01:59,060
if you're building abstractions
on top of abstractions,

52
00:01:59,060 --> 00:02:00,690
you're really walking
away from all the things

53
00:02:00,690 --> 00:02:01,940
we've talked about so far,

54
00:02:01,940 --> 00:02:05,890
that the idea of optimizing for
correctness and readability.

55
00:02:05,890 --> 00:02:07,480
You're walking away from your, really,

56
00:02:07,480 --> 00:02:09,930
ability to even understand
the mental models of your code

57
00:02:09,930 --> 00:02:11,600
because it's too abstract.

58
00:02:11,600 --> 00:02:14,620
What we need is this balance of decoupling

59
00:02:14,620 --> 00:02:19,420
but thin layers of decoupling
to deal with change.

60
00:02:19,420 --> 00:02:21,500
Change is still going to be important.

61
00:02:21,500 --> 00:02:24,010
But, look, if you're
starting to write some code

62
00:02:24,010 --> 00:02:26,070
and you're uncertain about the data,

63
00:02:26,070 --> 00:02:27,920
this doesn't give you a license to guess.

64
00:02:27,920 --> 00:02:31,350
It's a directive to stop,
stop what you're doing,

65
00:02:31,350 --> 00:02:33,390
sit back and ask yourself,

66
00:02:33,390 --> 00:02:36,090
what are the data transformations
that are in front of me.

67
00:02:36,090 --> 00:02:38,430
You don't have to know about all of them,

68
00:02:38,430 --> 00:02:40,640
but you can only code the ones

69
00:02:40,640 --> 00:02:41,890
that you're comfortable with,

70
00:02:41,890 --> 00:02:43,940
that you feel very confident about

71
00:02:43,940 --> 00:02:46,500
in terms of what my input
and what my output is.

72
00:02:46,500 --> 00:02:49,050
Look, if you are solving
problems you don't have,

73
00:02:49,050 --> 00:02:51,500
you're now creating more
problems that you do.

74
00:02:51,500 --> 00:02:53,780
We are writing code for today,

75
00:02:53,780 --> 00:02:56,550
we're going to design an
architect for tomorrow.

76
00:02:56,550 --> 00:02:59,160
Don't add more code to the code
you need today than you do.

77
00:02:59,160 --> 00:03:02,060
We've talked about that, that
just lends itself to bugs,

78
00:03:02,060 --> 00:03:04,710
more lines of code,
places for bugs to hide.

79
00:03:04,710 --> 00:03:07,060
We've had these conversations already.

80
00:03:07,060 --> 00:03:08,780
I want to just keep
reiterating this thing,

81
00:03:08,780 --> 00:03:11,540
that data-oriented design is
about understanding the data,

82
00:03:11,540 --> 00:03:14,620
writing the code that we need,
the algorithms that we need

83
00:03:14,620 --> 00:03:18,100
and eventually decoupling
those algorithms that we have

84
00:03:18,100 --> 00:03:22,134
in the concrete to deal
with the data changes.

85
00:03:22,134 --> 00:03:24,639
Everything we must do,
everything we must do

86
00:03:24,639 --> 00:03:27,187
must be focused around
minimizing, simplifying,

87
00:03:27,187 --> 00:03:29,630
and reducing the amount of code we need

88
00:03:29,630 --> 00:03:30,900
to solve every problem.

89
00:03:30,900 --> 00:03:34,540
We're going to learn very soon
about mechanical sympathy.

90
00:03:34,540 --> 00:03:38,070
If performance matters,
then how the hardware works

91
00:03:38,070 --> 00:03:40,940
and the operating system
work has to matter to you.

92
00:03:40,940 --> 00:03:42,630
It all, again, is going to be tying back

93
00:03:42,630 --> 00:03:44,610
into data-oriented design.

94
00:03:44,610 --> 00:03:45,940
Data, data, data, data, data.

95
00:03:45,940 --> 00:03:48,370
You don't want to hear me
moving forward quite a bit,

96
00:03:48,370 --> 00:03:50,790
constantly talking about
data driven everything,

97
00:03:50,790 --> 00:03:51,890
data's driving everything,

98
00:03:51,890 --> 00:03:55,170
everything is being driven
that way, all right.

99
00:03:55,170 --> 00:03:57,610
We're going to start looking
at those data structures,

100
00:03:57,610 --> 00:04:00,110
and start understanding why
Go only gives us a raise,

101
00:04:00,110 --> 00:04:01,830
and slices and maps,

102
00:04:01,830 --> 00:04:04,030
and I want to show you
the mechanical sympathies

103
00:04:04,030 --> 00:04:05,740
that these data structures have,

104
00:04:05,740 --> 00:04:08,040
and how we're able to not hide the cost

105
00:04:08,040 --> 00:04:09,470
of the things that we're doing,

106
00:04:09,470 --> 00:04:11,430
and we're able to gain more efficiencies

107
00:04:11,430 --> 00:04:12,710
when we're working with the data,

108
00:04:12,710 --> 00:04:14,820
and be able to write
algorithms that are readable

109
00:04:14,820 --> 00:04:17,300
and yet still very, very performant,

110
00:04:17,300 --> 00:04:18,840
because, again, on the scale

111
00:04:18,840 --> 00:04:21,440
of where do you lose
your performance in Go,

112
00:04:21,440 --> 00:04:24,920
algorithm efficiency is
really at the bottom of that.

113
00:04:24,920 --> 00:04:27,120
It's going to be latency
at networking and I/O,

114
00:04:27,120 --> 00:04:29,800
latency on allocations and memory,

115
00:04:29,800 --> 00:04:34,000
and latencies in your
inability to write code

116
00:04:34,000 --> 00:04:37,180
that can manage and work
with data efficiently.

117
00:04:37,180 --> 00:04:40,320
These are things we're
going to talk about now.

118
00:04:40,320 --> 00:04:41,370
We're going to start trying to,

119
00:04:41,370 --> 00:04:43,970
I'm going to just start
trying to break you down

120
00:04:43,970 --> 00:04:45,020
and build you back up

121
00:04:45,020 --> 00:04:48,060
to get away from these
object-oriented design principles

122
00:04:48,060 --> 00:04:49,110
and start moving

123
00:04:49,110 --> 00:04:52,223
towards these data-oriented
design principles.