Betatalks the podcast

Als lid van het .NET Core CLI and Languages team bij Microsoft, interviewen we haar over alles wat met Managed Languages te maken heeft. Wat zijn de wortels en sterke punten van Visual Basic, C#, en F#? En wat houdt ze in gedachten bij het maken van aanpassingen binnen deze talen? We praten over wat er in C# 11 zal komen en het grondige planningsproces voordat nieuwe functies worden geïmplementeerd. Zo zoomen we in op de discussie rondom het dubbele uitroepteken, ook wel bekend als 'the bang bang operator'. Verder duiken we in System.CommandLine en CLI's; wat komt er, gebeurt er en wordt er besproken? En als ze één vaardigheid direct kon leren, wat zou dat dan zijn?

Over deze aflevering, en Kathleen in het bijzonder: je kunt @KathleenDollard vinden op Twitter en je vindt de C# feature status pagina hier.

Over Betatalks: bekijk onze video's en praat mee op ons Betatalks Discord kanaal

00:00 - Introduction
01:23 - Friend of the day
05:05 - Explaining the different languages
10:36 - What to do with legacy code
14:26 - What happened with VB
16:59 - Is there increased momentum in C#, WinForms, and Net Core
19:24 - The why and how changes were made to C#
23:04 - The difficulties of managing and improving a language
37:17 - Totally random question
38:10 - Going back to system command line
45:36 - Closing

Introduction - 00:00

Rick 
Hey there, welcome to Betatalks the podcast in which we talk to friends from the development community. I'm Rick.

Oscar 
And I am Oscar. Hey, Rick, how you doing?

Rick 
Doing pretty well, pretty well, we're recording podcasts again. So that's always, always fun.

Oscar 
Yeah. Did you play around with any tech lately?

Rick 
Yeah, I actually had to create a console application for deploying several databases. And then we had to get some information in there. So we use the system of command line, which is currently still in preview. But it does actually make your life a whole lot better when you're trying to build CLI like, tools.

Oscar 
Yeah, I was at a client last week who had their own API SDK for their product, and they were using it. And I got really, like envious. Like, I didn't play around with it yet. So it's on my list of nice stuff to do

Rick 
On that everlasting list of stuff you we still need to look at right.

Oscar 
It's a proper backlog. It never ends. But yeah, it seems like it takes away a lot of complication I wrote in the past and way past. A lot of console things, but it's so much work getting all the arguments, right.

Rick 
Well have a look at it, because it actually works. Pretty awesome.

Oscar 
I really need to do that quickly.

Friend of the day - 01:23

Rick 
Oscar, who is our friend of the day?

Oscar 
Our friend of the day is Kathleen Dollard. Kathleen Dollard loves to code and loves to teach and talk about code. She is on the .NET core team at Microsoft, where she works on managed languages, Visual Basic, .NET, C#, and F#. She's always ready to help developers take the next step in exploring the wonderful world. We call code. Welcome, Kathleen.

Kathleen 
Hi, how are you doing today?

Oscar 
We're doing great. How are you? It's honored to have such a distinguished guest.

Kathleen 
Thank you very much. I'm really happy to be here. And I was super excited to hear you talking about system command line in the in the intro. And I'd love to talk more about the history of that and where we're at right now and why it's still in beta and talk about some of those kinds of things if you want to.

Oscar 
Yeah, definitely. We're all excited about it. So if you can make me more excited, I'll have something to do this weekend.

Rick 
But maybe we can first dive in a little bit into where you currently are. Since looking, looking at all of your online profiles. Yeah, to me, it wasn't completely clear yet. If you were now actually working for Microsoft or with Microsoft. So what's your current status? Where are you at?

Kathleen 
I actually work in Microsoft work for Microsoft, I'm sorry. And I've been there for about three and a half years. And I love it, it's great. As a pm, I feel that my job is to still be the representative of the community. So do a lot of I was an MVP for 20 years and did a lot of evangelism to Microsoft telling Microsoft what I thought the community needed. And that is still a big part of my job. And so, you know, I like to say I work with the managed languages team, and I work for it as well. But the Managed languages team is so many people doing so many fantastic things. And I feel my job is to facilitate leverage, expand, other people get the hard work done. And so I always feel like if I say, oh, you know, I am the pm for managed languages, which I am, I feel like, you know, it's like, oh, but everybody now that I know at Microsoft keeps, keeps the customer, the users I mean, we say customer, we mean all the open source people as well, at least I do that. But that's because I've been around for a while and it's habit. But everybody I work with keeps users at the top of their mind. And they keep they're always thinking about what makes sense. And we're certainly in a mode right now where I think we can improve how we communicate that. I think that that we've not gone we just got through a time where we didn't have a lot of really clear communications about our intention, good communications about what we were doing, how to use our features, but now why we built those features and how those features fit together. And so those are some of the things that are top of mind for me these days. So yes, I work at Microsoft, I live in Bellevue, Washington and I'm just this week starting to go back to the office. So it's great.

