The Modern .NET Show
A blurry image of source code, too blurry to read, take the place of the background. Layered over that are the headshot of Scott Hunter and a purple robot holding a microphone; these are on either side of the centre of the image. Above both is the heading 'THE MODERN .NET SHOW' in bold, white text.

S06E05 - Navigating the .NETverse: From Assembler to Open Source Marvel with Scott Hunter

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S06E05 - Navigating the .NETverse: From Assembler to Open Source Marvel with Scott Hunter
The .NET Core Podcast

S06E05 - Navigating the .NETverse: From Assembler to Open Source Marvel with Scott Hunter

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In this episode of The Modern .NET Show, Jamie Taylor and guest Scott Hunter engage in a thought-provoking discussion about the ever-changing world of .NET development. With a focus on embracing new languages and frameworks, the conversation highlights the importance of staying updated and adaptable in an evolving industry.

Both Jamie and Scott stress the significance of exploring other programming languages and frameworks to broaden one’s skill-set. They acknowledge the existence of developers who tend to stick to a particular language or framework, highlighting the benefits of branching out. Scott particularly mentions the younger generation’s openness to exploring different options, which fosters innovation and growth within the developer community.

Scott emphasizes that .NET is continuously evolving to incorporate modern features and facilitate a smoother transition for developers from other languages. The .NET team actively surveys trends in programming languages and strives to make .NET accessible to developers familiar with Python, JavaScript, and other popular languages. This adaptability ensures that .NET remains relevant and competitive in the market.

They both touch on the significance of supporting Linux and the impact it has had on the development world. Microsoft recognized the need to embrace Linux to provide a well-rounded development experience. Scott Hunter also mentions the compatibility of .NET with Apple’s M1 chips, highlighting the efforts made to ensure that .NET tools work seamlessly on Apple Silicon devices.

Scott Hunter introduces the concept of dev containers, a feature in Visual Studio Code that allows developers to create a docker container and develop within it. By keeping the developer’s machine clean and avoiding unnecessary globally installed dependencies, dev containers provide a consistent and reproducible environment for developers.

Episode Transcription

Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie “GaProgMan” Taylor.

In this episode, I spoke with Scott Hunter about the dynamic world of .NET, open-source, and a bunch of the related technologies that Microsoft have released. Things like DevContainers:

Yeah. So I would tell people that listen to this: please check out dev containers. I waited way too long to check them out. I knew they existed for a long time and just was too busy and never actually dug deep into it. And now that I have, it’s a really cool feature

- Scott Hunter

Along the way, we touch on the fact that .NET is not just open-source but actively accepts contributions from the wider development community - something unheard of in the .NET Framework days. As an example, .NET Seven had over 1,000 contributions from the developer community - not counting the changes that Microsoft’s engineers made to it.

We also touch on some advice that Scott has for participating in open-source communities, along with some hints as to how Microsoft helps to lead the community around their open-source projects. There’s some great advice here, from someone who works in enterprise-lead open-source everyday.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So Scott, this is an amazing - it’s a huge honour for me to have you on the show. I never would have guessed six years ago when I was sitting in a coffee shop going, “maybe this should be our podcast about .NET Core,” that I’d actually A) be sitting talking to you, or B) that we’d run into each other at MVP Summit. This is it’s a real honour for me. So thank you very much.

Scott : I’m super happy to be here and I’m glad that found each other at the MVP Summit and we’re able to talk and schedule this and I’d love to come back more than once. Huge .NET fan, and I appreciate people like yourself that are talking about it all the time. That makes me super happy.

Jamie : You’re very welcome.

No, I’m a huge fan of .NET myself. It isn’t the first thing that I ever learned to program in, but it’s the first thing that I’ve done any, that I did any sort of enterprisey stuff with. I actually go all the way back to Assembler. At college, so over here in the UK, the age of about 16, I got plonked down in front of a Motorola 68k and was booted into DOS. I wasn’t booted into DOS, the computer we were using, sorry, I need to be a little bit clearer. And they were like, “hey, here is assembler, make it do some stuff."

So from that directly into .NET was a bit of a jump.

Scott : I made a bigger jump because I first learned assembler as well, 6502. And then oddly enough, in college, assembler came back up again. In my case it was on an IBM 363/70 mainframe. And assembler in a mainframe is like .NET. Honestly, the registers are all so big, they’re 128 bits that you don’t have to do any carry over or any of the crazy stuff that you do in assembler on smaller architectures.

But funny story for me is after that, the first thing I worked on was a BBS called Wildcat and it was written in Turbo Pascal. And that’s just kind of weird because of my .NET roots, because who knows that X number of years later I’d be working for the same company where .Anders Hejlsberg works. .Anders Hejlsberg, for people that don’t know, is the creator of Turbo Pascal and C# and TypeScript. And so there’s weird combos of how the paths intersect.

But I went through C++ first at enterprise and then moved to .NET after that, and a small stint of Java there as well. We had one product that was written in Java that we had acquired. And so you acquire something and it just is what it is. But of all those, I will tell you that the most productive and the thing I’ve enjoyed the most is definitely .NET. And we’ve kept making it modern, which keeps it up to date.

Jamie : Sure. And I think that’s one of the most exciting things for me is that: I try to learn about other languages as well as the one that I’m using for my day-to-day stuff. Because I feel like my personal opinion that sometimes it can be dangerous just to stay in one language or framework. And so I’m looking around at what Java is doing, I’m looking around at what’s happening in the JavaScript ecosystem, I’m looking at what’s happening with Go, and Rust and things like that. And I do genuinely feel like you said net is staying as modern as it can be. There are things in there, that there are things in .NET that JavaScript has only just got hold of, right? The Python’s only just got hold of. We’ve had async/await for a long time. It’s a new thing perhaps to a lot of Python developers at least built in to Python and JavaScript developers. So it’s always good to find out what other people are doing.

Scott : I think we are always looking at what other folks are doing. That is part of the evolution of .NET in many cases. I sat down comically enough at the MVP summit with a bunch of MVPs and they’re like, “why did you do all this work to get rid of Main? Why did you do all this work to change the way you write APIs? And all this stuff? We said we don’t understand it, we’re never going to use that.” And I told them, I said, “well, that stuff wasn’t done for you, that stuff was done for the next generation developer."

So our assumption today is you’re going to learn either in high school or in college, you’re likely going to learn Python and JavaScript. And so if you learn one of those languages and then you come and start using .NET we actually, I don’t know if you heard the story, but Maria [Naggaga] on the team did interviews with Python developers and JavaScript developers and had them go through a .NET tutorial, and saw where they struggled and asked them for feedback on what they thought. And they’re like, “why all this work just to get to my code?” Because in both of those languages you just start writing code. You don’t put all this structure around the outside of the thing to get started. And so that work is all being done to basically say, “if you come from these other languages, .NET doesn’t look too alien to you."

The team knows I hate this word: minimal.

