WEBVTT

1
00:00:00.120 --> 00:00:02.839
<v Speaker 1>Imagine for a second, right that you are just relaxing

2
00:00:02.960 --> 00:00:05.040
<v Speaker 1>on a gorgeous, sun drenched beach.

3
00:00:05.240 --> 00:00:06.559
<v Speaker 2>Oh I'm already there, right.

4
00:00:07.200 --> 00:00:10.080
<v Speaker 1>You have a cold drink in your hand, the waves

5
00:00:10.119 --> 00:00:12.640
<v Speaker 1>are gently crashing, and you don't have a single care

6
00:00:12.679 --> 00:00:13.240
<v Speaker 1>in the world.

7
00:00:13.480 --> 00:00:16.079
<v Speaker 2>Sounds perfect. Why am I so relaxed?

8
00:00:16.160 --> 00:00:18.559
<v Speaker 1>Exactly because back in the real world, you have a

9
00:00:18.600 --> 00:00:24.320
<v Speaker 1>digital double Oh wow. Yeah, like a tireless, invisible assistant

10
00:00:24.640 --> 00:00:28.000
<v Speaker 1>who is currently handling all of your mundane daily tasks.

11
00:00:28.480 --> 00:00:32.039
<v Speaker 1>It's checking your schedules, filtering your messages, and basically doing

12
00:00:32.039 --> 00:00:34.280
<v Speaker 1>all the heavy lifting of your life while you just

13
00:00:34.320 --> 00:00:35.840
<v Speaker 1>sit back and listen to the ocean.

14
00:00:36.039 --> 00:00:37.679
<v Speaker 2>I mean that sounds like pure science fiction.

15
00:00:37.759 --> 00:00:40.679
<v Speaker 1>Honestly, he surely does, right, But today we're going to

16
00:00:40.759 --> 00:00:44.000
<v Speaker 1>show you exactly how close that reality actually is. Welcome

17
00:00:44.000 --> 00:00:44.759
<v Speaker 1>to the deep dive.

18
00:00:45.119 --> 00:00:46.240
<v Speaker 2>Glad to be here for this one.

19
00:00:46.359 --> 00:00:49.600
<v Speaker 1>Yeah, Today we are opening up a really fascinating piece

20
00:00:49.640 --> 00:00:53.200
<v Speaker 1>of source material. It's a book called Building Telegram Bots

21
00:00:53.679 --> 00:00:59.280
<v Speaker 1>Develop Bots in twelve programming languages by Nicholas Maudzik. And well,

22
00:00:59.359 --> 00:01:01.320
<v Speaker 1>we are going to expor how you can build these

23
00:01:01.399 --> 00:01:02.719
<v Speaker 1>digital assistance yourself.

24
00:01:03.079 --> 00:01:06.280
<v Speaker 2>Yeah, And what stands out immediately about mad ROC's approach.

25
00:01:06.319 --> 00:01:09.319
<v Speaker 2>And I love this is that he didn't write this

26
00:01:10.159 --> 00:01:14.280
<v Speaker 2>to show off like abstract theoretical coding.

27
00:01:13.959 --> 00:01:16.280
<v Speaker 1>Tricks, right, it's not a text put exactly.

28
00:01:16.680 --> 00:01:20.920
<v Speaker 2>He built these bots to solve highly relatable everyday problems

29
00:01:20.920 --> 00:01:23.159
<v Speaker 2>he was actually facing while living in Tokyo.

30
00:01:23.280 --> 00:01:26.319
<v Speaker 1>The examples are incredibly grounded. I mean, anyone who has

31
00:01:26.359 --> 00:01:29.480
<v Speaker 1>lived in a massive metropolis knows the absolute panic of

32
00:01:29.959 --> 00:01:31.879
<v Speaker 1>like missing the last train home.

33
00:01:32.000 --> 00:01:35.359
<v Speaker 2>Oh yeah, and having to pay for a ridiculously expensive taxi.

34
00:01:35.439 --> 00:01:37.920
<v Speaker 1>It's the worst. So instead of constantly checking an app,

35
00:01:37.959 --> 00:01:40.560
<v Speaker 1>he just wrote a bot that automatically tracks the last

36
00:01:40.560 --> 00:01:44.400
<v Speaker 1>train schedules and drops his optimal transit options right into a.

37
00:01:44.400 --> 00:01:46.840
<v Speaker 2>Chat window, which is brilliant. Yeah.

38
00:01:47.159 --> 00:01:49.879
<v Speaker 1>He also built an IoT webcam bot that snaps a

39
00:01:49.920 --> 00:01:52.239
<v Speaker 1>picture and sends it to his phone whenever someone rings

40
00:01:52.239 --> 00:01:55.439
<v Speaker 1>his doorbell. And oh, my favorite party bot, ah, the

41
00:01:55.480 --> 00:01:58.000
<v Speaker 1>party bot. Yeah, it uses a mini projector to display

42
00:01:58.079 --> 00:02:00.640
<v Speaker 1>random incoming chat messages onto his life living room wall

43
00:02:00.719 --> 00:02:01.640
<v Speaker 1>during get togethers.

44
00:02:01.840 --> 00:02:04.840
<v Speaker 2>It's so cool because it illustrates a fundamental shift in

45
00:02:04.920 --> 00:02:08.319
<v Speaker 2>how we should view automation. You know how so well,

46
00:02:08.400 --> 00:02:11.639
<v Speaker 2>a bot isn't just a corporate customer service gimmick anymore.

47
00:02:12.199 --> 00:02:16.719
<v Speaker 2>It is a highly customizable personal tool to reduce friction

48
00:02:16.800 --> 00:02:17.639
<v Speaker 2>in your daily life.

49
00:02:17.719 --> 00:02:18.039
<v Speaker 1>Right.

