1 00:00:06,620 --> 00:00:09,020 - Variables, all right, so in this section, 2 00:00:09,020 --> 00:00:10,120 we're gonna talk about variables, 3 00:00:10,120 --> 00:00:12,740 but trust me, this material assumes 4 00:00:12,740 --> 00:00:14,630 that you are already a software developer, 5 00:00:14,630 --> 00:00:15,920 you know what variables are. 6 00:00:15,920 --> 00:00:18,090 I'm not teaching you variables from the very beginning. 7 00:00:18,090 --> 00:00:19,130 They are just the things here 8 00:00:19,130 --> 00:00:21,010 that I need to talk about to 9 00:00:21,010 --> 00:00:23,300 help us develop a base knowledge 10 00:00:23,300 --> 00:00:26,360 of material as we continue to grow in complexity 11 00:00:26,360 --> 00:00:28,760 in our ability to read and write code in Go, 12 00:00:28,760 --> 00:00:30,840 so I really hope you stick out this section. 13 00:00:30,840 --> 00:00:33,170 I'm not teaching you what a variable is, 14 00:00:33,170 --> 00:00:35,420 but there are some very important things here. 15 00:00:35,420 --> 00:00:38,220 So we're gonna scroll down now into this area 16 00:00:38,220 --> 00:00:39,720 where we have the code review. 17 00:00:40,710 --> 00:00:43,440 We'll be using the Go Playground for a lot of this. 18 00:00:43,440 --> 00:00:45,389 Now, one of the things that 19 00:00:45,389 --> 00:00:47,530 I want to talk to you about is type. 20 00:00:47,530 --> 00:00:49,410 Type is everything. 21 00:00:49,410 --> 00:00:52,970 Type is life, and I promise you one day, 22 00:00:52,970 --> 00:00:54,230 if I get a little too drunk, 23 00:00:54,230 --> 00:00:55,610 I'm gonna go to a tattoo parlor 24 00:00:55,610 --> 00:00:58,530 and I'm gonna write type life right here in my knuckles, 25 00:00:58,530 --> 00:00:59,880 that's how important it is. 26 00:00:59,880 --> 00:01:00,940 Actually, if that ever happens, 27 00:01:00,940 --> 00:01:02,030 you can just laugh at me for the rest 28 00:01:02,030 --> 00:01:04,610 of your life, but type is everything. 29 00:01:04,610 --> 00:01:06,290 Type is life. 30 00:01:06,290 --> 00:01:09,450 Without type, we can't really have integrity 31 00:01:09,450 --> 00:01:12,320 and we can't really start to understand the cost 32 00:01:12,320 --> 00:01:15,400 of the decisions we are making in our code. 33 00:01:15,400 --> 00:01:17,700 I mean, start with this right here. 34 00:01:17,700 --> 00:01:20,440 Our basic unit of memory that we're gonna be working with 35 00:01:20,440 --> 00:01:23,240 in our programming model is a byte, 36 00:01:23,240 --> 00:01:25,190 and a byte is a bit, so now I've just drawn 37 00:01:25,190 --> 00:01:27,760 a byte right now here on the board 38 00:01:27,760 --> 00:01:29,650 with a particular bit pattern. 39 00:01:29,650 --> 00:01:31,110 Now, what I would like to ask you is, 40 00:01:31,110 --> 00:01:33,870 what is the value of this byte? 41 00:01:33,870 --> 00:01:35,850 What does this byte, what is the value 42 00:01:35,850 --> 00:01:37,860 I've just stored inside this box? 43 00:01:37,860 --> 00:01:39,590 The reality is you cannot answer 44 00:01:39,590 --> 00:01:43,720 this question unless I give you the type information, 45 00:01:43,720 --> 00:01:46,610 unless you know what this bit pattern represents. 46 00:01:46,610 --> 00:01:49,680 Now, if I tell you that this represents an integer, 47 00:01:49,680 --> 00:01:50,820 now you can tell me, well, 48 00:01:50,820 --> 00:01:53,980 Bill, that represents the number 10, brilliant. 49 00:01:53,980 --> 00:01:56,230 But if I said nah, it doesn't represent an integer, 50 00:01:56,230 --> 00:01:58,870 it represents a color, now you gotta say, 51 00:01:58,870 --> 00:02:02,050 Bill, what is number 10 on your color chart? 52 00:02:02,050 --> 00:02:05,600 And I might say to you, oh, yeah, yeah, no, no, that's red. 53 00:02:05,600 --> 00:02:06,840 So you could see that this 54 00:02:06,840 --> 00:02:11,480 bit pattern can represent an infinite number of things, 55 00:02:11,480 --> 00:02:14,970 it's all based on what the type information is. 56 00:02:14,970 --> 00:02:17,690 Now, type provides us two pieces of information, 57 00:02:17,690 --> 00:02:20,090 size, how much memory, how many bytes 58 00:02:20,090 --> 00:02:22,750 of memory we need to read or write at any given time, 59 00:02:22,750 --> 00:02:25,670 and its representation, what it represents, 60 00:02:25,670 --> 00:02:28,480 and Go is not being novel in many many cases 61 00:02:28,480 --> 00:02:31,722 that you really already know the syntax of this language, 62 00:02:31,722 --> 00:02:33,530 I don't have to really teach too much syntax, 63 00:02:33,530 --> 00:02:35,280 and just like other programming languages, 64 00:02:35,280 --> 00:02:36,770 Go has the built-in types, 65 00:02:36,770 --> 00:02:39,463 your numerics, your string, and your bool. 66 00:02:40,297 --> 00:02:43,090 What you are seeing on lines 15 through 18 in the code 67 00:02:43,090 --> 00:02:46,640 is just that, those built-in types being used, 68 00:02:46,640 --> 00:02:49,700 and if you look at the name of the types, 69 00:02:49,700 --> 00:02:52,310 start at 17, I love looking at 17, the name 70 00:02:52,310 --> 00:02:55,230 of the type float64 tells us two things, 71 00:02:55,230 --> 00:02:56,760 look, I want you to look at some 72 00:02:56,760 --> 00:03:00,870 of this early material differently than you ever 73 00:03:00,870 --> 00:03:03,290 have before, but I'm not necessarily teaching 74 00:03:03,290 --> 00:03:04,870 you anything new, I wanna give 75 00:03:04,870 --> 00:03:07,690 you a different perspective on what's happening here. 76 00:03:07,690 --> 00:03:10,190 So again, we can have this foundational material 77 00:03:10,190 --> 00:03:12,830 and understanding as things get more complex. 78 00:03:12,830 --> 00:03:16,430 When you look at the name float64, it's really interesting 79 00:03:16,430 --> 00:03:19,120 because it tells us both parts of the type information, 80 00:03:19,120 --> 00:03:22,770 float64, 64 tells us that it's an eight byte, 81 00:03:22,770 --> 00:03:25,420 64 bit value that's giving us the cost 82 00:03:25,420 --> 00:03:26,970 in terms of memory footprint, 83 00:03:26,970 --> 00:03:31,180 and float tells us it's an IEEE 754 binary decimal. 84 00:03:31,180 --> 00:03:32,520 You see how the name in this case 85 00:03:32,520 --> 00:03:35,040 is giving us both pieces of type information. 86 00:03:35,040 --> 00:03:36,700 We know a bool is one byte, 87 00:03:36,700 --> 00:03:38,690 we only need one bit for that byte, 88 00:03:38,690 --> 00:03:41,370 on or off, true or false, and then when you get 89 00:03:41,370 --> 00:03:43,470 to int, it's really interesting. 90 00:03:43,470 --> 00:03:46,090 There is precision based integers, 91 00:03:46,090 --> 00:03:49,490 int8 and 16 and 32, and 64. 92 00:03:49,490 --> 00:03:52,300 But if I saw you using a precision based integer 93 00:03:52,300 --> 00:03:54,840 and it wasn't obvious to me why, 94 00:03:54,840 --> 00:03:57,210 that would raise a flag to me during a code review. 95 00:03:57,210 --> 00:03:58,530 Now, when I say raising a flag, 96 00:03:58,530 --> 00:03:59,610 it doesn't mean it's wrong, 97 00:03:59,610 --> 00:04:01,210 it is not obvious to me why 98 00:04:01,210 --> 00:04:03,070 you're making a particular choice 99 00:04:03,070 --> 00:04:04,970 and I would wanna talk about it, 100 00:04:04,970 --> 00:04:08,230 and there are times when you need a precision based integer 101 00:04:08,230 --> 00:04:10,080 if we are using the atomic instructions 102 00:04:10,080 --> 00:04:11,910 or if you're doing something 103 00:04:11,910 --> 00:04:14,650 that has to be the same size across multiple platforms, 104 00:04:14,650 --> 00:04:16,900 but most of the time, we're just gonna use int, 105 00:04:16,900 --> 00:04:18,670 which can seem confusing because 106 00:04:18,670 --> 00:04:21,350 all this type name is giving us is half 107 00:04:21,350 --> 00:04:23,810 of the type information, all it's telling us 108 00:04:23,810 --> 00:04:26,620 is that whatever number of bytes we're going to allocate, 109 00:04:26,620 --> 00:04:30,160 they only represent an integer value. 110 00:04:30,160 --> 00:04:31,320 So when the question comes, 111 00:04:31,320 --> 00:04:32,450 if we don't understand size, 112 00:04:32,450 --> 00:04:34,830 we don't understand cost, so how much memory is 113 00:04:34,830 --> 00:04:37,240 allocated for an integer? 114 00:04:37,240 --> 00:04:41,480 Well, this is all gonna be based on the architecture 115 00:04:41,480 --> 00:04:43,010 that we are building for. 116 00:04:43,010 --> 00:04:46,930 Now, most of you, if you type Go space version into 117 00:04:46,930 --> 00:04:48,780 your command line, you're gonna see 118 00:04:48,780 --> 00:04:52,053 that you're using AMD64 as your architecture. 119 00:04:52,053 --> 00:04:54,913 Some of you might be on an ARM processor, 120 00:04:55,840 --> 00:04:59,450 but for the most part, you're probably all using AMD64, 121 00:04:59,450 --> 00:05:02,600 which tells us that we are on a 64-bit architecture. 122 00:05:02,600 --> 00:05:06,090 Now, we stick with AMD64 for a second. 123 00:05:06,090 --> 00:05:08,400 What that's gonna mean from a Go perspective 124 00:05:08,400 --> 00:05:11,240 is that since we're gonna work on a 64-bit architecture, 125 00:05:11,240 --> 00:05:12,640 that means that our pointer size 126 00:05:12,640 --> 00:05:16,290 or the address size is gonna be 64 bits or eight bytes. 127 00:05:16,290 --> 00:05:18,780 And the way Go kinda works is this. 128 00:05:18,780 --> 00:05:21,350 If we look at what the address size is gonna be 129 00:05:21,350 --> 00:05:22,910 for the architecture that we're on, 130 00:05:22,910 --> 00:05:26,120 AMD64, 64 bit, eight bytes. 131 00:05:26,120 --> 00:05:28,700 Then we say, okay, our generic word size, 132 00:05:28,700 --> 00:05:30,810 when you hear me use the term word throughout the class, 133 00:05:30,810 --> 00:05:32,580 we're talking about a value 134 00:05:32,580 --> 00:05:36,050 that can change size depending on the architecture, 135 00:05:36,050 --> 00:05:38,330 so our word size is gonna match the architecture, 136 00:05:38,330 --> 00:05:40,629 that's 64 bits or eight bytes, 137 00:05:40,629 --> 00:05:42,730 and then Go says, if your address and your word size 138 00:05:42,730 --> 00:05:44,410 is 64 bits or eight bytes, 139 00:05:44,410 --> 00:05:46,220 let's just make the integer follow. 140 00:05:46,220 --> 00:05:47,940 That will be 64 bits or eight bytes. 141 00:05:47,940 --> 00:05:50,360 All three are always going to be the same. 142 00:05:50,360 --> 00:05:51,250 Now, this gets interesting 143 00:05:51,250 --> 00:05:54,130 because you're seeing code on the Playground, 144 00:05:54,130 --> 00:05:57,260 the Playground is a single threaded environment, 145 00:05:57,260 --> 00:05:58,520 when we get to the concurrency stuff, 146 00:05:58,520 --> 00:06:00,200 we won't really be able to use it. 147 00:06:00,200 --> 00:06:02,380 But what's also interesting is the Playground 148 00:06:02,380 --> 00:06:07,380 is an amd64p32 architecture, p32, 149 00:06:08,237 --> 00:06:09,530 it's a native client architecture. 150 00:06:09,530 --> 00:06:11,530 What that means is that addresses 151 00:06:11,530 --> 00:06:14,480 are 32 bits on this architecture. 152 00:06:14,480 --> 00:06:16,010 For all intents and purposes, 153 00:06:16,010 --> 00:06:17,470 it's a 32-bit architecture 154 00:06:17,470 --> 00:06:21,900 because our address scheme is four bytes or 32 bits, 155 00:06:21,900 --> 00:06:24,140 which now means what, addresses are four byte, 156 00:06:24,140 --> 00:06:26,330 32 bits, word size is four byte, 157 00:06:26,330 --> 00:06:30,040 32 bits, therefore our integer's four bytes or 32 bits. 158 00:06:30,040 --> 00:06:31,390 So we see that our integer 159 00:06:31,390 --> 00:06:33,850 can change size depending on architecture, 160 00:06:33,850 --> 00:06:36,400 and there is mechanical sympathies for this. 161 00:06:36,400 --> 00:06:39,770 The hardware or the architecture is basically saying 162 00:06:39,770 --> 00:06:43,140 that four byte integers is gonna be more efficient 163 00:06:43,140 --> 00:06:45,060 than eight byte integers on our 64 bit, 164 00:06:45,060 --> 00:06:46,970 we're saying eight byte integers are more efficient, 165 00:06:46,970 --> 00:06:49,950 right, so we're trying to gain mechanical sympathies 166 00:06:49,950 --> 00:06:53,110 for the platform that we are building on when it comes 167 00:06:53,110 --> 00:06:56,570 to the address, the word size and the integer, 168 00:06:56,570 --> 00:06:58,650 and that's why we want to use int 169 00:06:58,650 --> 00:07:02,610 and not a precision based integer unless it's 170 00:07:02,610 --> 00:07:04,477 something very specific like we have to 171 00:07:04,477 --> 00:07:06,890 and it's very obvious we wanna do that. 172 00:07:06,890 --> 00:07:09,620 Now, there is another concept here, 173 00:07:09,620 --> 00:07:11,810 I would call it one of Go's words. 174 00:07:11,810 --> 00:07:13,990 There is a word in Go and it's 175 00:07:13,990 --> 00:07:16,540 that there's too many to declare variables 176 00:07:16,540 --> 00:07:17,950 and to create values in Go, 177 00:07:17,950 --> 00:07:21,290 and we'll talk about this early on in the class, 178 00:07:21,290 --> 00:07:24,810 but what you're noticing here is I'm using the keyword var 179 00:07:24,810 --> 00:07:26,640 to declare these variables. 180 00:07:26,640 --> 00:07:28,990 Now, there is a concept called zero values. 181 00:07:28,990 --> 00:07:31,310 Zero value's very very important, 182 00:07:31,310 --> 00:07:33,810 and it's an integrity play in Go, 183 00:07:33,810 --> 00:07:35,030 and I want us to understand that, 184 00:07:35,030 --> 00:07:38,420 again, the cost of integrity is performance, 185 00:07:38,420 --> 00:07:41,430 so this little performance hit will never show up 186 00:07:41,430 --> 00:07:42,610 in a profile, I mean machine's 187 00:07:42,610 --> 00:07:44,350 very very fast, but we want it. 188 00:07:44,350 --> 00:07:46,500 And what zero value says is all memory 189 00:07:46,500 --> 00:07:48,900 that we allocate gets initialized 190 00:07:48,900 --> 00:07:51,900 at least to its zero value state. 191 00:07:51,900 --> 00:07:55,180 In other words, any time we allocate a byte of memory, 192 00:07:55,180 --> 00:07:58,117 if we don't pre-initialize it with some value, 193 00:07:58,117 --> 00:08:00,720 and we're gonna run electrons through the machine 194 00:08:00,720 --> 00:08:03,860 and make sure that we set it all to zero. 195 00:08:03,860 --> 00:08:06,410 This is going to help with a huge number of bugs 196 00:08:06,410 --> 00:08:09,670 that we found in the past where a program starts up, 197 00:08:09,670 --> 00:08:12,470 it allocates a variable, it doesn't initialize it, 198 00:08:12,470 --> 00:08:14,880 the bit pattern is reasonable enough 199 00:08:14,880 --> 00:08:16,440 and the program starts running, 200 00:08:16,440 --> 00:08:19,570 and it's running, but it's also in a corrupted state, 201 00:08:19,570 --> 00:08:21,610 so zero value's an integrity play 202 00:08:21,610 --> 00:08:23,260 and it's very very important. 203 00:08:23,260 --> 00:08:25,200 One of the things we're gonna do in this code base, 204 00:08:25,200 --> 00:08:26,710 one of the things I follow, 205 00:08:26,710 --> 00:08:30,140 is that if I'm going to declare a variable, 206 00:08:30,140 --> 00:08:31,380 create some value like this, 207 00:08:31,380 --> 00:08:32,770 declare a variable and it's gonna be set 208 00:08:32,770 --> 00:08:35,970 to its zero value state, I'm gonna use var. 209 00:08:35,970 --> 00:08:40,050 Var is that kind of readability marker that we are declaring 210 00:08:40,050 --> 00:08:42,000 and initializing to zero value, 211 00:08:42,000 --> 00:08:44,680 and var gives us zero value 100% 212 00:08:44,680 --> 00:08:46,350 of the time in this language, 213 00:08:46,350 --> 00:08:49,850 and I'll show you some examples later on where if you use, 214 00:08:49,850 --> 00:08:52,600 if you're not using var, you're not getting zero value, 215 00:08:53,644 --> 00:08:56,220 and there's one more type here and it's called string. 216 00:08:56,220 --> 00:08:57,830 And string's a really kind 217 00:08:57,830 --> 00:09:00,030 of made up datatype for any language, 218 00:09:00,030 --> 00:09:02,340 and there's different ways to implement strings. 219 00:09:02,340 --> 00:09:04,310 Go has what I would call a unique way, 220 00:09:04,310 --> 00:09:07,020 I had never seen it before up until Go. 221 00:09:07,020 --> 00:09:09,340 Now, when we look at on line 16 222 00:09:09,340 --> 00:09:11,300 and we say this var b string, 223 00:09:11,300 --> 00:09:14,230 what we're seeing is a string being declared 224 00:09:14,230 --> 00:09:17,060 and created setting it to its zero value 225 00:09:17,060 --> 00:09:19,030 which is what we call an empty string, 226 00:09:19,030 --> 00:09:21,580 and so an empty string in Go is 227 00:09:21,580 --> 00:09:24,210 going to look something like this. 228 00:09:24,210 --> 00:09:28,420 B is going to be a two word data structure, 229 00:09:28,420 --> 00:09:29,850 strings are two words. 230 00:09:29,850 --> 00:09:32,290 Notice I'm using the term word 231 00:09:32,290 --> 00:09:34,460 because the size of a string will change depending 232 00:09:34,460 --> 00:09:36,620 on the architecture, on the Playground the word 233 00:09:36,620 --> 00:09:39,060 is gonna be two, four byte words, 234 00:09:39,060 --> 00:09:41,838 so that's eight bytes, on our 64 bit, 235 00:09:41,838 --> 00:09:44,010 it'll be 16 two eight byte words, 236 00:09:44,010 --> 00:09:46,340 there it is, where the first word is a pointer, 237 00:09:46,340 --> 00:09:47,680 we're gonna talk about pointers 238 00:09:47,680 --> 00:09:50,260 and the next word is the number of bytes. 239 00:09:50,260 --> 00:09:52,120 Since this is an empty string, 240 00:09:52,120 --> 00:09:53,070 we don't have any pointer 241 00:09:53,070 --> 00:09:55,970 to a backing array yet, and there are no bytes. 242 00:09:55,970 --> 00:09:59,420 So a word is a two word data value, 243 00:09:59,420 --> 00:10:01,860 eight to 16 bytes of depending upon architecture. 244 00:10:01,860 --> 00:10:03,970 Again, I want to talk about cost, 245 00:10:03,970 --> 00:10:06,130 engineering cost, so we can predict reasonably 246 00:10:06,130 --> 00:10:07,670 well how things are going to run, 247 00:10:07,670 --> 00:10:09,210 how things are gonna happen in memory, 248 00:10:09,210 --> 00:10:12,930 so type is important, the size of things can be important, 249 00:10:12,930 --> 00:10:14,490 we really want understand the cost 250 00:10:14,490 --> 00:10:15,840 of the things we're taking. 251 00:10:16,710 --> 00:10:19,910 Now, you're probably not gonna always want to create, 252 00:10:19,910 --> 00:10:22,710 construct, and initialize to zero value. 253 00:10:22,710 --> 00:10:24,870 There are gonna be times where you wanna pre-initialize 254 00:10:24,870 --> 00:10:26,270 something, and this is where 255 00:10:26,270 --> 00:10:29,380 the short variable declaration operator comes from, 256 00:10:29,380 --> 00:10:32,950 that is the colon equal that you see here on line 27. 257 00:10:32,950 --> 00:10:34,970 A lot of people think that this syntax 258 00:10:34,970 --> 00:10:36,880 from the language comes from C, 259 00:10:36,880 --> 00:10:40,160 but actually, the Pascal programming language 260 00:10:40,160 --> 00:10:42,170 had a large influence also 261 00:10:42,170 --> 00:10:43,960 in the syntax of this language. 262 00:10:43,960 --> 00:10:47,540 This is one of those places where Pascal comes from. 263 00:10:47,540 --> 00:10:52,040 Now, this operator is really a productivity operator, 264 00:10:52,040 --> 00:10:56,070 it's allowing us to declare and initialize at the same time, 265 00:10:56,070 --> 00:10:57,150 I don't want to use the concept 266 00:10:57,150 --> 00:10:59,480 that that Go has duck typing, it doesn't. 267 00:10:59,480 --> 00:11:01,960 It's really struct-based typing, 268 00:11:01,960 --> 00:11:03,270 but in this particular case, 269 00:11:03,270 --> 00:11:04,390 I want us to always look at 270 00:11:04,390 --> 00:11:06,730 the short variable declaration operator 271 00:11:06,730 --> 00:11:09,520 as a productivity operator, 272 00:11:09,520 --> 00:11:12,520 so aa is 10, bb is string, 273 00:11:12,520 --> 00:11:15,610 cc is a float, and dd is bool, 274 00:11:15,610 --> 00:11:16,443 and it's based on the fact 275 00:11:16,443 --> 00:11:17,390 that the compiler knows what type 276 00:11:17,390 --> 00:11:19,000 of value is sitting on the other side 277 00:11:19,000 --> 00:11:21,030 of that short variable declaration, 278 00:11:21,030 --> 00:11:23,810 and if we go back to hello for a second, 279 00:11:23,810 --> 00:11:26,950 what hello would look like from a string now, 280 00:11:26,950 --> 00:11:31,950 is an array of five bytes, right, H-E-L-L-O. 281 00:11:32,840 --> 00:11:35,218 Our pointer would point to that, 282 00:11:35,218 --> 00:11:37,210 and we would say we have five bytes right there. 283 00:11:37,210 --> 00:11:40,250 We're gonna go deeper into this stuff as the class goes on, 284 00:11:40,250 --> 00:11:42,800 but I really believe in visuals, 285 00:11:42,800 --> 00:11:45,840 being able to visualize code and early on in my career, 286 00:11:45,840 --> 00:11:48,080 I used to keep a piece of paper at my desk with a pen 287 00:11:48,080 --> 00:11:49,580 and I would draw these things out. 288 00:11:49,580 --> 00:11:51,410 So what you're seeing me draw on the board 289 00:11:51,410 --> 00:11:53,380 is really my mental models, 290 00:11:53,380 --> 00:11:55,140 my visual mental models of code 291 00:11:55,140 --> 00:11:56,730 and how things go and you're gonna see a lot 292 00:11:56,730 --> 00:11:58,210 of that throughout this class 293 00:11:58,210 --> 00:11:59,320 and I really think it helps 294 00:11:59,320 --> 00:12:02,200 and it's something that it might help you as well. 295 00:12:02,200 --> 00:12:04,700 So we've got the short variable declaration operator 296 00:12:04,700 --> 00:12:08,400 when it's something that's gonna not be zero value. 297 00:12:08,400 --> 00:12:12,860 Now, you might see code like this, and I could see this. 298 00:12:12,860 --> 00:12:16,880 I'm using the short variable declaration operator to assign 299 00:12:16,880 --> 00:12:19,850 or declare an integer and set it a zero value. 300 00:12:19,850 --> 00:12:22,120 There's nothing necessarily wrong with this. 301 00:12:22,120 --> 00:12:24,617 A big part of what we are gonna learn about writing code 302 00:12:24,617 --> 00:12:27,070 and mental models is consistency. 303 00:12:27,070 --> 00:12:30,230 If you wanna do this, then be consistent. 304 00:12:30,230 --> 00:12:31,200 I wouldn't. 305 00:12:31,200 --> 00:12:33,310 I would use var for zero value, 306 00:12:33,310 --> 00:12:35,450 because I think the readability marker 307 00:12:35,450 --> 00:12:38,420 of var is just way too strong to walk away, 308 00:12:38,420 --> 00:12:39,680 and if I was doing a code review, 309 00:12:39,680 --> 00:12:41,700 I would ask us to switch that to var, 310 00:12:41,700 --> 00:12:45,050 but it's not for any other reason for readability 311 00:12:45,050 --> 00:12:46,960 and consistency and readability. 312 00:12:46,960 --> 00:12:48,480 So I don't want to do that, 313 00:12:48,480 --> 00:12:51,490 you won't see that in this code base, but that's up to you. 314 00:12:51,490 --> 00:12:54,120 As long as everybody on your team is doing it the same way, 315 00:12:54,120 --> 00:12:55,610 then it's going to be okay. 316 00:12:55,610 --> 00:12:56,790 Now, there's one more concept here 317 00:12:56,790 --> 00:13:00,570 that I want to talk about, and it's called conversion. 318 00:13:00,570 --> 00:13:04,160 Go doesn't have casting, it has conversion. 319 00:13:04,160 --> 00:13:05,790 And what conversion means really 320 00:13:05,790 --> 00:13:08,120 is that we may be taking a cost, 321 00:13:08,120 --> 00:13:10,580 a memory cost, as we convert values 322 00:13:10,580 --> 00:13:12,330 from one type to the other. 323 00:13:12,330 --> 00:13:14,690 If you've never heard of casting before, 324 00:13:14,690 --> 00:13:17,130 what casting has done traditionally 325 00:13:17,130 --> 00:13:20,950 and it's really a part of helping with performance, 326 00:13:20,950 --> 00:13:23,480 is saying this following thing. 327 00:13:23,480 --> 00:13:26,240 Let's say that we allocated a one byte integer. 328 00:13:26,240 --> 00:13:28,500 There it is, there is my one byte integer. 329 00:13:28,500 --> 00:13:30,840 Let's say for some silly crazy reason, 330 00:13:30,840 --> 00:13:32,610 I decide that I really want a, 331 00:13:32,610 --> 00:13:34,500 not to represent a one byte integer, 332 00:13:34,500 --> 00:13:36,630 but a four byte integer. 333 00:13:36,630 --> 00:13:39,610 Casting will allow me to do something like this, 334 00:13:39,610 --> 00:13:41,070 where I could tell the compiler, 335 00:13:41,070 --> 00:13:44,550 look, you know and I know that a is an int eight 336 00:13:44,550 --> 00:13:48,630 or one byte integer, but casting let's us pretend 337 00:13:48,630 --> 00:13:51,400 that what that memory really is is a four byte integer, 338 00:13:51,400 --> 00:13:53,660 and the compiler trusting us will just say, 339 00:13:53,660 --> 00:13:57,470 okay, and suddenly now, if I'm casting a from one bytes 340 00:13:57,470 --> 00:13:59,790 to four bytes, I have the ability to read 341 00:13:59,790 --> 00:14:01,690 and write memory across those four bytes 342 00:14:01,690 --> 00:14:03,400 from this particular location. 343 00:14:03,400 --> 00:14:06,490 I could be potentially corrupting a lot of memory here. 344 00:14:06,490 --> 00:14:09,600 Now, this is a silly example because really, 345 00:14:09,600 --> 00:14:13,200 where casting traditionally comes in is kind of two places. 346 00:14:13,200 --> 00:14:16,310 One, if you're dealing with data coming over the wire 347 00:14:16,310 --> 00:14:17,540 and you've got large number of bytes, 348 00:14:17,540 --> 00:14:20,760 you probably would like blindly copy those bytes somewhere 349 00:14:20,760 --> 00:14:22,670 in memory and then you would cast 350 00:14:22,670 --> 00:14:25,710 or overlay a structure on top of it, right? 351 00:14:25,710 --> 00:14:27,640 And that's gonna be very very very fast. 352 00:14:27,640 --> 00:14:28,473 You're just gonna say, hey, 353 00:14:28,473 --> 00:14:31,270 those bytes over there, those 20 bytes starting at 354 00:14:31,270 --> 00:14:34,580 that address location, they really represent this structure, 355 00:14:34,580 --> 00:14:35,600 and then that's gonna let you, 356 00:14:35,600 --> 00:14:37,810 because without type, you can't read and write to memory, 357 00:14:37,810 --> 00:14:39,030 it's gonna let us do that, 358 00:14:39,030 --> 00:14:40,660 but if you're off by one byte, 359 00:14:40,660 --> 00:14:42,130 then we've got real problems, 360 00:14:42,130 --> 00:14:44,940 so casting comes with the idea that if you're off, 361 00:14:44,940 --> 00:14:47,780 or seeing that one byte is you overlay that struct, 362 00:14:47,780 --> 00:14:50,373 now you are reading and writing the bytes you didn't. 363 00:14:51,890 --> 00:14:54,300 And that's a real real problem with casting, 364 00:14:54,300 --> 00:14:57,240 so Go says, look, integrity is number one. 365 00:14:57,240 --> 00:14:59,360 We care about integrity as our highest priority, 366 00:14:59,360 --> 00:15:02,600 so you can use the unsafe package to do some casting, 367 00:15:02,600 --> 00:15:04,500 what we'd rather have is conversion, 368 00:15:04,500 --> 00:15:07,670 what Go would say here is we don't wanna even set up 369 00:15:07,670 --> 00:15:12,030 this scenario, so if you really want a to be four bytes, 370 00:15:12,030 --> 00:15:15,530 then we're gonna convert a into a new value 371 00:15:15,530 --> 00:15:19,410 that will be four bytes and maybe, 372 00:15:19,410 --> 00:15:20,620 and in this particular case, 373 00:15:20,620 --> 00:15:22,890 even have to give it a new variable name, 374 00:15:22,890 --> 00:15:26,230 in this case in the sample, we used aaa. 375 00:15:26,230 --> 00:15:30,784 But the idea of conversion over casting 376 00:15:30,784 --> 00:15:31,617 is again, is an integrated play. 377 00:15:31,617 --> 00:15:33,800 There could be a cost of new memory 378 00:15:33,800 --> 00:15:37,750 but we always rather be safe than sorry. 379 00:15:37,750 --> 00:15:39,910 So this is what I wanna share with you 380 00:15:39,910 --> 00:15:42,130 in the variable section, you already know what a variable 381 00:15:42,130 --> 00:15:45,530 is, but to sum up here, okay, type is everything. 382 00:15:45,530 --> 00:15:46,570 Type is life. 383 00:15:46,570 --> 00:15:48,160 It gives us two pieces of information, 384 00:15:48,160 --> 00:15:51,260 size of the memory that we're gonna be allocating 385 00:15:51,260 --> 00:15:53,730 and reading and writing and what that memory represents, 386 00:15:53,730 --> 00:15:56,520 and without the type information, we will have chaos. 387 00:15:56,520 --> 00:15:59,740 It gives us the levels of integrity we need, right? 388 00:15:59,740 --> 00:16:01,950 We have the idea of zero value in Go, 389 00:16:01,950 --> 00:16:03,570 and I wanna use the keyword var for that. 390 00:16:03,570 --> 00:16:06,340 All memory's initialized at least to a zero value state. 391 00:16:06,340 --> 00:16:08,810 We can use the short variable declaration operator when 392 00:16:08,810 --> 00:16:10,190 we are initializing something to it 393 00:16:10,190 --> 00:16:11,600 other than a zero value state. 394 00:16:11,600 --> 00:16:13,130 There is exceptions to everything, 395 00:16:13,130 --> 00:16:14,870 and part of engineering is knowing when to take 396 00:16:14,870 --> 00:16:17,030 that exception, but these are the guidelines 397 00:16:17,030 --> 00:16:17,863 we're gonna be following, 398 00:16:17,863 --> 00:16:20,670 and we have conversion over casting, 399 00:16:20,670 --> 00:16:23,820 again, it's an integrity play to keep our software, 400 00:16:23,820 --> 00:16:26,243 again, and our data and our memory safe.