Interview with Mads Torgersen at GOTO Chicago 2015

Hi it’s Mike with UGtastic. I’m here at GOTO Conf 2015 and I ‘m standing here with Mads Torgersen who talked about the future of C#. Thank you very much for taking the time to speak with me. So the future of C#, what is what’s in a crystal ball? Well they’re a bundle of things that are in the very near future of C#, which means we release in a couple of months. We just put out a release candidate for it. One being several language features for C# itself, which are all sort of in the category of helping clean up the code and remove boilerplate and so on. Pretty lightweight features, if you will, but should make everybody’s code look nicer. The signatures of funk and types and T are gonna go away? Well some things are, a lot of member declarations will get shorter. We’ll have shorthands for what we call the null conditional operator where lots more null checks become implicit. We have, you know, various little features that just make your code safer and nicer in various ways. Lots of little features. And that’s kind of not the most exciting thing that’s happening with C# actually. The main thing I think is that we’re sort of almost putting out a new kind of tech, like sort of a language engine. We call it Project Roslyn. That is, at the core it ‘s a compiler, so it’s something that understands. It’s the thing that we build our compiler with. It’s also underlying the tooling experience in Visual Studio, so it’s a very deep language understanding engine, if you will. It’s both good at compiling with high throughput to, you know, to some executable, but it’s also really good at being, sitting behind an ID and being reactive at a typing speed while answering all kinds of deep questions about the code. And it’s also good at performing custom analysis that people write for it. And this is one of the things that I think is really exciting about it is that it provides a complete and efficient API on top of the whole language that people can write to. And they can write, you know, batch static analysis over it. That’s very high fidelity. They can also write plug-ins that run in real time as you type and give you squiggles. Where they think, “Oh, this is going to take a long time.” So, you know, they can do that. Where they think that your code is wrong, offer suggestions for fixes that can be executed. So, lots of introspection type things. Sort of, you could call it compile time introspection. So, it’s that, it’s giving that ability to deeply understand the language. It’s putting that in the hands of people who want to enhance the tool in a very easy fashion. And so, I think, you can, for instance, imagine people who write APIs and share them out, whether within a company or publicly or whatever. What you could do now is to ship analyzers with your API that will help them, you know, that will help people use the API in the right way. Saying, “Don’t call it like this. Call it like this or use it in this sequence.” It can, you know, people can write very simple logic that discovers those patterns in people’s code and give them real time feedback saying, “Here’s how you should rather do it. Click the light bulb and I’ll fix it for you.” So, like, instead of just comments about deprecations, it could be like, “Oh, this method is old.” And that could be something that could be surfaced through the IDE. Certainly. Any pattern, essentially, we have this hardened immutable object model of code that we present to whoever wants to take advantage of it, want to plug in and take advantage of it. And they can look for whatever pattern they want in the code. So, tactically, semantically, following the static bindings, they can ask about all those things of the compiler in real time as advanced as they want it to and give immediate feedback to the compiler. So, to the eventual user of the IDE who’s using that plugin. Interesting. It’s actually very, it’s a very, it sort of opens a lot of doors for new tooling experiences, much more tailored tooling experiences, depending on your environment, depending on what libraries you use and so on, than people have had in the past. Interesting. And, you know, to kind of move over to some of the advancements in portability for the CLR, we’re looking at the recent release of the Visual Code and, you know, in promotion of running .NET code on non-Microsoft servers. How does this play into the Roslyn story? Well, it does play very nicely together. First of all, the Roslyn source code is in C#. Right. So, the fact that C# runs, is going to run well on Linux and on Mac means that, well, the C# language engine is going to run well there. So, now we can support, people can use that engine to support IDE integration. Visual Studio Code, for instance, does make use of that, where the way that the language engine runs with the IDE is not actually running inside of the IDE, but is running as a separate process on your Linux box, for instance. It’s a surface that runs on the box or anywhere else, but then the latency issues creep in. And then it just speaks a protocol, you know, through a pipe with the IDE and that’s a thin, long integration layer in the IDE. Is that the OmniSharp? The OmniSharp, exactly. Okay, yeah. Yes. So, it uses OmniSharp for that integration. And OmniS harp is also, it’s a great open project actually, with Microsoft participation, but driven by the community. It lets it easily integrate with a ton of different IDEs. Yeah, I’ve seen it for Vim, like hooking into OmniSharp with Vim and it kind of opens up. Right, it’s a blind text and so on. There’s a long list if you go to the website. So, enabling technology for all of that to happen. Interesting, yeah. And so, are you looking at other products, like Mono, who had been on non-dotnet runtimes? It’s because of this now open Ros lyn project. Is there more communication with Mono? Absolutely. We have this formal entity now called the dot net foundation, of which both Microsoft and Mono and many others are members. And these projects are undertaken under that foundation, if you will. So, essentially, you can think of dotnet on Linux and on Mac. You sort of think of them as the next version of Mono, if you will. The source code is primarily derived from the Microsoft source codes for Windows, but they are essentially the next version, being more robust and more tailored for sort of a modern… It brings me to even thinking about Office 365 and how it seemed like earlier resistance from the Office team to adopt dotnets, because they had their legacy code base with all the Win32 and C++ for optimized speed. But now, Office 365 seems to be really getting some serious traction. And I’m presuming that’s powered by ASP. NET. On Roslyn, are you working with some of these product teams internally to identify? There’s not a specific connection between those two things. I think they’re more expressive of a similar trend where we are happy to take our business to any platform. Well, I was just seeing more of how dotnet might be becoming more important to the overall strategy inside of Microsoft, and looking beyond the Microsoft desktop platform and saying, “Okay, we have this tool inside that’s doing this amazing stuff for ASP.NET. Let’s shore that up and make it even stronger.” I mean, is that even within any kind of strategy discussions you guys are working on? So the way to look at it is not so much that dotnet is the linchpin of everything we do to push into other platforms or to work in other places in the cloud or whatever. It’s really just one of the things that we’re opening up. We’ve stopped thinking about Windows as the only platform for things, and that goes across the board. Sometimes dotnet is enabling technology for that, and sometimes it’s something else. Some things work at the JavaScript level, cross-platform. Some things are actually, there’s a ton of C++ code that gets ported that’s a little harder to get to work cross-platform, but it’s not impossible. And so it’s not that dotnet is sort of like the thing that we’re shoving everything through or building everything on as we kind of expand into new places. Well, yeah, because I remember when dotnet came out and the original marketing push was that dotnet is the future, and then it seemed like there was kind of a winnowing of, like, okay, dotnet really is just for server stuff, but now it seems like, okay, now we’re going to expand what dotnet can be used for. Yeah, I don’t think we ever, like, thought, we didn’t think of dotnet as only for server stuff. I think it just, it’s just one of those technology choices. If you’re looking at efficiency, systems-level efficiency, you’re going to pick C++. It’s still going to be faster than dotnet or Java or whatever. If you’re looking at the reach that you can get on the web, for instance, well, you’ll pick JavaScript, even though you don’t have the same productivity and performance that you do in C#. For that vast space in the middle, C# is a really good choice. And that’s regardless of whether it’s in the cloud or on on-prem servers or whether it’s a client app. Like, if you look at our own… App ecosystem, most things are written in C# on Windows. And we don’t have a Microsoft offering. Microsoft, or Samurai is our close partner in offering C#-based development on other client platforms. So you can kind of pretty much take it in any direction you want. I don’t think we ever thought of it as not being for the whole range of clients, from client to server. It was more that we kind of focused all that energy in the Windows space only. Yeah. Well, personally, as a developer, I developed on Microsoft platforms for a decade and moved to Ruby on Rails. But now what I’ve seen, I was one of the people that was tweeting, “Wow,” when Visual Studio and Visual Code came out. And it ‘s kind of exciting to look at ways to be able to take those old skills and apply them in a broad space. It’s an exciting time to be working at Microsoft as well, because we really have opened up a lot. And we’re… Not only becoming available on a much broader range of platforms, we’re also doing it much more in the open. The open sourcing has been really exciting. The direct contact with the user community, the contributions that we get through that, both in terms of proposals and discussions and down to code contributions on our .NET Core CLR and framework there, and to Roslyn itself, the compiler engine, if you will. That’s just staggering and amazing. Yeah. It’s really great. It’s very cool. Even from the outside, it’s really cool to see that those changes taking place. Well, thank you very much for taking the time to speak with me. Thanks. That’s great. Appreciate it. Thank you.