For the new declarative API by syntax, the first versions of that required a whole bunch of typecasting and stuff like that, which for .NET people we’re used to. But Matt Ferguson on the team was able to go and make the compiler automatically typecast for you. It actually is doing that behind the scenes, so you’re not writing the typecast, the typecasts are still being put in there, but that was all being done. So if you came from one of these languages, .NET looks simple to you, and I think that’s super critical to the language.

And it’s funny, we all laughed a few months ago when we saw Java, the next version of Java is stealing some of that stuff as well. So they’re cleaning up their Main as well. I don’t think they’re going to go all the way as far as we did and get rid of Main, but they are going to simplify the parameters and a bunch of other stuff. But we all saw the pull request into Java to try to do the same thing that we’re doing. And I think that all of the older languages and older platforms should always be looking at what the newer platforms are doing and take the best from that. Even when we did MVC in .NET Framework, Ruby on Rails had been out for a while, and so in many cases, we all wrote Ruby code and then we learned - and so to me, ASP .NET, MVC was an evolution of Ruby on Rails. It was better because the next thing is always better than the first thing. Both you and I, if we look at any code we wrote five years ago, we’ll hate it because we’re probably continually getting better as developers, and we go back and go, “I wouldn’t oh, that’s awful. Why did I write it that way?”

Jamie : Sure. Okay, so you use the word stealing, but obviously as a sort of silly way to describe it. But I think, like you said, it’s very important for all languages, and all framework designers, and things like that to look around and say, “oh cool, they’re doing it this way. Can I adopt it into the way that my thing works?” And I think, at least from my perspective, the most important thing about that reduction of the I don’t want to say cruft, but the reduction of the extra stuff that needs to go around your code to make, say, a Hello, World or to make a minimal API or something like that. It’s not like it’s being removed and you can’t do that ever again. It’s at the moment, at the very least, the way that I’ve been playing with the preview bits and all that kind of stuff, is if I want to have that stuff removed, I can. Right?

Scott : So the reality is how that tech actually works. We actually inject a Main anyways, you just don’t see it. So whatever’s gone is still really actually there. We just did it all behind the scenes for you.

I don’t know if I use the word stealing, but we all steal from everybody, by the way. So, like, async/await, which is something that was created back in the .NET Framework 3.5 time frame. Almost every language out there has got a version of that today. Because basically that was just an example of I don’t know if we got lucky or what, but threads are hard and it’s just a much better way of writing thread code when you can actually follow it straight down versus having a bunch of forks and stuff like that. And so anytime a language has some major breakthrough, all the other languages will steal or borrow or whatever you want to call those capabilities. That’s just part of it.

And there’s a cool event in Seattle that’s coming up, I think, September 19, where .Anders Hejlsberg, the creator of Python, James Gosling, the creator of Java, and the lady who designed Small-Talk are all getting together and talking as language designers together. And so what I’ll tell you is you find that these people, even though they have very different opinions and thoughts, they’re all still friendly people and just love to talk languages and nuts and bolts. And so, as you said, I don’t think words like steel or those words are too strong. It’s more of everybody learns. And all the languages get better all the time because we’re all looking and changing and trying ideas.

Jamie : Absolutely 100%. Because be all know from, depending on which direction we came from in this industry, you may know, obviously you and I will, but the listener may know that there is no one way to solve a problem. And so you get a bunch of people together who solved a similar problem in different ways. You can all take inspiration from that, can’t you?

Scott : I will tell you, if you gave me a bunch of Excel files and told me to go scrape some code out of them, do some transformations and make a new file, I would not do that in .NET. I would do that in Python. Python is dang good at that. As you said, you use the tool for the job. .NET happens to be great for building web applications and desktop applications and API back ends. It is not the language that I would go use to glue a bunch of stuff together or the platform. And I hope the .NET team would agree with me on that. I think they would.

Jamie : No, I Think that’s a very good statement and a very fair statement to make because I feel like, in my own experience of working with a lot of Devs across my - I mean, I’ve only really been doing this for 14 years, so not a great deal of time. But in my experience, I’ve met a lot of people who are very I can’t think of the right word, but I worry that “evangelical” is the wrong word. But they’re very much, “we have to do it in this particular framework or this particular language or this particular setup, because that’s what we need to do it in.” And I’ll walk in and say, “well, actually, if you investigated Rust or Dart or Go or Python or JavaScript or… there’s likely a package in a different language for this and you may not have to put in as much effort,” but I feel like there’s a lot of maybe stick-to-it·ive·ness is probably the right word. I don’t know. But there’s a lot of people who are like, “no. We’ll do it this way.”

Scott : I’ve seen the same thing and I wonder if it’s more of your and my generation that are like that. And I don’t think the newer generations are the same as us that have the crazy strong, “I must do everything in this one way.” You know, like at Microsoft what I would say, when I joined know a lot of our customers were what I would call a Microsoft shop. All they use is Microsoft products. I don’t see that there’s not that many that are that way now. Most people or most companies that I see in my professional working are on purposely not putting all their eggs in one basket for valid reasons. And so I do think it is you’re right that especially my generation I think is super biased towards whatever their favourite languages and are kind of hostile to exploring others.

If I’m going to write a rule for an API management transformation, JavaScript is probably the easier language to do in that little small place, where I have a couple of lines of code, I’ll say I’ve gotten wiser and so I will not be full biased towards .NET but it’s still my preferred.

Jamie : Sure. And like you said, there’s nothing wrong with having a preferred. But knowing that the other tools exist means that you don’t fall into that pit of, I think it was Abraham Maslow who said, “when everything you’ve got is a hammer, everything looks like a nail,” when all you have is .NET, then all you can do is .NET solutions. And there’s nothing wrong with a .NET solution but like you said, a JavaScript or python or something may be better for the situation you’re in.

Scott : Definitely.

Jamie : Cool. Okay. So I want to say that I feel like I’m one of the “lucky” .NET devs in that I get to play with all of the new things as they’re coming out. Partially because I’m an MVP, but partially because I’m a curious kind of a chap. But I do know that there’s a lot of enterprisey devs who are in the .NET space who maybe don’t get the chance or don’t have the time outside of work to actually work on or look at the new stuff. So I do know a lot of enterprisey devs, and it has become a bit of a joke within my circles anyway of “wait, you can run net on Linux now?!” and lots of things like that. So I was just wondering would you be able to maybe mention and talk about some of the 10,000 foot differences between if I’m coming to net new and “I’m saying well I’ve got .NET Framework, I’ve got .NET Core and I’ve got .NET five or six or seven or eight, where do I start?” So I wonder could you just real quick just rattle off a few of those?

Scott : Sure.

First off, you mentioned Linux, and Linux is something that is super important to us. We started the journey that makes .NET what .NET is today, back about 2013, when we realized that because of the backwards compatibility requirements for .NET Framework, there was not a way to go forward. Meaning that we can never change anything in .NET Framework. Because you have to realize that .NET Framework is included in every Windows installation. And so every machine contains a copy of .NET. If we make a breaking change, it breaks apps all across Windows. And trust me, as somebody that works in the team, we had repeated cases where we broke big stuff across the years.