Rick 
Okay, well, that actually makes a lot of sense and actually explains where you're currently at. And then you work for the Managed languages, which means C#, VB .NET. And F#, at least for me, and I think for Oscar as well. C# is a well known, well known language and maybe also both of us used to work with VB .NET in the past.

Oscar 
I didn't much work with VB in the past. I think I followed Enders everywhere.

Kathleen 
Oh. Oh, so are you doing TypeScript now?

Oscar 
Also, yeah.

Explaining the different languages - 05:05

Kathleen 
All right. All right. So yeah. It's amazing, amazing, man. Amazing history for sure. Absolutely. Yeah. So we have three languages, and they're, they're different. And they're, they're different in the way that we think about and develop them, as well as in their, their native, you know, what is their face, what is the most important thing to them? So basic comes through, through the visual basic part of .NET. That comes up through a history that goes back to 1961, I think, and is a, it's a language that was designed at a time when people were trying to find the spot of where human language and computer languages intersected well, so there are still ideas of, you know, the natural language programming where you could just talk, and it'll figure it out. And that's still a long way off. Even after all these years. At the same time, we had things at that point, like COBOL, that were more towards the computer, how the computer thinks, and a little bit less how the human thinks. And basic just seems to hit the sweet spot where for now, you know, however many years going on 1960 would be like over 50 years now, for this, the basic the progressions of it through many, many, many different versions of basic, and visual basics, just one of those. And so, Visual Basic came to .NET. At the beginning, it was one of the two initial big languages back in the days, when we had a whole lot of languages. And we it's evolved, it evolved on to .NET core. But as we look at it, it's really still meets those needs of what it set out to do. And increasing surface area and changing it the way we change. C# is not something that we think is in its interest, because the people, the hundreds of 1000s of people that use VB every month, you know, we have this very dedicated base, they're using it, they're getting their job done. And if we start changing it, then we don't think that that is the best thing to do for that language. Yeah, there's a few small things I wish I could do. But it always lines up against this, you know, the surface area, and keeping the surface area from being ever increasing, which is what we do with C#. So C# is where we keep adding more, you know, we add more features, as we go along, we do have, I want to come back to talking about how we think about those features and why we pick the ones we do. But we do have this ever increasing surface area for C#, and then C#, let me get back to is an object oriented language as is Visual Basic. So these have their roots in the work of object orientation, when what we said is a principle was that it was a good thing to put data and functionality together. That's the root of C#, and I'll come back to talk about how we have moved beyond that. F#s roots are in functional languages. And I want to be really clear that when we think about functional languages, we tend to think of like, you know, something that's hard to use and fight you. And I know some Haskell, and if you're just learning Haskell, I'm going to give a shout out to my son's video on Pluralsight. Because I think it's completely awesome way to learn Haskell if you want to do that. But what F# did is said let's take those principles and let's bring them into the mainstream, let's bring them into a really solid foundation of .NET. Let's put it on .NET. And then by doing that, we just by making that statement, when folks designed F#, they said, okay, then it's going to also be object oriented, because you cannot be on .NET and not also be object oriented. So we've come back somehow that that plays out. And you know, so if they're both object, or they both functional, what's the difference? And it the core, if you look at C#, you're looking at an object, you're seeing an object, you're working with an object, and in F#, you're looking at a function, and that means that return something. And so this is the core difference between the two. And it plays out in the fact that they, they can do different things. So C# can keep growing. That's one of the things that can do F# is it's kind of it's got it's not a boundary it can't exceed, but a boundary of what all the work on functional languages through the 80s 90s and 2000s. All of that work came together to say, within this boundary, if we do these things, we can do these other things. There's a lot of rules associated with the internals, not what you do, but the internals of F# that coincide with that Functional background, which, you know, if we get chance, we can come back and talk about some of what that actually means. But there are different languages at core. And we also develop them differently, which is something that we may or may not want talk about design. But yeah, that's, that's kind of a little bit of a cruise across the top of, of our three languages. And why we have three languages, which I do understand is, you know, when one is huge, why do we have the other languages is certainly a question that we get asked. And the answer is really simple, because users want them. And in that, that comes down to being the core of it.