50
00:02:18.520 --> 00:02:20.800
<v Speaker 2>But the structure of this text is what makes it

51
00:02:20.840 --> 00:02:24.159
<v Speaker 2>a masterclass. He doesn't just teach you how to build

52
00:02:24.159 --> 00:02:27.199
<v Speaker 2>a bot. He teaches you how to build the exact

53
00:02:27.319 --> 00:02:31.199
<v Speaker 2>same bot using twelve different programming languages.

54
00:02:31.039 --> 00:02:34.560
<v Speaker 1>Which naturally brings up the big question, right, and really

55
00:02:34.639 --> 00:02:37.360
<v Speaker 1>the entire mission of our deep dive today for you,

56
00:02:38.240 --> 00:02:40.360
<v Speaker 1>Why in the world would you solve the exact same

57
00:02:40.439 --> 00:02:43.400
<v Speaker 1>problem in twelve different programming languages when you could just

58
00:02:43.560 --> 00:02:45.159
<v Speaker 1>learn one and stick to it.

59
00:02:45.319 --> 00:02:46.919
<v Speaker 2>Yeah, sounds like a lot of extra work.

60
00:02:47.280 --> 00:02:49.199
<v Speaker 1>It does. The best way I can think to describe

61
00:02:49.240 --> 00:02:52.800
<v Speaker 1>it is like cooking. Imagine cooking your absolute favorite go

62
00:02:52.840 --> 00:02:55.039
<v Speaker 1>to recipe. Okay, I'm with you, but instead of just

63
00:02:55.080 --> 00:02:57.439
<v Speaker 1>making it in your own familiar kitchen, you cook it

64
00:02:57.479 --> 00:03:00.560
<v Speaker 1>in a massive commercial restaurant, pitchin when you cook it

65
00:03:00.719 --> 00:03:03.960
<v Speaker 1>over a campfire in the woods, and then I don't know,

66
00:03:04.039 --> 00:03:06.000
<v Speaker 1>you cook it in a tiny, high tech kitchen on

67
00:03:06.000 --> 00:03:09.120
<v Speaker 1>a submarine. That is a great analogy, right, You're making

68
00:03:09.159 --> 00:03:12.400
<v Speaker 1>the exact same food, but the process teaches you just

69
00:03:12.400 --> 00:03:15.159
<v Speaker 1>as much about the constraints the tooling and the environment

70
00:03:15.520 --> 00:03:17.039
<v Speaker 1>as it does about the meal.

71
00:03:16.840 --> 00:03:21.039
<v Speaker 2>Itself, and that environmental constraint is precisely the point of

72
00:03:21.080 --> 00:03:26.080
<v Speaker 2>the exercise. By holding the output constant the BOD, we

73
00:03:26.199 --> 00:03:29.560
<v Speaker 2>get to clearly see the variables in the languages themselves, right.

74
00:03:29.639 --> 00:03:32.000
<v Speaker 1>It strips away the distraction of what you're building.

75
00:03:32.120 --> 00:03:37.400
<v Speaker 2>Exactly. It is about deeply understanding how different programming languages

76
00:03:37.479 --> 00:03:41.479
<v Speaker 2>approach the very nature of problem solving at a systemic level.

77
00:03:41.639 --> 00:03:43.680
<v Speaker 1>Like how they handle memory yes.

78
00:03:43.479 --> 00:03:45.439
<v Speaker 2>How do they handle memory management? How do they structure

79
00:03:45.479 --> 00:03:51.199
<v Speaker 2>their syntax to prioritize human readability versus raw machine level performance.

80
00:03:51.439 --> 00:03:54.439
<v Speaker 2>When you build the same tool repeatedly, the philosophy of

81
00:03:54.439 --> 00:03:56.039
<v Speaker 2>the language just kind of reveals itself.

82
00:03:56.080 --> 00:03:58.400
<v Speaker 1>Okay, let's unpack this Before we can start touring these

83
00:03:58.439 --> 00:04:02.039
<v Speaker 1>different programming kitchens. We actually need some groceries, or in

84
00:04:02.080 --> 00:04:04.080
<v Speaker 1>this case, we need a bot identity.

85
00:04:04.479 --> 00:04:06.479
<v Speaker 2>You can't code a bot if it doesn't exist yet.

86
00:04:06.800 --> 00:04:09.879
<v Speaker 1>Exactly, we have to start with the absolute foundation of

87
00:04:09.879 --> 00:04:12.479
<v Speaker 1>the telegram platform, and to do that, we are going

88
00:04:12.520 --> 00:04:15.879
<v Speaker 1>to look at one of the most famously readable, user

89
00:04:16.000 --> 00:04:18.439
<v Speaker 1>friendly languages out there. Ruby.

90
00:04:18.639 --> 00:04:22.519
<v Speaker 2>Ruby serves as an excellent gateway because of its design philosophy.

91
00:04:22.839 --> 00:04:25.759
<v Speaker 2>It explicitly prioritizes developer happiness.

92
00:04:25.839 --> 00:04:27.519
<v Speaker 1>Developer happiness, I love that.

93
00:04:27.720 --> 00:04:31.560
<v Speaker 2>Yeah, it reads almost like plain English. Yeah. Architecturally it's

94
00:04:31.600 --> 00:04:34.439
<v Speaker 2>an interpreted scripting language, and that means that means you

95
00:04:34.439 --> 00:04:37.040
<v Speaker 2>don't have to run it through a compiler to translate

96
00:04:37.079 --> 00:04:40.040
<v Speaker 2>it into machine code before executing it. An interpreter simply

97
00:04:40.040 --> 00:04:42.759
<v Speaker 2>reads your code line by line at runtime, which makes

98
00:04:42.800 --> 00:04:45.000
<v Speaker 2>spinning up a prototype incredibly fast.

99
00:04:45.199 --> 00:04:47.279
<v Speaker 1>But before we write a single line of Ruby, we

