WEBVTT

1
00:00:00.160 --> 00:00:03.480
<v Speaker 1>Welcome to the deep dive. This is where we take

2
00:00:03.640 --> 00:00:06.919
<v Speaker 1>you know, that big stack of technical papers, research, maybe

3
00:00:06.919 --> 00:00:10.560
<v Speaker 1>some book chapters, and boil it down. Today we're digging

4
00:00:10.560 --> 00:00:13.880
<v Speaker 1>into mastering Go third edition. We're focusing on the Go

5
00:00:14.000 --> 00:00:16.679
<v Speaker 1>programming language, Go laying right.

6
00:00:16.920 --> 00:00:19.519
<v Speaker 2>And our mission today it's pretty straightforward. We want to

7
00:00:19.559 --> 00:00:23.039
<v Speaker 2>give you the core ideas, the sort of architectural thinking

8
00:00:23.120 --> 00:00:23.640
<v Speaker 2>behind Go.

9
00:00:24.000 --> 00:00:27.160
<v Speaker 1>Yeah, what makes it good for system stuff concurrency exactly?

10
00:00:27.280 --> 00:00:30.320
<v Speaker 2>And how you can grasp that without wading through like

11
00:00:30.640 --> 00:00:33.399
<v Speaker 2>super dense text. We want to get the feel of.

12
00:00:33.359 --> 00:00:36.640
<v Speaker 1>Go, the mindset. Yeah. The source material really hammers home

13
00:00:36.679 --> 00:00:41.119
<v Speaker 1>this idea that goes strength comes from being well, simple

14
00:00:41.119 --> 00:00:44.479
<v Speaker 1>and clear ruthlessly so almost it really does. So let's

15
00:00:44.560 --> 00:00:46.759
<v Speaker 1>unpack that. Where did it start? What's its main goal?

16
00:00:46.840 --> 00:00:49.840
<v Speaker 2>Okay, so Go it's open source, started at Google and

17
00:00:49.880 --> 00:00:51.479
<v Speaker 2>went public around two thousand and nine.

18
00:00:51.520 --> 00:00:54.439
<v Speaker 1>And the names involved Greasemur, Thompson, Pike. These aren't just

19
00:00:54.520 --> 00:00:55.520
<v Speaker 1>random folks.

20
00:00:55.359 --> 00:00:59.000
<v Speaker 2>No, absolutely not. These are like programming legends. They knew

21
00:00:59.000 --> 00:01:03.200
<v Speaker 2>what systems programming needed, especially with multi core processors becoming

22
00:01:03.200 --> 00:01:07.040
<v Speaker 2>the norm. They were building for reliability, for scale.

23
00:01:06.760 --> 00:01:10.680
<v Speaker 1>And the source emphasizes it's mainly for systems programming, right,

24
00:01:11.040 --> 00:01:12.280
<v Speaker 1>even though it's general.

25
00:01:12.000 --> 00:01:18.120
<v Speaker 2>Purpose, that's its sweet spot. Think system tools, command line utilities, Docker, Hugo,

26
00:01:18.200 --> 00:01:19.079
<v Speaker 2>those kinds of things.

27
00:01:19.120 --> 00:01:24.840
<v Speaker 1>Big infrastructure too, like Kubernetes, a STO, massive networking servers definitely.

28
00:01:24.560 --> 00:01:27.760
<v Speaker 2>And that efficiency thinking. It starts right away with how

29
00:01:27.799 --> 00:01:29.280
<v Speaker 2>you actually run your GO code.

30
00:01:29.480 --> 00:01:31.719
<v Speaker 1>Ah, right, you got the two main ways.

31
00:01:31.799 --> 00:01:34.719
<v Speaker 2>Yeah, there's Go run, which is quick, feels kind of

32
00:01:34.760 --> 00:01:38.040
<v Speaker 2>like scripting, you know, builds a temporary thing, runs, it

33
00:01:38.079 --> 00:01:40.120
<v Speaker 2>cleans up, instant feedback.

34
00:01:40.200 --> 00:01:41.959
<v Speaker 1>Good for testing stuff out for sure.

35
00:01:42.480 --> 00:01:46.480
<v Speaker 2>But the real power, especially for systems deployment, is Go build.

36
00:01:46.599 --> 00:01:49.879
<v Speaker 1>And what's the key takeaway there. It's not just compiling, No.

37
00:01:49.840 --> 00:01:53.359
<v Speaker 2>It's what you get a single statically linked binary file

38
00:01:53.840 --> 00:01:57.280
<v Speaker 2>that's huge, meaning everything it needs to run is baked