What to do with legacy code - 10:36

Rick 
Well, in the end, I think it all boils down to one thing that you actually stated on if I'm not mistaking your LinkedIn profile, where it says I have a soft spot for legacy code. However, dead code should be hunted down and removed as a threat to the stability and security of production systems. But other code in production, is there because it does a job. And I think that's exactly the same with VB .NET. I mean, it's there, because it does a job, it helps people get stuff done. So if that works then it's, yeah.

Kathleen 
And I would push back a little bit on the way you said, I think I know what you meant. But you said you should hunt down legacy code, we should hunt down code that is doing things that are now considered dangerous. And so that's certainly exist, we certainly want to pay attention to it. And also code that we are, we are no longer able to maintain that we need to maintain, there is somebody I know that still supports a VB six app, they may now just be able to be looking at getting that those folks to change that. But this app has now been running for. It's been running since about 1995 as a core piece of this business. And so why rewrite it, it runs a few times a year, and it's doing the job and why rewrite it. So I think that we want to definitely be respectful of legacy code. Definitely, try not to put it in a corner, close your eyes and pretend it's not there, which is really easy to do. Because if we do that, then we do risk the stability of our entire systems, if we do ignore it too much. But with that, I don't think that means you rewrite it. And you know, .NET Frank was gonna keep working if it's working for you. And, you know, we certainly think that .NET core is, well, it's just not that .NET now, but we think it's amazing. We see phenomenal improvements in performance, particularly in the web, you know, we'd love to talk about it. But you know, if you're getting your job done, fantastic. That's great.

Rick 
That's in the end, the same approach that we take. Both Oscar and I work a lot with migrating companies towards the cloud. And then in the end, it's the same approach we take there. I mean, if we ever say anything, that might sound negative about current situations or solutions, we never mean it that way. Because the solution brought you to where you are right now. So without that solution, we wouldn't have been where you are right now, however,

Oscar 
But, but also yeah...

Rick 
In future we might want to change a few things if we are going cloud native.

Oscar 
Of course, but we you we have always a bit negative feeling, or we call things legacy that are running in production right now, like code that is making money for the company. It's not like the bad. It's legacy as like history to be proud of. It's making your money, it's giving us the opportunity to rewrite some things or to grow into a cloud. So there's definitely a difference with like dead code or stuff that is indeed considered dangerous now, or we should definitely not do that. Right now. But, code that's running and that's the same I think for these, these languages, they all have their place. And definitely, the VB community is still big. But we, I think a couple of years ago, especially when NET Core was starting to learn to grow really fast. C# started to offer Rosalyn started to add all kinds of features really quickly. It felt almost like but VB is stuck. will support be dropped. People are becoming nervous.

Rick 
There was discussion yeah.

Oscar 
And was it was it stuck or wasn't just done like it?

What happened with VB - 14:26

Kathleen 
Yeah, and I don't like the phrase done because it has words, not connotations and legacy. We've used that phrase sometimes when we've abandoned things. And so for VB first of all, I think it's reasonable that people especially were nervous, because we didn't talk a lot about what we were doing and how we were thinking. And we at that point, you know, when we very first went to, to .NET, actually WinForms which is so important to the VB ecosystem. Yeah, what we're doing WinForms wasn't clear and it was it was easy to be confused at one point. And the first versions of VB did not just like the first versions of C# by the way, the whole .NET. We didn't initially embrace everything. And VB was a little slow on that it was really three, one before it started hitting its stride. And then VB has a special VB runtime. And you can always run VB code that was never a problem on .NET. The thing that the VB community has been used to, that we feel they deserve. And his special about VB is things that are in the special VB runtime. And this includes an entire system called My and so you can say my dot computer dot audio, I think audio made it we did not bring everything across, because that was steeped in the Windows API and VB on .NET. Today .NET core is cross platform. And so we couldn't just drag along some of the windows API's, we did put some of them into the WinForms. This is a VB runtime and a VB WinForms runtime on .NET. And we used WinForms as our surrogate for the Windows API, so that we were able to take those things that would be cross platform and take them separately from those things that are going to be Windows only. So that's work that we did in 3.0 5.5 3.1. And 5.0, I'm sorry. And then 6.0 I think we're pretty we were pretty done by then. We still have some places that the .NET on VB is rough. And we're working on those. And one of those is the project properties pages. They're not working right for WinForms yet, and we're still working on some issues like that. So yeah.

