Latest / DevQuestions with Tim Corey / 261. Inside the Mind of Anders Hejlsberg

Transcript

261. Inside the Mind of Anders Hejlsberg · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: We have code bases in Microsoft that are upwards of So when you were building C sharp, you wrote the compiler in C sharp?
• 0:08
  SPEAKER_00: No.
• 0:09
  SPEAKER_00: What goes into building a new language?
• 0:23
  SPEAKER_00: Welcome to a special episode of DevQuestions.
• 0:26
  SPEAKER_00: I'm here at Build with Anders Heilsberg.
• 0:28
  SPEAKER_00: Anders, welcome.
• 0:29
  SPEAKER_00: Thank you for being here.
• 0:31
  SPEAKER_00: If you're not familiar, Anders is kind of the founder of C Sharp.
• 0:34
  SPEAKER_00: We're primarily a C Sharp channel, and so you know, we want to talk to you more about that.
• 0:39
  SPEAKER_00: But let's get started with, you know, what goes into building a new language?
• 0:46
  SPEAKER_00: I'm sure it's not much.
• 0:47
  SPEAKER_00: It's probably pretty simple, but you know.
• 0:49
  SPEAKER_02: Well, I think, first of all, like knowledge of a lot of other contemporary programming languages, because we all sort of stand on the shoulders of giants, right?
• 0:59
  SPEAKER_02: Every new programming language eventually is 90% not old, uh not new, right?
• 1:05
  SPEAKER_02: Because you've got to have, you know, expressions and you gotta have this and you've got to have a way of just you know defining types and so forth, right?
• 1:13
  SPEAKER_02: Um so I think it's important, first of all, to have a deep and solid understanding of how languages work and their history and and so forth, and the different families of programming languages, you know, functional versus object-oriented versus procedural and and and so forth, right?
• 1:29
  SPEAKER_02: Um and then I think there's uh there's both there's both science and art in in creating programming languages.
• 1:38
  SPEAKER_02: I mean, there's an enormously long history, you know, like the compilers go back as long as computers, pretty much.
• 1:46
  SPEAKER_02: Um and so there's a lot of established science around how you construct a compiler and and and a programming language, right?
• 1:54
  SPEAKER_02: Um there's a lot of theory around semantics and type systems and and and torn completeness and and whatever, you know, so you sort of gotta master that.
• 2:06
  SPEAKER_02: But then there's also sort of an art of making it feel right to code in.
• 2:11
  SPEAKER_02: Okay.
• 2:11
  SPEAKER_02: Do you know what I mean?
• 2:12
  SPEAKER_02: And and and and and that one is is like harder to teach, I would say.
• 2:18
  SPEAKER_02: It's more like you you know it when you see it.
• 2:22
  SPEAKER_02: Kind of that definition.
• 2:25
  SPEAKER_02: But it comes probably comes from having written a lot of code and going, This I don't like.
• 2:29
  SPEAKER_02: This does not feel right to me.
• 2:31
  SPEAKER_02: If if I had my own language, this would this would not be the way it was done.
• 2:35
  SPEAKER_02: Right.
• 2:36
  SPEAKER_00: Which you've done a few times.
• 2:37
  SPEAKER_02: Which I have done a few times now, yeah.
• 2:40
  SPEAKER_02: Although uh C sharp was the first language that I actually designed, right?
• 2:46
  SPEAKER_02: Okay.
• 2:46
  SPEAKER_02: I implemented Turbo Pascal, but Pascal was already a defined language defined by Niklaus Viet.
• 2:53
  SPEAKER_02: Um and so I wrote an implementation of of Pascal, and then Delphi was sort of a follow-on to that, right?
• 3:00
  SPEAKER_02: But C sharp was yeah, ground up.
• 3:03
  SPEAKER_00: Um so what were the initial uh thoughts around C sharp?
• 3:09
  SPEAKER_00: Why build C sharp?
• 3:10
  SPEAKER_00: What were the initial goals that you were looking at?
• 3:14
  SPEAKER_02: Um I think, well, we were building a new runtime platform, a new modern runtime platform uh called.NET.
• 3:22
  SPEAKER_02: Um which it was it wasn't called.NET at the time, but it was eventually called.NET.
• 3:27
  SPEAKER_02: And we knew that we were gonna have memory safety and garbage collection and exception handling and bytecodes and a whole bunch of concepts that we wanted to capitalize on to make programmers more productive.
• 3:40
  SPEAKER_02: Um and then also at that time, uh, and we gotta sort of rewind now to the late 90s, um, we sort of had two contemporary programming stacks at the time.
• 3:51
  SPEAKER_02: There was Visual Basic with rapid application development, uh and then there was C for you know like power and expressiveness and native code and so forth.
• 4:03
  SPEAKER_02: And the odd reality of the time was that everyone really wanted a little bit of both of those worlds.
• 4:13
  SPEAKER_02: They wanted the ease of use of Visual Basic, but with the power and expressiveness of C, right?
• 4:19
  SPEAKER_02: And they wanted it on a modern platform as opposed to Calm and Olay and all of these, you know, like fairly low-level infrastructures we were building stuff on at the time.
• 4:31
  SPEAKER_02: Um and so that was sort of the marching orders for C sharp, you know.