39
00:01:57.280 --> 00:02:00.400
<v Speaker 2>into that one file. No external dependencies to chase down,

40
00:02:00.719 --> 00:02:02.879
<v Speaker 2>no complex run times to install on the server.

41
00:02:03.000 --> 00:02:05.560
<v Speaker 1>Just copy and run. Solves a lot of deployment etics,

42
00:02:05.599 --> 00:02:07.400
<v Speaker 1>copendency hell gone.

43
00:02:07.280 --> 00:02:11.800
<v Speaker 2>Exactly, total simplicity, which interestingly is why the material even

44
00:02:11.800 --> 00:02:14.960
<v Speaker 2>suggests Go could be a good first language for someone

45
00:02:15.039 --> 00:02:16.639
<v Speaker 2>learning to code because.

46
00:02:16.360 --> 00:02:20.080
<v Speaker 1>It forces good habits, less for both clear rules.

47
00:02:20.240 --> 00:02:22.840
<v Speaker 2>Yeah, it sort of guides you towards clarity right from

48
00:02:22.879 --> 00:02:23.240
<v Speaker 2>the start.

49
00:02:23.319 --> 00:02:26.840
<v Speaker 1>Okay, So this ruthless simplicity idea, it shows up in

50
00:02:26.840 --> 00:02:29.680
<v Speaker 1>the language rules themselves, doesn't it. It's not just philosophy,

51
00:02:29.800 --> 00:02:30.680
<v Speaker 1>it's enforced.

52
00:02:30.800 --> 00:02:34.400
<v Speaker 2>Oh absolutely, And that strictness is what enables the stability

53
00:02:34.439 --> 00:02:37.800
<v Speaker 2>you need for goes big party trick concurrency.

54
00:02:38.000 --> 00:02:40.560
<v Speaker 1>But yeah, the rules like curly braces, that's.

55
00:02:40.360 --> 00:02:43.319
<v Speaker 2>A classic one. The source reminds us there's only one

56
00:02:43.360 --> 00:02:46.599
<v Speaker 2>way to format curly braces and go the tools enforce.

57
00:02:46.319 --> 00:02:50.120
<v Speaker 1>It, which probably saves countless hours of team arguments about

58
00:02:50.159 --> 00:02:50.879
<v Speaker 1>style guides.

59
00:02:51.080 --> 00:02:54.319
<v Speaker 2>You bet. It just settles the debate productivity win right there.

60
00:02:54.360 --> 00:02:57.400
<v Speaker 1>And the other big one is types right, type safety,

61
00:02:57.680 --> 00:02:58.240
<v Speaker 1>very strict.

62
00:02:58.360 --> 00:03:02.439
<v Speaker 2>GO won't just automatically change say an integer into a

63
00:03:02.479 --> 00:03:04.800
<v Speaker 2>float for you, no implicit conversions like that.

64
00:03:04.879 --> 00:03:07.400
<v Speaker 1>You have to explicitly cast it, tell GO yes, I

65
00:03:07.479 --> 00:03:08.080
<v Speaker 1>mean to do.

66
00:03:08.039 --> 00:03:12.319
<v Speaker 2>This exactly, which cuts out a whole category of really

67
00:03:12.400 --> 00:03:15.840
<v Speaker 2>subtle bugs, you know, where the language silently changes the

68
00:03:15.960 --> 00:03:19.319
<v Speaker 2>value and maybe loses precision and you didn't even realize.

69
00:03:19.400 --> 00:03:22.840
<v Speaker 1>Okay, makes sense. Let's talk about function returns, go off

70
00:03:22.840 --> 00:03:26.000
<v Speaker 1>and returns multiple values. How does that work in practice?

71
00:03:26.319 --> 00:03:27.759
<v Speaker 1>Doesn't it get messy.

72
00:03:27.599 --> 00:03:32.599
<v Speaker 2>It actually pushes you towards cleaner error handling. The common

73
00:03:32.680 --> 00:03:35.719
<v Speaker 2>pattern is to return two things, the actual result you

74
00:03:35.759 --> 00:03:36.759
<v Speaker 2>wanted and an.

75
00:03:36.719 --> 00:03:39.479
<v Speaker 1>Error value, like the strack on v dot oi function

76
00:03:39.759 --> 00:03:41.479
<v Speaker 1>for converting strings to integers.

77
00:03:41.520 --> 00:03:44.039
<v Speaker 2>Precisely, it gives you the integer or an error if

78
00:03:44.080 --> 00:03:46.240
<v Speaker 2>the string wasn't a valid number, and you have to

79
00:03:46.280 --> 00:03:48.639
<v Speaker 2>deal with that error variable or the compiler complaint.