Is there increased momentum in C#, WinForms, and Net Core - 16:59

Oscar 
Do you also see the adaptation for NET Core or .NET? Right now, if we growing again, because what I know and I see it are all around me that daily, people are still doing few new WinForms applications and picking up VB. But is it? Do you see increased momentum? Again? Do you have those? Do you have that data?

Kathleen 
It's about it's about the same across the languages, we're not seeing in any language changing significantly in relation to the other languages right now. So overall, .NET is growing. And we love that. And C# has a little bit more momentum. But overall, it's pretty much the same across the board. Because yes, people do love it. And people love WinForms. And WinForms has been this incredible struggle. I don't know, maybe you should have somebody from that team talk about it. But WinForms had a unique characteristic in that the designer ran the actual runtime. So if you put a control on a forum, you are actually going to run that control in your design environment. Okay, well, that's all well and good when we have like this one solid platform. But then all of a sudden those controls are in .NET core or .NET. And with Visual Studio is still .NET framework. And so therefore, what do you do? And so there was a lot of out of proc work. There's a blog post on this that Khosla Feldman did. And then let's make it more complicated. So then we're gonna take Visual Studio to 64 bit Oh, isn't that fantastic? Except oops, now the framework part of things is running 64 bit. And we do have some old controls and 32 bit that just don't work right now in in Visual Studio 2022. And so this is we're working on all these problems and trying to move it forward. But that team has been just hammered by the technical differences between .NET and framework as we as we move Visual Studio forward into 64 bit, and we move the head to move the designers into framework. So it there's this very long blog post that if this is interesting to you, you can go look on the .NET blog and find out more

The why and how changes were made to C# - 19:24

Oscar 
Cool, what is if you look at the other languages, C# is moving really fast as we discussed. And there are features added there's a whole planning process around it and it's pretty open. I follow that a bit because I'm interested. But is there an end to this? Because I see some people now really trying to push the brake in the community or, almost get off my lawn kind of remarks.

Kathleen 
So I believe that's because we've done a poor job of telling our story. So one of the things we haven't said enough is, and we've said this in a few places, but we haven't said it often enough, loud enough. And we're going to kind of move some of this conversation into our docs. So people can find it and keep up, you know, long term with it. But our changes fall into three buckets. And if it doesn't go in those buckets, we kind of don't do it. And if I tell you what those buckets are, I'm then going to tell you which of those buckets you want to slow down. So the first bucket is productivity, if we think something will make it easier for you to write and to read code, or drive something in relation to making the tools better, the formatting better, something like that, then that's the first bucket. Okay, the second bucket is performance. And we definitely, especially the last three years, a lot of work around the space of performance. And the third is new scenarios. So the third is something like things that we might need to do to support Xamarin. And Xamarin. has a need to run in some environments where they relate where they interact more with Java. So we have some things that that were related to how we did some things like default interface methods and details there, they kept in mind that we also had this this broader interrupt story that we needed to do because the Xamarin Maui work. And so these are our buckets. And so my question then is which of those buckets do you want us to slow down? And...

Rick 
Like not one.

Kathleen 
Exactly, exactly.
Oscar 
Yeah, I really like the more approachable C# became, especially since like nine and ten...

Rick 
Top level statements. Yeah.

Oscar 
Top label statements like and cleaning it up with removing an artificial space. Namespaces velscope namespaces. Sorry. Global usings and it's really approachable, because you can have a one liner in C# now. When you're teaching someone to code, and I think, teaching people to code for the first time, I think that the language you use for the first time, especially to you, and now you're the or you're always sent being sent off to other platforms, like Python that are really simple. In the first go to Hello world. But you see that C# enables you now and probably also enables a lot of students to be confronted with it and try it, try something out. And next to that the just cleaning up. But there was a discussion now, for instance, C# 11. And I think the biggest discussion was about the double exclamation mark.  Yeah, yeah, yeah.  And the first time I saw it, like, well, this is going to be a lot of symbols and things when, when is the time that we're started using emojis in code, but it, it struck me, I've seen some explanations. And I've seen, I've seen examples. I've also seen it what it's doing in the using # lab, like what it's really generating, and makes a lot of sense, it will clean up code, especially if you're writing frameworks, for instance.