• 4:35
  SPEAKER_02: Okay, create a programming language with the power and expressiveness of of Visual Basic, but the uh sorry, with the uh ease of use of Visual Basic and power and expressiveness of C ⁇ .
• 4:46
  SPEAKER_02: And and we we knew from the get-go that we wanted to um appeal to the curly braces crowd, if you if you will, and that sort of be rooted in C, right?
• 4:56
  SPEAKER_02: But but but still we definitely wanted to capture some of that make it easy to write an app.
• 5:04
  SPEAKER_02: Don't bother me with a bunch of ceremony all the time and and and so forth.
• 5:08
  SPEAKER_00: So yeah.
• 5:09
  SPEAKER_00: Excellent.
• 5:09
  SPEAKER_00: Yeah, yeah.
• 5:10
  SPEAKER_02: Now, I mean it's been what twenty plus years since that's well the first uh actually we're we're coming up, I think June of 2000 was the PDC where we the professional developers conference where we first released or uh announced C sharp and gave out the first preview beta copies twenty five years.
• 5:31
  SPEAKER_02: Believe it or not, it's yeah, it's amazing.
• 5:33
  SPEAKER_00: That's a long time for a language.
• 5:35
  SPEAKER_00: Well, I mean i it's just true that it's a long time.
• 5:39
  SPEAKER_02: It's actually it's not even that old of a language, right?
• 5:43
  SPEAKER_02: I mean, my gosh, you look at that we just we were just talking of Visual Basic and C, right?
• 5:47
  SPEAKER_02: And like Fortran and COBOL and what have you.
• 5:51
  SPEAKER_02: It's mid-age, I would say.
• 5:55
  SPEAKER_00: Gotcha.
• 5:56
  SPEAKER_00: So so in that, I mean, looking back at what you started with in your your original aspirations for C sharp, um, do you think that you know that that's evolved over time, or has a core tense really stayed true to C sharp?
• 6:12
  SPEAKER_02: Um I think I mean from the get-go, we designed C sharp to be an object-oriented programming language.
• 6:25
  SPEAKER_02: Uh, and those are sort of the core concepts, right?
• 6:27
  SPEAKER_02: Classes and inheritance and interfaces and what have you.
• 6:30
  SPEAKER_02: We had some new concepts in there that hadn't really seen first-class treatment in programming languages before, like properties and events, and you know.
• 6:38
  SPEAKER_02: Um I think over time we have adopted a lot of influences from functional programming languages.
• 6:46
  SPEAKER_02: Like when we got to C Sharp 3.0 with Link, uh, which was really sort of an application of I'd say applied functional programming patterns, right?
• 6:56
  SPEAKER_02: Sure.
• 6:56
  SPEAKER_02: Um we got Lambda expressions and and sort of the ability to dot together, you know sequences of operators, right, in a fluent style, you know, that that that that we didn't have before.
• 7:11
  SPEAKER_02: Um so over time it it has incorporated more, and we've learned a lot from functional programming languages, in particular from F sharp, you know, which is uh sister language on on the on the platform, right?
• 7:24
  SPEAKER_00: Um so do you see you know the next twenty-five years of C sharp um big changes or more a a gradual changing of how it works?
• 7:37
  SPEAKER_02: It's gonna be gradual because you know, like every language has a a lifetime arc, if you will, right?
• 7:43
  SPEAKER_02: Version 1.0 is a total green field.
• 7:46
  SPEAKER_02: Lots of things get put down, then 2.0, 3.0, you're sort of filling in the gaps that you didn't get to in 1-0.
• 7:52
  SPEAKER_01: Yeah.
• 7:53
  SPEAKER_02: And at that point, you are now sort of on the longer asymptote, I think, of, you know.
• 7:59
  SPEAKER_02: You gotta think more carefully about what you adopt because otherwise it just becomes a kitchen sink language, right?
• 8:05
  SPEAKER_02: And and and and you gotta you gotta you don't want that.
• 8:08
  SPEAKER_02: And you can't fundamentally change the nature of the beast.
• 8:11
  SPEAKER_02: I mean, like, like I said, C sharp is at heart an object-oriented programming language.
• 8:16
  SPEAKER_02: We can add functional programming construct constructs, but we can't make it into a functional, first class functional programming language, you know, because they they go a whole different way typically in in in in getting to their solution space, right?
• 8:31
  SPEAKER_02: So I think it's gonna be more gradual, but I think there's still plenty of evolution left that's possible.
• 8:37
  SPEAKER_02: Absolutely.
• 8:38
  SPEAKER_02: And and I I still participate in the um the design of the language, only more as a as in the we have the language design review board that meets like every month or every two months to review proposed new features and get feedback and ideas and you know, so yeah.
• 8:58
  SPEAKER_00: Some more management.
• 8:59
  SPEAKER_02: No, no, no, no, no, no.
• 9:00
  SPEAKER_02: It's purely technical.
• 9:01
  SPEAKER_02: I don't do I have never had people report to me, and I never will, so I am not a manager.
• 9:08
  SPEAKER_02: I am I am purely an engineer.
• 9:10
  SPEAKER_00: Excellent, yeah.
• 9:11
  SPEAKER_00: Excellent.