80
00:03:48.680 --> 00:03:50.639
<v Speaker 1>So you can't easily ignore potential problems.

81
00:03:50.759 --> 00:03:52.879
<v Speaker 2>Right, and the authors give a nice rule of thumb.

82
00:03:53.039 --> 00:03:55.520
<v Speaker 2>If your function needs to send back more than say,

83
00:03:55.599 --> 00:03:59.319
<v Speaker 2>three values, maybe rethink it. Also bundle them up, return

84
00:03:59.319 --> 00:04:02.120
<v Speaker 2>a customs strike to containing those values, or maybe a slice.

85
00:04:02.319 --> 00:04:03.800
<v Speaker 2>Keep the function's signature clean.

86
00:04:04.000 --> 00:04:07.680
<v Speaker 1>Got it, okay? Data structures arrays versus slices. What's the

87
00:04:07.680 --> 00:04:09.039
<v Speaker 1>core difference we need to grasp?

88
00:04:09.439 --> 00:04:12.800
<v Speaker 2>So arrays in go have a fixed length. Once you

89
00:04:12.840 --> 00:04:15.919
<v Speaker 2>declare an array of five integers, it's always five integers.

90
00:04:15.960 --> 00:04:18.040
<v Speaker 2>Slices are built on top of arrays.

91
00:04:18.199 --> 00:04:20.199
<v Speaker 1>But they're more flexible, much more.

92
00:04:20.600 --> 00:04:24.560
<v Speaker 2>A slice is like a dynamic view or window onto

93
00:04:24.600 --> 00:04:27.560
<v Speaker 2>an underlying array. It keeps track of its length and

94
00:04:27.560 --> 00:04:31.160
<v Speaker 2>its capacity, how much space is available in that underlying array.

95
00:04:31.399 --> 00:04:33.759
<v Speaker 2>You can check capacity with cap and you can add

96
00:04:33.800 --> 00:04:36.519
<v Speaker 2>things yep using the pen function. If you append something

97
00:04:36.560 --> 00:04:39.639
<v Speaker 2>and the underlying array is full, GO handles it for you.

98
00:04:39.720 --> 00:04:43.680
<v Speaker 2>It allocates a new, bigger array and copies everything over.

99
00:04:43.759 --> 00:04:44.600
<v Speaker 2>It's pretty efficient.

100
00:04:44.680 --> 00:04:46.399
<v Speaker 1>So slices are generally what you'd use.

101
00:04:46.360 --> 00:04:48.920
<v Speaker 2>Day to day most of the time. Yeah, they're the workhorse.

102
00:04:49.120 --> 00:04:52.360
<v Speaker 1>Then there are maps key value stores. What's special about

103
00:04:52.360 --> 00:04:52.720
<v Speaker 1>them in Go?

104
00:04:52.920 --> 00:04:55.480
<v Speaker 2>Well, they're powerful because the keys don't have to be integers.

105
00:04:55.600 --> 00:04:59.680
<v Speaker 2>They can be any comparable type, strings, numbers, strucks if

106
00:04:59.680 --> 00:05:01.639
<v Speaker 2>they're ca very flexible indexing.

107
00:05:01.879 --> 00:05:04.800
<v Speaker 1>Okay, but here's something from the notes that seems odd.

108
00:05:05.800 --> 00:05:10.519
<v Speaker 1>Go is about predictability, but map iteration order is randomized.

109
00:05:10.759 --> 00:05:14.480
<v Speaker 2>Ah. Yes, that often surprises people. It's deliberate, though.

110
00:05:14.240 --> 00:05:15.839
<v Speaker 1>Why would they force randomness?

111
00:05:16.079 --> 00:05:19.399
<v Speaker 2>It gets right to the core philosophy. The Go designers

112
00:05:19.480 --> 00:05:23.800
<v Speaker 2>did that specifically to stop developers from accidentally relying on

113
00:05:23.839 --> 00:05:26.199
<v Speaker 2>whatever internal ordering the map happened.

114
00:05:25.920 --> 00:05:28.240
<v Speaker 1>To have at the time, because that internal order could

115
00:05:28.360 --> 00:05:31.439
<v Speaker 1>change between GO versions or even between runs.

116
00:05:31.600 --> 00:05:36.279
<v Speaker 2>Exactly. It's fragile and implementation detail you shouldn't depend on.

117
00:05:36.680 --> 00:05:39.800
<v Speaker 2>By randomizing it, Go forces you if you need a

118
00:05:39.839 --> 00:05:43.240
<v Speaker 2>specific order, you must get the keys, sort them explicitly,

119
00:05:43.399 --> 00:05:43.759
<v Speaker 2>and then.