A couple of things there was number one is we also saw that in the server world, especially the web backend world, there was already in 2013 this big move to Linux. And so we deemed that to be critical for the platform that, “hey, if the world’s moving to Linux and .NET’s not, we’re going to get left behind.” And we expanded that because we actually took that to we support macOS and we’ve added architectures like Arm64, Arm32 as well to the platform. And all those are about those same kinds of things. It’s like, “hey, the industry is moving, “just like we’re talking about languages. Well, the industry is always shifting and moving. And so Linux has had this slow rise and even at Microsoft you’ve probably heard us say that Azure customers, more than half, are now using Linux. And so that’s a huge accomplishment.

So we as a team thought those were all super important things. Number one: if you want to take a bet on a platform, it needs to be open source. Why does it have to be open source? Because in many cases, if you’re in the industry as long as I’ve been, people keep old apps around for a long time and maybe the framework they built on is out of date and they have to maintain some of it themselves. And so they want the platform to be open source. Obviously we talked about Linux. That’s a huge important thing forward. And that was the genesis of what started off being .NET Core. And at the time, .NET Core had to have a new name because it wasn’t .NET Framework. .NET Framework was something we’d been shipping since 2002. And so we started off with a brand new name. And then in my terms, we got lucky. Most of the times when you reinvent the tech, you lose half of your audience. We did not, we actually gained audience, not lost audience, or we got people back. We heard many stories of people that actually moved off of .NET to Java because of Linux and then they’re like, “oh my gosh, you’ve got .NET on Linux, now we can come back.” I was at MVP Summits and at build conferences and I would get hit in the hallway all the time by people that thanked us for letting them move back to .NET.

And so we did the .NET Core thing for version one, version two, version three. And because we had so much uptake on the platform, I think because of performance, because of the fact you could put multiple versions on the same machine, we fixed a bunch of those things where an update on your machine would happen and it would break your applications. I think in the OS support, we got the right mix of things that caused people to be motivated to move to the new platform. And once we saw that we were going to be successful, that’s when in .NET Five, we skipped four. Because we had .NET Framework Four, we didn’t want to have .NET Core Four and .NET Framework Four, that’s kind of a confusing message. Or even .NET four and .NET Framework four. So we skipped four completely and said, “we’ll just go right to five.” And we rebranded the platform as net Five and dropped the core. Because really going forward, the version of .NET I want customers to use is .NET 5 6 7 8.

Don’t build new applications on net Framework. I mean, you can, but really all the new capabilities and features are only going to be in the new platform. And so we wanted our message to be moving forward, “if you’re brand new to the platform, sadly, you’re going to see some of that history.” But I wish you would just if you’re a JavaScript developer and you came, you go, oh, there’s net seven, the there’s net eight, and you don’t know all the history. It’s the negative of being a 20 year old platform is we’ve gone through the changes.

So I would tell most folks, “if you’re building brand new apps, do them on the newer .NET.” But the old .NET Framework will be there forever. It’s part of Windows and we’re never going to break those applications. And we still make subtle changes in it. A year or so ago, we ported .NET Framework to Arm64. Arm is a big thing that I’m super excited about. I’ve done a lot of work this year trying… Apple introduced the M1 Macs - the Apple silicon Macs - that have battery life that is just much better than being on an Intel or AMD processor. Last year we shipped a developer kit for developers where you could go and buy it’s a Mac mini style device, bring an Arm chip. We have some Arm laptops. They’re not the greatest yet, but they’re going to keep getting better. And I think even on the Windows side, the Arm stuff is going to be super important. And so I spent a lot of time this year, “well, what if you’re on an Arm machine and you want to publish to an x64 machine? How do you do that?” And so we’ve been modifying the docker files in VS Code. We’ll do them in Visual Studio as well. So our docker files are now cross architecture is what I would say. You can be on one architecture and publish another.

But that’s kind of the journey from .NET Framework to .NET Core to .NET. And our hope was to have just a unified platform which is just, “hey, I’m a net developer.”

Jamie : Sure and there’s a whole bunch to unpack there. But I just want to talk really quick about the Arm 64 M-chip stuff for Apple because I’m one of these people who has one of those Apple devices. In fact, I’m communicating using one right now. I’ve got this Mac Air M2 and it astounds me that I was able to just go to the .NET website, which I think is dot.net and just download the SDK and it just runs. And this is like effectively in the scheme of CPU architectures, a brand new CPU architecture and I could go dotnet new and there it is, it’s right there. That just astounds me.

Scott : I feel the same way and I am on a Apple silicon device as actually, it’s funny, I was telling some people that were staying at the house recently that I’ve been primarily using Apple Silicon for this year. And you might ask, “well Scott, why are you doing that?” And I’m making sure that all the tools that my team builds, I work on a team called the Azure Developer Experience Team. We build something called the Azure Developer CLI - azd. We build a bunch of the VS Code extensions for Azure. We build a programming framework called Dapr that helps build microservices, especially cross language microservices where you might have a .NET microservice calling a Java microservice or vice versa. And I make sure that all of our tools work on the Arm tech.

And I’m doing that for two reasons. One: I want to make sure that all of our tools work everywhere. Modern Microsoft, we don’t care whether you’re on Linux or you’re on Apple or you’re on Windows, we don’t really care. But I want to make sure all of our tools work great on Arm64 devices because I believe we’re going to see a lot more of these Arm devices in the future and I want to make sure all my tech is ready day 0. And that’s why one of the things you would struggle with today if you went to VS Code and built a net API and added a docker file to it, the docker file it’s going to generate by default is going to build an Arm container for you, and you’re then not going to be able to publish that to things like Azure because it’s going to go, “no, we want an x64 container.” It might already be live, I’ve not tried it. But we’ve done the work in VS Cde now where your debug builds will be on the same architecture as your local machine, but your production builds will actually be x64.

You can configure this in a file inside of VS Code, but we’re making the tools architecture where as well. So I can take my Apple silicon Arm device and I can build an x64 container and publish it to Azure. That’s the nirvana that we want to get to and it should be out today if you’re on the current version of VS Code. You’ve got me curious now, I’m going to try it and see if it’s fixed. But I know my team made the PRs a few weeks ago to update the docker files. And so we learned that the docker files were written wrong.

It comes back another way too, is we’ve had people ask, “hey, Azure DevOps pipelines, do you have any Arm devices there?” I’m like, “you don’t need Arm devices there . With these same new style docker files.” I did an episode of the AST .NET Weekly stand up where I talked about this with Richard Lander in detail. With the properly written docker file, you can build an Arm container on an x64 Azure DevOps pipeline or a GitHub action that’s running on x64 devices as well. So with a proper docker file, there’s a platform environment variable that you can actually use in a docker file. You can make all this stuff work. And so one of my goals is to make you successful on your Arm hardware. And as I said, “we ship that Windows device for developers and I assume we’re going to ship more Windows devices for developers."

And so it was fun all last year using a Windows Arm device too, which is just as quiet as the Apple silicon device you’re using now.