• 9:12
  SPEAKER_00: So yeah, looking at C sharp and you know the uh the breadth of the language, there's a lot that has grown and matured over time.
• 9:23
  SPEAKER_00: Um and one of the things looking at from a more kind of brownfield type uh experience is the fact that you can't just take things out.
• 9:33
  SPEAKER_00: You know.
• 9:34
  SPEAKER_00: So there's things in there that maybe you did things differently in the future, but you have to leave in for the past.
• 9:42
  SPEAKER_00: How does that affect that decision-making process going forward looking at things saying we don't love this?
• 9:48
  SPEAKER_00: Right.
• 9:49
  SPEAKER_00: But we can't just rip it out because of existing customers, existing applications.
• 9:53
  SPEAKER_00: Exactly.
• 9:53
  SPEAKER_02: Yeah.
• 9:54
  SPEAKER_02: No, and I'm I'm glad you bring that up because a lot of languages try, you know, to rip stuff out.
• 9:59
  SPEAKER_02: Um and it never ends well.
• 10:01
  SPEAKER_02: I mean, at least not if you have a user base, right?
• 10:04
  SPEAKER_02: Right.
• 10:05
  SPEAKER_02: I often joke, show me the perfect programming language and I'll show you a programming language with no users.
• 10:10
  SPEAKER_02: Because that's the only language that can constantly change and and and be perfect, you know.
• 10:15
  SPEAKER_02: Once you commit to something, it it both becomes a feature and it becomes baggage at the same time, right?
• 10:23
  SPEAKER_02: Because if you then discover, oh, there's actually a better way and whatever, well now what?
• 10:28
  SPEAKER_02: And I think we we try to evaluate new ideas on sort of I I I have this, it it's not at all a scientific method, but but I I often say, you know, every new feature you you propose in the programming language starts out with minus 500 points.
• 10:46
  SPEAKER_02: And now it has to just win 500 points just to get to a point where we would even consider putting it in.
• 10:52
  SPEAKER_02: Because adding anything new adds aggregate noise and more learning curve and whatever, right?
• 11:00
  SPEAKER_02: And I think the world is guilty of shipping lots of minus 200 pointers.
• 11:04
  SPEAKER_02: Do you know what I mean?
• 11:05
  SPEAKER_02: That's yeah, it made it better, but but it also it was it ends up this cacophony, right?
• 11:11
  SPEAKER_02: So often our job is to just go, you know, we'd love to do something in that space, but it's not ready yet.
• 11:19
  SPEAKER_02: It's not it's not in positive point territory yet.
• 11:23
  SPEAKER_00: Um so actually speed is a negative in a lot of ways.
• 11:28
  SPEAKER_00: Going too fast means cause too much chaos.
• 11:32
  SPEAKER_02: Oh, exactly.
• 11:32
  SPEAKER_02: Yeah, and then you're gonna ruin it for yourself because like you said, you can never take it out.
• 11:37
  SPEAKER_02: The minute you put it in, someone will use it.
• 11:39
  SPEAKER_02: And now if you try to take it out, you break their app, right?
• 11:42
  SPEAKER_01: Exactly.
• 11:42
  SPEAKER_02: And if you try to like come up with compiler switches to enable and disable, then you make the learning curve even bigger, right?
• 11:49
  SPEAKER_02: I mean, and so you just gotta be real careful.
• 11:52
  SPEAKER_00: Gotcha.
• 11:52
  SPEAKER_00: Yeah.
• 11:53
  SPEAKER_00: Well that's the thing that I mean we look at you know the change company C Sharp 14 or you know, on down the road, and it seems like their tweaks and their changes rather than this massive new feature is massive new area.
• 12:07
  SPEAKER_02: It's it's all you can do when you're as established as C Sharp is, right?
• 12:11
  SPEAKER_02: I mean, if you're like in the what are we in the top five programming languages in the world or thereabouts, right?
• 12:16
  SPEAKER_02: I mean it's like yeah, you don't get to it's the responsible parts of the foundation out at that point or or or build new things on top of it, you know.
• 12:27
  SPEAKER_02: It's it's just steady as she goes.
• 12:29
  SPEAKER_02: Sure.
• 12:30
  SPEAKER_00: Yeah.
• 12:30
  SPEAKER_00: So when you were building C sharp, you wrote the compiler in C sharp?
• 12:36
  SPEAKER_02: No.
• 12:36
  SPEAKER_02: No.
• 12:37
  SPEAKER_02: No.
• 12:37
  SPEAKER_02: Okay.
• 12:38
  SPEAKER_02: Not the first one.
• 12:39
  SPEAKER_02: Okay.
• 12:39
  SPEAKER_02: Uh the first one was it was written in C.
• 12:42
  SPEAKER_02: Okay.
• 12:43
  SPEAKER_02: Or as I sometimes say in C, because we we didn't use all of the features of C.
• 12:49
  SPEAKER_02: But we didn't have a compiler.
• 12:52
  SPEAKER_02: Right.
• 12:52
  SPEAKER_02: And so so we didn't so there was no bootstrapping that we did at that point we did later.
• 12:59
  SPEAKER_02: Okay.
• 12:59
  SPEAKER_00: But the first one was actually written in in C so tell me about the transition between the C compiler than the C sharp compiler, and how that went.
