WEBVTT 1 00:00:00.160 --> 00:00:02.399 Welcome back to the deep dive, where we cut through 2 00:00:02.439 --> 00:00:06.280 the noise to get you truly well informed. Today, we're 3 00:00:06.320 --> 00:00:09.359 embarking on a pretty exciting journey into the world of 4 00:00:09.400 --> 00:00:11.080 the Go programming language. 5 00:00:11.160 --> 00:00:13.679 Yeah. Go, it's been getting a lot of traction exactly. 6 00:00:13.279 --> 00:00:16.039 And we're not just diving in blind. We're using excerpts 7 00:00:16.199 --> 00:00:21.719 from a fantastic guide, head First Go, a brain friendly guide. 8 00:00:21.960 --> 00:00:24.960 Ah, they head First series. They have a very distinct. 9 00:00:24.519 --> 00:00:27.559 Style, they really do. So our mission isn't just to 10 00:00:27.640 --> 00:00:30.879 learn about Go itself, but maybe more importantly, to uncover 11 00:00:30.960 --> 00:00:33.840 how this book's unique approach to learning can make any 12 00:00:33.880 --> 00:00:36.280 complex topic stick for you exactly. 13 00:00:36.640 --> 00:00:39.320 That's what's so compelling here. The book offers a kind 14 00:00:39.320 --> 00:00:42.119 of metal lesson, doesn't it. It's teaching you go, yes, 15 00:00:42.439 --> 00:00:45.479 but it's also fundamentally teaching you how to learn effectively. 16 00:00:46.280 --> 00:00:49.719 So we'll be extracting both the core Go concepts and 17 00:00:49.759 --> 00:00:53.840 those universal insights into making even you know, highly technical 18 00:00:53.880 --> 00:00:55.960 ideas accessible and memorable. 19 00:00:56.039 --> 00:00:57.240 Like a blueprint for learning. 20 00:00:57.320 --> 00:00:59.520 Yeah, a blueprint for effective learning just wrapped up in 21 00:00:59.520 --> 00:01:00.960 a program. It's pretty clever. 22 00:01:01.240 --> 00:01:04.599 That's a powerful combination. Okay, So the book starts and 23 00:01:04.640 --> 00:01:07.159 I found this fascinating by talking about. 24 00:01:07.000 --> 00:01:10.200 Our brains, right, not code, but brains. 25 00:01:10.439 --> 00:01:13.840 Yeah, it points out that our brains are fundamentally wired 26 00:01:13.879 --> 00:01:18.159 for survival. They prioritize threats, you know, like hungry tiger 27 00:01:18.480 --> 00:01:21.239 over abstract stuff like programming syntax. 28 00:01:20.879 --> 00:01:23.319 Which makes sense evolutionarily speaking totally. 29 00:01:23.840 --> 00:01:26.560 So if our brains are so good at filtering out 30 00:01:26.599 --> 00:01:30.319 the mundane, the routine, how do we get them to 31 00:01:30.400 --> 00:01:34.480 actually sit up and pay attention to something like go code? 32 00:01:34.560 --> 00:01:35.640 It feels like an uphill. 33 00:01:35.439 --> 00:01:38.200 Battle the classic challenge, isn't it? And the core head 34 00:01:38.239 --> 00:01:42.599 first philosophy really tackles this head on. It acknowledges Okay, 35 00:01:42.719 --> 00:01:45.920 our brains are always scanning for novelty, for anything unusual, 36 00:01:46.680 --> 00:01:50.319 routine predictable information that gets filtered out pretty quickly. So 37 00:01:50.400 --> 00:01:53.879 to truly make learning stick, you have to engage your 38 00:01:53.879 --> 00:01:54.439 brain deeply. 39 00:01:54.599 --> 00:01:56.799 What does deeply mean in this context, Well, it. 40 00:01:56.760 --> 00:02:01.480 Means activating neurons, fostering genuine curiosity, making connections between ideas, 41 00:02:01.680 --> 00:02:06.519 and actively solving problems, not just passively reading. And the 42 00:02:06.560 --> 00:02:10.280 book uses all these clever strategies, engaging both sides of 43 00:02:10.280 --> 00:02:14.199 the brain, appealing to multiple senses, making the content visually 44 00:02:14.240 --> 00:02:15.560 strange or eye catching. 45 00:02:15.639 --> 00:02:18.280 Sometimes I've seen that in their books. Yeah, lots of 46 00:02:18.280 --> 00:02:19.479 pictures and weird. 47 00:02:19.280 --> 00:02:24.199 Layouts exactly, and crucially incorporating stories and human elements. Our 48 00:02:24.240 --> 00:02:27.319 brains are wired for narrative. We pay more attention when 49 00:02:27.319 --> 00:02:29.120 there are people and stories involved. 50 00:02:29.360 --> 00:02:34.240 So it's about making go less like a dry textbook 51 00:02:34.319 --> 00:02:38.479 and more like a captivating story almost for our brains. 52 00:02:38.479 --> 00:02:41.639 That makes perfect sense, and the guide also offers some 53 00:02:41.719 --> 00:02:44.599 really practical tips for you, our listener, to apply these 54 00:02:44.840 --> 00:02:48.919 brain friendly principles. You know, actual techniques like what well, 55 00:02:49.000 --> 00:02:52.439 things like slowing down to truly understand rather than just 56 00:02:52.520 --> 00:02:56.960 memorizing facts, engaging physically, actually doing the exercises, writing your 57 00:02:56.960 --> 00:02:57.560 own notes. 58 00:02:57.400 --> 00:02:58.719 That physical aspects is important. 59 00:02:58.759 --> 00:03:01.759 Yeah, definitely, even making it the last challenging thing you 60 00:03:01.800 --> 00:03:04.319 study before bed. Apparently that gives your brain time to 61 00:03:04.360 --> 00:03:07.719 process it for long term memory, the consolidation phase, right, 62 00:03:08.000 --> 00:03:11.199 and a big one. Talk about what you're learning out loud, 63 00:03:11.360 --> 00:03:12.719 even if it's just to yourself. 64 00:03:13.120 --> 00:03:14.879 Yeah, verbalizing reinforces it. 65 00:03:15.319 --> 00:03:19.039 And finally, they say, allow yourself to feel something, whether 66 00:03:19.080 --> 00:03:23.080 it's that aha moment of clarity or even just groaning 67 00:03:23.120 --> 00:03:26.879 at a silly example. Any emotion is better than none. 68 00:03:27.000 --> 00:03:29.159 And for programming specifically. 69 00:03:28.599 --> 00:03:31.960 Oh right, of course, for GO. All this culminates and 70 00:03:32.000 --> 00:03:35.199 the most important thing writing a lot of code you 71 00:03:35.319 --> 00:03:36.039 have to practice. 72 00:03:36.080 --> 00:03:39.039 You know, these aren't just nice suggestions, they're generally scientifically 73 00:03:39.039 --> 00:03:42.759 backed methods. It really makes you wonder as learners, Yeah, 74 00:03:42.800 --> 00:03:46.639 how often do we truly integrate these active techniques or 75 00:03:46.719 --> 00:03:49.319 do we just default to passive reading, which, as the 76 00:03:49.319 --> 00:03:52.639 book points out, our brains are actually very efficient at forgetting. 77 00:03:53.039 --> 00:03:55.199 It's a bit scary thinking about all the passive reading 78 00:03:55.240 --> 00:03:55.639 I've done. 79 00:03:55.680 --> 00:03:58.840 Well. Yeah, but when you actively apply these principles, you're 80 00:03:58.879 --> 00:04:02.360 not just learning GO. You're learning more effectively, and that 81 00:04:02.400 --> 00:04:07.000 directly helps you grasp new knowledge faster and more thoroughly. 82 00:04:07.240 --> 00:04:10.560 Okay, so we've got our brain friendly toolkit ready, let's 83 00:04:10.560 --> 00:04:14.159 actually embark on our journey into GO itself. What does 84 00:04:14.199 --> 00:04:18.000 this language look like? Starting with how it organizes information? 85 00:04:18.240 --> 00:04:22.639 The basics, right, the fundamentals. At its core, Go is 86 00:04:22.720 --> 00:04:24.399 strongly and explicitly typed. 87 00:04:24.600 --> 00:04:27.720 Okay, what does strongly typed really mean? In practice? 88 00:04:27.839 --> 00:04:30.639 It means every value you work with, whether it's in 89 00:04:30.639 --> 00:04:34.000 infohole numbers, a float sixty four for decimals, A string 90 00:04:34.079 --> 00:04:36.600 for text or a bull for true falls has a 91 00:04:36.639 --> 00:04:38.199 specific defined. 92 00:04:37.800 --> 00:04:40.279 Type and you can't mix them easily exactly. 93 00:04:40.600 --> 00:04:44.120 This emphasis on type safety is a really deliberate design 94 00:04:44.240 --> 00:04:47.279 choice in Go. If you want to do math or comparisons, 95 00:04:47.519 --> 00:04:49.759 the values generally need to be of the same type. 96 00:04:49.879 --> 00:04:52.720 So no adding an integer to a floating point number 97 00:04:52.759 --> 00:04:55.160 without telling GO what you're doing precisely. 98 00:04:55.279 --> 00:04:58.439 If they're different, you'll need an explicit conversion something like 99 00:04:58.480 --> 00:05:00.959 float sixty four might int value to make them compatible. 100 00:05:01.079 --> 00:05:03.519 Why so strict It goes way of catching a whole 101 00:05:03.519 --> 00:05:06.639 class of common programming errors before your code even runs 102 00:05:07.240 --> 00:05:10.800 during compilation. It leads to more robust, reliable software in 103 00:05:10.800 --> 00:05:11.360 the long run. 104 00:05:11.439 --> 00:05:14.920 Okay, so GO holds your hand a bit with types 105 00:05:15.079 --> 00:05:19.000 to prevent mistakes. How does that philosophy carry over to 106 00:05:19.040 --> 00:05:24.600 something as basic as variables? Any GO specific quirks there? 107 00:05:25.120 --> 00:05:27.079 That's a great question, and yeah, it ties right into 108 00:05:27.079 --> 00:05:31.480 Goe's pragmatism. Variables in Go have some distinct traits like no, 109 00:05:31.680 --> 00:05:33.800 you can declare them using the vary key word and 110 00:05:33.800 --> 00:05:37.360 specifying the type like var name string, or much more commonly, 111 00:05:37.360 --> 00:05:39.720 you use the short declaration operator. Ah. 112 00:05:39.920 --> 00:05:40.839 The colon equals. 113 00:05:40.839 --> 00:05:44.439 I've seen that. Yeah, name Alice with ygg. Go actually 114 00:05:44.519 --> 00:05:47.480 infers the type for you, which is super convenient. Nice. 115 00:05:47.600 --> 00:05:48.000 What else? 116 00:05:48.240 --> 00:05:51.079 What's also neat is the zero value concept. If you 117 00:05:51.120 --> 00:05:53.399 declare a variable but don't immediately. 118 00:05:53.000 --> 00:05:55.120 Give it a value like var count ins. 119 00:05:55.120 --> 00:05:58.439 Exactly, it automatically gets a sensible default zero for numbers 120 00:05:58.680 --> 00:06:03.040 and empty string for text booleans no uninitialized variable errors. 121 00:06:03.120 --> 00:06:04.800 That's handy, But you mentioned a quirk. 122 00:06:05.160 --> 00:06:08.600 Ah, yes, the kicker, and this really speaks volumes about 123 00:06:08.759 --> 00:06:11.480 Go's design philosophy. All declare variables, must be. 124 00:06:11.480 --> 00:06:13.879 Used, must be used. What happens if you don't compiler? 125 00:06:14.399 --> 00:06:16.879 Simple as that, If you declare variable and then don't 126 00:06:16.959 --> 00:06:20.959 use it anywhere in your function, GO says, nope, fix this. Wow. 127 00:06:22.079 --> 00:06:24.399 That sounds potentially annoying. 128 00:06:24.639 --> 00:06:26.600 It can feel like it at first, but it's not 129 00:06:26.680 --> 00:06:30.240 just an annoyance. Is Go actively helping you keep your 130 00:06:30.240 --> 00:06:34.480 code clean. It prevents unused dead code from cluttering things up, 131 00:06:34.800 --> 00:06:37.839 and sometimes an unused variable points to a genuine bug 132 00:06:38.360 --> 00:06:39.480 or overlooked logic. 133 00:06:39.600 --> 00:06:41.560 Okay, I see, It's like a built in linter and 134 00:06:41.680 --> 00:06:44.319 forcing good habits an immediate feedback. 135 00:06:43.879 --> 00:06:46.800 Loop exactly, connecting back to that brain friendly idea of 136 00:06:46.879 --> 00:06:50.120 solving problems actively. Go forces you to confront those little 137 00:06:50.120 --> 00:06:51.439 inconsistencies right away. 138 00:06:51.920 --> 00:06:55.160 So Go acts like a diligent code editor, preventing clutter. 139 00:06:55.279 --> 00:06:57.879 I like that, now, zooming out a bit. How does 140 00:06:57.920 --> 00:07:01.439 Go organize all these variables and functions into bigger, more 141 00:07:01.439 --> 00:07:02.399 manageable chunks. 142 00:07:02.560 --> 00:07:06.800 Structure Wise, Go is incredibly consistent, and that consistency is key. 143 00:07:07.079 --> 00:07:09.040 Code is organized into packages. 144 00:07:08.680 --> 00:07:11.720 Packages like libraries or modules and other languages pretty much. 145 00:07:11.800 --> 00:07:14.279 Yeah, think of them as well defined collections of related 146 00:07:14.279 --> 00:07:17.040 functions and types. To use stuff from another package, like 147 00:07:17.079 --> 00:07:19.959 the standard FMT package for printing, you just import it. 148 00:07:20.120 --> 00:07:21.800 You just use an import statement at the top of 149 00:07:21.800 --> 00:07:25.120 your file. Simple, okay. And here's another really unique Go 150 00:07:25.279 --> 00:07:29.920 design choice related to packages. Naming conventions are syntax. 151 00:07:30.519 --> 00:07:32.600 What do you mean? Naming conventions are syntax. 152 00:07:33.040 --> 00:07:35.759 Names starting with a capital letter like my function or 153 00:07:35.800 --> 00:07:37.800 my type are automatically. 154 00:07:37.319 --> 00:07:39.160 Exported exported, meaning. 155 00:07:39.199 --> 00:07:42.360 Meaning they are accessible from outside their own package. If 156 00:07:42.399 --> 00:07:44.600 a name starts with a lower case letter, like my 157 00:07:44.680 --> 00:07:48.160 internal helper, it's unexported. It's private to that package. 158 00:07:48.240 --> 00:07:52.680 WHOA. So visibility isn't controlled by keywords like public or 159 00:07:52.720 --> 00:07:54.000 private Nope. 160 00:07:53.800 --> 00:07:56.079 It's purely based on the case of the first letter. 161 00:07:56.600 --> 00:08:00.639 It's a fundamental mechanism for controlling visibility and promoting encapsulation. 162 00:08:01.360 --> 00:08:03.879 And it makes it immediately obvious just by looking at 163 00:08:03.920 --> 00:08:06.959 a name, whether it's part of the packages, public API 164 00:08:07.199 --> 00:08:08.439 or just an internal detail. 165 00:08:08.560 --> 00:08:14.079 That's surprisingly simple and elegant. Actually, okay, so we've got types, variables, packages, 166 00:08:14.160 --> 00:08:18.160 this cool export rule, how do we actually make decisions 167 00:08:18.240 --> 00:08:20.720 or repeat actions? Control flow? 168 00:08:21.040 --> 00:08:24.600 Go keeps its control flow remarkably simple and focused, which 169 00:08:24.639 --> 00:08:27.759 is great for learners. For conditionals, you have the standard 170 00:08:27.839 --> 00:08:29.040 if else, if and. 171 00:08:29.040 --> 00:08:30.879 Else anything special about them. 172 00:08:30.800 --> 00:08:35.399 A small but noticeable syntax difference. The conditions don't require 173 00:08:35.440 --> 00:08:36.519 parentheses around. 174 00:08:36.320 --> 00:08:39.600 Them, ah like if by ten exactly just if by ten. 175 00:08:39.919 --> 00:08:43.080 It gives the code a slightly cleaner, less cluttered look. 176 00:08:43.200 --> 00:08:44.600 Okay, and loops. 177 00:08:44.879 --> 00:08:46.879 This is another area where GO makes a very deliberate 178 00:08:46.960 --> 00:08:50.840 choice for simplicity. It has only one looping keyword for. 179 00:08:50.519 --> 00:08:52.600 For no while or do while Nope. 180 00:08:52.440 --> 00:08:55.919 Just for. But this single keyword is really versatile. It 181 00:08:55.960 --> 00:08:58.320 handles everything al sir. You can use it for the 182 00:08:58.320 --> 00:09:01.799 classic C style loop than an initializer, condition and post 183 00:09:01.799 --> 00:09:07.759 statement for i zero, i ten ilus plus core. You 184 00:09:07.759 --> 00:09:10.159 can use it like a wile loop by just having 185 00:09:10.159 --> 00:09:12.759 the condition for count five. You can even do an 186 00:09:12.759 --> 00:09:13.960 infinite loop with just. 187 00:09:13.960 --> 00:09:17.919 Foura and iterating over collections like a raise or maps yep. 188 00:09:17.720 --> 00:09:20.559 For horse handles that too using the four dot range construct. 189 00:09:20.559 --> 00:09:21.440 It's really powerful. 190 00:09:21.480 --> 00:09:24.559 So one qword covers all common looping patterns. 191 00:09:24.440 --> 00:09:27.000 Exactly, And of course you still have break to exit 192 00:09:27.039 --> 00:09:29.679 a loop early and continue to skip to the next iteration. 193 00:09:30.080 --> 00:09:33.799 Just like in many other languages. That consistency reduces the 194 00:09:33.840 --> 00:09:36.480 mental load, making it easier to grasp. 195 00:09:36.240 --> 00:09:39.279 That single four loop is definitely a win for learning. Okay, 196 00:09:39.360 --> 00:09:43.480 speaking of war courses, let's talk functions. They're central everywhere. 197 00:09:43.799 --> 00:09:48.159 How does GO handle functions, especially when things go wrong 198 00:09:48.879 --> 00:09:49.759 errors right? 199 00:09:49.879 --> 00:09:53.759 Functions? They're declared with parameters and return types, pretty standard stuff. 200 00:09:54.000 --> 00:09:57.399 But what really sets GO functions apart is their built 201 00:09:57.480 --> 00:09:59.919 in ability to return multiple. 202 00:09:59.600 --> 00:10:02.240 Values multiple return values. How does that work? 203 00:10:02.279 --> 00:10:05.799 The most common absolutely idiomatic pattern you'll see everywhere and 204 00:10:05.840 --> 00:10:09.360 Go is a function returning two things, the primary result, 205 00:10:09.360 --> 00:10:12.000 a calculated and an error value. Okay, so if the 206 00:10:12.000 --> 00:10:15.120 function runs successfully, it returns the result and a nil 207 00:10:15.200 --> 00:10:17.320 value for the error nil just means no. 208 00:10:17.399 --> 00:10:19.320 Error, and if something goes wrong, then. 209 00:10:19.240 --> 00:10:22.360 It returns some default or zero value for the primary result, 210 00:10:22.399 --> 00:10:25.960 which you should ignore, and an actual error object containing 211 00:10:25.960 --> 00:10:27.240 information about what happened. 212 00:10:27.440 --> 00:10:30.480 Ah, so errors aren't exceptions that fly up the stack, 213 00:10:30.799 --> 00:10:32.159 They're just values. 214 00:10:31.759 --> 00:10:36.120 Being returned precisely. This explicit error handling is a cornerstone 215 00:10:36.120 --> 00:10:40.120 of Goh's design. It forces developers you the programmer, to 216 00:10:40.240 --> 00:10:43.840 actively acknowledge and deal with potential failure points right where 217 00:10:43.840 --> 00:10:44.519 the function is. 218 00:10:44.480 --> 00:10:46.639 Called, instead of just hoping for the best or wrapping 219 00:10:46.720 --> 00:10:48.320 everything in a big tricatch block. 220 00:10:48.519 --> 00:10:53.240 Exactly, it pushes you to think about failure paths explicitly, which, 221 00:10:53.440 --> 00:10:56.440 going back to the brain friendly idea, helps build more 222 00:10:56.559 --> 00:10:59.279 robust mental models of your code from the very beginning, 223 00:11:00.000 --> 00:11:01.799 deduces those nasty surprises later. 224 00:11:01.960 --> 00:11:02.399 Makes sense. 225 00:11:02.440 --> 00:11:05.159 Anything else about functions, well, they can also have named 226 00:11:05.159 --> 00:11:08.320 return values, which can sometimes make the functions purpose clearer, 227 00:11:08.399 --> 00:11:12.320 almost like self documentation. And of course variables declared inside 228 00:11:12.320 --> 00:11:13.639 a function have local scope. 229 00:11:13.840 --> 00:11:17.120 Okay, so this explicit error handling returning an error value 230 00:11:17.200 --> 00:11:20.759 or nil is fundamental. What tools does go give us 231 00:11:20.759 --> 00:11:24.039 to actually manage these errors effectively? What's the core message. 232 00:11:24.159 --> 00:11:27.320 The core message is crystal clear. Always handle your errors, 233 00:11:27.840 --> 00:11:28.639 don't ignore them. 234 00:11:28.679 --> 00:11:30.000 And the error type itself. 235 00:11:30.200 --> 00:11:32.320 It's actually an interface, believe it or not. We'll get 236 00:11:32.320 --> 00:11:34.960 to interface as soon, but basically it means errors are 237 00:11:34.960 --> 00:11:36.639 just another type of value you work with. 238 00:11:36.559 --> 00:11:37.720 So how do you handle them? 239 00:11:37.960 --> 00:11:41.240 Well? For really critical errors, the kind where your program 240 00:11:41.320 --> 00:11:45.120 simply cannot continue meaningfully, there's a function log fatal or 241 00:11:45.360 --> 00:11:47.720 do it logs the air message you give it and 242 00:11:47.759 --> 00:11:51.799 then immediately exits the program. It's for unrecoverable situations, okay. 243 00:11:51.639 --> 00:11:55.080 And for less drastic errors, we're creating your own if. 244 00:11:55.000 --> 00:11:57.399 You need to create your own custom air message, perhaps 245 00:11:57.440 --> 00:12:01.679 with some context. FMT error is your It formats a 246 00:12:01.720 --> 00:12:04.759 string just like FMT print, but it returns it as 247 00:12:04.799 --> 00:12:05.960 an actual error value. 248 00:12:06.039 --> 00:12:08.759 But the most important thing is the absolute key. 249 00:12:08.840 --> 00:12:11.519 Takeaway, and I really can't stress these enough, is to 250 00:12:11.679 --> 00:12:14.720 always test if the error value returned from a function 251 00:12:14.919 --> 00:12:17.480 is nil immediately after the call. 252 00:12:17.799 --> 00:12:23.120 So result er some function, then if er nil. 253 00:12:23.080 --> 00:12:26.320 Exactly that pattern. If air is not nil, you have 254 00:12:26.360 --> 00:12:29.200 an error. You must handle it. Maybe log it, maybe 255 00:12:29.240 --> 00:12:31.720 return it up the call stack, maybe try something else. 256 00:12:32.519 --> 00:12:35.320 And crucially, if there is an error you should generally 257 00:12:35.320 --> 00:12:39.399 ignore the other return values like result in that example, 258 00:12:39.679 --> 00:12:41.960 because they're likely unreliable. 259 00:12:41.399 --> 00:12:43.519 Right because the function didn't succeed. What if you don't 260 00:12:43.559 --> 00:12:45.720 care about one of the return values, like maybe you 261 00:12:45.759 --> 00:12:48.039 only care if there was an error, not the result. 262 00:12:48.200 --> 00:12:51.159 A good question. That's where the blank identifier comes in 263 00:12:51.200 --> 00:12:55.120 handy the underscore a you can assign unwanted return values 264 00:12:55.159 --> 00:12:58.960 to explicitly tell GO, I know this function returns this, 265 00:12:59.080 --> 00:13:00.000 but I don't need. 266 00:12:59.879 --> 00:13:03.399 It, So air some function if you only care about 267 00:13:03.399 --> 00:13:03.840 the error. 268 00:13:03.960 --> 00:13:07.759 Perfect that avoids the declared but not used compile error 269 00:13:07.759 --> 00:13:10.720 for the result you're ignoring. It's all about being explicit. 270 00:13:11.080 --> 00:13:14.759 This whole pattern really cultivates a habit of defensive programming. 271 00:13:14.960 --> 00:13:18.200 Yeah, it's fascinating how Go guides you towards more robust 272 00:13:18.279 --> 00:13:21.960 code just by making error handling so visible and explicit 273 00:13:22.080 --> 00:13:25.240 in the function signature itself. It's not an afterthought, It 274 00:13:25.279 --> 00:13:25.759 really isn't. 275 00:13:25.759 --> 00:13:26.519 It's fundamental. 276 00:13:26.759 --> 00:13:30.759 Okay, let's shift gears slightly. Functions usually work on copies 277 00:13:30.759 --> 00:13:33.639 of data, but sometimes you actually want a function to 278 00:13:33.759 --> 00:13:37.519 change the original value of a variable outside it. How 279 00:13:37.559 --> 00:13:38.840 does GO let you do that? 280 00:13:38.840 --> 00:13:40.799 That's precisely where pointers come into play. 281 00:13:40.879 --> 00:13:44.320 Pointers. Okay, they sometimes have a reputation for being tricky. 282 00:13:44.600 --> 00:13:48.039 They can be, but Go handles them fairly straightforwardly. A 283 00:13:48.080 --> 00:13:50.840 pointer is basically just a variable that holds the memory 284 00:13:50.879 --> 00:13:52.480 address of another. 285 00:13:52.279 --> 00:13:55.799 Variable, so it points to where the data lives exactly. 286 00:13:56.080 --> 00:13:58.759 You can get the memory address of any variable using 287 00:13:58.799 --> 00:14:02.080 the attack ye operator. The address of operator, so in 288 00:14:02.159 --> 00:14:04.720 my variable gives you a pointer to my variable. 289 00:14:04.759 --> 00:14:05.879 And once you have that pointer. 290 00:14:06.080 --> 00:14:08.759 Once you have a pointer, you use the operator the 291 00:14:09.000 --> 00:14:12.279 value added to reference operator to get or change the 292 00:14:12.360 --> 00:14:13.360 value at that address. 293 00:14:13.519 --> 00:14:16.679 So my pointer new value would change the original variable. 294 00:14:16.799 --> 00:14:19.240 Correct. This is the key mechanism that allows you to 295 00:14:19.279 --> 00:14:22.679 pass pointers into functions. By passing a pointer, the function 296 00:14:22.759 --> 00:14:25.799 can use the operator to modify the original value that 297 00:14:25.879 --> 00:14:27.799 exists outside its own local scope. 298 00:14:28.000 --> 00:14:31.159 Got it powerful, but needs care definitely. 299 00:14:31.559 --> 00:14:34.360 As with any direct memory manipulation, you need to be 300 00:14:34.440 --> 00:14:36.799 mindful to avoid unexpected side effects. 301 00:14:37.200 --> 00:14:41.679 Okay, so pointers give you that direct line to modify originals. Now, 302 00:14:41.799 --> 00:14:45.159 beyond basic types like in and string, how does go 303 00:14:45.279 --> 00:14:48.799 let you group different kinds of data together or define 304 00:14:48.840 --> 00:14:51.679 specific actions for your own custom data types. 305 00:14:52.120 --> 00:14:55.679 This brings us to one of Goh's core data structuring tools. 306 00:14:56.159 --> 00:14:59.720 Strucks structs like structures and see similar concept. 307 00:14:59.759 --> 00:15:04.799 Yeah, structs are goes way of grouping together values potentially 308 00:15:04.799 --> 00:15:07.720 of different types into a single cohesive unit. 309 00:15:07.799 --> 00:15:08.759 Can you give an example? 310 00:15:08.840 --> 00:15:11.879 Sure? Imagine you want to represent, say a subscriber for 311 00:15:11.919 --> 00:15:14.519 an email list. A subscriber might have a name, which 312 00:15:14.559 --> 00:15:16.960 is a string, okay, a subscription rate which might be 313 00:15:17.000 --> 00:15:19.639 a float sixty four, and whether they're currently active, which 314 00:15:19.639 --> 00:15:20.320 would be a bool. 315 00:15:20.440 --> 00:15:23.279 Right, different types of data, all related to one subscriber. 316 00:15:23.399 --> 00:15:26.080 Exactly. A struck Lets you bundle all those related pieces 317 00:15:26.080 --> 00:15:30.200 of information name, rate, active into a single subscriber type. 318 00:15:30.240 --> 00:15:32.559 And how do you access the individual pieces like the name? 319 00:15:32.840 --> 00:15:36.879 Simple dot notation. If you have a variable my subscriber 320 00:15:37.080 --> 00:15:40.360 of type subscriber, you just use my subscriber dot name 321 00:15:40.639 --> 00:15:42.080 or my subscriber dot rate. 322 00:15:42.279 --> 00:15:42.919 Easy enough. 323 00:15:43.080 --> 00:15:46.840 You can also initialize structs very concisely using struct literals, 324 00:15:47.360 --> 00:15:50.200 and for more complex structures, you could even embed structs 325 00:15:50.240 --> 00:15:50.879 within other. 326 00:15:50.720 --> 00:15:53.879 Structs and the bed like nesting sort of but more direct. 327 00:15:54.039 --> 00:15:57.159 Yeah, you could embed an address struct directly into your 328 00:15:57.200 --> 00:16:00.679 subscriber struct. It's like all the fields of address like 329 00:16:00.720 --> 00:16:04.720 street city, become direct fields of subscriber. It's a powerful 330 00:16:04.720 --> 00:16:08.399 way to compose larger data structures from smaller, reusable ones. 331 00:16:08.639 --> 00:16:10.679 It favors composition over inheritance. 332 00:16:10.919 --> 00:16:14.279 Okay, so structs group related data. But what if you 333 00:16:14.279 --> 00:16:16.519 want to be really explicit about the meaning of some 334 00:16:16.639 --> 00:16:20.440 data or attach specific actions or behaviors directly to your 335 00:16:20.440 --> 00:16:21.200 custom types. 336 00:16:21.320 --> 00:16:23.559 That's where defined types and methods come into play. 337 00:16:23.600 --> 00:16:25.679 Define types. How's that different from. 338 00:16:25.519 --> 00:16:28.519 A struct You can create a completely new type based 339 00:16:28.519 --> 00:16:31.200 on an existing one. For example, you could define type 340 00:16:31.240 --> 00:16:32.519 leaders float sixty four. 341 00:16:32.720 --> 00:16:35.279 So leaders is just a float sixty four underneath. 342 00:16:35.519 --> 00:16:39.879 Yes, its underlying type is float sixty four. But by 343 00:16:39.919 --> 00:16:42.559 creating the new type leaders, you add semantic meaning and 344 00:16:42.600 --> 00:16:46.240 type safety. You can't accidentally assign a plane float sixty 345 00:16:46.279 --> 00:16:49.519 four to a leader's variable or vice versa without an 346 00:16:49.559 --> 00:16:53.519 explicit conversion. It prevents mixing up different kinds of quantities, 347 00:16:53.799 --> 00:16:56.240 even if they're both stored as floating point numbers. 348 00:16:56.360 --> 00:17:00.399 Oh I see for clarity and preventing mistakes. Methods. 349 00:17:00.679 --> 00:17:04.680 Methods are functions that are specifically associated with a particular type. 350 00:17:04.839 --> 00:17:06.960 Could be a struct type, could be a defined type 351 00:17:07.000 --> 00:17:07.680 like our leaders. 352 00:17:07.680 --> 00:17:09.960 How are they defined differently from regular functions. 353 00:17:10.240 --> 00:17:13.039 They have a special extra parameter before the function name, 354 00:17:13.359 --> 00:17:16.559 called the receiver parameter. It looks like this funk a 355 00:17:16.680 --> 00:17:18.559 subscriber print details. 356 00:17:18.279 --> 00:17:21.039 So that as subscriber part means print details is a 357 00:17:21.079 --> 00:17:23.599 method belonging to the subscriber type exactly. 358 00:17:23.720 --> 00:17:26.480 You call it using the dot notation like my subscriber 359 00:17:26.559 --> 00:17:29.759 dot print details. The receiver as inside the method holds 360 00:17:29.759 --> 00:17:32.319 the specific subscriber value you call the method on. 361 00:17:32.640 --> 00:17:35.119 Okay, does it matter if the receiver is say a 362 00:17:35.200 --> 00:17:37.920 subscriber versus s subscriber with a. 363 00:17:37.880 --> 00:17:41.880 Pointer, huge difference. This connects right back to our pointer discussion. 364 00:17:42.559 --> 00:17:45.400 If you define a method with a value receiver like 365 00:17:45.519 --> 00:17:48.960 as subscriber, the method operates on a copy of the 366 00:17:49.000 --> 00:17:52.880 subscriber data. It can't change the original subscriber. 367 00:17:52.359 --> 00:17:55.039 And with a pointer receiver you oil subscriber. With a 368 00:17:55.079 --> 00:17:58.839 pointer receiver, the method gets a pointer to the original subscriber. 369 00:17:59.480 --> 00:18:02.640 This means a method can modify the original values fields. 370 00:18:03.079 --> 00:18:05.559 So you use pointer receivers when a method needs to 371 00:18:05.640 --> 00:18:06.839 change the state of the object. 372 00:18:06.880 --> 00:18:10.640 It's called on got it value receiver for read only operations, 373 00:18:10.920 --> 00:18:15.640 pointer receiver for modifications. This raises a question, though, how 374 00:18:15.680 --> 00:18:19.079 does GO help you protect the data inside your structs 375 00:18:19.400 --> 00:18:22.680 prevent someone from setting, say, an invalid rate on a subscriber. 376 00:18:22.960 --> 00:18:24.319 Encapsulation exactly. 377 00:18:24.440 --> 00:18:28.039 Encapsulation is key, and GO provides a very straightforward mechanism 378 00:18:28.119 --> 00:18:30.559 for it, using that same capitalization rule we talked about 379 00:18:30.559 --> 00:18:31.160 for packages. 380 00:18:31.319 --> 00:18:33.599 Ah, the exported unexported thing again. 381 00:18:33.359 --> 00:18:35.880 Precisely, if you start a struck field name with a 382 00:18:35.880 --> 00:18:38.640 lowercase letter like rate instead of rate, it. 383 00:18:38.559 --> 00:18:43.039 Becomes unexported private to the package. Correct code outside the 384 00:18:43.079 --> 00:18:47.400 structs package cannot directly access or modify my subscriber that rate. 385 00:18:47.680 --> 00:18:49.960 But then how do you modify it safely from outside? 386 00:18:50.240 --> 00:18:54.200 You provide exported capitalized methods, often called getter and setter methods. 387 00:18:54.759 --> 00:18:57.119 You might have an exported method like set rate new 388 00:18:57.160 --> 00:18:59.839 rate float sixty four defined with a pointer. 389 00:18:59.640 --> 00:19:01.559 Receiver and inside set rate. 390 00:19:01.680 --> 00:19:04.920 Inside set rate you can include validation logic. You check 391 00:19:04.960 --> 00:19:07.759 if new rate is valid PG not negative. Only if 392 00:19:07.759 --> 00:19:11.160 it's valid do you actually update the internal unexported rate field. 393 00:19:11.359 --> 00:19:13.960 So the methods act as gatekeepers exactly. 394 00:19:14.119 --> 00:19:17.039 They provide controlled access and ensure the integrity of your 395 00:19:17.079 --> 00:19:21.079 struct's internal state. It's a clear, simple design choice that 396 00:19:21.200 --> 00:19:22.759 encourages writing robust code. 397 00:19:22.880 --> 00:19:24.960 Okay, This is making a lot of sense. Now. You 398 00:19:24.960 --> 00:19:27.759 mentioned earlier that error was an interface, and this seems 399 00:19:27.759 --> 00:19:30.359 to be where GO gets really interesting and maybe a 400 00:19:30.359 --> 00:19:32.880 bit different from other languages, allowing you to care more 401 00:19:32.920 --> 00:19:35.440