The Definition of Done

In the depths of the code where the wild bugs reside,
A programmer steps in a trusted guide.

With his eyes keen as an eagle and heart full of pride,
there’s no nasty bug he’ll let slide.

He slogs through the lines where secrets may hide,
scanning for errors….

Announcer : For all the tech enthusiasts and lovers of verse comes a poetic journey like never before. Dive deep into the world of programming, of ones and zeros, of challenges met and solutions known. With “The Definition of Done and Other Tall Tales” navigate the intricate layers of code and creativity. Whether you’re a seasoned developer or just someone who appreciates the art behind the algorithms, this collection promises to offer a fresh perspective, melding the worlds of poetry and programming in a way that’s never been done before.

The Definition of Done and Other Tall Tales now available on Amazon. Get your hands on this literary masterpiece either as a beautiful physical book or conveniently for your kindle. Don’t miss out on this unique intersection of tech and text.

Terms and conditions apply. Your home may be at risk if you don’t keep those repositories up to date. If any bugs, literal or digital, arise from using this book, it’s not on us. Ensure there is no merging without testing. Some of these poems are absolutely hilarious, others may not be - humour is subjective. If you don’t find them funny, maybe check yourself before you wreck yourself. By purchasing this book, you hand over your soul.

Your future now awaits, either as a Java developer or a business analyst. Reproduction steps found within might not resemble live or dev situations. If you’re confused, so are we. And if by any wild chance this book causes harm or any injuries, we won’t judge. But maybe give the good folks at the Darwin Awards a shout.

And just remember it’s all fun and games until someone forgets to comment their code.

Jamie : Yeah, I really like that because it feels very much like it doesn’t matter what I build on, right. I think it was your colleague Scott Hanselman who said in one of his videos, “use what you like.” I think he was talking about line endings for files and file editors. “Use what you like.” And I love this idea of being able to use whatever supported hardware I want to make the changes to the code in order to then push it and have some builder Azure DevOps, GitHub actions, whatever, build my thing, deploy it to where it needs to be deployed in the format it needs to be running in. I love that because then I don’t then need to be carrying around a 17 inch, weighs 300 pound - you won’t get a laptop that weighs 300 pounds. But you know what I mean, I don’t need to be carrying around a huge amount of equipment just to be able to make a single line change to push up to wherever to then fix the problem, right.

Scott : It’s crazy. Isn’t that though, Jamie.

Today I could take an iPad and create an entire environment with Code Spaces. I could basically just go to a URL. I can go to my repo in GitHub, click a button in the browser on an iPad with a keyboard and go make that same code change. I mean that to me is the crazy part of the world that we live in today is I have a variety of options. I’d love to come back and talk about all these developer options. There’s a feature in VS Code called dev containers.

So one of the things that I hate the most as a developer is, and you’re probably just like me, my machine is sacred. I’m afraid of putting something on my machine that I can’t take back off my machine. And so super sacred for me is being able to keep my machine exactly like I want it. And so dev containers is a cool feature in VS Code where it creates a docker container and you actually are developing inside the container. And so inside that container, I could install the SQL Server container image, I could install MySQL, postgres, redis, whatever. And I know that when I’m done, I close VS Code, all that goes away. And my machine never had a MySQL or a SQL Server or Postgres or a Redis or Grafana ever installed on top of it.

And so I assume you’re like me, I try to all extents not to do stuff that globally affects my machine, especially to work on one project. If you and I work on a project and it installs a bunch of junk in my box, I’m like not happy.

Jamie : No, I agree. I have not tried it yet, but it’s on my list of things to try because I work as a freelancer. So every couple of months, every couple of years, I’m moving from project to project. And so, like you said, I’m making global changes to my machine every time I open a different project for a different client, a different whoever. And so sometimes even small things like node version changes. Now I know that nvm exists, but I shouldn’t have to know that it exists, right? I should just be able to go, “here’s my project, figure it all out computer,” and then like you said, I close the app and then boom, all of those dependencies are gone. I love that.

Scott : That’s what dev containers does. So my team at Microsoft, we built some best practices for how to build applications for Azure. And we built the .NET one first of course, because I’m Scott Hunter, and it’s called the .NET reliable web app pattern. You can just Google that and you will find that code.

But we also just released a Java version of it. And of course that requires - you know, I’m a hands on person, so I like to test all of the stuff that we build. And the Java one is built inside of a dev container. And so literally I can go and pull the project from GitHub, open up in VS Code, tell it to open the developer container, it installs a version of Ubuntu in that dev container. It installs Java in that container, installs all the stuff required for the app to work and then, as I said: when I’m done I close the container and I walk away and my machine never was touched for that.

And so I’m like you if I’m going to do I’d want a node thing to do the same kind of thing I don’t want to use what version of node my customer wants on my local machine. I want to use the LTS but I’m happy to in a dev container use whatever version of node my customer would want.

Jamie : That’s pretty cool. I do like that because I know that there are some different attempts at doing something similar in the Linux-on-the-desktop space; but obviously that requires you to have a Linux-on-your-desktop. I think things like Fedora Silverblue but there’s a lot of stuff missing - from my most recent exploration of those, there’s a lot of things missing because my understanding of the way that it works is every single dependency you take is installed as a separate container on your machine and API, calls are then Redirected. But the problem is that the Ides don’t know that because they’re in a separate container. And so when you’re running, say Visual Studio Code and you say, “hey dotnet run”, it goes “dotnet is not installed.” And then you open a terminal and go, dotnet run, and it runs right? So there’s a little bit more work from those folks to wire those things up.

But I love this idea of just having something set up in my Visual Studio Code repo - in my repo that I’m loading with Visual Studio Code. I load it. Maybe I need to do some work, I don’t know. But it just takes over. It goes, “hang on a minute. Let me just deal with all of this for you. Here’s all of your stuff. Here’s your environment running in your container,” you hit F5 or whichever keyboard shortcut you’ve got set to, “run the thing in Visual Studio code” and it just runs and you’ve got effectively nothing installed on your machine. I like that.

Scott : That’s exactly how it works. And so if you go to VS Code and go to the extension tab and search for “dev container” you click that, then bring up the command palette and type “dev container” and there’ll be a create and the create will then ask, “you what language do you want to use?” And .NET will be in the list. You could select .NET and you could say .NET five and then it’s going to ask you what OS do you want to use? It’s probably going to default to Ubuntu and you press Return a couple of times and then today I would not have .NET five installed on my machine but using dev containers I could easily go and develop on .NET five all inside that container without touching my global machine at all.

Jamie : Right? And I think that’s the most important thing is because net Five, as we’re recording, this is out of support. So if there is an application which runs, which has that requirement, that hard requirement, “no, we’re on .NET five, we can’t upgrade for whatever reason.” You don’t want to I don’t want to have to click through all of the different pages on the .NET website to try and find the installer, to then find that it’s a minor version out and go, “no, I’ve got to go back through that loop of looking for the right version of the controls, and the right version of the software development kit and the right version of everything.” Then finally we get there. It’s taken me 2 hours. It may not take me 2 hours. I’m obviously over exaggerating. I get to that point, it’s done. And then I make my single line change. I then test it locally and push it up to source control and I’m done. But it’s taken me two and a half, maybe 3 hours to get there. I don’t want that.