100
00:04:47.399 --> 00:04:48.319
<v Speaker 1>have to meet the boss.

101
00:04:49.120 --> 00:04:50.560
<v Speaker 2>Ah, yes, the Botfather.

102
00:04:50.839 --> 00:04:53.439
<v Speaker 1>To create a bot on Telegram, you don't just fill

103
00:04:53.439 --> 00:04:55.399
<v Speaker 1>out a web form. You actually have to chat with

104
00:04:55.480 --> 00:04:58.040
<v Speaker 1>a bot. To create a bot, you talk to prafana

105
00:04:58.120 --> 00:05:01.000
<v Speaker 1>Agat bot Father, who is the literal old godfather of

106
00:05:01.120 --> 00:05:02.279
<v Speaker 1>all telegrambots.

107
00:05:02.399 --> 00:05:04.439
<v Speaker 2>The book highlights some hilarious details here too.

108
00:05:04.519 --> 00:05:07.759
<v Speaker 1>Oh my gosh. Yes, Botfather is available twenty four to seven.

109
00:05:07.879 --> 00:05:10.879
<v Speaker 1>Never sleeps, but according to his bio, he quote takes

110
00:05:10.879 --> 00:05:14.040
<v Speaker 1>showers and always looks fresh. I mean, you gotta appreciate

111
00:05:14.040 --> 00:05:16.560
<v Speaker 1>the lore, right his profile picture isn't.

112
00:05:16.720 --> 00:05:16.959
<v Speaker 2>Yeah.

113
00:05:17.040 --> 00:05:19.519
<v Speaker 1>The author makes a great joke about this, actually warning

114
00:05:19.560 --> 00:05:21.800
<v Speaker 1>you not to leave this token hanging around on a

115
00:05:21.800 --> 00:05:26.000
<v Speaker 1>public GitHub repository quote. Especially now that Microsoft.

116
00:05:25.600 --> 00:05:27.680
<v Speaker 2>Owns it, we'll developer humor there.

117
00:05:27.560 --> 00:05:30.360
<v Speaker 1>Right, so you keep it haydden in an environment variable.

118
00:05:31.040 --> 00:05:34.000
<v Speaker 1>Now diving into the Ruby environment, setting this up is

119
00:05:34.000 --> 00:05:37.600
<v Speaker 1>incredibly smooth. You use Ruby's package manager, which is called

120
00:05:37.680 --> 00:05:41.519
<v Speaker 1>JEM to install the telegrambot library yep standard setup, and

121
00:05:41.560 --> 00:05:43.959
<v Speaker 1>you create a simple file like step zero dot rb.

122
00:05:44.560 --> 00:05:47.279
<v Speaker 1>But how does the code actually know when someone sends

123
00:05:47.319 --> 00:05:48.480
<v Speaker 1>a message? Like?

124
00:05:48.560 --> 00:05:53.399
<v Speaker 2>Mechanically, the mechanics rely on what we call a polling loop. Specifically,

125
00:05:53.560 --> 00:05:58.000
<v Speaker 2>the script calls a dot get updates method. Okay, Conceptually,

126
00:05:58.040 --> 00:05:59.639
<v Speaker 2>think of it like a kid in the backseat of

127
00:05:59.639 --> 00:06:02.560
<v Speaker 2>a car constantly asking are we there yet? How about

128
00:06:02.600 --> 00:06:03.519
<v Speaker 2>now are we there yet?

129
00:06:03.600 --> 00:06:04.199
<v Speaker 1>Oh man?

130
00:06:04.360 --> 00:06:07.720
<v Speaker 2>Right? The Ruby script is in a continuous loop, constantly

131
00:06:07.800 --> 00:06:11.360
<v Speaker 2>knocking on Telegram server door asking if any new data.

132
00:06:11.120 --> 00:06:13.920
<v Speaker 1>Has arrived, and when a message finally does arrive, it's

133
00:06:13.920 --> 00:06:17.079
<v Speaker 1>not just the text the user typed. The book shows

134
00:06:17.120 --> 00:06:21.160
<v Speaker 1>how if you use Ruby's toyomal function, which formats data

135
00:06:21.199 --> 00:06:25.079
<v Speaker 1>into a really readable structured list, you can actually see

136
00:06:25.120 --> 00:06:27.279
<v Speaker 1>the full anatomy of a Telegram payload.

137
00:06:27.519 --> 00:06:28.720
<v Speaker 2>It's surprisingly dense.

138
00:06:28.800 --> 00:06:31.360
<v Speaker 1>It's a massive package of data. You get a message

139
00:06:31.839 --> 00:06:35.040
<v Speaker 1>you get the from field detailing the user, the chat

140
00:06:35.160 --> 00:06:38.600
<v Speaker 1>channel info, the exact timestamp, and of course the actual

141
00:06:38.639 --> 00:06:39.399
<v Speaker 1>text itself.

142
00:06:39.480 --> 00:06:42.560
<v Speaker 2>And this is where Ruby's high level abstractions really shine.

143
00:06:43.079 --> 00:06:45.439
<v Speaker 2>To make the bot reply, you don't have to manually

144
00:06:45.439 --> 00:06:48.959
<v Speaker 2>construct some complex httppost requests from scratch.

145
00:06:49.040 --> 00:06:49.759
<v Speaker 1>Thank goodness.

146
00:06:49.920 --> 00:06:53.360
<v Speaker 2>Right, you use string interpolation instead of clunky commands to

147
00:06:53.399 --> 00:06:57.000
<v Speaker 2>concatenate or glue text together. Ruby lets you seamlessly evaluate

148
00:06:57.079 --> 00:07:00.439
<v Speaker 2>variables right inside a string. You just write hello, followed

149
00:07:00.439 --> 00:07:03.240
<v Speaker 2>directly by a hashtag message up from dot first name.

