WEBVTT 1 00:00:00.120 --> 00:00:04.719 Imagine you spend like two solid years writing this highly 2 00:00:04.719 --> 00:00:10.039 proprietary algorithmic trading engine. I mean it's your company's absolute 3 00:00:10.119 --> 00:00:10.800 secret sauce. 4 00:00:10.880 --> 00:00:12.320 Oh yeah, the crown jewels of. 5 00:00:12.240 --> 00:00:15.160 The business exactly. So you compile the application you deployed 6 00:00:15.199 --> 00:00:17.519 to a server, and you think your intellectual property is 7 00:00:17.559 --> 00:00:18.760 completely secure. 8 00:00:18.600 --> 00:00:19.800 Right because it's compiled. 9 00:00:20.000 --> 00:00:23.640 Yeah, but here's the crazy part. Anyone with a free 10 00:00:23.760 --> 00:00:27.640 open source tool can just take your compiled executable file 11 00:00:28.399 --> 00:00:32.960 and decompile it back into perfectly readable C sharp source 12 00:00:33.000 --> 00:00:34.840 code in seconds. 13 00:00:34.640 --> 00:00:36.280 Which is wild to think about. 14 00:00:36.280 --> 00:00:39.520 It really is. I mean, in almost any other programming ecosystem, 15 00:00:39.920 --> 00:00:43.240 that kind of transparency is a catastrophic security flaw, but 16 00:00:43.280 --> 00:00:46.479 in c sharp it is this deliberate, genius architectural choice. 17 00:00:46.560 --> 00:00:49.119 Yeah, it all comes down to the intermediate language or IL. 18 00:00:49.240 --> 00:00:51.799 It leaves all the rich metadata completely intact. 19 00:00:51.520 --> 00:00:53.439 So it's basically an open book pretty much. 20 00:00:53.479 --> 00:00:56.679 And I mean that level of exposure feels terrifying initially, 21 00:00:56.759 --> 00:00:59.520 but when you really look under the hood, that exact 22 00:00:59.560 --> 00:01:04.120 transparency is the engine powering the entire dot net ecosystem. 23 00:01:04.599 --> 00:01:09.920 It's the fundamental mechanism that enables cross platform capabilities. Dynamic 24 00:01:10.000 --> 00:01:12.879 memory safety and cross language interoperability. 25 00:01:12.959 --> 00:01:15.239 Well, welcome to this custom tailor deep dive. Today we 26 00:01:15.280 --> 00:01:18.599 are cracking open the blueprint of this architecture. We're using 27 00:01:18.680 --> 00:01:21.280 the book c sharp seven point zero in a nutshell, 28 00:01:21.599 --> 00:01:24.640 the Definitive Reference by Joseph and Ben Albahari. 29 00:01:24.799 --> 00:01:27.120 It's a massive book, but there is so much good 30 00:01:27.120 --> 00:01:27.680 stuff in there. 31 00:01:27.760 --> 00:01:31.359 Oh completely, Yeah, So okay, let's unpack this. Our mission 32 00:01:31.359 --> 00:01:34.640 today is to explore how c sharp balance is incredibly 33 00:01:34.680 --> 00:01:38.359 strict bunker level compile time rules with the run time 34 00:01:38.439 --> 00:01:39.840 flexibility of a pop up tent. 35 00:01:40.000 --> 00:01:40.959 That's a great way to put it. 36 00:01:41.000 --> 00:01:43.359 We are going to extract the underlying mechanics of how 37 00:01:43.400 --> 00:01:46.760 this language evolve from this rigid Windows only desktop tool 38 00:01:46.959 --> 00:01:51.280 into a framework powering everything from Linux servers to iOS 39 00:01:51.319 --> 00:01:51.959 mobile games. 40 00:01:52.079 --> 00:01:55.000 Yeah, and to truly appreciate the advanced optimizations in the 41 00:01:55.000 --> 00:01:57.120 seven point zero release, we first have to examine the 42 00:01:57.120 --> 00:01:58.439 foundational DNA. 43 00:01:58.280 --> 00:02:00.640 Right right where it all started exactly. 44 00:02:00.840 --> 00:02:00.920 So. 45 00:02:01.040 --> 00:02:04.799 C sharp is historically rooted as a statically typed language, 46 00:02:05.120 --> 00:02:08.639 but it actively subverts its own strict identity by pulling 47 00:02:08.639 --> 00:02:11.039 in heavy functional programming concepts. 48 00:02:11.280 --> 00:02:14.560 I definitely notice that tension while reviewing the sources. You 49 00:02:14.639 --> 00:02:19.439 have this rigid type enforcement where you simply cannot implicitly 50 00:02:19.520 --> 00:02:21.639 coerce a string into an integer. 51 00:02:21.879 --> 00:02:23.560 No, the compiler will just yell at you. 52 00:02:23.800 --> 00:02:28.000 Right. But simultaneously you have these functional constructs like delegates, 53 00:02:28.120 --> 00:02:31.159 where functions themselves are treated as first class citizens. 54 00:02:31.199 --> 00:02:33.879 Yeah, you can pass methods around as arguments. 55 00:02:33.439 --> 00:02:36.800 Exactly and use Lamba expressions to spin up anonymous functions 56 00:02:36.800 --> 00:02:39.599 on the fly. Plus, there is this aggressive push toward 57 00:02:39.639 --> 00:02:41.680 immutability in the language design. 58 00:02:41.639 --> 00:02:44.599 And that functional borrowing. I mean, it's an incredibly pragmatic 59 00:02:44.680 --> 00:02:47.599 choice by the language designers. When you treat functions as 60 00:02:47.719 --> 00:02:52.000 values and favor read only immutable types, you drastically reduce 61 00:02:52.080 --> 00:02:52.919 unintended side. 62 00:02:52.759 --> 00:02:54.719 Effects, which is huge for debugging. 63 00:02:54.919 --> 00:02:57.680 Oh massive. It becomes critical when you start dealing with 64 00:02:57.759 --> 00:03:02.599 concurrent execution across multiple threats because immutable states simply cannot 65 00:03:02.639 --> 00:03:04.120 be corrupted by race conditions. 66 00:03:04.159 --> 00:03:05.400 That makes total sense. 67 00:03:05.439 --> 00:03:09.319 But the strictness you mentioned the static typing is equally important. Now. 68 00:03:09.360 --> 00:03:12.479 Some developers feel that static typing creates friction, you know. 69 00:03:12.599 --> 00:03:13.280 Oh for sure. 70 00:03:13.400 --> 00:03:16.759 They argue they lose agility when forced to rigidly define 71 00:03:16.960 --> 00:03:19.319 every interface and type boundary up front. 72 00:03:19.400 --> 00:03:22.439 I will admit I have felt that friction myself. If 73 00:03:22.479 --> 00:03:25.800 I compare it to a dynamic language like Python or JavaScript, 74 00:03:26.080 --> 00:03:28.800 where I can just start writing logic and assigning variables 75 00:03:29.080 --> 00:03:32.639 without declaring their shapes, right, you just go yeah, exactly, 76 00:03:32.960 --> 00:03:34.759 c sharp can feel like it requires a lot of 77 00:03:34.759 --> 00:03:37.439 bureaucratic overhead before you even get to run the code. 78 00:03:37.520 --> 00:03:40.120 What's fascinating here is the counter argument presented by the 79 00:03:40.159 --> 00:03:43.840 Albahari brothers. They argue that this strictness is actually a 80 00:03:43.919 --> 00:03:45.599 massive development accelerant. 81 00:03:45.879 --> 00:03:47.560 Really how so well. 82 00:03:47.879 --> 00:03:51.960 By enforcing type safety at compile time, c sharp completely 83 00:03:52.120 --> 00:03:55.280 shifts the burden of discovering bugs. You aren't relying on 84 00:03:55.400 --> 00:03:58.439 massive suites of run time unit tests just to catch 85 00:03:58.439 --> 00:03:59.719 a basic type mismatch. 86 00:04:00.120 --> 00:04:02.120 Because the compiler just refuses to build. 87 00:04:01.960 --> 00:04:03.639 The application exactly. 88 00:04:03.719 --> 00:04:06.400 It stops you before you even start. And beyond that, 89 00:04:06.639 --> 00:04:10.080 because the environment knows the precise memory layout and type 90 00:04:10.240 --> 00:04:14.919 of every single object, that rich metadata feeds directly into 91 00:04:14.919 --> 00:04:16.000 your ide. 92 00:04:15.879 --> 00:04:17.360 Oh like IntelliSense. 93 00:04:17.480 --> 00:04:20.439 Yes, tools like intell a Sense aren't just guessing. They 94 00:04:20.519 --> 00:04:24.120 actively generate code and suggest valid methods based on the 95 00:04:24.160 --> 00:04:26.279 absolute certainty of the type system. 96 00:04:26.600 --> 00:04:29.560 Let's transition to how that memory is actually managed. Because 97 00:04:29.839 --> 00:04:33.199 the garbage collector within the Common language runtime handles an 98 00:04:33.319 --> 00:04:34.680 enormous amount of heavy lifting. 99 00:04:34.800 --> 00:04:37.120 It really does. It's the unsung hero, right. 100 00:04:37.439 --> 00:04:40.560 Instead of forcing the developer to manually allocate and free 101 00:04:40.639 --> 00:04:44.160 up individual bites of memory, the COLR operates as a 102 00:04:44.199 --> 00:04:47.240 background night watchman. I like that analogy, and it isn't 103 00:04:47.279 --> 00:04:50.839 just cleaning up orphaned objects. The garbage collector actually physically 104 00:04:50.879 --> 00:04:55.120 compacts the memory heap. It moves active objects closer together 105 00:04:55.199 --> 00:04:57.079 to prevent fragmentation. 106 00:04:56.759 --> 00:05:00.120 Which ensures much faster CPU cash access when the program 107 00:05:00.160 --> 00:05:03.759 is running. And that compaction process is a brilliant piece 108 00:05:03.800 --> 00:05:09.319 of runtime engineering. It utilizes a generational model, categorizing objects 109 00:05:09.319 --> 00:05:12.839 into generation zero, one, or two based on how long 110 00:05:12.879 --> 00:05:14.519 they have survived in memory. 111 00:05:14.240 --> 00:05:16.480 So it knows what to check and what to ignore. Right. 112 00:05:16.560 --> 00:05:19.920 It optimizes the scanning process. But doing this requires the 113 00:05:20.000 --> 00:05:22.920 run time to briefly pause application. 114 00:05:22.560 --> 00:05:25.240 Execution, the dreaded GC pause. 115 00:05:25.360 --> 00:05:28.639 Yeah. For the vast majority of applications, that pause is 116 00:05:28.639 --> 00:05:32.680 completely imperceptible. However, if a developer is writing a highly 117 00:05:32.680 --> 00:05:36.639 performance critical system, say a high frequency trading platform or 118 00:05:36.680 --> 00:05:38.639 a low level graphics engine. 119 00:05:38.319 --> 00:05:39.720 Where every millisecond counts. 120 00:05:39.759 --> 00:05:45.160 Exactly in those cases that garbage collection pause introduces unacceptable latency. 121 00:05:45.439 --> 00:05:47.759 And this is where c sharp offers a really fascinating 122 00:05:47.839 --> 00:05:50.519 escape patch. The language does not actually lock you out 123 00:05:50.560 --> 00:05:52.680 of direct manual memory manipulation. 124 00:05:52.920 --> 00:05:54.839 Now, it gives you the keys if you really want them. 125 00:05:54.920 --> 00:05:58.079 Yeah, you can still use explicit memory pointers to bypass 126 00:05:58.120 --> 00:06:01.879 the garbage collector entirely catch is that you must explicitly 127 00:06:01.920 --> 00:06:05.360 wrap those specific code blocks in an unsafe context. 128 00:06:05.480 --> 00:06:07.439 The unsafe keyword, right. 129 00:06:07.680 --> 00:06:09.879 It is the compiler's way of letting you take the 130 00:06:09.920 --> 00:06:14.160 safety rails off, provided you explicitly acknowledge the risk of 131 00:06:14.199 --> 00:06:16.959 introducing memory leaks or buffer overflows. 132 00:06:17.199 --> 00:06:20.839 And the inclusion of that unsafe keyword really highlights the 133 00:06:20.879 --> 00:06:24.759 strict boundary between the managed environment and raw machine execution. 134 00:06:25.360 --> 00:06:27.959 Because c sharp code is never executed directly by. 135 00:06:27.879 --> 00:06:30.279 The processor, right, there's a middleman exactly. 136 00:06:30.800 --> 00:06:34.279 The compiler acts as a first stage translator, converting your 137 00:06:34.399 --> 00:06:37.959 high level syntax into intermediate language and then packaging it 138 00:06:38.040 --> 00:06:38.879 into an assembly. 139 00:06:39.040 --> 00:06:42.279 And going back to our opening hook, this assembly isn't 140 00:06:42.360 --> 00:06:45.360 just a basic container for instructions. It is packed with 141 00:06:45.480 --> 00:06:46.680 comprehensive metadata. 142 00:06:46.720 --> 00:06:52.399 We're talking complete type definitions, method signatures, properties, events. 143 00:06:52.000 --> 00:06:55.680 Everything, and tools like aslespy use that exact medidata to 144 00:06:55.720 --> 00:06:58.560 reverse engineer the original C sharp code. So if a 145 00:06:58.600 --> 00:07:01.480 developer needs to protect their intel sellectual property, they have 146 00:07:01.519 --> 00:07:05.160 to rely on third party obbusekaters to actively scramble that 147 00:07:05.199 --> 00:07:06.600 metadata before deployment. 148 00:07:07.000 --> 00:07:10.480 Yeah, they have to intentionally break the readability. But the 149 00:07:10.560 --> 00:07:14.120 deliberate decision to ship assemblies with that level of introspection 150 00:07:14.240 --> 00:07:18.000 is what makes dynamic linking possible without complex C plus 151 00:07:18.040 --> 00:07:19.399 plus style header files. 152 00:07:19.519 --> 00:07:20.360 Oh, that makes sense. 153 00:07:20.560 --> 00:07:23.800 When one assembly references another the common language, run time 154 00:07:24.000 --> 00:07:28.240 uses that embedded metadata to verify type safety and memory 155 00:07:28.319 --> 00:07:30.600 layouts instantaneously. 156 00:07:29.800 --> 00:07:31.399 So they could just talk to each other naturally. 157 00:07:31.560 --> 00:07:36.240 Exactly. It allows completely different languages to interact seamlessly. A 158 00:07:36.319 --> 00:07:39.040 library written in F sharp can be natively consumed by 159 00:07:39.079 --> 00:07:42.639 a C sharp application because both compilers output the exact 160 00:07:42.639 --> 00:07:45.319 same self describing intermediate language, and. 161 00:07:45.240 --> 00:07:49.279 The final translation step happens at the absolute last possible millisecond. 162 00:07:49.920 --> 00:07:53.639 The just in time compiler or JIT takes that intermediate 163 00:07:53.720 --> 00:07:55.959 language and converts it into native machine. 164 00:07:55.639 --> 00:07:56.879 Code right at the finish line. 165 00:07:56.959 --> 00:07:59.600 Yeah, and it analyzes the specific hardware it is currently 166 00:07:59.600 --> 00:08:02.600 executeting on. If the server has in x sixty four 167 00:08:02.639 --> 00:08:07.240 processor with advanced vector extensions, the JIT optimizes the machine 168 00:08:07.240 --> 00:08:10.279 code specifically to leverage that hardware. 169 00:08:09.959 --> 00:08:13.240 Architecture, which is something a standard ahead of time compiler 170 00:08:13.319 --> 00:08:15.560 can only guess at during the build process. 171 00:08:15.639 --> 00:08:18.720 Exactly, it's building the plane while flying it, but in 172 00:08:18.759 --> 00:08:19.759 the best way possible. 173 00:08:19.879 --> 00:08:23.519 The JT compiler optimizes for the execution environment rather than 174 00:08:23.519 --> 00:08:28.680 the build environment. It continuously profiles the running application, identifying 175 00:08:28.720 --> 00:08:34.679 which methods are called frequently, and aggressively optimizes those hot paths. 176 00:08:34.600 --> 00:08:37.200 While largely ignoring dead code exactly. 177 00:08:37.360 --> 00:08:40.720 And this architecture, the IL, the rich metadata, and the 178 00:08:40.840 --> 00:08:46.279 GIT compiler forms the absolute bedrock of c sharp's platform independence, 179 00:08:46.519 --> 00:08:46.919 and that. 180 00:08:46.919 --> 00:08:50.480 Intermediate state is the exact mechanism that allowed the ecosystem 181 00:08:50.519 --> 00:08:53.600 to break out of its Windows only origins. Because you 182 00:08:53.639 --> 00:08:57.360 aren't compiling to operating system specific machine code. 183 00:08:57.039 --> 00:09:00.000 You merely need a run time environment on the target device. 184 00:09:00.240 --> 00:09:01.960 Right, So what does this all mean for you as 185 00:09:01.960 --> 00:09:05.000 a developer? This architectural pivot led to dot net core 186 00:09:05.120 --> 00:09:08.480 for Linux and macOS and zamorin for iOS and Android. 187 00:09:08.639 --> 00:09:09.720 It opened the floodgates. 188 00:09:10.000 --> 00:09:12.799 It really did. You can write an enterprise back end 189 00:09:13.000 --> 00:09:16.240 running on a Headlessubuntu server and a mobile client app 190 00:09:16.240 --> 00:09:20.000 on an iPhone utilizing the exact same language and logic. 191 00:09:19.879 --> 00:09:23.679 But to remain highly performant across all those disparate platforms, 192 00:09:24.080 --> 00:09:28.120 the language itself had to undergo rapid, massive mutations over 193 00:09:28.159 --> 00:09:28.559 the years. 194 00:09:28.639 --> 00:09:28.799 Oh. 195 00:09:28.799 --> 00:09:31.600 Absolutely, the history of c sharp really serves as a 196 00:09:31.639 --> 00:09:37.759 master class in solving structural developer bottlenecks without breaking backward compatibility. 197 00:09:38.159 --> 00:09:41.320 We see this super clearly in how Microsoft addressed the 198 00:09:41.360 --> 00:09:43.919 performance overhead of early collection types. 199 00:09:44.000 --> 00:09:46.120 Oh I was reading the breakdown on how early sea 200 00:09:46.159 --> 00:09:49.960 sharp handled data collections. It sounded painful. If you wanted 201 00:09:49.960 --> 00:09:51.720 a simple list of integers, you had to use a 202 00:09:51.759 --> 00:09:54.600 collection that treated everything as a generic base object. 203 00:09:54.720 --> 00:09:56.360 Yeah, the old array list right. 204 00:09:56.879 --> 00:09:59.440 And an integer is a value type, meaning it's stored 205 00:09:59.480 --> 00:10:02.799 efficiently on the memory stack, but objects live on the heap, 206 00:10:03.000 --> 00:10:05.679 So the runtime had to constantly box the integer by 207 00:10:05.720 --> 00:10:08.960 allocating memory on the heap and wrapping it in an object. 208 00:10:08.759 --> 00:10:11.679 And then unbox it later by extracting the value back out. 209 00:10:11.960 --> 00:10:16.200 Yes, the CPU cycles wasted on allocating and garbage collecting 210 00:10:16.240 --> 00:10:19.279 those tiny objects were massive. 211 00:10:19.039 --> 00:10:22.639 Huge bottleneck, but the introduction of generics and c sharp 212 00:10:22.679 --> 00:10:26.120 two point zero fundamentally solve that memory overhead. Instead of 213 00:10:26.159 --> 00:10:30.159 boxing everything into base objects, developers could define strongly typed 214 00:10:30.200 --> 00:10:33.480 collections using a placeholder type parameter, and. 215 00:10:33.440 --> 00:10:36.000 That required a totally new CLR. Didn't it. 216 00:10:36.000 --> 00:10:39.840 It did because c sharp utilizes reheffied generics, meaning the 217 00:10:39.960 --> 00:10:44.440 runtime generates specific, highly optimized implementations for each type used. 218 00:10:44.799 --> 00:10:48.360 It eliminated the performance penalty of boxing entirely while preserving 219 00:10:48.399 --> 00:10:50.399 absolute compile time type safety. 220 00:10:50.679 --> 00:10:53.840 Another massive bottleneck they had to fix was data query. 221 00:10:54.440 --> 00:10:57.279 When developers needed to filter a data set or query 222 00:10:57.279 --> 00:11:01.120 a database, they wrote deeply nested loops. Worse, embedded raw 223 00:11:01.159 --> 00:11:03.919 sequel strings directly into their c sharp code. 224 00:11:04.039 --> 00:11:05.879 Oh the magic strings. They were a nightmare. 225 00:11:06.000 --> 00:11:09.080 Right. The compiler couldn't verify the syntax of those sequel strings, 226 00:11:09.159 --> 00:11:12.039 meaning a simple typo would compile perfectly fine but cause 227 00:11:12.039 --> 00:11:15.200 a catastrophic crash at runtime. C sharp tackled this in 228 00:11:15.279 --> 00:11:18.360 version three point zero by introducing Language Integrated Query or 229 00:11:18.480 --> 00:11:19.000 LA and Q. 230 00:11:19.320 --> 00:11:22.320 The underlying mechanics of LA and Q are just brilliant. 231 00:11:22.799 --> 00:11:26.679 It leverages extension methods lambda expressions and deferred execution. 232 00:11:26.759 --> 00:11:28.679 Deferred execution, that's the key part. Yeah. 233 00:11:28.960 --> 00:11:31.480 When a developer writes a L and Q query, the 234 00:11:31.559 --> 00:11:34.840 program does not immediately fetch the data. Instead, it builds 235 00:11:34.840 --> 00:11:37.960 an expression tree, which is a memory representation of the 236 00:11:38.000 --> 00:11:38.679 query logic. 237 00:11:38.759 --> 00:11:40.559 It's just mapping out the plan exactly. 238 00:11:40.960 --> 00:11:43.879 The query is only executed at the exact moment the 239 00:11:43.879 --> 00:11:47.799 code actually attempts to iterate over the results. This deferred 240 00:11:47.799 --> 00:11:52.320 execution allows the underlying provider like entity framework to heavily 241 00:11:52.360 --> 00:11:55.159 optimize the query before ever sending it to the database. 242 00:11:55.399 --> 00:11:59.120 It's so smart, But I think my favorite architectural shift 243 00:11:59.360 --> 00:12:02.720 is how c SHP are five point zero addressed UI freezing. 244 00:12:03.360 --> 00:12:06.639 We have all used applications that lock up entirely while 245 00:12:06.679 --> 00:12:08.759 downloading a file or processing data. 246 00:12:08.919 --> 00:12:10.960 Oh the spinning wheel of death right. 247 00:12:11.120 --> 00:12:13.679 And this happens because the heavy operation is blocking the 248 00:12:13.679 --> 00:12:18.000 main user interface thread. The historical solution was manually spawning 249 00:12:18.039 --> 00:12:21.759 background threads and managing complex callback delegates. 250 00:12:21.360 --> 00:12:24.799 Which quickly devolved into unreadable spaghetti. 251 00:12:24.399 --> 00:12:28.919 Like code completely but the asynchronous programming model flattened that 252 00:12:28.960 --> 00:12:33.799 complexity entirely by introducing the ASNC and AWAKE keywords. Developers 253 00:12:33.840 --> 00:12:38.759 could write asynchronous operations that visually resemble synchronous linear code. 254 00:12:39.240 --> 00:12:42.360 It reads top to bottom just like normal code, but 255 00:12:42.440 --> 00:12:45.720 the compiler is doing intense gymnastics under the hood to 256 00:12:45.759 --> 00:12:46.879 make that syntax work. 257 00:12:47.000 --> 00:12:48.720 Yeah, when it hits in a way keyword, it doesn't 258 00:12:48.759 --> 00:12:52.320 just plause the thread. The compiler actually generates a hidden 259 00:12:52.559 --> 00:12:54.080 i asink state machine. 260 00:12:54.159 --> 00:12:56.519 It's basically rewriting your methods exactly. 261 00:12:56.720 --> 00:12:59.879 It effectively chops your method in half, unwinds the call stack, 262 00:13:00.399 --> 00:13:02.879 and immediately returns control to the main thread, so the 263 00:13:02.960 --> 00:13:06.320 user interface remains highly responsive. And then it just waits right, 264 00:13:06.360 --> 00:13:09.080 And once the background task finishes fetching the data, the 265 00:13:09.120 --> 00:13:12.759 state machine restores the local variables and resumes executing the 266 00:13:12.799 --> 00:13:15.639 remainder of the method from the exact point it left off. 267 00:13:15.840 --> 00:13:20.159 All of these continuous, complex language improvements required a highly 268 00:13:20.200 --> 00:13:24.159 adaptable compiler infrastructure, and this culminated in c sharp six 269 00:13:24.200 --> 00:13:25.919 point zero with Project Rosalin. 270 00:13:26.080 --> 00:13:27.559 Here's where it gets really interesting. 271 00:13:27.840 --> 00:13:31.799 Yeah, Microsoft completely rewrote the c sharp compiler from scratch 272 00:13:32.120 --> 00:13:36.000 using c sharp itself. They exposed the entire compilation pipeline 273 00:13:36.039 --> 00:13:38.480 as a set of open source libraries. 274 00:13:38.000 --> 00:13:40.440 So developers can now use the compiler as a service, 275 00:13:40.559 --> 00:13:43.120 feeding its source code and asking it for a syntax 276 00:13:43.159 --> 00:13:45.679 tree or deep smantic analysis on the fly. 277 00:13:45.960 --> 00:13:48.440 It opened up so many doors for custom tooling. 278 00:13:48.600 --> 00:13:51.559 It really did, and this massive rewrite set the stage 279 00:13:51.559 --> 00:13:53.519 for the rapid cadence of features we see in C 280 00:13:53.639 --> 00:13:56.759 sharp seven point zero, where the focus shifted aggressively toward 281 00:13:56.840 --> 00:14:00.480 reducing visual noise and developer fiction. Let's look at some 282 00:14:00.519 --> 00:14:03.120 of the syntactic sugar that cleans up modern code basis. 283 00:14:03.279 --> 00:14:08.039 My favorite is the null conditional operator. It drastically reduces 284 00:14:08.080 --> 00:14:09.039 boilerplate logic. 285 00:14:09.159 --> 00:14:10.679 Oh the Elvis operator, Yes. 286 00:14:10.559 --> 00:14:15.399 The Elvis operator. Because checking for null references historically required 287 00:14:15.440 --> 00:14:19.480 deeply nestative statements just to safely access a property buried 288 00:14:19.519 --> 00:14:21.039 within an object hierarchy. 289 00:14:20.720 --> 00:14:23.919 If the parent, then the child, then the grandchild exactly. 290 00:14:24.240 --> 00:14:28.360 The null conditional operator allows developers to safely chain property accesses. 291 00:14:29.000 --> 00:14:31.399 If any link in the chain is null, the evaluation 292 00:14:31.480 --> 00:14:34.000 stops immediately and quietly returns null. 293 00:14:34.080 --> 00:14:37.840 It prevents a runtime null reference exception without cluttering the 294 00:14:37.879 --> 00:14:41.360 screen with logic. It provides an incredibly elegant syntax. 295 00:14:41.440 --> 00:14:41.919 Definitely. 296 00:14:42.120 --> 00:14:46.039 They also introduce numeric literal underscores in seven point zero. 297 00:14:46.840 --> 00:14:49.360 If you need a variable to define a memory byte limit, 298 00:14:49.759 --> 00:14:53.039 writing out one billion as a string of nine zeros 299 00:14:53.399 --> 00:14:55.840 is a recipe for an undetected typo. 300 00:14:55.759 --> 00:14:58.120 Because the human eye just blurs them all together. 301 00:14:58.320 --> 00:15:01.519 Right. So C sharp seven point zero allows you to 302 00:15:01.639 --> 00:15:05.559 insert underscores anywhere within the numeric literal. You write one 303 00:15:05.759 --> 00:15:08.519 underscore zero zero zero underscore. 304 00:15:08.120 --> 00:15:09.919 Just like writing commas in a normal number. 305 00:15:10.039 --> 00:15:13.080 Yeah, the compiler strips the underscores out entirely during the 306 00:15:13.080 --> 00:15:17.320 build process, leaving the machine code unaffected while significantly improving 307 00:15:17.399 --> 00:15:18.320 human readability. 308 00:15:18.960 --> 00:15:21.480 But I'd say the most profound structural change in version 309 00:15:21.559 --> 00:15:25.720 seven point zero involves tuples. Returning multiple distinct values from 310 00:15:25.759 --> 00:15:29.679 a single method has historically been a clumsy, high friction process. 311 00:15:29.720 --> 00:15:31.879 I was actually looking at the Albahari breakdown of the 312 00:15:31.919 --> 00:15:35.120 legacy workarounds for that. The old method was either using 313 00:15:35.200 --> 00:15:38.960 out parameters, which forced you to declare variables before calling 314 00:15:38.960 --> 00:15:40.559 the function, breaking the natural flow. 315 00:15:40.799 --> 00:15:42.519 Yeah, that was always so annoying, right. 316 00:15:42.519 --> 00:15:45.080 Or you had to build a custom class purely to 317 00:15:45.080 --> 00:15:48.600 hold a return data. It's like packing for a quick 318 00:15:48.600 --> 00:15:51.679 weekend trip. You don't want to buy and label this massive, expensive, 319 00:15:51.720 --> 00:15:54.639 heavy duty suitcase. Just to carry a toothbrush and one 320 00:15:54.639 --> 00:15:55.279 pair of socks. 321 00:15:55.360 --> 00:15:57.720 No, you just need a lightweight Duffel bag exactly. 322 00:15:57.960 --> 00:16:01.000 Building a formal class is the heavy suitcase. You are 323 00:16:01.039 --> 00:16:04.480 allocating a reference type on the heap, which the garbage 324 00:16:04.480 --> 00:16:07.080 collector now has to track and clean up just to 325 00:16:07.120 --> 00:16:09.399 pass a couple of integers out of a function. 326 00:16:09.399 --> 00:16:13.080 And tupples bypass that overhead entirely. The c sharp seven 327 00:16:13.120 --> 00:16:17.000 point zero implementation introduces native language support backed by the 328 00:16:17.120 --> 00:16:17.879 value tupples. 329 00:16:17.879 --> 00:16:20.440 Struct and structs are value types right yes. 330 00:16:20.679 --> 00:16:23.519 Meaning they are allocated highly efficiently on the memory stack 331 00:16:23.600 --> 00:16:27.000 rather than the heap. When the method finishes execution, the 332 00:16:27.039 --> 00:16:30.879 stack frame pops and the memory is instantly reclaimed. 333 00:16:30.440 --> 00:16:32.480 Completely avoiding any garbage collection over. 334 00:16:32.440 --> 00:16:36.360 It exactly, and the syntax is incredibly clean. Now you 335 00:16:36.399 --> 00:16:39.200 wrap your return values in parentheses and you can name 336 00:16:39.240 --> 00:16:43.639 the elements directly. A method simply returns, say, parentheses string name. 337 00:16:43.600 --> 00:16:47.639 In age, and the calling code accesses those properties instantaneously 338 00:16:48.080 --> 00:16:50.279 without needing a formal class blueprint. 339 00:16:50.480 --> 00:16:53.559 Right And to complement the creation of tupples, seven point 340 00:16:53.639 --> 00:16:58.600 zero also introduced deconstructors. Now a standard constructor takes independent 341 00:16:58.679 --> 00:17:01.960 variables and package them into a unified object right. 342 00:17:01.879 --> 00:17:02.799 Right, it puts them together. 343 00:17:03.120 --> 00:17:07.240 A deconstructor is the exact mechanical inverse. It allows you 344 00:17:07.279 --> 00:17:10.119 to take an object or a tuple and unpack its 345 00:17:10.160 --> 00:17:14.279 internal values directly into separate, brand new local variables in 346 00:17:14.319 --> 00:17:16.200 a single fluid line of code. 347 00:17:16.359 --> 00:17:19.440 It effectively dissolves the container and leaves you with just 348 00:17:19.519 --> 00:17:21.559 the raw data variables you actually. 349 00:17:21.200 --> 00:17:24.640 Need exactly the language actively tries to get out of 350 00:17:24.640 --> 00:17:25.559 the developer's way. 351 00:17:25.759 --> 00:17:29.039 I see that same philosophy applied to local methods. Often 352 00:17:29.240 --> 00:17:32.160 a developer writes a highly specialized helper function that is 353 00:17:32.200 --> 00:17:34.680 strictly used by one specific method. 354 00:17:34.480 --> 00:17:36.359 Like a calculation you only need in one spot. 355 00:17:36.519 --> 00:17:39.079 Yeah, and defining it at the class level just clutters 356 00:17:39.160 --> 00:17:42.559 up the object's public blueprint. Local methods allow you to 357 00:17:42.640 --> 00:17:45.839 define a fully functional method nested inside the body of 358 00:17:45.880 --> 00:17:46.559 another method. 359 00:17:46.839 --> 00:17:50.680 They provide stronger encapsulation than lambda expressions, and they avoid 360 00:17:50.759 --> 00:17:53.119 the hidden delegate allocation overhead. 361 00:17:53.319 --> 00:17:56.359 Plus, the local method can access the local variables of 362 00:17:56.400 --> 00:17:57.720 its parent function directly. 363 00:17:58.240 --> 00:18:01.279 Right. It keeps the logic isolated and defined exactly where 364 00:18:01.319 --> 00:18:04.359 it is invoked, which hugely improves maintainability. 365 00:18:04.759 --> 00:18:09.039 Another powerful feature drastically reducing boilerplate is the expansion of 366 00:18:09.039 --> 00:18:13.720 pattern matching C sharp seven point zero significantly upgraded the 367 00:18:13.799 --> 00:18:17.119 capabilities of the eyes operator and the switch statement. 368 00:18:17.400 --> 00:18:20.839 Oh this is a game changer. In earlier versions, a 369 00:18:20.839 --> 00:18:24.799 switchblock operated as a basic routing table strictly for specific 370 00:18:25.000 --> 00:18:26.359 constant values like. 371 00:18:26.279 --> 00:18:28.799 If it's one, do this, if it's two, do that exactly. 372 00:18:29.279 --> 00:18:33.000 But the new pattern matching capabilities allow developers to evaluate 373 00:18:33.039 --> 00:18:36.240 the actual type of an object directly within the switch 374 00:18:36.240 --> 00:18:37.279 statement's conditions. 375 00:18:37.359 --> 00:18:37.759 Wow. 376 00:18:38.160 --> 00:18:40.599 Yeah, you can pass a completely unknown object into a 377 00:18:40.640 --> 00:18:43.440 switch block and program logic that says, you know, if 378 00:18:43.440 --> 00:18:46.720 this object evaluates as a string type, execute this case block. 379 00:18:46.759 --> 00:18:49.759 If it evaluates as an integer array, execute this one. 380 00:18:50.039 --> 00:18:52.279 And the best part is that it combines the type 381 00:18:52.319 --> 00:18:55.799 check and the casting operation into a single efficient step. 382 00:18:56.079 --> 00:18:57.599 Yes, that saves so much time. 383 00:18:58.079 --> 00:19:01.480 If the object matches the string pattern, you instantly assign 384 00:19:01.519 --> 00:19:04.720 it to a new, strongly typed string variable right there 385 00:19:04.720 --> 00:19:08.359 in the case declaration. The CPU only performs the expensive 386 00:19:08.359 --> 00:19:10.160 type checking instruction once. 387 00:19:10.240 --> 00:19:12.680 Rather than checking the type entering the block and then 388 00:19:12.799 --> 00:19:16.359 executing a separate cast operation on the variable. It really 389 00:19:16.400 --> 00:19:19.640 reduces the amount of casting logic developers have to write. 390 00:19:19.400 --> 00:19:22.519 Ensuring the code remains focused on business logic rather than 391 00:19:22.559 --> 00:19:23.279 just type wrangling. 392 00:19:23.400 --> 00:19:23.880 Exactly. 393 00:19:24.000 --> 00:19:26.400 Well, let's step back and look at the massive architectural 394 00:19:26.440 --> 00:19:30.079 blueprint we've traced today. We started with a language heavily 395 00:19:30.119 --> 00:19:33.640 bound to the Windows operating system, strictly reliant on rigid 396 00:19:33.680 --> 00:19:34.960 object oriented structures. 397 00:19:35.000 --> 00:19:37.319 It was a very different beast back then, it really was. 398 00:19:37.759 --> 00:19:40.799 But through the engineering ingenuity of the Common Language run time, 399 00:19:41.279 --> 00:19:46.359 the highly optimized JIT compilation of intermedy language, and this 400 00:19:46.519 --> 00:19:50.799 aggressive evolution to solve developer bottlenecks, c sharp morphed into 401 00:19:50.839 --> 00:19:53.920