James: 00:00 This week's episode is sponsored by our amazing friends over at [inaudible] fusion. Listen, you need to be building your apps with seeing fusion. There are amazing toolkits for any application. We'll help you go from concept to truly stunning application. Whether you're building web, mobile or desktop application, they have you covered. They have everything that you need. Navigation buttons, notifications, layouts, calendars, grids, data visualizations, editors, file format support, image editors, PDF viewers. They have everything that your application needs. They have over 145 controls ready for your applications so you're like, where do I go to get started? Go to sync fusion.com/merge conflicts. Check out all of their amazing controls for Xamarin or anything else that you're building for. They not only have great prices and a free trial, but they also have a free community license and if you're part of visual studio dev, essentially a free program sync fusion, Xamarin controls are now part of that. Go to sync fusion.com/merge conflict to learn more. They sing fusion for sponsoring this week's [inaudible]. James: 01:09 Everyone. James here, Frank can't be with us because we are alive here at Microsoft ignite 2019. Uh, the honor and the privilege has one of my best friends in the entire world, Mads targets in over here. Uh, he's, he's here with me live. This is a great opportunity because there's no other time where we've been in the same building together mans well that is almost entirely true. First of all, I'm thrilled to be here and now that we don't have offices next to each other anymore. This is the only way I get to talk to you. It's true. Uh, some people may not know, but when I came to Microsoft, I had the opportunity to work in building 25 and this was a great building because, uh, when I took Frank into building 25, he just started to drop his jaw in awe of all the names on, on, on there. James: 01:56 And there's a lot of people I didn't know that were on the.net team for a long time. And Frank is really deep, rich and ingrained and, and uh, and knowing people in the area, cause he used to work at Microsoft and he was like, you, you, you're next to Matt as your next to this person, you're next to that. And I was like, yeah, you know, just like I just thought I'd say, Hey man, how's it going? And so we were literally office, literally office mates right next to each other. Yeah, we were. Yeah. When you were allowed, I was the one who got the, uh, I remember, I remember the, you're doing a live stream one time and I could hear everything that you talking about. I think it was was Fritz or something like that on, on Twitch. I could hear everything. And actually it was like putting my arrogance, so I was like, Ooh, what's man's talking about? James: 02:35 I'm interested even though I could just tune in online. But um, yeah, now we're an hour in building 18, so we're an hour, we're floors apart I think. Yeah. And we only bump into each other occasionally, which is a shame. It is a shame. But we do get to talk about travel and about life. Uh, every single conversation I have with you is absolutely delightful. You, you, you make me want to show up to work. Oh, now I'm weeping into my microphone. That's true. That there's, there's, there's a lot of people that I love on campus, but honestly, some of the conversations I have with you are just like, wow. Like I'm just really great. Like, you know, talk and conversation. I think that is Mads: 03:09 the, um, um, people really show up. I love that. Yeah. Yeah. We always have something to say, right. Other than, uh, the coffee's a little thin today. That's true. Yeah. I love working there and I love us all being in the same building. James: 03:24 Yeah. A lot of people ask me like, you know, how, how is it going from, you know, Xamarin to Microsoft, but like, how has it been? You've been at Microsoft for a long time doing C sharp. Like how has it been? Like, can you give some insight into just how Microsoft works and what's it like to be in a.net area? Well. So Mads: 03:41 I think that I've, I've almost always been blessed with being on a team that had a good vibe on it with a few exceptions. So over the years, I've, you know, that's been a great spirit of, um, both being passionate about doing the work together and you know, instead of just, instead of co competing, you know, always helping each other out and going out of my way to, you know, to boost each other. Um, but also like that people are more than just colleagues, that we tend to become friends and get interested in other aspects of each other's lives. So I've, I've had a very fulfilling 14 years at Microsoft then I, and, and I have that now, probably more than ever. I think it is, um, wonderful place to live. And the things that I think that the opening up that we've done over the last five, seven years or so, um, has given that another has added another flavor to it where it's not just, you know, us in the bunker being open and friendly with each other, but we sort of, we are more the, the membrane to the rest of the community has thinned and this sort of more of a, a bigger interaction that is also I think generally very, um, very rewarding. James: 05:01 Yeah, I agree with that. I think that w w a lot of times people ask me about that Xamarin and Microsoft transition. I said, actually, you know, how the team works is different. I think also how I've noticed how the.net team and the C sharp team and the wind farms and WPF team work is at Xamarin. Like we, we had a product that we sold, right? It was, it was Amarin. We, we sold the product and at Microsoft, like Xamarin is included in visual studio community. It's free. So now that means that we can focus on listening to our developers. Like, what are they actually building and how can we build things to help them be more productive? Yes. So that's quite delightful and mean. You're right. I think the move to open source has been been delightful too. So that's kind of, you know, Frank and I did a really in depth podcast on C sharp eight is probably the one of the most in depth. James: 05:49 Uh, I mean we just opened the documentation and read it to be honest with you. But you know, one thing that came up is that we just launched our net core three just launched C eight and every time I go to the C sharp eight like documentation, I always just click on one feature. My mind is like blown and it was, this is the coolest thing ever. I could use this right now today. And I don't want to just go over like, well it's a new one. See Sharpie. Because people can go read docs or read or listen to that podcast. I really wanted to sit down and talk about that transition, that removing that, that bubble and how do we get closer? So I thought it'd be really neat is to talk about that transition that you've seen of how we used to build C sharp and.net. Right. And how we build it now [inaudible] so how do we actually build features for C sharp? Like how does that work? I actually don't even know, Mads: 06:36 right? Well, it starts with the sign and um, and of course the first, the first part of designing a feature is not deciding what it looks like. It's deciding whether you want it, right. It's deciding which features we should focus on. And uh, there's been quite a big transition in some ways in how we go about it and in other ways, not at all. Okay. Um, so when I joined 14 years ago, um, the, the lead designer of C sharp was Andrews Hillsburg whom one or two of your listeners may have heard of James: 07:12 big fan and facts. Whenever I see Anders like walk around campus and he'll just have like a casual lunch in the middle of like, Oh my God, there's, so, I'm like, I'm not worthy. But it seems like just a very, really laid back, really, really like delightful person. He is. Mads: 07:29 And he, uh, he sort of already already when I joined and I, I was lucky to get to be on the C sharp language design team from when I started. And, and one thing that I noticed was even that there was a language design team and they were language design meetings that Andrews was running that were, uh, very focused on the collaborative acts aspect, right? They, it was a, in those meetings that C sharp got created, like the next version of C got created now. And so there was a set of people that were carefully chosen by him. And, and the rule was when you got in that room, you did not represent your team or your perspective or anything as in a political fight or, you know, it wasn't a negotiation, it was a creative process. You got in there, we were all in it together and we, and we created things. Mads: 08:23 And that was really important because back then we did all this in deep secret, right? The first people got to hear about what was happening in CCR was way after we had done lots and lots of work and um, and sometimes, you know, way past the point of no return. And so it was really important that we used each other as sounding boards and, and had kind of, um, and it was important to Andrew's right. People think of him as his genius and he is, but I think he's the kind of genius that needs probably most geniuses really do with that. He, he needs his, um, he needs sparring, right? And he needs to collect a process because, um, multiple viewpoints really, really matters. Like having different perspectives really matters until we get a very diverse set of people, uh, in the room. And we would look at things from many sides and decide what was the optimal way to go. Mads: 09:18 Now that's still how I tried to do it. Um, and, um, the difference being that I'm not a genius and I don't have the sure-fire kind of ability that Andrews has said, he can just know whether something's going to be a success or not. He came into that already with an enormous amount of experience. And so he could, he could sort of tell, yeah, this is going to, this is going to be good, right? He was the one who could say, yeah, this is going to be a blockbuster. And he was right just based on experience but us mortals, we can't do that. And so for us to make the right decisions in that room, we really need to extend it in a way to the whole world, right? We need to have ongoing conversation where we understand what matters to developers, which things are they struggling with, what, uh, both in terms of what kinds of roadblocks can we remove from them, but also what, what would delight them, you know, what are the things that he would go, Oh, this is awesome, thank you so much. Mads: 10:15 And, um, and we have to learn that day by day by day by, and so the, the move to having an openness around the C sharp language design was one that we, we did very carefully because on the one hand we needed to open up and we needed to get much more interaction with a bigger community on a much more day to day scale rather than, you know, at ship time. But we also needed to preserve, I think what was also key to the success of C sharp, which was that there was a coherence and a, um, center of gravity around it that we didn't just, you know, do kitchen things, kitchen sink stuff, but we had shared vision and, and so on. And so having the design meetings is something that we chose to keep. And having, um, specific people get together often and discuss in real time rather than the kinds of interactions that scale more. Mads: 11:17 And that is, that does make it a little exclusive. Still not, you can't just go to the C-sharp language design meeting. Um, and it's up to us that are there to kind of bring in the other perspectives to that event. But it's, but it seems to strike a balance. I mean, I, sometimes I do feel bad about it. I want the whole world to be able to participate, but it doesn't scale. Right. And, and so, um, but that's the best balance that we've been able to strike where we still have a set of people that carry the mantle and kind of are responsible for the coherence and the spirit of seashore because there has to be some sort of, um, longterm strategy James: 11:54 for it. You know, in general, like even going into probably a C sharp or seven or C sharp aid, there needs to be this vision. Right? And inside that vision, I'm assuming there's, there's a wiggle room where there is, this is the vision that we think we have and then maybe we learned that it's not the vision or maybe only 50% of it and then we change it. So like from those, those meetings that you have, how do you take those ideas and then collaborate with the community to understand that those are actually the things that they want to do. And have you ever found that they're not the things that they want at all? Mads: 12:27 Oh yeah. Well we, we communicate everything we do on language design. Our, the sort of, um, when you say the materials, we work with the, uh, the artifacts, the documents, the, um, everything related to our design process is public. It's just in the C-sharp Lang repo on an under the dotnet organization on get hub. And so it's not, so we don't have some sort of like shadow bookkeeping and then we, then we publish it when we ready. That's where it happened, right. If we, so there's some new idea it gets, it gets logged as an issue. If we want to turn that into a proposal, then the proposal is up there and get up right away and people can chime in and they do in droves, right. And then we try to keep an eye on it. It's actually really hard to keep up. And we kind of have to, um, be a little selective or spread the work sometimes. Mads: 13:18 But, um, then we get a sense of not just, you know, how much people like it, but also a lot of creative input. Like what if you did this or how about this syntax or what if you could also do that? And, and so, but, but, but, and on top of that, we people will play in some of the scenarios. Like I wanted to use it for this. And we were like, Oh, we didn't think about that scenario. Can we? So, um, so that's sort of like the interaction point in the day to day work is the, is the get hub repo. James: 13:47 And it sounds like you have this diverse set of individuals on campus thinking about it. And then when you open it up, that diverse set of individuals that are using and even thinking about using a feature really broadens, I mean, to get that many people in a virtual room is kind of what get hub is as you create this issue and now you have the world at your disposal of a diverse set of individuals that are all using things. Like you said, you would never even think about. And it's, it's, it's curious how that works. Cause when I read the documentation I'm like, Oh, this is interesting how they documented it, but I'm gonna use a completely different because everyone codes a little bit different. Mads: 14:26 Yeah. And so I think that's a, so that's sort of the next ring out is the um, the community that participates in get hub, but you also have to keep in mind that that's not necessarily, or that is certainly not to be, to be more direct about it. A representative set of C sharp developers either, right. It takes a certain, there's a certain self-selection in being someone who goes and discusses language design, um, and um, that and, and someone, someone who is able to articulate themselves about the design of a language feature that they may not be, you know, the, um, the typical user of that language feature. And so, um, we have to make sure that we don't just adhere to that community. You typically get people who have more, maybe they have more tolerance for complexity or highly abstract things or, uh, they don't have enough, you know, there's this just a certain perspective that maybe gets over-represented there. Mads: 15:25 And so it's important that we also try to reach more broadly and try to get the buzz of what are people otherwise doing and what are the day to day problems that they struggle with. We go to events like this one, talk to a lot of people. Um, try to do some user groups and stuff where we, um, get more breadth and more diversity in the input, um, and try to bring that back as well. So that's part of being a language designer is to uh, be uh, you know, uh, to be a messenger back to the design team of what you, um, of what, what you think people feel about things and what you think is important. James: 16:03 Yeah. Cause there's the, the tone that you can get from internet conversation, but then the tone that you get from actually talking to someone is completely different sometimes even if it's the same person. Right. Yeah. Which is kind of interesting to think about. That's really, it's really fascinating to sort of hear how that that expands but also just how it expands outside of that meeting room into the open but then into all sorts of actual real interactions with the development community. That's very cool. And so when it came to C sharp eight or any C sharp feature actually like how do you make the determination when there is like a lot of pushback on a feature, but then you still decide to go and do it anyways. Like has that happened where like, and how do you make that decision? Mads: 16:50 Well there's still, I mean at the end there's still some amount of gut feel involved. I think, um, a lot of the things that a lot of the product decisions that I made in general, you can do in a very sort of data oriented way or based on hard facts of some kind or measurements or whatnot. But I don't think if lengths design is one of them, then I haven't found the way to do that. Um, there has to be a lot of God feel involved and also a little courage. Sometimes you take it take a feature like the biggest, the most impactful feature of sharp eight by far is notable reference types. And it's not a slam dunk feature because it, I think it brings a tremendous amount of value and I think any new programming language should just have that built in from the beginning. Mads: 17:39 And I, and everybody would be happy. But it's also something that in order to introduce it in version eight of an existing language, um, there's a lot of the, that adds a lot of extra hassle on that. And you know, the opt in that has to happen, the uh, the, the thinking about how do you move forward code that wasn't written with this feature and now you want to make it sort of all resilient and all that. And so there's a lot of drawbacks. That image immediately is there where it's a feature that people have to adopt and do extra work to adopt on the existing, um, code bases. And there was definitely pushback saying, Hey, we just can't do that kind of thing. Um, that is just, uh, I'm sorry we have to wait for the next programming language to come around. Right. And, and just a lot of people worried about the risk of fuel say, okay, I'm going to flip the bid on this feature because it's too much hassle for me. Mads: 18:29 And so in order to decide to do that, that was a feature that has been particularly long in the making with very early prototypes that we shipped and got feedback on and gradually iterated and got more people adopting and playing with. And, and it evolved a lot over that to try to find that path through all those challenges and all those hurdles that would actually make it reasonable and make it a good experience. And, you know, knowing full well that we might not find it and we might have to say, well, I guess they're right. We're not gonna do it after all. It is a thing that we've considered before on numerous occasions and eventually dropped, right? It's first time we thought about this feature where I was there and it's probably even been thought about before I is more than 10 years ago, but I think we found it and we were able to show, you know, uh, evidence based in users and, and based in, you know, how the feature flowed, uh, to convince people that, Hey, it's good enough now. Right? It wasn't for that, for their pushback. It might not have been so. So the pushback in this case just became part of what made the feature better James: 19:42 compromises. There's some agreement, there's some moving forward, just like sort of anything we do in life. Like when you make a decision, you discuss that decision and what's gonna work well for everyone. And in fact, that's Frank's favorite feature by the way. Oh, so mine is the mine is actually a new pattern matching um, uh, items in C sharp a do you have a favorite C sharp eight feature? Mads: 20:01 Oh, I love all my children equally. I don't, well it's funny because whenever I'm working on one of them, that's the one I love the most where I get sucked into the internal logic of it and trying to achieve maximum beauty and so on. And so I don't really have one that's my favorite. I think that the most impactful one is going to be nullable. Um, but I love many of them and I love where they landed. I think that async streams is also one that has been on the table since we did async, which is also a long time ago. That was C sharp five. Um, and um, back then we couldn't do it right. Like some of us pushed for it, for a version of it that Andrew said, no, no, that's not going to be good because it's going to be, have too much performance overhead and it's going to encourage people to do a sink in to fine grain of a way that's going to hurt their programs and so on. Mads: 21:02 And we were like, Oh, this is a [inaudible] because we really want the scenarios to work. But he was right, of course she was right. And in the meantime, now three versions later, um, we have evolved a sink and various other ways, uh, particularly at the framework level to where, but also it broadened the language in such ways that now you no longer have to use a task type that you can be as alternatives and are various ways that you can avoid allocations as T value task, which is, um, struck based. So you avoid those allocations and so on. And there'd been various optimizations and so on to a point where we said, okay, now we do have the building blocks to make a great async streaming feature. Now we can't integrate async. And for each and iterators in the language. And then we went in and I think created, we made a beautiful simple version of that, but then somebody says, Hey, but what about cancellation? Mads: 22:02 You know, cancellation tokens are this integral part of async and we managed to keep them completely out of the language. Like there's just this part of the story that's completely framework based. Like how can you, how can you wrap cancellation into all of that? And we were like, Aw, they're right. Ah, we have to figure this out. And then it was hard again, but then we found a way through that and okay, the language knows a little bit about cancellation tokens but not too much and it doesn't look too different from what people already do with cancellation tokens and so on. And we, and again, we were like, okay, we got it. And I love how it came out. I love the compromises we made I think are the right ones that make for a great feature there. That's both neat in the simple scenarios and and scales to the complex async scenarios that people sometimes use and forth. James: 22:47 Yeah. When you see it in use and the scenarios, extremist data or even I was talking with um, Scott Hunter about some use cases for it and just around like file access and like uploading big blogs. Oh that, that makes a lot of sense cause I come from the mobile world where I was like, I'm not really streaming data, but then I start to look at some other applications like stock tickers where you actually are pulling in this data in real time and in uploading big files and pulling on big files like Oh, I'm waiting for the ecosystem to build up around it, which seem quite delightful. Um, can I ask you something about async await really quick? So Mads: 23:20 it might take me a while to get back to you on a reply, James: 23:22 but I'm functioning, I'll pass the cancellation token in case it gets too difficult. Um, okay. So async await has definitely for me change everything of how I program. It's one of my favorite features in C sharp. I think one of the most powerful features of C sharp. But I also feel that new developers coming to the language, it becomes the most difficult part. Programming. Yes. So how, how do we actually go to new developers or how do you even approach new developers to explain this programming model to them as a, it's, I think it's a really hard problem because actually async await is starting to be infused in every single programming language in different ways. So how do, how do we approach new developers? Explain, explain to them this model? Mads: 24:09 Well, I think that first of all, there is the problem with asynchrony is that there's, when we did async, we talked a lot about the difference between, uh, inherent complexity and accidental complexity where, uh, when you're trying to work asynchronously, there's inherent complexity in that just just by being async this, some listen, you level of difficult that you just can't get away from. It's just part of what async means. And uh, like any kind of async, not, not even talking about the language specific model here. Just life facing J. yeah, yeah, exactly. Async in life is just hard. Um, or it has things that you have to think about that you don't otherwise. And um, but then there's accidental complexity, which is how difficult it is to write your async code. Like what barriers are we putting in the way of that? And the state of the art back then with async code was, uh, all based on passing callbacks, right? Mads: 25:12 So when you're done with that, do this, and the problem with callbacks of course, is that something that's supposed to happen after now happens in snow. The code is now inside instead of being next to, well, you know, so the, the flow of execution doesn't match the shape of the code, if you will. And you essentially get this inside out thing happening. That's the accidental complexity of it. If you enclose that whole thing with the way you sign up the call bag, if you enclose it with, um, a loop or a, you know, a try, um, and try catch or something like that, then that only applies to the signing up code, not to the Lambda or you delegate that, you pass this to callback. And so essentially all the imperative, uh, programming, uh, that, that C-sharp through its, its heritage all the way back to see that it builds on Nike, the core of how your program is busted. Mads: 26:15 You can't do anything the same way, right? That's the accidental complexity and what async was. And I think successfully was a way of putting all that toothpaste back into TUPE and saying, Hey, in an async scenario now your flow of code, like the order in which things happen is back to being represented by the [inaudible], the composition of control structures. So we took away a lot of accidental complexity with it and that I feel good about. Um, now this inherent complexity left. And then there's also some accidental complexity that we couldn't get rid of, partly because we weren't smart enough perhaps. And, but also partly because of heritage that was already is specially in the frame Mark. And we just had to know ways around how the, um, how their on-time function and around, uh, synchronization contexts and you know, various things that were partial trust, which ha, which was a big thing back then. Mads: 27:09 We had to work around how to work with that. And, and so all of these things make it so that the more you dig, the more into async, the more complex it gets. And if you get all the way down to how it actually works, if you're the kind of person who needs to understand things by how they work at the bottom, then it's, it's hideously complex. And we did our best and I don't know if our best wasn't good enough or whether that was just, you know, the constraints just conspired to make it that hard. So back to your [inaudible] James: 27:41 question. I said it would take awhile, but I'm glad it is because it's good to hear from, you know, Mads: 27:47 I have a long, uh, a long computation. You say a tasks that run and you go off and you do the computation, you come back. And that's what I'm, so now I'm coming back with a result. Um, I think that you have to explain it at the, you first have to explain the task concept, which is it's an object that represents a thing that's in the middle of happening. And you can interact with that object to, to find out whether the thing is there, what it is, if it's there or have things happen after it's there when it's there. Right. So the concept of a future or a promise, it's called a task and it doesn't have a framework. People get that concept after a little, um, after a little, you know, explanation, they get that concept. It's a beautiful concept. Um, that's, you know, it goes way back in computer science history and now the other part is, and we have a language feature that lets you interact with those with promises, futures, tasks in such a way that you can create your own delayed thing that consumes that other delayed thing. Mads: 28:57 And that's what a weight does is to say, Hey, the thing that the, the future representing my action is now dependent on that thing completing and whatever. I'm doing it to it next. And through that, that's I think, I think if you go, you can show people async code without explaining tasks and they can sort of, and if they only have to read it, they sort of can. But if you need any kind of, if you need to do anything with the code, let alone write it, like even maintain it, you need to understand what a task is as a concept. James: 29:32 That makes sense. Yeah. I think that Mads: 29:33 often we overlook James: 29:35 look that fact that, Oh, I'm just going to magically make this a task thing and a, I'm just going to add a sink away and it's like, it's okay. Just skip why this is all happening, but just kind of understand that I'm awaiting on this. I also, when I got started with uh, Xamarin development eight years ago, we were on um, um, earlier versions of C sharp that didn't have async away. So I was doing a lot of continuous and, and that concept because I had transitioned from continuous into async await it. It then stuck I think a lot with me because this is what I used to write and this is what I am writing and it's the same code. Now the, the try catching like you were talking about is different in that context. And then I went to a talk one time where someone showed me the compiled code, um, when you compile a single weight code and then like, this is what it's actually generating for you. James: 30:24 And then that blew my mind. And I think that's something that developers, I forget how to even do it now and look a find it, but it was just in a very simple WinForms application that they were like locking it with dot result or whatever, a good old dot result all the time. But that sort of opened up my eyes to say, Oh, now I see what's actually happening under the hood of saving contacts and doing this. But do you think that that you were kind of talking about that, you know, even Eisinger numerable and async streams took some, some time. Was it because of the constraints of hardware at the time? Like do you think that because hardware and processors have gotten this, that you're able to do more complex things, or is that not part of the [inaudible]? Mads: 31:04 So on the contrary, I think that, um, by the time we were doing async, we finally understood that processes weren't going to get faster. On average, they were going to get slower in this. Like if you take an average across the whole market of where do we want our code to run, then we're going to want to run it on smaller and smaller and smaller hardware. There's all the IOT stuff now. And back then it was mobile. That was a small, small thing, right? We just go into smaller and smaller. And so I think C sharp four and dynamic was the last time we made the mistake of relying on hardware getting better in the future. Um, and with async it was important that every allocation counted and you know, that would, you know, context switches and so on. There was, we had to have a focus on all of that and make sure that, um, you could do things very efficiently with it. So, but it was just that, um, figuring out how to do that, um, for the, the repetitive scenario of, um, uh, waiting again and again and again. That's something that keeps producing, just took us awhile to get all the, you know, get it all figured out. So essentially it took Steven Tobe a few years before he, uh, he created the, if he fell, he got the right types together for us. James: 32:16 Gotcha. Gotcha. Well, one of the thing I want to ask you too is C-sharp seven was a, for me, a very delight I ever released of C sharp, so very delightful release. Uh, in general, I always, like I said, I go to the documentation, I hit a button and I'm always blown away. Even I, since C-sharp six, these are up seven and C sharp seven was a fascinating release cause that was the first time that the team did point releases. Um, how was experience for the first time ever making the shift to say, Hey, listen, we're going to incrementally improve [inaudible] and why did, why did the team even decide to do that? Mads: 32:47 Right. We had a particular scenario that drove it, which was, uh, integrating span of T into the language. And, uh, we knew that the span thing was happening on a timeline that didn't line up with when T sharp, um, when the major release of C-sharp had to happen. Um, now we have different um, shipping cadences, but back then it was just like we can't, uh, we're, we're shipping C-sharp here and span isn't online at that point and we, we uh, we were not going to wait around for it. And so, um, we decided, okay, there needs to be a point release where that is all integrated into C sharp. So that was a C sharp seven two. And then since we knew we had to do it, we did sort of a practice point release C sharp seven one, which was essentially let's put a few features in that are little features that we would normally gather up and just put in the next release just to see what happens. Mads: 33:48 You know, just to work out the kinks of what does it mean to do a point release before it's really important for it to go right. You know, before we become, the thing that fails in the whole span story is I was rolled out. And so that's why we did seven one with a few very delightful little features like async main came in at that point for instance. Um, and, and then we did, um, seven two which embraced most of the span stuff. And then we realized a few things that had to be better, uh, or to complete the span story as it was rolling out on. People were starting to adopt it and we were like, Hey, we'll do another point release and we'll kinda fix those last things. Um, and um, on the whole it was a good story and I think we would be happy to do it again. Um, we are now, um, so right now we don't have an incentive to do so. We are trying hard to, you know, we, we don't even have, this is crazy games. We don't even have to be cagey about dates anymore. We just w. dot. Net now releases on a cadence that we told people about. Like there's to be a.net five next year in November. Like a year from now, it's happening. And after that year after it's going to be done at six and done at seven and on a wow, we like real, it's a real platform now. James: 35:08 You can do these things. It took us a little while and now her a real platform. It's all have it. I feel like it's sort of, I listen to Donovan Brown all the time about dev ops and how the team, like the Azure dev ops team, they're on this cadence of every three, three weeks, like continuous, just this. And like I look at Dodd and Adam's just like, even even the iterative of, you know, three.one is going to come off, or Donnette core three one, it's just this iterative over and over again. And that's sort of how the C sharp stuff sort of felt in my mind was seven, seven, one seven two is like, well, I'm just continuously getting delightful features. Mads: 35:36 But so now we have to think about when, so when do the C sharp releases happen? And, and it's fair to say that now visual studio ship cadence is no longer the dominating factor. Uh, we've just shown that we can ship a major, major version of, of.net and C sharp on M on a point release of visual studio. Right? So that's no longer a concern. We sort of divorced those things completely. Like the Microsoft proprietary product is now completely and beautifully, uh, separate from the.net platform. Um, but, but the.net releases and the C sharp releases on the other hand, those, it's important to line those up. And that sort of also what we learned with the span thing, that it wasn't good that they didn't line up. So I think that the major C-sharp releases are always going to be along with a major.net release from now on. Mads: 36:24 And, uh, and we're right now, we're definitely thinking to suit to ship C sharp nine with the next one we've done at five. And so that means we have our hands full is not going to be point to point releases between now and then, which is gonna go straight to nine. Whether we're then going to do it in the future, we will have to see, we haven't decided on the ship cadence fussy, sharp beyond that. Um, one proposal that I like, but I don't know if we're going to eventually, uh, snap there is that a major version of C-sharp ships every other year whenever Danette has a non LTS, non longterm support release, we will say that's sort of the, where there's room for more innovation and we don't have to stabilize so much. That's a good time to have a new big version of C sharp and then that's two years between each major version of C sharp. Maybe there'll be some point releases in between as necessary. So we don't, so people don't have to wait too long for features that are, um, that we could as well ship. But we'll see. I mean, that's just one model and we haven't, we haven't settled on it yet for now and just plow through and do C sharp nine and then we'll settle all that later, see if, whether, whether we go on a yearly or by yearly cadence or what happens there. James: 37:32 That's awesome. Yeah, I mean it does make a lot of sense. As a developer you want to sort of gracefully upgrade and I really enjoyed the, the 16 three point iteration. I just got so much new and awesome inside the IDE and I've been flipping on C-sharp eight flags all the time using VAR. Phenomenal. And it's fun because I'll, I'll start to refactor some code and then I'll tweet about me refactoring and then you know, someone from the team will be like, why don't you use this new feature? I was like, Oh, I didn't know. And then I see like the little triple dot and I'm just like, Oh yeah, the light it up, you know, is super fun. The last thing I want to ask you because I can't not talk about functional programming on merge conflict because that's what we're known for. We're known AMA, we're known for obviously all.net but Frank is really AI functional programming and one thing that I've seen in the world of C sharp is we've slowly seem to have adopted some functional programming. Goodness, especially around pattern matching, I guess. Is there a, what is the relationship like between like the F sharp design process and the C sharp design process are kind of both open obviously now and, and does that bringing over functional programming into C sharp developers look like? Like what was the drives for that? Mads: 38:42 Well, those are actually two different questions. James: 38:45 Yes. Okay. Let's start with the first one. So start with the F sharp C sharp collaborations. Mads: 38:49 So we uh, we do collaborate some undesigned but we, we don't coordinate design in that sense. It's very important that F sharp gets to be its own language. Yes. And the degree to which F sharp is functional is just like through the roof, more than than C sharp. James: 39:06 I mean it is a functional programming inherently, I'm sure if it's functional. Yeah. Mads: 39:10 And it should just be able to go and do, it's, it's functional programming all the way. Right. Um, now what has sometimes happened is that F sharp has gone ahead and done a feature in one way and now we come and look at a similar feature for C sharp. And we are faced sometimes with, well the way F sharp did, it is probably not the best for C sharp all week. James: 39:35 One's functional, one's not functional, so always align up I assume. Mads: 39:39 Yeah. Well it's not always that. Um, it's not always that that's the sort of a dividing line, but um, but in some cases it is if you go back again to async, um, F sharp already had an async model and it was different, very, very different from what we ended up with. And it was really that it was too functional. It wasn't imperative enough. We wanted to solve imperative programming for async and F sharp sorta did a different thing a little bit. And um, and so we had to say, okay, we do async differently from F sharp and there if sharp is now having to try to adapt to the thing that C sharp did as well as have that coexist with what they already did. And we put them in that situation a couple of times. Where, uh, another, another thing is two poles that we added in C sharp seven where F sharp already had tubals baked in. Mads: 40:26 And they had certain framework types that they use for that. And a certain way they did it. Um, and we came and said, Hey, we need a different model, two poles, we need, eh, we need two bulls to behave differently. Um, in terms of being mutable instead of immutable. Um, I guess that's the imperative programming again, right there versus the functional. And we need them to have different, uh, memory care characteristics. We need them to be value types, not, um, not allocated objects and so on, so that they are cheaper to, to create and, but then maybe more expensive to copy. Right. That was a better trade off for how C-sharp was going to adopt it. And now F sharp is they're looking at and going, ah, um, but then, uh, they figure out a way to, to, um, include value tuples as well in F sharp and design the way through that. Mads: 41:16 And so we, we make sure that those surprises don't happen when we shipped C sharp but early in the process. And, and, and is there something we can do in C sharp to, to lessen the blow of that? For instance, the ability to add your own deconstructor is in C sharp. So we're very much, uh, because they're already system doc to poll things in the world. That was the F sharp tubal type and now it can have deconstructor is and be consumed as a tuple and NC sharp as well until you show. So we did things on the C sharp side as well to integrate with that reality. James: 41:51 Gotcha. And is the drive more towards, I want to say we're driving towards TCO to be functional, but it's like we're getting some of those cool functional esque like pattern matching things. Is that more of a developer demand or like, Hey, like, you know, there's actually a different need in the, in the, in the world of.net for this? Mads: 42:09 I think it's both. Um, I, but I buddied specifically not because functional programming is cool. It's more for the reasons functional programming is cool, if you know what I mean. Yeah, that makes sense. We don't want to pander to the functional audience. It's not, that's not what you're trying to do. And if you look at how we include those functional esque features, we often change them quite a bit from what they would look like in a functional programming language. It's so that's more inspiration, um, and less outright theft. I guess we try to really make them feel like an inherent feature in C sharp. But the world I think has really evolved in a way where, um, I want to say functional programming. I sometimes say a beetle a bit flippantly that uh, history is on the side of functional programming. I don't actually mean it that strongly, but there were some aspects of functional programming that are really, uh, a better fit for the world we're in now. Mads: 43:09 Where, where data and computation is distributed so much. Um, where object oriented programming, uh, approaches everything by wrapping data and functionality up together. Um, functional programming is very much about expressing them separately, you know, and that matches very well a cloud world where you are a data world where you have your data stored for many different purposes and it's, and the functionality that you want associated with it. That depends on what domain is processing the data, but the shapes of the data have to be shared, right? And so we need to receptor rate those and [inaudible] and that's where pattern matching for instance comes in because, uh, both functional programming and object in programming is they're both big on what they each are their own solution to. How do you make functionality that is dependent on a conditional, on the shape of data, right? And in our programming you do that with virtual methods. Mads: 44:06 You say, okay, the base, I have these seven virtual methods or interface methods and I'm implementing. And then the specific type gets to say how to do those seven things for it. And if functional programming on the other hand, what'd you do is you defined the data shape in one place and then every function that takes that, so the quote unquote base type of that, um, then has a, it switches over the different shapes and, and in what the function is described in one place where deals with all the different possible shapes. All right? And it's on an optic iron programming. You have, um, you have a fixed number of operations as specified by the base type, but you can have as many derived types as you want distributed all over your code, right? It's closed functionality, open types, functional side. It's the opposite. You have the shape is fixed, you have a fixed number of different kinds of this, you know diff. Mads: 45:03 It's a discriminated union. You have seven different ways that it can look and that's specified in one place centrally. But now you can write functions over that wherever you like with the switch. So you have close types, open functionality, that's a duality of it. And the latter, the functional one just fits better with a situation where the data shapes are established, but everyone wants to write their own functionality over, you can't have a close set of functions over it. You have to have the ability to write shape, dependent behavior without being able to modify the original source code of the types. James: 45:39 That makes sense. That makes sense. That's a great explanation of it, by the way. So hats off, people can't see what I did with my hands. The hands or the hand description is very elegant that's going on in this booth. Oh yeah. And in fact, you know, I look at how um, the, the team implemented the switch expressions, especially around two pole, um, switch expressions and property expressions and switch, uh, expressions and it's very delightful. Um, I'm, it makes a lot of sense when you read it and I started to describe it to people in the booth here especially you have like an address, you have a person, your first names, last names and being able to do that or even the documentation of rock, paper, scissors, the different things that you can pass it in. And it was really elegant. I was like, wow, this is a very delightful, and I can see how it not only, um, cleans up my code and a lot of ways, but also how it sort of makes it more maintainable. It's very readable compared to tons of if statements that you would have to write previously and casting and all these things. It's a very nice I news. Great job team. Mads: 46:38 Thanks. I'm glad you think that. I mean, the idea it's not just for it to look more functional, right? It is to be more declarative and, and mortars. People often worried about terse code because it's you, if you're not used to the syntax, it can be hard to read. But the, but the good thing about terse code is that there are a few opportunities for mistakes, right? If you have a bunch of, if statements that are nested, then any little refactoring is dangerous as you move things around and it doesn't do exactly what you thought. If you have a neat little declarative thing where everything you say everything only once, um, then it's really, it's a lot harder to screw up. Yeah. And so I think you're, you're right about the maintenance thing. That's certainly one of the things that we are going for with it. James: 47:19 Yeah. I'm a big fan of all the things that you and your team do. Madden, thank you so much for, thank you. Pleasure to talk to you. Yeah, absolutely delightful. We should probably hang out more. Yeah, we will. We should. We literally are about five feet away from each other. I can't miss that. Anyways, thanks everyone for tuning in. Any final words from UMass? Anything that you want to tell the people about C sharp or how they can be more active in the community? Mads: 47:41 Um, well I think we mentioned the, um, the get hub site. Uh, so definitely, um, you go in there or in other ways interact with us, you know, tell us what you think and what's important to you. It's always, that always helps us, you know, focus on the right thing. James: 47:56 Yeah. And go flip on that C sharp eight flag and all your projects or just upgraded.net core three and you're good to go. Absolutely. Thanks everyone for tuning in. And of course also we have a special giveaway because we are recording here at Microsoft ignite 2019. They're giving away some Microsoft surface air buds. You can go to AKA dot. Ms slash podcast sweepstakes, um, before December 9th, December 15th, 2019. Um, whenever you're listening to this, um, I guess that's free stuff. That's cool. There's just a piece of paper here, by the way, that I'm reading this off of. That's cool. Thanks. Of course to Matt's for coming in and spending a delightful 47 minutes with me. It's the best 47 minutes of my entire life. I absolutely appreciate it. Of course, everyone can go on the internet to find Mads. I'll put links into the show notes. You can find me on Twitter at James mountain Magna, the podcasts at merge conflict at FM. Until next time, I'm James Monta mag. Now Speaker 3: 48:46 I'm Matt [inaudible] and thanks for listening. Peace.