• 13:07
  SPEAKER_02: Well, oddly, we actually had the command line compiler, and then we also had a separate lighter weight compiler for IntelliSense in the IDE.
• 13:19
  SPEAKER_02: We're talking back in the early days.
• 13:21
  SPEAKER_02: And that was horrendously hard to deal with because we would go first we have to go implement the feature, and then we had to go implement the feature.
• 13:32
  SPEAKER_02: Over and over, and they were always out of sync.
• 13:35
  SPEAKER_02: And uh and and the the compiler we had in the IDE, you know, for intelligence and whatever, took some shortcuts in the which at the time it was designed, seemed to make sense because hey, in an IDE you gotta be fast, and therefore you can't do everything, and therefore, well, it turns out you actually can do everything, you just gotta be smarter about how you do it.
• 13:58
  SPEAKER_02: But we didn't have the smarts at the time, and so we didn't do it that way.
• 14:02
  SPEAKER_02: But but uh that sort of went on for years, and then eventually was the genesis for what became the Rosslyn project.
• 14:12
  SPEAKER_02: The uh the the the re rewriting of the compiler in itself.
• 14:17
  SPEAKER_02: So writing the C compiler in itself, and writing a single compiler that could be both the command line compiler and the the compiler that the language service uses.
• 14:29
  SPEAKER_02: Um and there's a whole art to how to do that.
• 14:33
  SPEAKER_02: I'm sure.
• 14:34
  SPEAKER_02: Um because you know when you think command line compiler, fine.
• 14:39
  SPEAKER_02: It's like you feed it a bunch of text and magic happens in a box and then out comes assemblies or whatever bytecode or object code or or whatever, right?
• 14:48
  SPEAKER_02: And but you think about like the compiler in the IDE, well, first of all, it's never going from fully it's never fully compiling the program.
• 15:01
  SPEAKER_02: Um I mean, that's part of it if you ask for all the error messages.
• 15:04
  SPEAKER_02: But when you're just typing in in the editor and you press dot and you want statement completion, how do you do that faster?
• 15:12
  SPEAKER_02: If your program is huge and it takes like, say, 15 seconds to compile the whole thing, you can't wait 15 seconds every time you press dot.
• 15:20
  SPEAKER_02: So now you've got to do something incrementally in order to get to the answer fast.
• 15:26
  SPEAKER_02: And trying to architect a compiler to both be something that can be a command line compiler that can check everything, but also something that can do just the minimal amount of work when you're typing, because we know from user studies that if it takes more than 250 milliseconds to deliver that drop down, then people think the IDE is slow.
• 15:46
  SPEAKER_02: Right?
• 15:46
  SPEAKER_02: And and not responsive enough.
• 15:50
  SPEAKER_02: Yep.
• 15:51
  SPEAKER_02: And that's that's tricky.
• 15:53
  SPEAKER_02: Um and so you gotta you gotta really come up with some interesting uh uh data structures to make this possible.
• 16:01
  SPEAKER_02: You gotta think deeply about how do we defer work and make the compiler completely lazy?
• 16:07
  SPEAKER_02: Uh how do we give the compiler the sort of ability to helicopter into the middle of a program and start asking questions right here without first having to establish the the deeper context that this piece of code sits in.
• 16:20
  SPEAKER_02: Let's say it's nested in a function, in a class, in a in a module, in a whatever, you know.
• 16:25
  SPEAKER_02: How do you how do you not like first have to build all of that up in order to answer the question in there?
• 16:31
  SPEAKER_02: And so so that was a big learning curve.
• 16:36
  SPEAKER_02: I think we came up with some really interesting solutions there that we've then subsequently applied in how we built the TypeScript compiler.
• 16:44
  SPEAKER_02: Um and it's paid off in spades.
• 16:46
  SPEAKER_02: Uh I mean we we can in both of these language services, they're excellent.
• 16:51
  SPEAKER_02: You know, you can load gigantic projects and then just type away, and it's just super snappy and responsive.
• 16:58
  SPEAKER_00: So you started in C but you switched over to C sharp.
• 17:02
  SPEAKER_00: What was the thought process behind why use C sharp and not continue with C?
• 17:07
  SPEAKER_02: Um well self-hosting is is huge, right?
• 17:11
  SPEAKER_02: And also productivity.
• 17:13
  SPEAKER_02: I mean, honestly, writing in C is not a particularly productive experience, right?
• 17:18
  SPEAKER_02: Um C sharp is it just things are way easier, right?
• 17:22
  SPEAKER_02: And and you can be way more productive.
• 17:25
  SPEAKER_02: And you can also, I mean, and and I've always been a big believer in in self-hosting, you know, and so so we wanted to write in our own language so we could feel for ourselves what needed fixing and what wasn't performant enough, and you know, so yeah.
• 17:41
  SPEAKER_00: So you find the primary pain points yourself before you ship the code.
• 17:45
  SPEAKER_02: There's nothing better than that.
• 17:47
  SPEAKER_02: Yes, yeah, yeah, yeah.
• 17:48
  SPEAKER_02: Because you know if if it sucks, you know it before it even gets to co to customers, right?
• 17:53
  SPEAKER_02: It's really only the the situations where the customer code exhibits something out of the ordinary that that you wouldn't know about, right?