120
00:05:43.720 --> 00:05:47.120
<v Speaker 1>Iterate right correct code. Don't rely on side effects precisely.

121
00:05:47.279 --> 00:05:48.560
<v Speaker 2>It makes your code more robust.

122
00:05:48.680 --> 00:05:51.360
<v Speaker 1>Okay, that makes a weird kind of sense now, and

123
00:05:51.480 --> 00:05:54.199
<v Speaker 1>a quick warning from the source. Don't try to write

124
00:05:54.199 --> 00:05:55.680
<v Speaker 1>to a map that's mil right.

125
00:05:55.720 --> 00:05:58.240
<v Speaker 2>A nil map is basically an uninitialized map. If you

126
00:05:58.279 --> 00:06:01.600
<v Speaker 2>try to put data into it, your program will panic crash.

127
00:06:01.720 --> 00:06:04.079
<v Speaker 1>You have to initialize it first, usually using make.

128
00:06:04.040 --> 00:06:06.639
<v Speaker 2>Yep, my map, make map. Then you're good to go.

129
00:06:06.680 --> 00:06:10.079
<v Speaker 1>All right, let's get to the main event. For many people, concurrency.

130
00:06:11.360 --> 00:06:13.519
<v Speaker 1>This is where Go really shines, isn't it.

131
00:06:13.519 --> 00:06:16.279
<v Speaker 2>It really is. It's baked into the language design with

132
00:06:16.399 --> 00:06:20.160
<v Speaker 2>two core concepts, gord utines and channel groutines.

133
00:06:20.160 --> 00:06:20.639
<v Speaker 1>What are they?

134
00:06:20.680 --> 00:06:24.519
<v Speaker 2>Fundamentally think of them as incredibly lightweight threads. They're the

135
00:06:24.560 --> 00:06:27.920
<v Speaker 2>smallest unit of work that can run concurrently, often just

136
00:06:27.959 --> 00:06:30.199
<v Speaker 2>a few kilobytes of memory stacked to start.

137
00:06:30.319 --> 00:06:32.959
<v Speaker 1>Super cheap compared to traditional OS threats.

138
00:06:33.000 --> 00:06:35.759
<v Speaker 2>Massively cheaper, and you launch one really easily. Just put

139
00:06:35.759 --> 00:06:38.160
<v Speaker 2>the go keyword before a function, call go my function.

140
00:06:38.439 --> 00:06:41.199
<v Speaker 1>That's it, and the function runs concurrently.

141
00:06:41.319 --> 00:06:45.240
<v Speaker 2>Yep. And interestingly, your main function the entry point of

142
00:06:45.279 --> 00:06:48.480
<v Speaker 2>your program is itself running as a gore routine.

143
00:06:48.680 --> 00:06:51.399
<v Speaker 1>Okay, so you can have potentially thousands of these running.

144
00:06:52.120 --> 00:06:54.759
<v Speaker 1>How do they talk to each other safely? That's where

145
00:06:54.800 --> 00:06:56.079
<v Speaker 1>channels come in exactly.

146
00:06:56.519 --> 00:07:00.600
<v Speaker 2>Channels are the preferred way for goroutines to communicate and synchronize.

147
00:07:01.319 --> 00:07:03.959
<v Speaker 2>They provide a typed conduit through which you can send

148
00:07:04.040 --> 00:07:05.240
<v Speaker 2>and receive values.

149
00:07:05.439 --> 00:07:08.800
<v Speaker 1>So instead of multiple groteins all trying to access and

150
00:07:08.839 --> 00:07:11.120
<v Speaker 1>modify the same variable directly.

151
00:07:10.800 --> 00:07:13.639
<v Speaker 2>Which leads to race conditions and complexity.

152
00:07:13.079 --> 00:07:15.079
<v Speaker 1>The past data between them through a channel.

153
00:07:15.240 --> 00:07:18.720
<v Speaker 2>Right, the go proverb is, don't communicate by sharing memory,

154
00:07:18.920 --> 00:07:21.959
<v Speaker 2>share memory by communicating. Channels facilitate that.

155
00:07:22.279 --> 00:07:24.920
<v Speaker 1>But there's a catch, isn't there? Since Maine is also

156
00:07:25.000 --> 00:07:25.560
<v Speaker 1>a guarantee.

157
00:07:25.879 --> 00:07:30.279
<v Speaker 2>Ah? Yes, the synchronization challenge. If your main function finishes and.

158
00:07:30.279 --> 00:07:32.240
<v Speaker 1>Exits, the whole program stops.

159
00:07:32.319 --> 00:07:35.160
<v Speaker 2>Correct. It doesn't matter if you have hundreds of other