Scott : Yeah. So I would tell people that, listen to this, please check out dev containers. I waited way too long to check them out. I knew they existed for a long time and just was too busy and never actually dug deep into it. And now that I have, it’s a really cool feature.

Jamie : Cool. Okay.

So I do have a question relating to open source stuff. I know that there’s a lot of - as the date of recording, there’s a lot of discourse about .NET and open source. I’m going to try and avoid that because that’s I feel like a conversation for another time and for people who are way smarter than me. Happy for you to go into that if you want Scott. So my question is essentially twofold. I’ve got a question from the community, from my good friend Scott, so this is going to get confusing because he’s called Scott and you’re called Scott, so we can do that one first if you like.

Scott : Let’s do it.

Jamie : I will, I will include Scott’s entire full background of the question in the transcription in the show notes.

here is Scott’s original question, in full

I’ve seen your articles on the .NET Blog and I’m surely in the silent majority who loves to stay informed by reading every post and never commenting, but I can’t help but notice that the comments area often contains some highly critical feedback from some pretty frustrated people. I am thankful that the comments area exists, and I applaud the Microsoft crew for responding to the tense messages so professionally.

At the scale of large projects, every design decision will make some fraction of people unhappy. How do you deal with that mentally, and does it ever bring you down? Does the anticipation of negative feedback influence the way you write articles or announce new features? Do you have any advice for open source developers just starting out on how to deal with public criticism of design decisions coming from anonymous strangers on the internet

- listener Scott Harden

Jamie : But essentially he says that he absolutely loves the fact that the .NET team, and especially you, were quite open about what we’re doing. I said “we” there, obviously I’m not part of any of the Microsoft teams. But it’s what’s going on, what’s being built and what directions everyone’s taking. And that’s pretty cool. And he also says that he notices that the comments area, which he is happy and glad exists, but he sees that there’s a lot of critical stuff there from frustrating people. “Why can’t you do this? Why did you do that? Why did you do the other?"

And first off, he wants to applaud everyone who writes those blog posts, and everyone who jumps in to maybe respond to those messages. Because obviously it’s difficult to maintain a cool outlook and be supportive and accepting of someone who’s maybe at a pain point or maybe just venting their frustration, but without responding in anger or anything like that. So I appreciate it too. And he’s saying that he really appreciates all of you for saying stuff like that.

But the crux of his question is essentially: with all of the projects that perhaps you’ve been involved in or that you’re involved in writing up, or the people that you work with and the people who work for you have been involved with, especially those in a position like yourself who are public about what’s happening. How do you deal on a personal level? And maybe this is a bit too personal for the podcast, but on a personal level. How do you or the rest of the team deal with these people who are coming to you with these perhaps negative reactions to these things? And does it ever make anyone anticipate those negative feedback when you’re about to release a new product or announce a new product?

I feel like that’s more of a “software development and being public question” than a “.NET question,” but I like it, and if you’re okay with answering it, then I’m happy to skip it if you like. That’s not a problem.

Scott : I’m happy to try. I think it’s bigger than open source. I’m not sure it’s even an open source question.

So let me give you my angle on this, which is obviously .NET is a huge project, but if you ignore .NET and as you said, just think about the entire open source ecosystem. I’m going to say step back a little further, let’s talk about social media.

So when we started rebooting .NET back in 2013, we talked openly on Twitter was primarily the main place that we as a team were. There was two places the team represented itself. I would say it was Twitter and GitHub. YouTube is part of that, as well. But you know, especially, I would say sometimes, and I’d hate to talk about politics, but in the era of Donald Trump in America, we found that these social media platforms became places for hate, places for false information, places for, I don’t know, just made up crap. The reality is, unfortunately, all these places are places where that can happen. I could go on Twitter and say, “hey, we’re going to do this new feature for AoT for .NET,” and maybe I get attacked, maybe I don’t, I’ll make it worse.

I’m going to go really deep in Jamie and get myself in trouble: If I’m a woman, my chance of attack is probably higher. If I’m a woman of color, then my chance is probably even higher. That’s the tough thing is I grew up in an era when these communities felt like they were kinder, gentler communities and they’ve gotten much harsher.

We have an entire team at .NET, in Microsoft and .NET there’s a team, we call it the 911 Community Team, and they are the part of our organization that deals with whenever one of these things kind of happens in the social media or happens in GitHub. And if people are looking for an example, let’s say that you feel very strong and that we should change some API some direction. And so what kind of happens is various people inside the team will look and go, “does this change go in the direction that .NET is actually moving in?” In many ways microsoft’s the benevolent dictator, and you need a benevolent dictator in open source project you just can’t have pure chaos because just imagine if you’re in Teams or some application, if just random buttons started showing up because Bob likes a button, Jane doesn’t like a button. You have to have some control here and so when people don’t get the way they want, sometimes it can turn nasty.

And so I said we have a team that actually looks at this because we’re also trying to prevent that hate from being in our communities. We want the .NET community, especially things like GitHub, to be safe places and comfortable places for all developers. But there is no magic answer for that. We set clear codes of conduct in our repos, and we have people in that alias I was mentioning before whose job is to make sure that the feedback and stuff in those communities is being held that direction. But I feel bad because as you said, if you’re a developer and you just happen to go fall in to go look, “hey, I mentioned this part of the networking stack,” and then you might run into one of these kind of nasty conversations and you’re like “eek, what the heck is this? I don’t know, these .NET people don’t seem that nice."

I’ve just come to accept it. And as I said, what I would tell anybody doing open source is build a code of conduct that you think and you can copy borrow from many of us that have worked on these things for many many years and just enforce them. And I think it’s kind of the negative of the world we’re in today where these social communities, because there’s no filters anywhere, can just get out of hand.

I don’t know if that’s where you were looking to go, but that is kind of my belief on it and I hope that helps.

Jamie : Sure, yeah, I think it certainly helps.

From what I understood of other Scott’s question - because there was something in there about, “do you have any advice for people who are getting into open source development or development full stop to perhaps attempt to not nullify but reduce the effects of that?"

And I think from my perspective, I think you’re right if you set those expectations from the ground up of, “we expect people who interact with this project to behave in this certain way, and to provide this kind of environment for everyone involved,” I think that it’s important and I feel like it’s necessary shouldn’t be necessary. You’re right. But I feel like it is necessary. I mean, we even have one for this podcast. I don’t think we need one, but it’s on the website. There is a code of conduct for interacting with the podcast, not for guests, but for people who might be like, “oh, I didn’t like what Jamie said on this episode, we’d better…” And it feels like a necessary step, but that it maybe shouldn’t be, but that’s my own personal opinion.