• 18:02
  SPEAKER_00: So you've experienced it first, excellent.
• 18:05
  SPEAKER_02: Yes, yeah, yeah.
• 18:05
  SPEAKER_00: So I mean you mentioned TypeScript and TypeScript are the same thing.
• 18:08
  SPEAKER_00: TypeScript has a compiler that was built in TypeScript.
• 18:11
  SPEAKER_00: Yes, well it it it it has been so far.
• 18:14
  SPEAKER_00: Correct.
• 18:14
  SPEAKER_00: And I want to talk about that.
• 18:16
  SPEAKER_00: Yes, yes, but let's start with the the first I mean it's the same thought process behind it was we want to build our you know we want to build in TypeScript in order to experience those pain points first.
• 18:26
  SPEAKER_02: It was um I think well TypeScript is is pretty unique because again, we're not talking about a new language now, we're talking about retrofitting a type system on top of an existing language, um, which is yet again a new uh sort of that was what made the the project interesting to me, right?
• 18:48
  SPEAKER_02: Because that that's like, oh okay, I don't think who's done that before, you know, that that I want to I wanna I want in on that and try some of that.
• 18:55
  SPEAKER_02: Um and uh we knew that that in order to appeal to the ECMAScript community or the JavaScript community, you had to be of the JavaScript community.
• 19:09
  SPEAKER_02: And we also had to really get to learn deep, deep down what is the nature, the gestalt of this JavaScript programming language and the node platform and so forth.
• 19:19
  SPEAKER_02: And and the best way to do that is to is to use the platform to write the the compiler.
• 19:26
  SPEAKER_02: Uh we also knew that we wanted to, we're very uh TypeScript is very much affinitized with front end and browsers and whatever, and we wanted an artifact that we could run in the browser.
• 19:39
  SPEAKER_02: And because TypeScript is written in TypeScript, i.e.
• 19:42
  SPEAKER_02: therefore runs as JavaScript, the TypeScript compiler is perfectly happy to run in a browser.
• 19:47
  SPEAKER_02: I mean, our playground, it's the full compiler.
• 19:49
  SPEAKER_02: It's it's like it's right there.
• 19:50
  SPEAKER_02: It doesn't need a server to talk to to no no no, it does it all right right there, you know.
• 19:54
  SPEAKER_02: That's how and like like the early Monaco, you know, uh the beginnings of Visual Studio Code with TypeScript integrated into it, that was that was all like running in JavaScript in the browser.
• 20:06
  SPEAKER_02: But I will also say that if someone had told me like say, well now it's been 15 years with TypeScript, but if someone had told me uh 15 plus years ago that Anders, you're gonna spend over a decade writing compilers in JavaScript, I would have gone, hell, that's that's never gonna happen.
• 20:24
  SPEAKER_02: And yet it did.
• 20:26
  SPEAKER_02: Yeah, sure.
• 20:27
  SPEAKER_02: Um but and it served us well.
• 20:32
  SPEAKER_02: It really has.
• 20:34
  SPEAKER_02: But there are limits to what you can wring out of the JavaScript execution environment.
• 20:40
  SPEAKER_02: Um you hit those.
• 20:41
  SPEAKER_02: And you hit them.
• 20:42
  SPEAKER_02: Uh and we have hit them pretty hard.
• 20:44
  SPEAKER_02: Um I will say I think the TypeScript compiler is an it's an excellent compiler.
• 20:49
  SPEAKER_02: It is very well written.
• 20:50
  SPEAKER_02: It it given given the millstones that it's forced to carry around, it runs incredibly fast.
• 20:58
  SPEAKER_02: Um But it is locked in an execution environment that has an ex that has a very expensive um execution model.
• 21:08
  SPEAKER_02: It's JIT-based, JIT compiled, you know, you gotta start from scratch, and uh and and and like like all you get is source text, and now you gotta run it, right?
• 21:16
  SPEAKER_02: I mean, so you gotta turn it into code first.
• 21:20
  SPEAKER_02: That takes time.
• 21:22
  SPEAKER_02: It has a very expensive object model.
• 21:24
  SPEAKER_02: Objects in JavaScript are really more like dictionaries or maps, you know.
• 21:29
  SPEAKER_02: Like you can just dot into anything.
• 21:32
  SPEAKER_02: Or you can even add a new property, like midstream, and now it has this property that it didn't have before.
• 21:36
  SPEAKER_02: You know, I mean, how do you make that be performant, right?
• 21:40
  SPEAKER_02: Um and then JavaScript comes with uh because of its browser origins, it is um effectively forced to be single threaded.
• 21:54
  SPEAKER_02: It runs on a single thread, the UI thread, in in the browser, and it can never block.
• 22:00
  SPEAKER_02: Because that locks up the browser.
• 22:02
  SPEAKER_02: Yep.
• 22:03
  SPEAKER_02: You know.
• 22:04
  SPEAKER_02: Hence all of these callbacks that you have to do in in in JavaScript, you know, that run uh asynchronously and and and so forth.
• 22:13
  SPEAKER_02: And now of course over time we've patched it a bit by by you know supporting web workers, which is effectively the ability to spawn a new execution environment, give it some code and have it run.
• 22:27
  SPEAKER_02: But the execution environments can't share any structured data.