160
00:07:35.240 --> 00:07:39.360
<v Speaker 2>gurroutines still doing important work in the background. If main returns,

161
00:07:39.439 --> 00:07:40.639
<v Speaker 2>they all just terminate.

162
00:07:41.040 --> 00:07:42.560
<v Speaker 1>So you need a way to make main weight.

163
00:07:42.920 --> 00:07:45.959
<v Speaker 2>You do, and the source material is very clear. Using

164
00:07:46.000 --> 00:07:50.519
<v Speaker 2>something like time sleep in Maine just to weight is

165
00:07:50.560 --> 00:07:52.120
<v Speaker 2>a bad hack. Don't do it.

166
00:07:52.360 --> 00:07:53.040
<v Speaker 1>That's the right way.

167
00:07:53.240 --> 00:07:56.959
<v Speaker 2>Proper synchronization tools. The sink package has things like weight group,

168
00:07:57.160 --> 00:07:59.959
<v Speaker 2>which lets main weight until a specific number of guroutines

169
00:08:00.120 --> 00:08:03.519
<v Speaker 2>have signaled they're done. Or for more complex scenarios, you'd

170
00:08:03.600 --> 00:08:06.319
<v Speaker 2>use the built in context package to manage the life cycle,

171
00:08:06.680 --> 00:08:10.720
<v Speaker 2>deadlines and cancelations of your grouteines properly. That's the robust

172
00:08:10.720 --> 00:08:11.639
<v Speaker 2>approach makes sense.

173
00:08:12.040 --> 00:08:15.680
<v Speaker 1>Let's shift gear slightly to IO input output. The notes

174
00:08:15.680 --> 00:08:19.720
<v Speaker 1>talk about ioreader and io writer. Why are these so important?

175
00:08:20.079 --> 00:08:25.439
<v Speaker 2>They're fundamental interfaces, hugely important. Ioreader defines the basic behavior

176
00:08:25.439 --> 00:08:28.360
<v Speaker 2>for reading a sequence of bytes. An io writer defines

177
00:08:28.399 --> 00:08:29.600
<v Speaker 2>writing a sequence of bytes.

178
00:08:29.720 --> 00:08:32.960
<v Speaker 1>Okay, simple enough, but why is that architecturally significant?

179
00:08:33.200 --> 00:08:37.159
<v Speaker 2>Because so many things in Go implement these interfaces, files,

180
00:08:37.240 --> 00:08:42.279
<v Speaker 2>network connections in memory, buffers, zip archives, encryption streams, ah.

181
00:08:42.320 --> 00:08:44.600
<v Speaker 1>So you can treat them all uniformly exactly.

182
00:08:44.799 --> 00:08:48.679
<v Speaker 2>It enables incredible composability. You can write a function that

183
00:08:48.720 --> 00:08:51.639
<v Speaker 2>takes any ioreader and it can read from a file

184
00:08:52.039 --> 00:08:56.080
<v Speaker 2>or a network socket or standard input without needing to change.

185
00:08:56.240 --> 00:08:59.279
<v Speaker 1>You could like chain them together, read from network, pass

186
00:08:59.320 --> 00:09:00.559
<v Speaker 1>through an encryptor write to.

187
00:09:00.519 --> 00:09:03.360
<v Speaker 2>A file precisely. If your encrypto takes a reader and

188
00:09:03.399 --> 00:09:05.919
<v Speaker 2>returns a reader, and your file writer takes a reader.

189
00:09:05.919 --> 00:09:08.320
<v Speaker 2>You just plug them together. Everything is treated as a

190
00:09:08.320 --> 00:09:12.600
<v Speaker 2>stream of bytes, massive flexibility from building systems.

191
00:09:12.440 --> 00:09:16.240
<v Speaker 1>And GO uses byte slices bite for this low level io.

192
00:09:16.519 --> 00:09:20.279
<v Speaker 2>Yes, because bytes are the universal currency of computing systems.

193
00:09:20.360 --> 00:09:20.559
<v Speaker 1>Right.

194
00:09:21.000 --> 00:09:23.639
<v Speaker 2>Using myte slices gives you very precise control over how

195
00:09:23.720 --> 00:09:25.360
<v Speaker 2>much data you're reading or writing.

196
00:09:25.120 --> 00:09:28.039
<v Speaker 1>Which is critical for network protocols or fixed format files.

197
00:09:28.120 --> 00:09:30.360
<v Speaker 2>Absolutely, you need that little level control.

198
00:09:30.559 --> 00:09:33.519
<v Speaker 1>Okay. And finally for this section, system utilities often need

199
00:09:33.559 --> 00:09:36.000
<v Speaker 1>command line arguments. How does GO handle those?