Scott : There’s lots of people in the world. Most conferences have code of conducts and I’ve been around too long and so because of that, I’ve actually heard why some of those code of conducts exist. I’ve heard about the incidents that occurred in the audiences at some of these conferences and stuff like that before. I think in most cases, if you’re doing open source, you’re not going to see a lot of that. .NET is high profile because it has millions of users and so it might see more of that than if you and I went out and wrote our own image library, or audio processor, or something like that.

Even myself, I use a really cool open source project called HomeBridge. And what that does is that takes let’s say you’ve got a ring camera and you want that to appear in HomeKit on an Apple device. It bridges that gap. And so I contribute to that community all the time and I don’t see the hate there, but I think it’s because it’s just a smaller subset of people in our case that are super home automation kind of oriented people. So I think it just depends on the scale and the size of the project. It’s just like that’s why major politics has even crazier followers and stuff. Because that’s not millions, that’s hundreds of millions.

Jamie : Yeah, I think not to belabour the point, but I feel like when you get a large enough collection of people together, the percentage of I’m worried about saying this, but bad actors. I feel like that in some respects, plays down what happens, and then in some effects plays up what happens, but the percentage of those people goes up. And with .NET being, like you said, as big as it is, you likely see that more than say, I do with one of my open source projects because there’s like five people who use it. My project, that is.

Scott : Yeah, that was my meta point, was and I feel bad that people have to see that stuff, but it is out there and as I said, there’s a whole team at Microsoft that tries to control that as best we can, but we can’t see it all. It has to be reported to us to even find out in some case.

Jamie : Let me think of how to put this: so .NET’s open source and it’s not an accusatory, but why, right? Because wasn’t everyone happy with .NET Framework being shared source and closed source? For most of us?

Scott : No, that’s… it’s interesting to think about how the world’s always evolving.

.NET Framework was built back in 2002. I don’t even think I even heard the word open source back in 2002. Open source was just becoming a thing before I joined Microsoft and I remember hearing about open source primarily from Linux. Linux was one of the things that was open source back in that era that we had friends that were looking at. But I think the big thing and why does it matter that .NET is open source? I think it comes down to Scott Hanselman and I - lots of Scots - we were actually doing a European tour back in 2013 and we were super curious. We tried to do a stealth series of meetings to go ask people what tools they were building their applications with and unfortunately it got out that we were doing this and some of the fans showed up.

We didn’t want the fans, we just wanted to hear the raw thing. We heard enough raw stuff and we had companies that told us that they were more than happy to use closed source operating systems, they were more than happy to use closed source office suites. But for the stuff they were building for their companies, they wanted that stuff to be open source. And some of the reasons that would be cited for this is well, “what if we build a .NET Five application and Microsoft in support for it? But we don’t want to get rid of the .NET five application? We want the ability to go maintain that ourselves or go ask somebody to maintain that for us for a longer period of time than the .NET lifecycle."

We had a great customer in France that runs an ad platform and they needed to tune .NET in ways that we would never tune it.

We tune .NET for the general public and there’s some knobs and switches to tune it. They run it at an insane scale and so they needed to modify the product. And so if it’s not open source, they wouldn’t have access to the code, they couldn’t build the product themselves and they wouldn’t be able to go make those custom modifications. I am happy to say that they were great people and they actually came to Redmond one time, and we actually took most of their changes, and they’re actually in the product today. So it was like they battled proved those things. But open source really just comes down to, as I said, many companies, when they build an application, might keep it around for 510, 1520 years and they need some kind of guarantee that if they had to go fix something in an out of support product, they could.

Inside of Microsoft, we take it a step further as we’re building things like parts of the back end of Azure or whatnot obviously we use open source too. We don’t use any open source that we can’t. If we use open source at Microsoft, we actually want to build it ourselves. So if we’re going to go use your Zip library code or JSON.net, let’s use a very popular net one. If we’re using JSON.net on something, we’re not going to go and download the JSON.net NuGet package from NuGet.org. We are going to have a team that goes and builds it for us. And you might ask, well, “why would you do that? Sounds crazy.” Well, what if James Newton King is on vacation for six months and a major security issue happens in JSON.net? Well, we want to know that because we’ve already built it all from source. We could fix it ourselves if we had to. And I don’t think we’re unique in that aspect. If you’re making major dependencies on open source, you probably want to have the ability to go, “hey, if something bad happened, we could do something in that space."

But that was a trend that we started seeing in 2013, was just this general kind of like… and I think the reason this happens was back in the day there was a bunch of developer stacks that went out of support and then companies were stuck and nobody wants to be stuck. I mean, it’s scary. I still talk to at least once every two months, a big customer at Microsoft will come through and I’ll be talking to them and they’re still using mainframes. So software stays around for a long time. Mainframes, that means that code was probably written in 1960, 1970. Crazy that that stuff’s still around. But I see mainframes come up in our Azure calls all the time.

But that’s kind of why we did open source. The other thing for us and .NET really surprised us, I think. We open sourced in 2014 the bits that would become .NET and then .NET seven, ,NET eight. But we get also tons of contributions from the community. And so we’re only x number of developers. And I remember when I was first at Microsoft, I had to learn how to triage bugs for ASP .MET and you would see bugs that would come through and you’re like, “yeah, we could fix that, but should we?” Meaning that we would stack rank based on priority. It’s like, “hey, this bug affects 10 million people or 20 million people. We’re going to fix that first. Jamie’s bug. Well, it’s a nice to have, but only Jamie’s complaining about it,” and open source changes that where now Jamie can go and actually submit a PR to fix the bug. It’s not as high a priority on our list and so more of those bugs get through.

We had a lot of fun during the early .NET Core days with the community helping us build the performance improvements. And so if you end up having it being an open source project with lots of momentum. Then you get all these community contributions and that really helps the product. And .NET has been blessed because we’ve had tens of thousands of community contributions to .NET over the last, since 2013, 2014. So some mix of all that stuff kind of matters. But I think the wave started with people, if they’re going to take a bet on something, they wanted to know that if the company behind what they took a bet on went away, that asset doesn’t go away.

A Request To You All

If you’re enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I’d really appreciate it if you could indeed share the show.

But if you’d like other ways to support it, you could:

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let’s get back to it.

Jamie : One of them is the mainframes, and I know at the minute, I think IBM are looking to figure out a way of converting COBOL to other languages. And I know that there’s a COBOL for net stuff because that… folks go ahead and go to Google or Bing or whatever and go look into what COBOL is and why it’s so important that we keep that code running. That’s some scary stuff.

But I like what you said about this, tou said that there was a customer who needed to tweak some things, and now that they’re able to tweak those things, those things can be put back into the source code and then I can use those things. Because there was a conversation I had, I want to say, a year and a half ago with some folks who were using .NET - they were using .NET five, I think, at the time - to make an emulator for video games. Now there’s a gray area about emulators. I’m not going to talk about that. But this developer had said essentially, “we needed some performance stuff. We put a great case towards the maintainers. They added this performance stuff, and you get it for free.” Which I think is, for me, the biggest bonus of being part of an open source community is that I, as a .NET developer, when .NET eight releases, which will be very soon. As of when this episode releases, all of those performance increases, which we can maybe talk about in a moment. I get them for free. I don’t have to do anything. I just go into my csproj, I change it from net70 to net 80, recompile: bang.