• 22:32
  SPEAKER_02: They can pass messages to each other as JSON or or they can pass byte arrays, but they're no you can't like have one web worker make a graph of objects and then give it to some other web worker to operate on.
• 22:44
  SPEAKER_02: Nope, nope, no, it can't be done.
• 22:47
  SPEAKER_02: So so we've sort of the TypeScript TypeScript has sort of been locked in a in an execution environment that's very expensive and been forced to run single-threaded.
• 22:58
  SPEAKER_02: And those those are two big millstones to carry around, right?
• 23:01
  SPEAKER_02: They are.
• 23:02
  SPEAKER_02: Yes.
• 23:03
  SPEAKER_02: And and we know now that each of them comes with a 3x, 3 to 4x penalty.
• 23:11
  SPEAKER_02: And they are multiplicative, right?
• 23:14
  SPEAKER_02: Meaning that you're talking 10x if you could be not forced to be out of the boxes.
• 23:28
  SPEAKER_02: And that's effectively how our port to native code gains its 10x.
• 23:33
  SPEAKER_02: It's half from being in native code and half from having the ability to take c care of concurrency.
• 23:40
  SPEAKER_02: And I mean if you look at a a colleague of mine, Herb Sutter, who who used to run our our uh who was on our C team uh as our representative in the standardization committee, whatever, he wrote a paper about 20 years ago called The Free Lunch Is Over.
• 23:58
  SPEAKER_02: Um and and what he talked about in that paper is how Moore's Law keeps going, but at that point it stopped giving us faster CPUs and it instead started giving us more CPUs.
• 24:13
  SPEAKER_02: Okay.
• 24:14
  SPEAKER_02: The clock rate sort of went up and then it plateaued around four gigahertz or wherever it is we are, and now we just get more cores.
• 24:21
  SPEAKER_02: Right.
• 24:21
  SPEAKER_02: And if you have compute-intensive workloads, which a compiler is, the only way you can make it faster is to use those cores.
• 24:30
  SPEAKER_02: Right.
• 24:31
  SPEAKER_02: It's never gonna get faster on a single thread, you know.
• 24:33
  SPEAKER_00: So you're leaving a lot on the table by not.
• 24:35
  SPEAKER_02: So you're leaving money on the table.
• 24:37
  SPEAKER_02: You're leaving more money on the table every year because we get more and more cores every year.
• 24:41
  SPEAKER_02: So that's all we're gonna get from here on out.
• 24:44
  SPEAKER_00: So you're looking at that massive compiler, and there's a lot of work that went into building the TypeScript compiler.
• 24:48
  SPEAKER_00: Yeah.
• 24:49
  SPEAKER_00: And you've got what essentially is a massive brownfield application.
• 24:52
  SPEAKER_00: Yep.
• 24:53
  SPEAKER_00: And you're almost starting over from scratch.
• 24:56
  SPEAKER_00: I mean, you're not, because you're trying to port.
• 24:58
  SPEAKER_02: Oh yeah, yeah.
• 24:59
  SPEAKER_02: No, we knew from day one that this was gonna be a port.
• 25:03
  SPEAKER_02: If we started from first principles, oh my lord, we would I mean, it is it it is just way too big.
• 25:09
  SPEAKER_02: I mean, TypeScript is now, well, I mean, certainly if if you look on GitHub, it's the number three programming language after JavaScript, after Python.
• 25:20
  SPEAKER_02: But if you put together JavaScript and TypeScript, then they're number one.
• 25:25
  SPEAKER_02: Um so I mean, and and and today the two are have have become so commingled, right?
• 25:30
  SPEAKER_02: And it is like our compiler, whenever you're doing anything with JavaScript in Visual Studio Code, you're using our compiler.
• 25:38
  SPEAKER_02: That's the one that delivers the language service for JavaScript and TypeScript.
• 25:43
  unknown: Okay.
• 25:43
  SPEAKER_02: And it just if there's no types in your code, fine, well then it'll have to infer as best it can, but it's the same compiler, it's the same infrastructure, right?
• 25:52
  SPEAKER_02: So we have an enormous amount of dependencies out there.
• 25:57
  SPEAKER_02: And we can't just start over from scratch and expect to ever finish, you know.
• 26:04
  SPEAKER_02: But we can port.
• 26:06
  SPEAKER_02: Um and that's uh that's basically what this effort has been about.
• 26:11
  SPEAKER_02: It's it's literally we want to port so that we get precisely the same semantics, so that we get precisely the same types computed or inferred for the same piece of code.
• 26:24
  SPEAKER_02: We literally want to be able to open a drawer, take out the old compiler, put in the new compiler, close the drawer again, and you never know the difference.
• 26:32
  SPEAKER_02: That that's that's the plan.
• 26:35
  SPEAKER_02: That's it.
• 26:35
  SPEAKER_02: And it's working out.
• 26:36
  SPEAKER_02: It's good.
• 26:37
  SPEAKER_02: It's working out really well.
• 26:38
  SPEAKER_02: Yeah.
• 26:39
  SPEAKER_00: Well that's my next question is is how's that going?
• 26:40
  SPEAKER_00: And it's going great.
• 26:42
  SPEAKER_00: Excellent.