200
00:09:36.279 --> 00:09:39.679
<v Speaker 2>It's straightforward. They're available in a slice of strings called

201
00:09:40.080 --> 00:09:40.960
<v Speaker 2>dot rgs.

202
00:09:40.879 --> 00:09:42.519
<v Speaker 1>OS for the operating system package.

203
00:09:42.679 --> 00:09:45.080
<v Speaker 2>Right, and the key detail to remember is OS dot

204
00:09:45.159 --> 00:09:47.919
<v Speaker 2>org zero, the very first element in that slice.

205
00:09:47.960 --> 00:09:48.600
<v Speaker 1>What is it?

206
00:09:48.320 --> 00:09:51.559
<v Speaker 2>It's always the path to the executable file itself. The

207
00:09:51.600 --> 00:09:55.080
<v Speaker 2>actual arguments you type start from dot Org's one.

208
00:09:55.200 --> 00:09:58.879
<v Speaker 1>Good to know, so OS dot rs is never completely empty.

209
00:09:58.639 --> 00:10:00.720
<v Speaker 2>Correct, It always has at least that one element.

210
00:10:01.039 --> 00:10:04.159
<v Speaker 1>Okay, let's look at some more modern development patterns. Web

211
00:10:04.200 --> 00:10:08.960
<v Speaker 1>services often deal with Jason, sometimes messy Jason, where you

212
00:10:09.000 --> 00:10:11.080
<v Speaker 1>don't know the exact structure upfront. Ah.

213
00:10:11.159 --> 00:10:13.759
<v Speaker 2>Yes, the dreaded arbitrary Jason.

214
00:10:13.919 --> 00:10:17.519
<v Speaker 1>How does GO handle that gracefully? The notes mentioned map

215
00:10:17.519 --> 00:10:18.320
<v Speaker 1>string interface.

216
00:10:18.480 --> 00:10:20.679
<v Speaker 2>That's the go to structure. It's a map where the

217
00:10:20.720 --> 00:10:23.799
<v Speaker 2>keys are strings common for Jason objects, but the values

218
00:10:23.799 --> 00:10:24.960
<v Speaker 2>are interface.

219
00:10:25.080 --> 00:10:26.919
<v Speaker 1>The empty interface. What does that mean again?

220
00:10:27.000 --> 00:10:29.639
<v Speaker 2>It goes way of saying, this value could be anything

221
00:10:29.840 --> 00:10:33.600
<v Speaker 2>a string, a number, integer or float, a boolean, even

222
00:10:33.639 --> 00:10:35.240
<v Speaker 2>another nested map or slice.

223
00:10:35.320 --> 00:10:38.279
<v Speaker 1>So you can unmarshal almost any valid Jason into.

224
00:10:38.080 --> 00:10:41.639
<v Speaker 2>It pretty much. And the crucial benefit, which the source

225
00:10:41.679 --> 00:10:45.679
<v Speaker 2>points out, is that you don't lose type information immediately.

226
00:10:46.000 --> 00:10:48.039
<v Speaker 2>What do you mean, Well, if the Jason had a

227
00:10:48.120 --> 00:10:51.200
<v Speaker 2>number one twenty three, it stays a number type within

228
00:10:51.240 --> 00:10:54.559
<v Speaker 2>the interface value. If it had true, it stays a booleon.

229
00:10:55.159 --> 00:10:57.440
<v Speaker 2>You don't just convert everything to strings, which would lose

230
00:10:57.480 --> 00:10:59.399
<v Speaker 2>that original structure and type, and you.

231
00:10:59.360 --> 00:11:02.639
<v Speaker 1>Could figure out the actual type later using type assertions

232
00:11:02.679 --> 00:11:03.840
<v Speaker 1>or switches exactly.

233
00:11:03.960 --> 00:11:07.120
<v Speaker 2>It preserves the data fidelity, which is really important when

234
00:11:07.159 --> 00:11:09.039
<v Speaker 2>you're processing unknown structures.

235
00:11:09.399 --> 00:11:13.120
<v Speaker 1>Very useful for web APIs now Go evolved. For a

236
00:11:13.159 --> 00:11:16.279
<v Speaker 1>long time, interfaces and reflection were the main tools for

237
00:11:16.360 --> 00:11:19.639
<v Speaker 1>handling different types flexibly, but now we have generics.

238
00:11:19.759 --> 00:11:22.559
<v Speaker 2>Yes, generics landed properly and go one point one eight.

239
00:11:22.559 --> 00:11:23.840
<v Speaker 2>It was a big addition.