The difficulties of managing and improving a language - 23:04

Kathleen 
Yeah, yeah, can I get I want to just really quickly jump back for just a second to top level statements and just say one thing, a few things really quick? First of all, we do hear the people that say, I don't like that we are having internal conversations. And well, you know, we just sort of Hallway Conversations. We don't, you know, share that with the public. But we will be looking at sharing some ideas. In the future that we're bopping around about how to make it easier for you to have stylistic choices even easier today, even easier than editor what probably still based on editor config. And the other thing is, when we did that feature, we do believe that features for everybody, we actually don't do features, or at least not very often, only for new users. If we believe people would graduate beyond that. This was one we might happen. As we reviewed it, we really think most people do not need anything except a few lines of code to go from their entry point into the bulk of their application. So we think for most people, actually, it works out pretty well. And not everybody all the time. But yeah, we do think it's a broad purpose thing. And I want to get back to the double exclamation point operator, which we do call the bang bang operator. I do want to get back to that, that I wanted to just make sure that we had this notion that when we do language design, we don't set out and say, Oh, this group needs this. So we'll do this special feature for this group. We do that for performance. But we generally can hide that from users pretty entirely.

Oscar 
Yeah. For me, the top level statement is great. It also cleaned up the default template for ASP NET. A lot like the single fell approach. I see with bigger projects. It starts looking like a script a bit, but like you can optimize that and make it more readable.

Rick 
And the cool thing is it's your choice, right? Whatever you choose.

Oscar 
But you see a lot of people just always having problems with change. Especially the ones who are not on top of this thing, you show them something new. It's like, what did you do with this project?

Rick 
Why?

Kathleen 
Yeah, it's actually I think it's a really important conversation, and we're certainly having it. So if we keep moving, C# forward, we never we leave the old stuff in. And we need to for that legacy code we talked about earlier, that's so important. And so we wonder with this long arc with all this stuff underneath his heart, and it just gets big. And so we're definitely having conversations, and anyone who has thoughts can certainly send them, you know, send to me Twitter is one way to do that. To say, you know, how do we, how do we keep it from being overwhelming? And we certainly have some ideas on that we certainly work hard to have people that want to uptake the new features, do that by analyzers as much as possible, you know, we certainly think about this problem, but because, yeah, you know, it's like, there's just so much out there, and so much, oh, you know, you just look at one source of information like Stack Overflow, and you're gonna see all these styles across this entire range of, of C#, and that is challenging. And so we are, you know, it can to feel this to some people like we're moving slowly. I know, some people do feel like we're moving awfully fast. But yeah, that's a, it's a balance. It's definitely balance.

Oscar 
Why? I think it is being handled with a lot of care if I see all the notes and discussions way before this gets introduced. And I'm always a bit annoyed by the people that who come last moment when the decisions are made. And I think it's really good compromise. And I would do it differently.

Kathleen 
Yeah, well, it's, it's really actually, there's two things that sometimes frustrating to me personally. One is when somebody says or implies that we just do these things off the cuff without thinking about it. And I know how many hours of just sometimes grueling work that we do. And you know, Mads has talked about this on a language and runtime community stand up, and I think November, about how we, how we do this process, and we have a bunch of people, some of whom are LDM members, which means, you know, we're supposed to be there as part of, and then we also, you know, allow, you know, other people from Microsoft to come visit. And we, so we have a lot of input, a lot of people dedicate a lot of time, to listening to proposals and working through details. And that is closed, and it's closed, because we have a lot of bad ideas. And we definitely want to filter out a lot of the crazy. And if you look at something like we do the .NET API review in the open, and that's fantastic. But it's a review, the work we do in LDM is not review, we are doing core design work there. And that is where we go 100 directions, maybe for the five that actually come to fruition. And it's not really helpful for us to either, you know, expose our own mistakes, or to you know, or to have people wondering, why didn't you do this thing you said once you were going to do? And then we found out it was it was a bad idea. So yeah, I'm really happy with where we land, we have really good notes. And I respect very much the people that do those notes, and how they, they keep them at the I think at a good level of detail. One of the holes we have that we're I'm working with, with Bill Wagner at docs for working a plug in the future is that it's a little hard to get the simple view of our features, you can see the title of the feature, and then you dive into this, you know, sometimes grueling detail of you know, how will this affect something else? What will it change the language spec? You know, we've had more hours than I'd like to say, deciding on a particular comma. And we have not decided on whether that comma should become legal. You know, when I say grueling, I mean, grueling. For us language geek it's great, but you know, it's definitely not something for the faint of heart to get into.