• 26:42
  SPEAKER_00: Yeah.
• 26:43
  SPEAKER_02: I mean, we are We started out thinking that we could get to 10X because that's what our prototypes seem to indicate.
• 26:53
  SPEAKER_02: Now we know that we can get to 10X, because we're getting 10X consistently on large code bases like Visual Studio Code that today with the old compiler takes about 70, 60, 70 seconds to compile, takes six seconds to compile with with the with the new compiler.
• 27:12
  SPEAKER_02: Um and if you go in anywhere and introduce an error, it produces precisely the same error message.
• 27:17
  SPEAKER_02: You can't tell the difference between these two, it just goes ten times faster.
• 27:22
  SPEAKER_02: Um yeah.
• 27:23
  SPEAKER_02: Um and this bears itself out with other other large codebases that we've tried.
• 27:28
  SPEAKER_02: Um we have code bases in Microsoft that are upwards of 15 million lines of code.
• 27:34
  SPEAKER_02: Like I'm not gonna name names, but massive, yeah.
• 27:38
  SPEAKER_02: Code bases that we could never even load in Visual Studio that now load in 15 seconds.
• 27:45
  SPEAKER_02: You know, I mean you this is like I mean, like Node would just choke, you know, and and now it's possible for us to so so the scaling has just gone through the roof here, our ability to escape.
• 27:58
  SPEAKER_02: Which is really wonderful.
• 27:59
  SPEAKER_02: And and we can see that we've also managed to successfully parallelize all the phases of compilation.
• 28:09
  SPEAKER_02: They're there which in turn means we can harvest concurrency wildly, not just y you know, in in the well there if you look at if you think about how a compiler works, you know, it it has certain phases of compilation, like parsing, binding, checking, and emit are sort of the faces that we have in our compiler.
• 28:29
  SPEAKER_02: And some of them are what's called, what I would say are embarrassingly parallel problems, where, you know, for example, parsing a source file.
• 28:36
  SPEAKER_02: Well, it can just load the file and then build a data structure that allows you to quickly navigate the file and find stuff in it that have objects that describe the different pieces of the source code, right?
• 28:48
  SPEAKER_02: But it's completely independent for each file.
• 28:51
  SPEAKER_02: So you can start a task, run that on one CPU, and you can if you have 32 CPUs, you can start 32 files at the same time.
• 29:00
  SPEAKER_02: And that scales linearly.
• 29:03
  SPEAKER_02: Right?
• 29:04
  SPEAKER_02: And parsing, which is the construction of simple tables to first pass locally over each of the trees, also scales linearly.
• 29:11
  SPEAKER_02: Emit scales linearly, but checking doesn't.
• 29:15
  SPEAKER_02: But we've come up with some really clever solutions to how we manage to scale almost linearly for checking, and we're seeing it play out now.
• 29:24
  SPEAKER_02: I mean, you get some of these like crazy in-the-cloud dev boxes with 32 cores and 128 gigs of memory, and you allow it to just use all the cores, and you literally see the CPU bar and go all of them just going full throttle.
• 29:40
  SPEAKER_02: Like to compile these 15 million lines of code I talked about, like compiling all of it in 45 seconds.
• 29:46
  SPEAKER_02: It used to not even be possible to do it, and and and that, but if you chunked it up, you could you I mean you could get it, but it would take like I mean half an hour or something.
• 29:55
  SPEAKER_02: I mean, it's it's just nuts how how how it scales.
• 29:58
  SPEAKER_00: So you're improving developer productivity by the case.
• 30:04
  SPEAKER_02: We're making the world greener, we're consuming less energy.
• 30:07
  SPEAKER_02: We don't need a data center to run our compiler anymore.
• 30:10
  SPEAKER_00: The green new effort, right?
• 30:12
  SPEAKER_00: Yep, excellent.
• 30:14
  SPEAKER_00: Um so I mean you've you've kind of scratched some itches, I'm sure, for yourself, writing Tarot Pascal and then Delphi and then getting this in a C sharp and TypeScript.
• 30:24
  SPEAKER_00: I'm just curious.
• 30:26
  SPEAKER_00: Is there another itch at some point you want to scratch, build a new language, or are you thinking like I kind of want to time out here and stay where I'm at?
• 30:34
  SPEAKER_02: Well, I'm not as young as I used to be.
• 30:36
  SPEAKER_02: You know, so I will eventually retire, you know.
• 30:38
  SPEAKER_02: I mean, I'm in my mid-sixties now, pretty bad, you know, close to.
• 30:43
  SPEAKER_02: Um so but I enjoy what I do.
• 30:46
  SPEAKER_02: I still get up every morning, make coffee, and write some code.
• 30:50
  SPEAKER_02: And it what keeps it's what keeps me happy.
• 30:52
  SPEAKER_02: You know, I've I've tried being a manager, I've tried being a product manager or whatever.
• 30:56
  SPEAKER_02: I I don't like I want to write code.
• 30:58
  SPEAKER_02: Excellent.
• 30:59
  SPEAKER_02: And I'm still pretty good at it.
• 31:01
  SPEAKER_02: So, you know, and then it's fun.
• 31:02
  SPEAKER_02: Um and I so so I'm gonna keep writing code.
• 31:07
  SPEAKER_02: I don't know what that code's gonna do.