150
00:07:03.120 --> 00:07:06.399
<v Speaker 1>Which instantly grabs that specific piece of data from the payload.

151
00:07:06.439 --> 00:07:10.079
<v Speaker 1>So the bot replies, hello Nico exactly. It completely abstracts

152
00:07:10.120 --> 00:07:12.920
<v Speaker 1>away the complex network requests and the dense data parsing.

153
00:07:13.160 --> 00:07:15.959
<v Speaker 1>You get a fully functioning, responsive bot in under ten

154
00:07:16.079 --> 00:07:16.839
<v Speaker 1>lines of code.

155
00:07:17.040 --> 00:07:17.759
<v Speaker 2>It's beautiful.

156
00:07:17.800 --> 00:07:21.360
<v Speaker 1>But and here's where we hit a wall. Ruby is

157
00:07:21.399 --> 00:07:24.279
<v Speaker 1>brilliant for a personal bot. Well, what happens if your

158
00:07:24.279 --> 00:07:25.160
<v Speaker 1>bot goes viral?

159
00:07:25.360 --> 00:07:26.680
<v Speaker 2>Uh? The scaling problem?

160
00:07:26.800 --> 00:07:30.199
<v Speaker 1>Yeah? If that interpreter is reading code line by line

161
00:07:30.519 --> 00:07:33.040
<v Speaker 1>and suddenly ten thousand people are messaging your bot at

162
00:07:33.040 --> 00:07:36.360
<v Speaker 1>the exact same second, that are we there yet? Polling

163
00:07:36.360 --> 00:07:38.040
<v Speaker 1>loop is going to become a massive bottleneck.

164
00:07:38.319 --> 00:07:42.319
<v Speaker 2>Precisely, the interpreter becomes a huge liability under heavy load.

165
00:07:43.040 --> 00:07:45.720
<v Speaker 2>If you want raw speed and if you want a

166
00:07:45.720 --> 00:07:49.319
<v Speaker 2>standalone executable file that runs directly on the machine's hardware

167
00:07:50.000 --> 00:07:52.920
<v Speaker 2>without needing a Ruby environment installed on the server at all,

168
00:07:53.000 --> 00:07:55.240
<v Speaker 2>which is a hassle it is, so if you want

169
00:07:55.279 --> 00:07:58.639
<v Speaker 2>to avoid that, you have to leave scripting languages behind entirely.

170
00:07:58.720 --> 00:08:02.000
<v Speaker 1>Here's where it gets really interesting. We want the readability

171
00:08:02.000 --> 00:08:04.839
<v Speaker 1>of a script, but we need the heavy duty performance

172
00:08:04.879 --> 00:08:08.439
<v Speaker 1>of a compiled binary, and that architectural shift brings us

173
00:08:08.439 --> 00:08:09.600
<v Speaker 1>to a completely different.

174
00:08:09.360 --> 00:08:13.120
<v Speaker 2>Language, NIM. NIM is a fascinating piece of technology. If

175
00:08:13.120 --> 00:08:15.560
<v Speaker 2>you look at NIM code on a screen, it visually

176
00:08:15.680 --> 00:08:17.360
<v Speaker 2>looks and feels very much like Python.

177
00:08:17.480 --> 00:08:18.319
<v Speaker 1>Oh really yeah.

178
00:08:18.360 --> 00:08:22.519
<v Speaker 2>It uses indentation and really clean readable syntax. But under

179
00:08:22.519 --> 00:08:26.600
<v Speaker 2>the hood, NIM doesn't interpret. It compiles, meaning it translates

180
00:08:26.600 --> 00:08:30.920
<v Speaker 2>your code down into clus plus U or JavaScript and

181
00:08:30.959 --> 00:08:33.399
<v Speaker 2>then uses a C compiler to turn it into a

182
00:08:33.480 --> 00:08:36.279
<v Speaker 2>highly optimized bare metal machine binary.

183
00:08:36.360 --> 00:08:38.480
<v Speaker 1>Okay, I have to play the skeptic for you here though,

184
00:08:38.679 --> 00:08:41.879
<v Speaker 1>because reading the NIM section of the text, the developer

185
00:08:41.960 --> 00:08:45.919
<v Speaker 1>experience felt incredibly jarring after how smooth Ruby.

186
00:08:45.720 --> 00:08:47.840
<v Speaker 2>Was, Well, yeah, that's a different beast.

187
00:08:48.000 --> 00:08:50.320
<v Speaker 1>With NIM, we need the NIM compiler, we need the

188
00:08:50.399 --> 00:08:53.440
<v Speaker 1>Nimble package manager, and we have to install a specific

189
00:08:53.679 --> 00:08:57.600
<v Speaker 1>vs code extension by constantin Zeitzev just to get syntax

190
00:08:57.639 --> 00:09:01.200
<v Speaker 1>highlighting right. And even then I can't just click run.

191
00:09:01.480 --> 00:09:04.759
<v Speaker 1>The author outlines how you have to configure custom tasks.

192
00:09:04.799 --> 00:09:07.840
<v Speaker 1>Do Jason build tasks. You have to use terminal commands

193
00:09:07.840 --> 00:09:09.799
<v Speaker 1>like nimcar to compile and run.

194
00:09:09.879 --> 00:09:11.000
<v Speaker 2>It's definitely more involved.

195
00:09:11.080 --> 00:09:14.440
<v Speaker 1>And to make a simple secure web request to get HUBSAPI,

196
00:09:14.840 --> 00:09:17.360
<v Speaker 1>the code straight up fails unless you manually add a

197
00:09:17.480 --> 00:09:20.759
<v Speaker 1>just dossl flag to the compile command. With Ruby, the

198
00:09:20.759 --> 00:09:23.799
<v Speaker 1>web request just worked. Why take on all this extra friction?