Oscar 
But yeah, I think if you compare it like it's completely different, if I if I design a system and make some choices, what happens in how we store things. It's so easy to have that one off system or service I'm building and refactor it later. Oh, the naming was a bit off. Let's make the API compatible and inner workings we can completely rip out as long as my tests are still green.

Rick 
Yeah, now try a language.

Oscar 
Try a language. That is that is a choice for life.

Kathleen 
It is it really is. And, you know, and we also think a lot of how we communicate. So there's two problems around the bang. Operator. One is that, in retrospect, I don't want to, I guess I don't know whether they should blame us or not. But a lot of people don't understand no reference types themselves. So if you enable nulls, you're enabling static analysis. Static analysis is by almost by definition. And certainly by the, the boatloads of academic research that's been done is imperfect, we you cannot do perfect static analysis. And in our case, we go one step further, because we have issues around our boundaries. So when something comes in, we don't know if it's a null or not. And even though we can tell the world, it should not be enough, that does not say the world is not going to give us at all. So we have this, these situations where it's not enough to just enable knows, and then live happily ever after. There's ways that can still go wrong at runtime. And so we there are places not everywhere, there are places that it's logical to do still a check for nulls. We strongly believe it should not be everywhere, it will hurt your performance. If you do it everywhere. It's only a few instructions. The instructions, if you'd looked at # lab are the runtime told us what to do. I mean, they said this is the fastest way you can do it. Steven Tobin, you know, we have brilliant people over there that helped us to get that work, work in place. So it comes down to really kind of a couple of problems, one of which is some people really wish no reference types could be perfect. And it we just kind of run into physics there. So you know, it's not going to be perfect. And then the second thing is we really struggle with the syntax, and the syntax we've thrown around other syntaxes people have given us other syntax. And we are trying to balance this reality where when you see something new, it will always look weird. So you see these two exclamation points. And you're like, why is that in my code? What is that telling me? Okay, that's great. So in two years, are you still going to be thrown off by that? Or is this just going to be part of the way you think about the code? The alternatives are things like and is example putting in a new keyword? And something like a, throw a null, not null, some sort of a word that either that probably precedes the parameter, and we're talking about parameters to functions here. I wasn't clear enough on that. So that takes up more space in your code, and that we really come down to questions around what is the cognitive load short term and long term? What's it for a new user? What's it for an experienced user? You know, is this is this important when you're looking at the logic of your code? These are this this really deep questions, and we're asking, and we have we have a lot of we put it out early, because we want feedback that we push to get this feature into people's hands, because we knew that we were going to have some, some questions on it. So we're super glad that it's out there now. And I said, there were two things that annoy me. And I didn't get to the second one. And the second one is, I love every single user. And I'm glad people have opinions. But honestly, if you haven't tried the feature, could you just hold off till you try it? Because I mean, it's just like, just please try it. And then see what you think and try it for a little while. And in the knee jerk reaction of why does it no reference types work the way I want it to? Or why is it two exclamation points before you actually start typing before you actually start being in it? That can be frustrating sometimes, because it means that people that that speak quickly, make it harder for us to hear the people that actually used it and thought about it. And we work hard not to say Oh, well, the people who thought about it agree with us. And the people who didn't think about it yet don't agree with us, we really work hard not to that. And so we're so that's the process that we go through. And it's, we care a lot about it. So yeah, it's and there's other stuff coming in C# 11. We just started with features that we wanted to get out early, which include collections. We did some collection patterns, and we're doing the no type checking is the name of this feature. And then we have a couple of other things that are coming in and then anyone who wants to know what's coming. I believe this will be very direct for you. If you search for C# feature status, or C# Roslyn feature status, you'll go to the feature status page, every feature that we're currently considering working on for C# 11 is on the list. They may not all make it. And you can go jump off from there into proposals, deeper conversations. C# line has discussions on these. So yeah, we're the conversation we can have with community is the greatest gift of open source, it is fantastic.