• 31:09
  SPEAKER_02: Right now, we're we're but it's it's you know, I know I'm committed for the next year to finish and get to TypeScript 7, which will be the the release vehicle for the new native code base.
• 31:21
  SPEAKER_02: Um and MLC.
• 31:24
  SPEAKER_02: Excellent.
• 31:25
  SPEAKER_00: Yeah, yeah.
• 31:26
  SPEAKER_00: So I mean you kind of touch on something there that a lot of developers miss or or you know, you're looking at your career trajectory, it feels like it's you know, junior dev, mid-level developer, senior developer, manager.
• 31:38
  SPEAKER_00: Yeah.
• 31:39
  SPEAKER_00: And you're saying I don't want to do that.
• 31:41
  SPEAKER_02: I think you know, if you some people discover at that point that they really have a passion for management and they enjoy doing that.
• 31:51
  SPEAKER_02: For me, that's not my passion.
• 31:54
  SPEAKER_02: My passion truly is writing code and solving complicated technical or algorithmic problems, you know.
• 32:01
  SPEAKER_02: That's what keeps me happy.
• 32:03
  SPEAKER_02: And I and I think you're never gonna do your best work if you're not passionate about it.
• 32:08
  SPEAKER_02: You may do good work, but if you want to do truly great work, it's gotta be there's gotta be a fire burning or some passion there behind it.
• 32:16
  SPEAKER_02: Do you know what I mean?
• 32:17
  SPEAKER_02: I do, yes.
• 32:18
  SPEAKER_02: Yeah, yeah.
• 32:18
  SPEAKER_02: Excellent.
• 32:19
  SPEAKER_02: Yeah.
• 32:19
  SPEAKER_02: So so for me, that's the right thing to do for me.
• 32:23
  SPEAKER_02: But I mean it's not it's not for everybody.
• 32:27
  SPEAKER_00: But that's I think that's the um the example of a people amiss is often they see that you know in order to progress I have to do this management step.
• 32:36
  SPEAKER_02: And you can just be honest with yourself at that point and and you have to you have to look at it, you go, but but can I can it fulfill me?
• 32:46
  SPEAKER_02: And I learned that it couldn't fulfill me.
• 32:49
  SPEAKER_02: I I got involved in more and more task forces and slideware and presentations and specs and whatever, and I was just like burning out, you know, it like like in my in my middle years at at my at Microsoft at one point.
• 33:03
  SPEAKER_02: And I sort of had to like I was either gonna leave or I was gonna reset.
• 33:09
  SPEAKER_02: And and chose to take time off and and reset and get involved in in uh say no more.
• 33:16
  SPEAKER_02: Do you know what I mean?
• 33:17
  SPEAKER_02: I do, and and and it's hard because you have ambition and you you don't wanna, but you know, but but at the end of the day you've got to be true to yourself too.
• 33:26
  SPEAKER_02: Find that right outlet for your skills and abilities.
• 33:29
  SPEAKER_02: Excellent.
• 33:30
  SPEAKER_00: Yeah.
• 33:30
  SPEAKER_00: Um turning back to C sharp, this is a primarily C sharp channel, uh primarily C sharp audience.
• 33:36
  SPEAKER_00: Um you've seen how C sharp is used over the years.
• 33:41
  SPEAKER_00: Is there areas of C sharp or you know, C sharp adjacent you feel like people are missing or that they don't utilize as often, or things you're like, that's an awesome feature, and I think you're missing it.
• 33:52
  SPEAKER_00: Is there one of those?
• 33:53
  SPEAKER_02: I mean I'm kind of putting you on the spot here, but No, I I mean I I am hoping that that the world will really open its eyes to how uh serious the C Sharp team and.NET are about uh open source and and being on all platforms.
• 34:14
  SPEAKER_02: And I know that that has been sort of a change from where it started originally, but it's it's it's interesting.
• 34:21
  SPEAKER_02: It was always built to be a general purpose runtime that could go anywhere, you know, but but for for other reasons it was not it was just not you know sold that way in the beginning.
• 34:36
  SPEAKER_02: But now that we're open source and that we're on Linux and Mac and uh have.NET core and have extracted out all of the all of the the core pieces of the runtime and we're starting to have a better ahead of time compilation story and whatever.
• 34:52
  SPEAKER_02: It it really is in many ways a different product than but but but you know again it's like it's tar it's hard to change people's pers perceptions, right?
• 35:06
  SPEAKER_02: Sure.
• 35:09
  SPEAKER_02: But I do think uh C sharp has a lot more legs than it's uh than it's sometimes you know perceived to have.
• 35:19
  SPEAKER_00: Yeah, yeah.
• 35:20
  SPEAKER_00: I agree.
• 35:20
  SPEAKER_00: Yeah, yeah.
• 35:21
  SPEAKER_00: All right, well, I appreciate you being here.
• 35:23
  SPEAKER_02: Oh, my pleasure.
• 35:24
  SPEAKER_02: Thanks so much.
• 35:24
  SPEAKER_02: Fun conversation, yeah, yeah.
• 35:26
  SPEAKER_00: And that's it for this episode of Dev Questions.
• 35:28
  SPEAKER_00: Um, and as always, I am Tim Corey.