199
00:09:23.960 --> 00:09:25.919
<v Speaker 2>If we connect this to the bigger picture, you have

200
00:09:25.919 --> 00:09:28.759
<v Speaker 2>to understand the fundamental trade off of compiled systems. The

201
00:09:28.799 --> 00:09:31.840
<v Speaker 2>friction you're describing is the literal price of optimization. When

202
00:09:31.840 --> 00:09:36.120
<v Speaker 2>you manually add that digdssl flag, you are making a

203
00:09:36.320 --> 00:09:40.559
<v Speaker 2>conscious architectural decision through a process called dead code elimination.

204
00:09:40.759 --> 00:09:44.960
<v Speaker 2>Dead code elimination, Yes, NIM gives you the ultimate power

205
00:09:45.200 --> 00:09:49.399
<v Speaker 2>to exclude massive libraries you just don't need. If your

206
00:09:49.519 --> 00:09:53.120
<v Speaker 2>specific bot doesn't need to make secure external web requests.

207
00:09:53.600 --> 00:09:57.039
<v Speaker 2>Nim won't include that heavy SSL cryptographic code in your

208
00:09:57.080 --> 00:09:57.879
<v Speaker 2>final binary.

209
00:09:58.000 --> 00:09:58.879
<v Speaker 1>Oh I see.

210
00:09:59.000 --> 00:10:02.240
<v Speaker 2>The result is a final program that is astonishingly tiny

211
00:10:02.440 --> 00:10:05.759
<v Speaker 2>and lightning fast because the processor executes it directly.

212
00:10:05.799 --> 00:10:08.320
<v Speaker 1>So you trade a little upfront convenience for a massive

213
00:10:08.399 --> 00:10:09.679
<v Speaker 1>back end performance boost.

214
00:10:09.840 --> 00:10:10.320
<v Speaker 2>Exactly.

215
00:10:10.519 --> 00:10:13.240
<v Speaker 1>So, when we build the nimbot, we use the telebot library,

216
00:10:13.360 --> 00:10:16.120
<v Speaker 1>but we also have to import something called async dispatch,

217
00:10:16.559 --> 00:10:19.360
<v Speaker 1>and this introduces a completely different paradigm than that Ruby

218
00:10:19.399 --> 00:10:20.759
<v Speaker 1>polling loop we discussed earlier.

219
00:10:20.840 --> 00:10:24.240
<v Speaker 2>Yes, the text introduces the async pragma, which is vital

220
00:10:24.279 --> 00:10:25.120
<v Speaker 2>for concurrency.

221
00:10:25.320 --> 00:10:25.480
<v Speaker 1>Right.

222
00:10:25.679 --> 00:10:28.399
<v Speaker 2>Think about synchronous programming. Like a single barista at a

223
00:10:28.399 --> 00:10:31.360
<v Speaker 2>coffee shop. They take an order, make the coffee, and

224
00:10:31.399 --> 00:10:33.799
<v Speaker 2>hand it over before even making eye contact with the

225
00:10:33.840 --> 00:10:37.360
<v Speaker 2>next customer in line. That sounds infuriating, It is if

226
00:10:37.360 --> 00:10:40.120
<v Speaker 2>the coffee takes five minutes, the line stops moving. That

227
00:10:40.279 --> 00:10:43.399
<v Speaker 2>is a synchronous bottleneck. Right. A synchronous programming is like

228
00:10:43.440 --> 00:10:46.519
<v Speaker 2>a head barista taking an order, handing the ticket to

229
00:10:46.559 --> 00:10:49.519
<v Speaker 2>the espresso machine, and immediately turning to take the next

230
00:10:49.559 --> 00:10:53.519
<v Speaker 2>customer's order while the first coffee is brewing in the background.

231
00:10:53.480 --> 00:10:57.480
<v Speaker 1>But traditionally, writing that asynchronous logic leads to what developers

232
00:10:57.519 --> 00:11:02.000
<v Speaker 1>call callback hell right where the code becomes this deeply nested,

233
00:11:02.120 --> 00:11:06.279
<v Speaker 1>unreadable mess of functions waiting on other functions.

234
00:11:05.879 --> 00:11:09.440
<v Speaker 2>Exactly, and that is where NIM shines. The ACYNC feature

235
00:11:09.480 --> 00:11:11.799
<v Speaker 2>allows you to write asynchronous code as though it were

236
00:11:11.840 --> 00:11:13.759
<v Speaker 2>simple top down synchronous code.

237
00:11:13.840 --> 00:11:14.360
<v Speaker 1>Wow.

238
00:11:14.519 --> 00:11:17.000
<v Speaker 2>Yeah. It yields control back to the event loop without

239
00:11:17.039 --> 00:11:21.960
<v Speaker 2>deeply nesking functions, keeping the logic clean while maintaining massive concurrency.

240
00:11:22.200 --> 00:11:25.200
<v Speaker 1>The author also uses a brilliant security trick in NIM

241
00:11:25.240 --> 00:11:28.480
<v Speaker 1>that you simply can't do in Ruby, going back to

242
00:11:28.519 --> 00:11:31.279
<v Speaker 1>that golden rule of hiding the token. In NIM, he

243
00:11:31.399 --> 00:11:34.720
<v Speaker 1>uses a built in function called slurp secret dot key.

244
00:11:34.799 --> 00:11:36.759
<v Speaker 2>I love the name of that function, slurp.

245
00:11:37.080 --> 00:11:42.159
<v Speaker 1>It's great mechanically. What this does is reach out, grab

246
00:11:42.200 --> 00:11:44.639
<v Speaker 1>the token from a local hidden text file on your

247
00:11:44.679 --> 00:11:48.440
<v Speaker 1>hard drive, and bake it directly into the binary during

248
00:11:48.480 --> 00:11:49.480
<v Speaker 1>the compilation step.