Rick 
We will make sure to add a link to that feature page, because I think that's a good reference for people who would like to look at that. But I think that's probably the most important reason for the double exclamation point was the tweet that you retweeted, I think a week or two ago, where somebody had a class Chitty.

Kathleen 
Yeah Chitty, Chitty Bang has to happen. I just have to have it. Right. So yeah, I don't know if we'll land on that syntax or not, you know, and one of the reasons that we do behind closed doors, this conversation is that it is it isn't, I will tell you that it is not universal in the LDM, that that syntax, is the correct syntax. What I will tell you also is that we do not want that to be about I trust him over her or her over him. And it's not a popularity contest. And it's so we really do make an effort to say that when we are talking publicly, we're talking about the opinion of the LDM. And my opinion in this conversation does not matter. And so that everybody does that Mads does that everyone does that. And I didn't shout out to the, to the language designers when I was talking about language design. And so I do want to shout out to Mads Torgussen, and, of course, Anders Houseberg, who we mentioned earlier, who does still do review over C#, and then Don Syme does an amazing job as the benevolent dictator for life. If you go to Wikipedia, you will actually be able to look up the list of who is considered a benevolent dictator for life. And you'll see people like Greta Van Rossum on Python and downtime on F#, it's a very efficient way to do language design. But C# is not. Mads is definitely the leader of a collaborative group. And that's how we do C#.

Totally random question - 37:17

Oscar 
Hi, Rick, do you know what time it is?

Rick 
Is it time for a totally random question?

Oscar 
It's time for a totally random question.

Kathleen 
Okay

Rick 
Kathleen, if you could learn one skill instantly. What would it be?

Kathleen 
Oh, wow, that is fantastic. I'm gonna say to play the fiddle well. I play it badly, and, you know, a fiddle can be a very dangerous instrument that can sound really bad. And so I'm gonna say if I could learn one skill instantly, it would be to be a competent fiddle player. Maybe not as good as Steve Martin or somebody like that. But a good fiddle player. Yeah.

Rick 
Nice. But you do play?

Kathleen 
I do play I play badly. Yeah. I try. I annoy my dog. Yeah.

Rick 
As long as it's only the dog.

Kathleen 
Anyway, yeah. And my teacher. Yeah.

Going back to system command line - 38:10

Rick 
So you wanted to go back to system command line, right? Because I think that's a nice closing, we started, we need to end there. Right?

Kathleen 
Yeah. So I'll give you a quick a quick history on this. And so back, you know, three and a half years ago, whenever, after I led the effort for .NET. Initially global tools, and now they're just .NET tools, because we have both local and global tools. So when we first did that, I was so excited, you know, new at Microsoft, my first big feature, and I sat down, I created some and I'm going wait, wait, right, I am spending more time writing a very bad parser than I am doing the actual work. So let me go look for a parser. And this is going back in time. And I realized there's been a lot of parser of evolution across the board since then. And it's like, there just really wasn't one that did what I wanted. So there was certainly some there. But strong typing was an absolute requirement. I wanted features and blah, blah. So I was sad. And I went to Dr. Johnson Carrera. And he said, Well, this is really a big problem. And we know a lot about this from doing the one in the CLI and the CLI will eventually need to evolve and blah, blah, but we had really hard time getting support from management. So it has taken so long, because here's this very grown up project that has been largely a labor of love. From a series of people Kevin best out of Spokane has contributed a lot as well as John but a lot of it's been a solo project. And now we've grown up and this delay has had this this amazing synergy in that we're hitting, getting ready for our GA at the same time that we have other things happening. So for example, we would have gone out with something that was very dear To call to trim. And now that trimming is becoming more important than we are right now making some cuts in system command line that we don't think people will be affected by that takeout. Some rarely use things that got in the way of trimming. We've also done some work around performance. And so the performance is now getting to be very, very good. And so this work was probably not have been able to be there had we gone GA even a year ago. But right now, we have found another thing that we need to cut for trimming. And so it's something we don't think people are using. It was to support a scenario that we have dropped. And so we have one more beta to do, we thought we were done. But we have one more beta to do. But we are, we're very, very close to that. And I am very proud of that work, it is a full featured parser. We can, we can put it up against just about any parser on any ecosystem, in terms of features. And now that that is in the CLI. Chad has skin in the folks on .NET new and .NET CLI have really there's some really good things coming in .NET, seven, around improving some SDK, CLI behaviors. And .NET new is really going to be fun and exciting. We've got we've really they've done amazing work on tab completion, they're on getting rid of dash list, it will still work if you need it. But we're not going to support that a new list instead of .NET new dash list. And so there's just a ton of stuff that's come out of that effort, as well as the fact that the initial nightmare I had of every .NET tool having its own parser and especially the tools inside Microsoft because, yeah, okay, it's extra work. Okay, that's a problem. But the really big problem is had we not nailed a single parser. Every tool would have different CLI behaviors, different behaviors around tab completion, different behaviors around default, different messages, if you messed up something that was required. If you put a string and where integer was expected, all of that would vary tool over tool. And by nailing it with one, core parser that by default, gives this consistent experience it gives you help for free, it gives you tab completion for free, it gives you this long list of things. And every one of those things. If you choose to take the default, then you're just like other .NET apps. And that is a really good place to be. And I'm really proud of the work we did to get here.