My binaries are faster, they are smaller, they deploy quicker. All of this kind of stuff happens for free without doing anything comparatively. Whereas you and everyone else over at Microsoft are doing the hard work, and the community is doing the hard work of, “how do we make this faster, how do we make this smaller, how do we make this,” for want of a better phrase, fit on the head of a pin. Right?

Scott : Yeah. One of the benefits of being a .NET customer in many cases is this: we at Microsoft run .NET at insane scale levels. You would be surprised at how big the scale that we can run this platform at. And so I’ll throw out a couple of fun things. So, Microsoft Graph, this is how you talk to the M365 back end: It’s written in .NET. 70 billion requests a day. Billion.

Jamie : Wow.

Scott : Azure Active Directory, 185 billion requests a day.

Jamie : Wow.

Scott : And so when you think about those numbers, we’re running it at that scale. And so, as you said, you just get to just use the product. But companies like Microsoft are running .NET at these crazy scales. That company in France runs it at the same types of scales as this as well. They’re one of the higher ones.

And I’ll give you examples of also their findings like that. Microsoft Graph, 70 billion requests a day. When they moved the latest version of .NET, their CPU usage went down by 37%, which means the cost of running the graph went down by 91%. Azure Active Directory when they moved to the latest version of .NET, their CPU went down 67%. Once again, cost savings. Microsoft Teams moved to the newest version version of .NET 25% CPU reduction. So we are running .NET at insane scale inside of Microsoft, and then all of our customers get to reap the benefit of that. And we have other customers that sit out in the public that are running it at crazy scales as well, and they’re making PRs into the platform.

If you had told me ten years ago that we could reduce CPUs 30%, version over version, over version. I mean, the performance delta between .NET Core 1.0 and .NET Seven is insane. So never would have ever expected those types of numbers. It makes me go, “I didn’t think .NET framework could slow when I first developed in it."

There’s another cool thing. I’m looking at a graph here from Stephen Toub, who’s one of the crazy engineers that works on .NET. .NET five had 250+ performance improvements, .NET six had 550+ performance improvements, and then .NET seven had 1000+. And so it’s accelerating. It’s not decelerating, it’s actually accelerating, which is just crazy. I can’t wait to see where it goes in the future.

I’m looking at more performance stuff for the Tech and power benchmarks. Looking at the JSON benchmark, .NET six was 999K request. .NET seven is 1.16 million requests, up 16%. This was when I knew a whole bunch about which is inserting multiple rows inside of EF Core in .NET six, that was 1.7 milliseconds. In .NET seven, that’s 0.43 milliseconds.

gRPC Java - this is an open source, this is a person who runs their own gRPC benchmarks. Java 68.9K, Go 72.5k, C++ 89.4K, Fust 96.1k, .NET 99.18k. That’s .NET seven. Those numbers are just crazy. And that’s the benefit of open source as well. And using a framework running huge workloads in a big company like Microsoft.

Jamie : Sure, I have to admit those numbers are very impressive. And I know that when I read Stephen Toub's blog posts, about 5% of it makes sense to me. And the rest of it is like, “these are numbers, I get this, but I don’t know what this means.”

Scott : Well, I think the crazier thing is: how many days does it take you to read the blog post? The .NET Seven performance blog post? It’s not for the faint of heart. It’s hundreds of pages. And as you said, you understand some of it, and some of it you don’t understand, but it’s all cool anyways. It’s like full geeky out material. He’s an amazing engineer.

One of my fun anecdotes is we were doing probably .NET Core 1, and we had done research to go figure out how many people use data sets and data tables, which was the popular way of doing database operations in the .NET framework world. And it ended up being a large number. And we were asking ourselves, “which APIs do we bring over?” That was always a hard question back in the .NET Core 1 all the way through 3 days. And we decided to bring this thing over. And I’m talking to the engineering team and they’re like, “yeah, it takes three or four weeks to get that ported over.” And then I’m chatting with Toub one night and I wake up in the morning. When I say at night, I mean, I probably talked to Toub 09:00 p.m. And I wake up at 07:00 A.m. And the code is sitting there.

And so, I mean, he’s a machine. The bigger dev team thought it was going to be a couple of weeks worth of work, or a month worth of work, and then he did it in a couple of hours. So that’s the best part of working at Microsoft, is being able to interact with the people that we have here. It’s just the David Fowlers, and the Stephen Toubs, Damien Edwards. Scott Hanselman, Glenn Condron, Maria Naggaga. I could go on and on, and on and on, and on. My favourite part of my job is working with all these crazy smart people. Jenny [Jennifer] Lawrence is a person in Azure Services. Oh, amazing.

So that’s the best part of coming to Microsoft is getting a chance to work with all these experts.

Jamie : Awesome.

So I know that there’s lots of really exciting things coming with .NET Eight, which is releasing very soon. If you’re listening to this on the day of release, it is like a few days away. But I also know that you’re very excited about AoT stuff. I’m wondering, could you talk to that a little bit?

Scott : Yeah, let me explain what AoT is.

AoT stands for… First off, before you even explain what AoT is, let’s explain how .NET works today. .NET is a JITed language that stands for just in Time compile. So what happens is, and there’s lots of benefits of this, so when you compile a .NET. Application, we don’t actually generate x64, or Arm64, or Arm32 code. We just generate what’s called IL. And then when you run the application and the cool thing about this is, because we don’t generate any of that code, it means .NET runs everywhere. So what happens is, when you boot up a ,NET application on your silicon Mac, the .NET runtime installed on your machine goes, “oh, I’m going to go take this IL, and as the code starts running, I’m going to convert it to the native machine language of my machine.” In your case, it’s Arm64. In the case of my Windows machine here, it’s going to be x64. But it means .NET can run on all these platforms because it’s not compiled to one platform.

But notice I said, “just-in time,” which means as the app boots up, part of net boots up and starts converting this IL into machine code. That takes time. That means your app is going to start a little slower. The app might run faster in the long run because in many cases, let’s say back to our C++ days, you compile that C++ code it’s compiled, it can never change in a just in time environment.

The JITt can go, “wow, you’ve run this method a thousand times. Maybe I should JIT it more optimized. It’ll take me longer to do that, but I know you’re going to run this a million times,” and so I can do that. And so a JITted language, while it starts slower, can actually perform faster than the statically compiled application in any cases.

But what are the negatives of a JITed language? Number one: it’s got a slow startup time. Number two: you have to have enough tech on the machine to compile the thing on the fly. So you have to have a .NET runtime installed that can do that. And another benefit of a JITted application, is development time is very fast. A C++ app, you have to compile the entire app statically every time you run it, that’s slow. .NET, pressing an F5 in your editor typically is a second or so.