249
00:11:49.639 --> 00:11:53.480
<v Speaker 2>It's an elegant demonstration of compiler power. Because NIM compiles

250
00:11:53.519 --> 00:11:56.519
<v Speaker 2>down to machine code. That token gets embedded into a

251
00:11:56.559 --> 00:11:58.000
<v Speaker 2>binary format.

252
00:11:57.840 --> 00:12:00.399
<v Speaker 1>So it's not just sitting in plaintex. No.

253
00:12:00.759 --> 00:12:03.159
<v Speaker 2>A malicious actor can't just open a text file and

254
00:12:03.200 --> 00:12:05.519
<v Speaker 2>read it on your server. They would have to reverse

255
00:12:05.559 --> 00:12:08.960
<v Speaker 2>engineer and decompile a machine binary to extract that string,

256
00:12:09.279 --> 00:12:11.840
<v Speaker 2>which raises the security barrier exponentially.

257
00:12:12.000 --> 00:12:14.200
<v Speaker 1>And the bot we build a NIM is super fun.

258
00:12:14.279 --> 00:12:17.120
<v Speaker 1>It's a Cats and Dogs blot classic. The compiled code

259
00:12:17.120 --> 00:12:19.240
<v Speaker 1>listens to the chat and if a user types the

260
00:12:19.240 --> 00:12:22.000
<v Speaker 1>word cat or dog, it triggers a new photo function.

261
00:12:22.519 --> 00:12:25.399
<v Speaker 1>It pulls a local image file, attaches a custom caption,

262
00:12:25.679 --> 00:12:28.200
<v Speaker 1>and fires it back to the user. It proves that

263
00:12:28.240 --> 00:12:31.320
<v Speaker 1>even though NIM compiles down to raw c it handles

264
00:12:31.399 --> 00:12:33.600
<v Speaker 1>media and chat interactions effortlessly.

265
00:12:33.879 --> 00:12:37.200
<v Speaker 2>It does, but it also highlights the eternal programmers dilemma.

266
00:12:37.519 --> 00:12:41.360
<v Speaker 2>You love the fast write elegant syntax of Ruby, but

267
00:12:41.440 --> 00:12:44.960
<v Speaker 2>you also want the raw, compiled speed and type safety

268
00:12:45.000 --> 00:12:49.039
<v Speaker 2>of NIM. The friction of compilation versus the joy of scripting.

269
00:12:49.919 --> 00:12:52.919
<v Speaker 2>It's natural to ask if a language exists that bridges

270
00:12:52.960 --> 00:12:53.799
<v Speaker 2>that gap.

271
00:12:53.720 --> 00:12:56.360
<v Speaker 1>Which brings us to a language that genuinely feels like

272
00:12:56.399 --> 00:12:57.600
<v Speaker 1>the best of both worlds.

273
00:12:57.960 --> 00:13:02.440
<v Speaker 2>Crystal Crystal is fascinating because it was explicitly heavily influenced

274
00:13:02.440 --> 00:13:02.919
<v Speaker 2>by Ruby.

275
00:13:03.000 --> 00:13:04.960
<v Speaker 1>Yeah, if you glance at a Crystal file, you would

276
00:13:04.960 --> 00:13:06.960
<v Speaker 1>swear you're looking at Ruby code.

277
00:13:06.679 --> 00:13:10.159
<v Speaker 2>But just like NIM, it compiles directly. To see the

278
00:13:10.159 --> 00:13:12.759
<v Speaker 2>author provides a benchmark to prove this speed. Actually, he

279
00:13:12.840 --> 00:13:15.559
<v Speaker 2>runs a script to calculate the Fibonacci sequence up to

280
00:13:15.600 --> 00:13:19.759
<v Speaker 2>one billion a billion. Yes, and in Crystal, this massive

281
00:13:19.799 --> 00:13:21.840
<v Speaker 2>calculation takes fewer than five seconds.

282
00:13:21.879 --> 00:13:22.879
<v Speaker 1>That is insane.

283
00:13:23.039 --> 00:13:26.080
<v Speaker 2>That is a level of CPU performance that a dynamically

284
00:13:26.159 --> 00:13:29.639
<v Speaker 2>typed interpreted scripting language could never dream of achieving.

285
00:13:29.679 --> 00:13:30.480
<v Speaker 1>How does it do that?

286
00:13:30.720 --> 00:13:34.480
<v Speaker 2>Crystal achieves this through advanced type inference. It looks dynamically

287
00:13:34.480 --> 00:13:37.000
<v Speaker 2>types like Ruby, but the compiler figures out the data

288
00:13:37.039 --> 00:13:40.039
<v Speaker 2>types of compile time, enduring memory safety and raw speed.

289
00:13:40.360 --> 00:13:42.519
<v Speaker 1>I have to challenge this premise, though, go for it.

290
00:13:42.600 --> 00:13:46.159
<v Speaker 1>Calculating the Fibonacci sequence to a billion in five seconds

291
00:13:46.200 --> 00:13:49.320
<v Speaker 1>is an incredible feed of engineering. Sure, but we are

292
00:13:49.320 --> 00:13:51.519
<v Speaker 1>building a telegram bot to tell us when the next

293
00:13:51.559 --> 00:13:53.960
<v Speaker 1>train leaves or to reply with the picture of a dog.

294
00:13:54.679 --> 00:13:58.720
<v Speaker 1>Isn't optimizing for that level of intense CPU performance? Total

295
00:13:58.799 --> 00:14:01.559
<v Speaker 1>overkill for what is his essentially just a text messaging

296
00:14:01.600 --> 00:14:02.399
<v Speaker 1>assistant for.

297
00:14:02.399 --> 00:14:05.840
<v Speaker 2>A single user checking a train schedule. Absolutely, it's overkill,