240
00:11:24.000 --> 00:11:25.799
<v Speaker 1>What's the core idea? How do they help?

241
00:11:26.200 --> 00:11:28.600
<v Speaker 2>Generics let you write functions and data structures that can

242
00:11:28.639 --> 00:11:31.320
<v Speaker 2>operate on a range of types you specify without you

243
00:11:31.399 --> 00:11:33.679
<v Speaker 2>having to write separate code for each type.

244
00:11:33.559 --> 00:11:36.679
<v Speaker 1>So less repetitive code, a lot less potentially.

245
00:11:37.480 --> 00:11:40.159
<v Speaker 2>The source material suggests that if you compare doing something

246
00:11:40.200 --> 00:11:43.480
<v Speaker 2>with interfaces versus doing it with generics, the generic version

247
00:11:43.559 --> 00:11:45.720
<v Speaker 2>is often simpler and shorter.

248
00:11:45.559 --> 00:11:49.639
<v Speaker 1>Code, especially for common tasks like working with slices or

249
00:11:49.639 --> 00:11:51.000
<v Speaker 1>maps of different custom types.

250
00:11:51.120 --> 00:11:53.240
<v Speaker 2>Right, think of writing a function that works on a

251
00:11:53.240 --> 00:11:56.279
<v Speaker 2>slice of integers, or a slice of floats or a

252
00:11:56.320 --> 00:11:59.240
<v Speaker 2>slice of your custom order type. Generics make that much

253
00:11:59.279 --> 00:12:02.200
<v Speaker 2>cleaner than faces and reflection typically would.

254
00:12:02.519 --> 00:12:06.159
<v Speaker 1>Cool and Go plays nicely with modern observability practices too.

255
00:12:06.360 --> 00:12:09.679
<v Speaker 2>Monitoring systems, Oh yeah, it's quite common. You can easily

256
00:12:09.679 --> 00:12:12.120
<v Speaker 2>build a small web server right into your GO application

257
00:12:12.279 --> 00:12:15.240
<v Speaker 2>using the standard FTTP package.

258
00:12:14.879 --> 00:12:16.919
<v Speaker 1>And use that to expose metrics exactly.

259
00:12:17.000 --> 00:12:20.480
<v Speaker 2>You can expose things like how many groutines are currently active,

260
00:12:20.799 --> 00:12:24.360
<v Speaker 2>how much memory is the process. Using custom application.

261
00:12:24.000 --> 00:12:27.679
<v Speaker 1>Counters and tools like Prometheus can scrape.

262
00:12:27.279 --> 00:12:30.399
<v Speaker 2>That data yep, Prometheus scraping is a very common pattern.

263
00:12:30.679 --> 00:12:33.440
<v Speaker 2>Then you can visualize it all in something like Rafana.

264
00:12:33.480 --> 00:12:37.519
<v Speaker 2>It integrates really well into that whole cloud native monitoring ecosystem.

265
00:12:37.759 --> 00:12:42.480
<v Speaker 1>Nice. Lastly, documentation Go has a specific way of doing it.

266
00:12:42.480 --> 00:12:46.039
<v Speaker 2>It's very simple, very effective. The rule highlighted in the

267
00:12:46.080 --> 00:12:51.240
<v Speaker 2>notes is strict a comment written immediately before a function, type, method,

268
00:12:51.360 --> 00:12:53.919
<v Speaker 2>or variable definition with no blank line in.

269
00:12:53.879 --> 00:12:57.639
<v Speaker 1>Between that comment. Because it's official documentation.

270
00:12:57.200 --> 00:13:00.759
<v Speaker 2>Correct the godoc tool picks it up automatically. Simple rule

271
00:13:01.000 --> 00:13:02.759
<v Speaker 2>makes documentation consistent.

272
00:13:02.919 --> 00:13:04.559
<v Speaker 1>And there's something about example code too.

273
00:13:04.720 --> 00:13:08.039
<v Speaker 2>Yeah, that's neat. You can write functions that start with

274
00:13:08.200 --> 00:13:11.440
<v Speaker 2>the word example, like example dotatoy. If you put a

275
00:13:11.480 --> 00:13:14.919
<v Speaker 2>special comment output at the end of that function, uh huh,

276
00:13:15.159 --> 00:13:17.960
<v Speaker 2>the Go test tool will actually run that example function

277
00:13:18.200 --> 00:13:20.879
<v Speaker 2>and check if it's printed output matches what's in your comment.

278
00:13:21.039 --> 00:13:23.000
<v Speaker 1>So your examples are also runnable.

279
00:13:22.639 --> 00:13:26.720
<v Speaker 2>Tests exactly, keeps the documentation accurate, and serves as a