But there’s also this thing called AoT, which stands for Ahead of Time compile. In this case, you are making a binary that can run without anything on the machine at all. So it supports what I would call self-contained. I could give you the app. You don’t have to have .NET on your machine at all. The app will just run because the app doesn’t have to JIT, it’s going to start faster. What we find is some popular programming languages, things like Go and Rust, people compare .NET to that; and so there’s always this huge spectrum of the other benefit of AoT applications is they’re smaller in size. So if you build a “Hello World” in Go, you’re going to get like a 10MB executable in .NET today, you’re going to install a 60 or 70 meg runtime and then you’re going to run your code. Wow. That’s 60 or 70 megs versus ten. So Go is popular for building command line tools today because of this self contained thing. In fact, even my team built a tool called Azure Developer CLI straight in Go for that exact reason.

So we’ve been doing AoT and .NET for a while. So if you’ve been using Xamarin or .NET MAUI, we are required in some cases to put native apps on devices. And so we actually do AoT those applications. If you’ve been using Blazor WebAssembly, that’s kind of some AoT tech as well. We’re compiling your net down into WebAssembly. And so we’ve been doing AoT all along, but it’s been kind of a fringey thing. And in .NET eight it’s becoming more realistic.

So for the first time ever, you’ll be able to build an ASP .NET minimal API and it will run AoT. And you might go, “well, why doesn’t it all just run?” Well, we all use these features called reflection in .NET. It’s one of the most used things where the code can introspect the app and do stuff on the fly. So if you do things like routing inside of our web platforms, dependency injection, they’re all using this. You can’t do that with AoT because it’s just machine code, you don’t know what the heck it is. And so we have to make libraries inside of .NET AoT aware where they can work in some of those cases. And so the team made a huge bunch of strides in .NET eight. And I’ve got an amazing slide that you unfortunately cannot see, but I’ll give you some cool examples.

So we took an application and it’s a web app and we compiled it without native AoT. And so I’ll give you an example. So this is a Linux application. Its size was 88.3 megs. When it started up, it used 235 megs of RAM. It took 182 milliseconds to start up and it basically was doing 650,000 requests a second. In .NET eight, if I AoT that, the size goes from 88.3 megs to 8 megs. The working set goes from 235 megs to 33 megs [op RAM]. The startup time goes from 182 milliseconds to 27 milliseconds and the performance stays roughly the same.

Now don’t get yourself excited and go, I’m going to AoT everything. AoTing is meant for special cases today. When you need really fast startup time, you need a really small working set. But it’s a journey in .NET. And as I said, .NET eight will be the first version where we’ve got some of the web tech working inside of this stuff and you’ll see us as new .NETs come out. We’ll keep expanding the amount of stuff that you can AoT. There’s teams inside of Microsoft that actually care about some of this stuff. It’s like maybe they’re building some super microservice that has to start up very fast or they have a lockdown machine that requires native code. But the cool thing is we’re going to get to the point where those same command line tools that you write in Go today, you could write them in .NET and get the same kind of size on disk benefits.

And in many cases you might ask questions like, “well, why is .NET slower? Why is that working set so big?” Well, our garbage collector today is greedy. When the app first boots up, we go grab a bunch of RAM. So we’re exploring in .NET eight the first time, having the garbage collector not be greedy, which will make the working sets go down. So the cool thing for a .NET developer, if you’re listening to this, is we’re always evolving .NET. Just like we talked about programming languages earlier, where we’re always looking at what trends are happening in languages. We’re also looking at things like, “well, why did you build your command line tool with Go? Oh, because the single legacy small size is important to you.” Well, we want net to be good in all categories. We don’t have to win all the categories, but we want to be a top 80% in every category, whether it’s size on disk, startup time, working set. And to me that’s one of the benefits - as we talked about the entire podcast - of .NET is we could just stop and call it good, we’re making it better every cycle. And so I’m excited for what’s in .NET eight.

If you really care about those performance characteristics in .NET eight, it might be more work to do it, but you can get there in .NET nine, more stuff will work. And so it’s kind of cool that you’ll be able to choose: do you want the JIT world? Do you want the AoT world? And they both have their pros and cons. Like the AoT world is also going to be slower to compile because we have to make native code. But as I said, we used to close every .NET conf with this: “It’s an exciting time to be a developer. I still believe it’s an exciting time to be a developer, especially .NET developer.”

Jamie : Nice. Those numbers are super impressive. Now obviously I could imagine we’re running short on time, but I can imagine that that was a specific app that was written in a specific way in that there will be things that are being used in that app that you are supporting in AoT, right. You said earlier on there are bits that are not fully supported yet. And I guess whether I want to go down the route of AoT or not will depend on whether I’m using those bits that are not supported. Right.

Scott : Right. And the level of how important it is to you.

For example, “you might say the size on disk and the startup time is so important to me that I’m willing to put JSON.net aside, and I’ll do something different instead of using that package.” I think our hope in the long run would be that I envision a future world where NuGet packages are marked whether they’re AoT safe or not. And so you could easily know what graph of stuff that you care about actually is AoT safe. Anything that uses Reflection, as I said, will likely not be AoT safe. And the developer would have to make a version that does not use AoT as well. And that’s what’s happening in .NET. The team’s looking at these things and building AoT aware versions of some of this stuff.

Unlike in the Java world, there’s something called a Graal, and that’s the Java version of being able to go do the same kind of thing. And once again, in the Graal world, there’s just a bunch of stuff that doesn’t work. And our hope in .NET is that we don’t want to change .NET. We don’t want the AoT thing to be like some 1% subset of .NET. We want it to be a much bigger part of that. And so that’s why we’re taking a slightly different approach than the Java folks are. But this matters to everybody. I think Twitter is an example of a platform that’s written in Java that was then converted to GraalVM for performance.

Jamie : Awesome. Awesome.

Well, this has been an incredibly enlightening conversation, Scott. I thank you very much for being available to be on the show, and thank you for saying that you would as well. And I know you said earlier on that you’d love to be on again, talking about all sorts of different stuff. What I would love to do if you’re okay with it, and I know I’m putting you on the spot by asking you in the episode, but I’d love to go away and play around with dev containers and do some more stuff with all the different azure tooling and then come back to you again and say, “hey, can we talk about this?” Would you be up for that?

Scott : I would love to. I would even take it further if you want to go further. If we want to do like a YouTube and actually have video and actually show us playing with dev containers and stuff like that, I don’t know if you’re open to that kind of thing. I don’t want to push you into the uncomfortable spot as well. But I’d be happy to do both a podcast and then one where we also recorded the video too, and made that available.

Jamie : Amazing. Let’s figure that out.

Scott : Cool.

Jamie : Awesome. Well, like I said, Scott, thank you ever so much for being available today and for being on the show. I really appreciate it. And I know that .NET eight when this drops, is right around the corner, so I want to wish you and the team the best of luck with all of that and everything going forward.

Scott : Thanks so much.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest, Scott Hunter, for graciously sharing his time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/review for ways to do that - reach out via our contact page, or join out discord server at dotnetcore.show/discord - all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places