298
00:14:06.039 --> 00:14:10.000
<v Speaker 2>But think about scalability and infrastructure costs. Okay, if your

299
00:14:10.039 --> 00:14:13.440
<v Speaker 2>bot is adopted by one hundred thousand users, an inefficient

300
00:14:13.480 --> 00:14:17.679
<v Speaker 2>scripting language will require you to rent expensive, heavy duty

301
00:14:17.679 --> 00:14:21.000
<v Speaker 2>cloud servers just to keep up with the memory overhead

302
00:14:21.000 --> 00:14:22.080
<v Speaker 2>and the interpreter lag.

303
00:14:22.240 --> 00:14:23.440
<v Speaker 1>That gets pricey fast.

304
00:14:23.879 --> 00:14:27.600
<v Speaker 2>Because Crystal compiles to such highly optimized, lightweight C code,

305
00:14:28.000 --> 00:14:31.279
<v Speaker 2>you could theoretically run that massive one hundred thousand user

306
00:14:31.320 --> 00:14:35.080
<v Speaker 2>bot on a cheap five dollars a month virtual private server.

307
00:14:35.480 --> 00:14:38.159
<v Speaker 2>You aren't just optimizing for speed, you are optimizing for

308
00:14:38.519 --> 00:14:39.480
<v Speaker 2>server resources.

309
00:14:39.559 --> 00:14:42.039
<v Speaker 1>Oh. That puts it in perspective. The efficiency pays off

310
00:14:42.080 --> 00:14:45.120
<v Speaker 1>at scale, and Crystal doesn't sacrifice developer experience to get

311
00:14:45.120 --> 00:14:47.759
<v Speaker 1>there either, not at all. It has an amazing built

312
00:14:47.759 --> 00:14:50.840
<v Speaker 1>in sandbox feature called Crystal Play. You type that into

313
00:14:50.840 --> 00:14:53.559
<v Speaker 1>your terminal and it instantly launched the web server on

314
00:14:53.600 --> 00:14:55.639
<v Speaker 1>port eighty eighty, where you can test your code live

315
00:14:55.720 --> 00:14:56.360
<v Speaker 1>in a browser.

316
00:14:56.519 --> 00:14:57.639
<v Speaker 2>It's so user friendly.

317
00:14:57.919 --> 00:15:00.679
<v Speaker 1>But what really blew me away was the standard library.

318
00:15:01.080 --> 00:15:03.480
<v Speaker 1>The author shows an example where the code queries the

319
00:15:03.480 --> 00:15:07.879
<v Speaker 1>GitHub api to search for repositories. In most languages, you're

320
00:15:07.919 --> 00:15:10.480
<v Speaker 1>hunting down third party libraries for network requests.

321
00:15:10.720 --> 00:15:14.360
<v Speaker 2>Crystal, however, has eahttp client and Jason Parsing built right

322
00:15:14.399 --> 00:15:17.080
<v Speaker 2>into its core standard library that is so convenient you

323
00:15:17.120 --> 00:15:20.000
<v Speaker 2>don't have to import external packages just to perform basic

324
00:15:20.080 --> 00:15:23.360
<v Speaker 2>modern web functions. The language is fundamentally designed for the

325
00:15:23.399 --> 00:15:25.440
<v Speaker 2>Internet age out of the box, and.

326
00:15:25.399 --> 00:15:28.200
<v Speaker 1>When you are ready to build a larger project, Crystal's

327
00:15:28.200 --> 00:15:31.200
<v Speaker 1>tooling treats you like a professional. From second one. You

328
00:15:31.279 --> 00:15:34.799
<v Speaker 1>take Crystal init app my bot, and it instantly builds

329
00:15:34.799 --> 00:15:40.000
<v Speaker 1>out an entire, scalable project skeleton, testing folders, get ignore files, license,

330
00:15:40.200 --> 00:15:42.679
<v Speaker 1>and your shard dot EML dependency file.

331
00:15:42.919 --> 00:15:46.679
<v Speaker 2>And that Shard dot eml file represents a massive philosophical

332
00:15:46.720 --> 00:15:50.759
<v Speaker 2>shift in how Crystal handles packages compared to traditional ecosystems.

333
00:15:50.799 --> 00:15:54.559
<v Speaker 2>How so well, Crystal's package managers called shards. Instead of

334
00:15:54.559 --> 00:15:58.120
<v Speaker 2>relying on a centralized package repository which acts as a

335
00:15:58.120 --> 00:16:00.720
<v Speaker 2>single point of failure that can go offline or be

336
00:16:00.799 --> 00:16:05.360
<v Speaker 2>compromised by supply chain attacks, Crystal allows direct Git access

337
00:16:05.720 --> 00:16:07.639
<v Speaker 2>for dependencies.

338
00:16:07.279 --> 00:16:10.039
<v Speaker 1>Meaning you simply point your code directly to the source

339
00:16:10.039 --> 00:16:14.720
<v Speaker 1>code repository on GitHub. You completely bypass the middleman centralized server.

340
00:16:14.799 --> 00:16:19.080
<v Speaker 2>Exactly which inherently makes your build process significantly more resilient.

341
00:16:19.320 --> 00:16:22.440
<v Speaker 1>So we've explored the developer happiness of Ruby, the bare

342
00:16:22.559 --> 00:16:26.200
<v Speaker 1>metal optimization of NIM, and the scalable hybrid power of Crystal.

343
00:16:26.720 --> 00:16:29.600
<v Speaker 1>So if Crystal writes like beautiful Ruby and runs with

344
00:16:29.639 --> 00:16:33.399
<v Speaker 1>the blistering speed of c is Crystal the ultimate programming

345
00:16:33.480 --> 00:16:36.120
<v Speaker 1>language for building our personal digital assistance?

346
00:16:36.519 --> 00:16:39.320
<v Speaker 2>This raises an important question about the nature of tool optimization.