280
00:13:26.759 --> 00:13:30.039
<v Speaker 2>basic test case. Very pragmatic hashtag tag outro.

281
00:13:30.200 --> 00:13:32.720
<v Speaker 1>Okay, so we've covered a lot of ground. The core

282
00:13:32.799 --> 00:13:36.440
<v Speaker 1>Go philosophy seems to be strict rules, clear.

283
00:13:36.159 --> 00:13:38.360
<v Speaker 2>Syntax, leading to predictability.

284
00:13:38.440 --> 00:13:42.600
<v Speaker 1>Powerful but well defined concurrency with gororitines and channels, milk

285
00:13:42.679 --> 00:13:46.799
<v Speaker 1>for scale, those really flexible io interfaces, reader and writer supercomposable,

286
00:13:47.120 --> 00:13:50.200
<v Speaker 1>and then modern features like handling arbitrary data with interface

287
00:13:50.240 --> 00:13:51.120
<v Speaker 1>and the addition.

288
00:13:50.799 --> 00:13:52.960
<v Speaker 2>Of generics, right covering the whole life cycle.

289
00:13:53.080 --> 00:13:55.840
<v Speaker 1>The recurring theme, as the source points out, is that

290
00:13:55.960 --> 00:13:58.240
<v Speaker 1>go is often called boring.

291
00:13:58.879 --> 00:14:03.039
<v Speaker 2>Which sounds negative, but in systems programming it's actually a compliment.

292
00:14:03.120 --> 00:14:05.440
<v Speaker 1>Right, predictable, reliable.

293
00:14:05.360 --> 00:14:09.480
<v Speaker 2>Understandable, exactly boring is good when you need systems that

294
00:14:09.600 --> 00:14:12.279
<v Speaker 2>don't fall over unexpectedly in the middle of the night.

295
00:14:12.639 --> 00:14:15.080
<v Speaker 2>That predictability is a massive virtue.

296
00:14:15.320 --> 00:14:18.840
<v Speaker 1>So what's the final takeaway for you? The listener writing code?

297
00:14:19.279 --> 00:14:21.320
<v Speaker 1>It seems to echo that classic advice.

298
00:14:21.519 --> 00:14:24.919
<v Speaker 2>Yeah, the material references wisdom often attributed to Joe Armstrong,

299
00:14:24.960 --> 00:14:28.919
<v Speaker 2>though it's a common sentiment, focus on correctness. First, write

300
00:14:28.919 --> 00:14:30.360
<v Speaker 2>code that is bug free.

301
00:14:30.440 --> 00:14:33.080
<v Speaker 1>May it work reliably, then make it fast enough.

302
00:14:33.399 --> 00:14:36.799
<v Speaker 2>Worrying about micro optimizing every last nanosecond too early is

303
00:14:36.840 --> 00:14:41.200
<v Speaker 2>often counterproductive. Premature optimization the root of all evil, as

304
00:14:41.320 --> 00:14:44.759
<v Speaker 2>Nuth famously put it, though maybe slightly misquoted. Sometimes right,

305
00:14:45.200 --> 00:14:47.879
<v Speaker 2>get it right, then make it fast if needed, Goh's

306
00:14:47.879 --> 00:14:49.159
<v Speaker 2>design helps you get it right.

307
00:14:49.360 --> 00:14:51.399
<v Speaker 1>Okay, so here's the final thought to leave you with

308
00:14:51.919 --> 00:14:55.960
<v Speaker 1>something to chew on. Go's simplicity was fundamental in enabling

309
00:14:56.080 --> 00:14:59.720
<v Speaker 1>huge complex systems like Kubernetes and Docker to even be

310
00:14:59.720 --> 00:15:00.720
<v Speaker 1>built manageably.

311
00:15:00.840 --> 00:15:02.600
<v Speaker 2>It teamed a certain level of complexity.

312
00:15:03.200 --> 00:15:07.519
<v Speaker 1>So, thinking ahead, what's the next layer of complexity in

313
00:15:07.559 --> 00:15:12.000
<v Speaker 1>software development that goes continued focus on discipline? Simplicity might

314
00:15:12.039 --> 00:15:16.279
<v Speaker 1>help us tackle what will it make boring and predictable next?

315
00:15:16.480 --> 00:15:19.519
<v Speaker 2>Hmmm, that's a really interesting question for the future.

316
00:15:19.919 --> 00:15:22.480
<v Speaker 1>Definitely something to ponder. That wraps up this deep dive.

317
00:15:22.600 --> 00:15:23.440
<v Speaker 1>Thanks for joining us

318
00:15:23.480 --> 00:15:24.159
<v Speaker 2>See you next time.