Rick 
Yeah, I understand. But does that mean that this is also used by for instance, CLI's like the AZ CLI?

Kathleen 
No, it's not and it, there's a couple of reasons for that they have some different needs. And so it is it is not right. It is not at least in the current versions. And we actually kind of we're not, we're not pushing it across all of Microsoft. It's really the in part of the reasons is that we've really just got our performance story in order recently. And so there's a lot of there's also, what is such a difficult CLI that is just really, really a hard CLI. So there is so much in there it is so deeply nested that yeah, it's you know, certainly when we were looking at guidelines for CLI, which we will, we do have in place that I didn't mention the system command line, one of the things we've done moving into g d GA is Docs. So we have good docs and PR right now. They're amazing. And they do include suggestions for designing your CLI. So I'm super excited about the work that Tom Dykstra did on that. And it's just it's amazing work. So I'm really happy. But yeah, so if you go into that, I mean, the system command line is, is really, it's tuned to parsers of a reasonable size, and certainly up to and including all of the .NET. SDK, CLI, the CLI, and it can do things that are bigger, but it really wasn't ready to do that in a performant way when they were designing the Azure, Azure CLI. And there's still some things you might do with the CLI like that. That, for example. The this is an example of this, because I know I'm talking about stuff that people generally don't think deeply about. But why would you I mean, it's a parser, for goodness sakes, but there's kind of two approaches you can take to a parser one is to be rather static, and one is to be dynamic and figured out as you go and system command was actually static. If you build in general you can go beyond this, but its default is to be static. So you build your entire A CLI which works really well for things up to and somewhat beyond the size of the .NET. CLI. But if you go to the Azure CLI, I don't know what they've done. But given the way they extend that their extensibility works within, you know, every time there's new service, you need something new, that I would guess that they, they may well not be doing a static, a static. So it's very fast to do a static straight. And that's why we do it for the size that we're at. But if you get very large, then you may not want to be doing that.

Closing - 45:36

Rick 
There's so much information. And there's so much coming that I feel like we could talk for hours on end.

Oscar 
Yeah, I love talking about this. Because normally you indeed what you say you don't and you shouldn't maybe think about all these things under the, under the hoods. But it is so much fun to figure out. What work goes in here and all the details. So, really love your excitement.

Kathleen 
Yeah. And if you want to take a look at it, I think what I think is a nice, a nice repo for an open source repo, we've got really good tests, which actually allowed us to do the performance work is that you know, when we when I was sitting here, did that work picked it up? He's like, Oh, I got tests. This is great. And so he could be really radical, because he had this really good, good cadre of tests we've got I'm happy. I'm really happy with that quality side of things as well.

Rick 
Thank you so much for all of these lovely insights.

Oscar 
Thank you for being a guest.

Kathleen 
It's been so much fun. So I really enjoyed it.

Rick 
That's cool.

Oscar 
Thank you for listening to Betatalks the podcast. We publish a new episode every two weeks.

Rick 
You can find us on all the major streaming platforms like Spotify and iTunes.

Oscar 
See you next time.

Rick 
Bye.