347
00:16:39.879 --> 00:16:42.600
<v Speaker 2>There is really no six thing as an ultimate language, ah,

348
00:16:42.759 --> 00:16:45.679
<v Speaker 2>the classic developer answer, Well, it's true. The best language

349
00:16:45.679 --> 00:16:49.480
<v Speaker 2>depends entirely on your specific ecosystem and constraints. For instance,

350
00:16:49.639 --> 00:16:52.840
<v Speaker 2>Crystal currently relies heavily on a Unix like environment. If

351
00:16:52.840 --> 00:16:55.600
<v Speaker 2>your native development machine is running Windows, you have to

352
00:16:55.679 --> 00:16:59.519
<v Speaker 2>use the Windows subsystem for Linux or WSL, which adds

353
00:16:59.559 --> 00:17:02.559
<v Speaker 2>a layer of virtualized complexity that might defeat the purpose

354
00:17:02.639 --> 00:17:06.319
<v Speaker 2>of a fast setup. Furthermore, the best language is often

355
00:17:06.359 --> 00:17:09.160
<v Speaker 2>simply the one that aligns best with your own mental

356
00:17:09.200 --> 00:17:10.119
<v Speaker 2>models of logic.

357
00:17:10.640 --> 00:17:13.359
<v Speaker 1>So what does this all mean? We started this journey

358
00:17:13.400 --> 00:17:16.400
<v Speaker 1>imagining a digital double handling your life while you relax

359
00:17:16.440 --> 00:17:19.839
<v Speaker 1>on a beach, and what Nicholas Muljik's book shows us

360
00:17:19.920 --> 00:17:23.759
<v Speaker 1>is that getting there isn't about finding one magical, perfect

361
00:17:23.880 --> 00:17:27.200
<v Speaker 1>piece of syntax. It's about learning how to translate your

362
00:17:27.200 --> 00:17:31.680
<v Speaker 1>physical problems into computational solutions. Whether you choose the interpreted

363
00:17:31.720 --> 00:17:33.720
<v Speaker 1>ease of Ruby to whip up a quick script to

364
00:17:33.839 --> 00:17:36.839
<v Speaker 1>check your doorbell, or you embrace the compile time friction

365
00:17:36.920 --> 00:17:40.079
<v Speaker 1>of NIM to build a tiny standalone binary, or you

366
00:17:40.160 --> 00:17:43.559
<v Speaker 1>leverage Crystal to build a massive, highly scalable architecture for

367
00:17:43.720 --> 00:17:47.319
<v Speaker 1>thousands of users. The real takeaway here is empowerment.

368
00:17:47.480 --> 00:17:48.759
<v Speaker 2>Yes, absolutely, building a.

369
00:17:48.759 --> 00:17:51.200
<v Speaker 1>Personal bot is a gateway to upgrading your own life.

370
00:17:51.440 --> 00:17:53.880
<v Speaker 1>You truly can stop worrying about checking the train schedules

371
00:17:53.880 --> 00:17:55.920
<v Speaker 1>at midnight and let your code do the heavy lifting

372
00:17:56.000 --> 00:17:56.319
<v Speaker 1>for you.

373
00:17:56.680 --> 00:18:00.880
<v Speaker 2>It democratizes automation. You don't need an enterprise grades server,

374
00:18:01.000 --> 00:18:02.920
<v Speaker 2>rack or a whole team of engineers to have a

375
00:18:02.920 --> 00:18:06.359
<v Speaker 2>personal assistant. You just need an understanding of your own constraints,

376
00:18:06.559 --> 00:18:08.759
<v Speaker 2>a few lines of code, and a chat app.

377
00:18:09.200 --> 00:18:12.279
<v Speaker 1>And that leaves us with one final slightly wild thought

378
00:18:12.279 --> 00:18:12.839
<v Speaker 1>to Mullover.

379
00:18:13.000 --> 00:18:14.359
<v Speaker 2>Oh boy, we've.

380
00:18:14.119 --> 00:18:16.519
<v Speaker 1>Seen today just how easy it is to spin up

381
00:18:16.559 --> 00:18:20.319
<v Speaker 1>a digital double to fetch images, parse Jason data, or

382
00:18:20.440 --> 00:18:24.640
<v Speaker 1>monitor trans at times using surprisingly little code. The barriers

383
00:18:24.640 --> 00:18:28.119
<v Speaker 1>to entry are practically gone. They really are, But as

384
00:18:28.160 --> 00:18:32.680
<v Speaker 1>these programming languages become increasingly abstracted, as the compilers get smarter,

385
00:18:32.759 --> 00:18:34.920
<v Speaker 1>and standard libraries do more of the heavy lifting for

386
00:18:35.039 --> 00:18:37.559
<v Speaker 1>us right out of the box. How far are we

387
00:18:37.640 --> 00:18:40.480
<v Speaker 1>from a future where our personal bots become smart enough

388
00:18:40.480 --> 00:18:41.960
<v Speaker 1>to write code for other bots?

389
00:18:42.000 --> 00:18:42.559
<v Speaker 2>Oh wow?

390
00:18:42.839 --> 00:18:45.680
<v Speaker 1>Imagine relaxing on that beach not just because your bot

391
00:18:45.720 --> 00:18:48.079
<v Speaker 1>is checking your emails, but because your bart noticed a

392
00:18:48.079 --> 00:18:52.200
<v Speaker 1>repeated inefficiency in your daily routine, automatically generated a brand new,

393
00:18:52.279 --> 00:18:56.480
<v Speaker 1>compiled robotic assistant, deployed it, and solved an inconvenience you

394
00:18:56.519 --> 00:18:59.960
<v Speaker 1>hadn't even consciously noticed yet until next time. Keep dye

395
00:19:00.000 --> 00:19:00.480
<v Speaker 1>moving deep