Speaker 1: Imagine you're building an application that handles like a million
Speaker 1: transactions every single second.
Speaker 2: Oh wow, Yeah, like a global banking app or a
Speaker 2: massive multiplayer game or something.
Speaker 1: Right exactly, And every time your code runs, it creates
Speaker 1: this tiny temporary file in your system's memory just to
Speaker 1: hold a couple of numbers right now, multiply that by
Speaker 1: a million. Eventually a background process has to come through
Speaker 1: and clean up those million tiny files, and when it does,
Speaker 1: your entire server suddenly.
Speaker 2: Just grinds to a complete halt.
Speaker 1: Exactly. Users get disconnected, carts crash, it's a mess. So
Speaker 1: today we're looking at how a seemingly minor tweak in
Speaker 1: a programming language completely eliminates that problem.
Speaker 2: It really is the butterfly effect of software development, you know,
Speaker 2: a microscopic change, and how developer types a line of
Speaker 2: code cascading upward to save entire server architectures from collapsing.
Speaker 1: Welcome to today's deep dive. We are exploring the c
Speaker 1: Sharp seven and dot net Core cookbook. It's written by
Speaker 1: Dirk Strauss, who is a seasoned software developer and a
Speaker 1: Microsoft MVP.
Speaker 2: Yeah he really knows his stuff, he does.
Speaker 1: But we aren't just like reading you a manual today.
Speaker 1: The mission here is to help you cut through the
Speaker 1: noise of modern software documentation. We're tracking an evolutionary leap
Speaker 1: in how developers think about and write code.
Speaker 2: And we're eventually going to zero in on one specific
Speaker 2: highly anticipated feature from c Shark seven point zero release.
Speaker 1: Right. And to really understand why this feature matters, we
Speaker 1: have to look at the environment that well forced it
Speaker 1: into existence.
Speaker 2: Yeah, the macro context is huge. Here the forward of
Speaker 2: this book, it's written by doctor James McCaffrey for Microsoft Research,
Speaker 2: and he paints a pretty intense picture of the industry.
Speaker 1: He really does.
Speaker 2: He calls it this astonishing explosion of new technologies and
Speaker 2: a title wave of various forms of documentation.
Speaker 1: I mean, tidle wave almost feels like an understatement. If
Speaker 1: you look at the sheer scope of what developers are
Speaker 1: expected to manage today, it's it's honestly paralyzing. Oh. Absolutely,
Speaker 1: You've got your legacy syst but now you're also expected
Speaker 1: to build cross platform apps with net core one point
Speaker 1: one that run seamlessly on Windows, Linux, mac op.
Speaker 2: Right, and you're creating mobile apps using Zamorin and Cordova.
Speaker 1: Yeah, and you're moving from old school monolithic architectures where
Speaker 1: everything lives on one big server, to these cloud based
Speaker 1: micro services on Azure service fabrics exactly.
Speaker 2: Not to mention serverless computing right aws, Lambda S three
Speaker 2: Azure functions. For a developer trying to stay relevant, it
Speaker 2: really is just pure information overload.
Speaker 1: So okay, let's unpack this. Yeah, because it's like standing
Speaker 1: in front of this massive, globally themed all you can
Speaker 1: eat buffet.
Speaker 2: That's a great way to put it, right.
Speaker 1: You've got sushi, tacos, roast, beef pasta, all just staring
Speaker 1: at you. You're holding an empty plate, and if you
Speaker 1: just start piling everything on without a strategy, it's gonna
Speaker 1: be a complete.
Speaker 2: Mess, a total disaster on a plate.
Speaker 1: Yeah. So, how is a developer supposed to navigate this
Speaker 1: massive landscape without feeling, you know, entirely paralyzed by all
Speaker 1: this info overload?
Speaker 2: Well, if we connect this to the bigger picture, this
Speaker 2: is exactly why a cookbook approach is vital. A cookbook
Speaker 2: doesn't ask you to eat the whole buffet. It offers quick,
Speaker 2: targeted solutions, you know. But here's the underlying thread that
Speaker 2: connects that massive buffet. Whether you are building a native
Speaker 2: iOS app or an AWS lambda function. You are ultimately
Speaker 2: relying on the foundational syntax of c sharp.
Speaker 1: The language itself is the kitchen. So if we want
Speaker 1: to survive this shift, we have to make sure our
Speaker 1: kitchen tools are ruthlessly efficient.
Speaker 2: Exactly, you can't afford memory leaks when you're running millions
Speaker 2: of automated cloud function.
Speaker 1: Right, And that architectural pressure actually forced the c Sharp
Speaker 1: language designers to rethink something as basic as how a
Speaker 1: method hands data back to a developer.
Speaker 2: Which brings us to the blockbuster feature of c sharp
Speaker 2: seven point zero. Matt's Turgerson, the Sea Sharp program manager,
Speaker 2: went on a record saying that, alongside pattern matching, the
Speaker 2: biggest feature by far.
Speaker 1: Was tupples tuples. Okay, let's establish the technical floor here,
Speaker 1: because the core problem top will solve is like incredibly relatable.
Speaker 2: Oh yeah, every developer faces it.
Speaker 1: Often. You write a function and you want that function
Speaker 1: to give you back more than one piece of data, right, But.
Speaker 2: A method naturally just wants to return one thing. It
Speaker 2: calculates a result, hands it back, closes out right, But
Speaker 2: real world logic rarely fits into a single result.
Speaker 1: But wait, couldn't developers already return multiple values using other
Speaker 1: clunky workarounds before this. I mean, I remember inheriting legacy
Speaker 1: code where they used out parameters everywhere. Ah.
Speaker 2: Yes, the classic out parameter trap.
Speaker 1: It's so messy it breaks the entire flow. You have
Speaker 1: to preemptively declare empty variables before you even call the method.
Speaker 1: It sounds like going to a drive through and being
Speaker 1: forced to make a separate transaction for your burger, your fries,
Speaker 1: and your drink instead of just being able to order
Speaker 1: the number two combo.
Speaker 2: That is exactly what it felt like. And if you
Speaker 2: didn't use out parameters, you had to build an entirely
Speaker 2: new custom class or struct just to transport the data,
Speaker 2: which is just boilerplate clutter exactly. So the tupple is
Speaker 2: your number two combo. It's a lightweight structure that packages
Speaker 2: multiple values together cleanly. But what's fascinating here isn't just
Speaker 2: that tupples exist. It's the technical specifics of how they
Speaker 2: are implemented.
Speaker 1: Right, because not all data containers are created equal.
Speaker 2: Precisely, in C sharp, tupples are implemented as strucks, meaning
Speaker 2: they are value types rather than reference types.
Speaker 1: Okay, that's a huge distinction.
Speaker 2: It really is. It means they are created locally and
Speaker 2: passed by copying the content.
Speaker 1: So no heat allocation exactly.
Speaker 2: No heat allocation, which means the garbage collector doesn't have
Speaker 2: to come clean it up later. It is friction free
Speaker 2: data transport. And they are completely mutable with public mutable fields.
Speaker 1: Which makes perfect sense. If I hand you a combo meal,
Speaker 1: you shouldn't have to jump through hoops just to change
Speaker 1: out the fries for a salad.
Speaker 2: Right, it's your local data exactly. It's lightweight, it's performance,
Speaker 2: and it saves memory.
Speaker 1: So what does this all mean, Like, how does this
Speaker 1: actually change the code on a practice level.
Speaker 2: Well, Strauss uses this really great scenario in the book
Speaker 2: to demonstrate.
Speaker 1: This, well, the student's score dilemma.
Speaker 2: Yes, imagine you have a method that needs to calculate
Speaker 2: the average score for a class, but because class sizes vary,
Speaker 2: the method also needs to return the count of students processed.
Speaker 1: Two pieces of data, the average and the count.
Speaker 2: Right, And he provides this hard coded input array of
Speaker 2: scores in the text just to ground it.
Speaker 1: I actually have that right here. The array is seventeen
Speaker 1: forty six thirty nine sixty two eighty one seventy nine,
Speaker 1: fifty two, and twenty four perfect.
Speaker 2: So with the new c sharp seven point zero return
Speaker 2: type syntax, you just declare the methods return type using
Speaker 2: a set of parentheses. You write public int innt, get
Speaker 2: average and.
Speaker 1: Account just int innt. That's so clean it is.
Speaker 2: And inside the method as a dummy implementation, he shows
Speaker 2: you can just write var return tuple equals zero zero
Speaker 2: using a tupple literal.
Speaker 1: Okay, but here's where I have to push back a
Speaker 1: little on the implementation. Yeah, because the calling code still
Speaker 1: has to consume it, and historically tuples rely on these
Speaker 1: default properties, right.
Speaker 2: Right, item one and item two.
Speaker 1: Yeah, you have to type f item one for the
Speaker 1: average and s item two for the count. That is
Speaker 1: so confusing. Imagine reading that code three months later. Is
Speaker 1: item one the average, that the count is the highest score.
Speaker 2: It's completely opaque, You have zero context.
Speaker 1: It's a breeding ground for bugs.
Speaker 2: Oh absolutely, I completely agree. And that exact limitation of
Speaker 2: default tuble naming is what leads to the final most
Speaker 2: elegant feature of c sharp seven point zero tuples.
Speaker 1: Here's where he gets really interesting, because.
Speaker 2: They fixed this, right they did. You can declare variable
Speaker 2: names directly in the return type now, so.
Speaker 1: Instead of just inint INNT, you can write public int
Speaker 1: average in student count, get average in count.
Speaker 2: Exactly. You are attaching the semantic meaning right there in
Speaker 2: the signature, and the.
Speaker 1: Impact that has on the calling code is massive, because
Speaker 1: you jump from generic item one tags to named elements
Speaker 1: inside an interpolated string. You just type s dot average
Speaker 1: in s student count, which.
Speaker 2: Is incredible readable, and you can even name tupple literals internally,
Speaker 2: like var return tupple, I've ave dot average, scout dot.
Speaker 1: Right. It isn't just about making the code run faster,
Speaker 1: It's about making it human readable for the nice person
Speaker 1: who inherits the project.
Speaker 2: And this raises an important question about how language features
Speaker 2: fundamentally change team collaboration. Oh, for sure, writing code is
Speaker 2: as much about communicating intent to other developers as it
Speaker 2: is about giving instructions to a compiler, exactly.
Speaker 1: But we do need warn people about a specific setup requirement.
Speaker 2: Right, Yes, the gotcha, gotcha? If you are working in
Speaker 2: Visual Studio twenty seventeen release candidate, this doesn't just work
Speaker 2: right out of the box, right.
Speaker 1: Because the core compiler didn't natively know how to process
Speaker 1: value tech toples yet exactly.
Speaker 2: So developers have to go to the new Get package
Speaker 2: manager and actively install a package called system dot value tuple.
Speaker 1: And hit accept on the Microsoft license agreement that pops up.
Speaker 2: Yes, you have to accept the agreement for it to work.
Speaker 2: It's a small hurb, but if you don't know it's required,
Speaker 2: you'll be staring at compiler errors for hours completely baffled.
Speaker 1: Yeah, well, I think that brings us full circle on
Speaker 1: this deep dive. We started out looking at this overwhelming
Speaker 1: macro world, right, micro services, serverless architecture, cross platform app,
Speaker 1: giant buffet, the giant buffet, and we seemed all the
Speaker 1: way down into the elegant micro level syntax of c
Speaker 1: shark seven point zero tuples.
Speaker 2: And mastering these precise quick solutions is exactly what makes
Speaker 2: a developer truly formidable.
Speaker 1: It really is, and it leads you with a final
Speaker 1: somewhat provocative thought to mull over. Yeah, think about it.
Speaker 1: If programming language syntax is constantly evolving to mirror natural
Speaker 1: human logic, like seamlessly packaging and naming multiple related ideas
Speaker 1: at once, like we saw with tuples, how close are
Speaker 1: we to a future where code structure becomes almost indistinguishable
Speaker 1: from plain English.
Speaker 2: Wow, that's a huge question.
Speaker 1: Right, And how are the tools you use today subtly
Speaker 1: shaping the way you actually think about problems evolving in
Speaker 1: your everyday life.
Speaker 2: We shape our tools, and then our tools shape us.
Speaker 1: Exactly something to think about the next time you write
Speaker 1: a line of code. Thanks for joining us on this
Speaker 1: deep dive.
Speaker 2: Thanks for having me