Latest / DevQuestions with Tim Corey / 251. What Microsoft Choosing Go over C# Can Teach Us

Transcript

251. What Microsoft Choosing Go over C# Can Teach Us · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Microsoft realized they needed to redo the TypeScript compiler because the TypeScript was just too slow.
• 0:06
  SPEAKER_00: So they chose Go.
• 0:08
  SPEAKER_00: That choice sparked a lot of debate over the idea that Microsoft was signaling they didn't have confidence in C Sharp as a language.
• 0:18
  SPEAKER_00: Personally, I think that argument shows a lack of real-world experience.
• 0:22
  SPEAKER_00: But let's talk about why, along with what lessons we can learn from this decision in today's episode of Dev Questions.
• 0:38
  SPEAKER_01: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:42
  SPEAKER_00: Software development is more than just writing code.
• 0:45
  SPEAKER_00: So let's talk about the rest of it.
• 0:47
  SPEAKER_00: Specifically, let's talk about the considerations that go into major application decisions.
• 0:54
  SPEAKER_00: Now, in case you don't know, Microsoft is a creator of TypeScript.
• 0:58
  SPEAKER_00: In fact, the lead architect of TypeScript, Anders Heilsberg, is also the lead architect of the C sharp language.
• 1:06
  SPEAKER_00: TypeScript is a super set of JavaScript and it's used to build a lot of products, including VS Code.
• 1:13
  SPEAKER_00: Recently, the TypeScript team started to work on replacing the TypeScript engine, the compiler, which was built in TypeScript.
• 1:21
  SPEAKER_00: So TypeScript builds TypeScript.
• 1:24
  SPEAKER_00: The language they chose to replace TypeScript with was Go.
• 1:29
  SPEAKER_00: So let's talk about why Go and why not another language like C sharp or Rust.
• 1:34
  SPEAKER_00: The answer is really a fairly simple one.
• 1:37
  SPEAKER_00: The TypeScript team wanted to port the code, not rewrite it.
• 1:42
  SPEAKER_00: A rewrite could take years to complete, whereas the port will only take about a year to complete in total.
• 1:50
  SPEAKER_00: Now, even now, they have been able to realize about a 10x improvement in compile times for their projects.
• 1:58
  SPEAKER_00: For instance, the VS Code project with about a million and a half lines of code used to take or takes currently 77 seconds to compile using the TypeScript compiler.
• 2:11
  SPEAKER_00: Under the new TypeScript compiler, which is written in Go, it only takes about seven and a half seconds.
• 2:18
  SPEAKER_00: So why is there a controversy around this decision to go from TypeScript to Go instead of another language?
• 2:27
  SPEAKER_00: Well, there's two reasons.
• 2:29
  SPEAKER_00: First, people love to gain attention through controversy.
• 2:33
  SPEAKER_00: It gives them something to debate about, it gives them something to create memes about.
• 2:38
  SPEAKER_00: And it's just kind of an internet thing to do.
• 2:42
  SPEAKER_00: The second reason is that people don't understand the actual real-world development decisions that go into building something.
• 2:50
  SPEAKER_00: They don't understand why the answer should always be it depends.
• 2:55
  SPEAKER_00: Now, I'm not interested in the controversy since I think it's silly.
• 3:00
  SPEAKER_00: However, I think this is a great opportunity to learn some key lessons about software development and especially around enterprise software development.
• 3:11
  SPEAKER_00: This is something I've spent years and years working on.
• 3:14
  SPEAKER_00: I have spent years and years in the industry building enterprise applications and supporting enterprise applications.
• 3:21
  SPEAKER_00: So, what can we learn from this particular situation?
• 3:25
  SPEAKER_00: The first thing I think is early decisions have long-term consequences.
• 3:31
  SPEAKER_00: I heard someone say recently that the best experience you can get is living with the consequences of your decisions.
• 3:38
  SPEAKER_00: Where if you're deciding how to architect an application and you start that process, you start building, you build the entire application, do you stick around long enough to see how that works five, 10 years down the road?
• 3:51
  SPEAKER_00: Often not, in which case you might miss some really important lessons about those decisions.
• 3:59
  SPEAKER_00: Well, when you stick around long enough with an application or in this case a compiler, what you find out is there's long-term consequences to the choices you made early on.
• 4:13
  SPEAKER_00: Now, in this case, the choice I made early on was to build TypeScript with TypeScript, which is something that Anders has done for a long time.
• 4:22
  SPEAKER_00: For instance, C sharp is built by Rosalind, which is written in C sharp.
• 4:28
  SPEAKER_00: So that's a pattern that he has that has gone back to many previous languages that he's built.
• 4:35
  SPEAKER_00: And I think it's a good one in most cases.
• 4:37
  SPEAKER_00: But as he pointed out, there's a limitation to what JavaScript can do.
• 4:42
  SPEAKER_00: Remember, TypeScript is just a superset of JavaScript.
• 4:45
  SPEAKER_00: And it's meant for display, especially web display and UI work, not necessarily some of the deep technical things that have to go into a compiler.
• 4:57
  SPEAKER_00: Well, those decisions have long-term consequences because what they're looking at today is that they have over a million lines of code.
• 5:08
  SPEAKER_00: They have, as he puts it, over a hundred man years of time put into building what they have so far, and they have a large customer base.
• 5:19
  SPEAKER_00: People that are currently using the compiler today.
• 5:22
  SPEAKER_00: If you change how the compiler works in the next version, well, you've essentially said, hey, sorry, we don't support you anymore to your current customers.
• 5:31
  SPEAKER_00: They didn't want that.
• 5:32
  SPEAKER_00: They wanted to have something that was as close as possible to an exact replica of their current compiler.
• 5:40
  SPEAKER_00: Well, that made some decisions limitation, but that put some limitations on those decisions today.
• 5:48
  SPEAKER_00: Because they can't just choose any situation or any language or any way of doing things.
• 5:54
  SPEAKER_00: They had to look at what we can do to move off of this.
• 5:57
  SPEAKER_00: And one of the decisions they made was we want to have as close as possible to the same syntax so that the port, which is what it is, it's not a rewrite, it's a port.
• 6:10
  SPEAKER_00: That port can have as few changes as possible and still get us up to speed quickly, which is what they did.
• 6:17
  SPEAKER_00: Go is very, very similar in structure to how they wrote the JavaScript.
• 6:22
  SPEAKER_00: They wrote JavaScript with a very functional approach.
• 6:26
  SPEAKER_00: And with Go, it's very functional.
• 6:29
  SPEAKER_00: And the code mostly is just a conversion rather than a rewrite.
• 6:35
  SPEAKER_00: Now there are some things like the rewrite, but it's tweaking things rather than redoing the entire process.
• 6:42
  SPEAKER_00: So those early decisions about writing in TypeScript meant that they were pretty locked into something like Go moving forward, where they couldn't just say, well, we're going to go to C sharp because it's a totally different syntax.
• 6:58
  SPEAKER_00: It's object-oriented instead of functional.
• 7:01
  SPEAKER_00: It's just entirely different.
• 7:03
  SPEAKER_00: If they wanted to go a.NET language, they might actually have done better going to F sharp, which is much more functional or can be.
• 7:10
  SPEAKER_00: And so therefore it would have been easier, but still not a syntax similar language, which means that it's much closer to a rewrite than it is a port.
• 7:22
  SPEAKER_00: So those early decisions affected what they could do today.
• 7:27
  SPEAKER_00: Number two, rewrites don't happen often.
• 7:31
  SPEAKER_00: So Microsoft, with what feels like infinite resources, and that's laughable if you actually understand how budgeting works, because they're all fighting for the last dollar to try and get some resources towards projects.
• 7:44
  SPEAKER_00: But with what feels like unlimited resources, Microsoft doesn't rewrite things that often.
• 7:51
  SPEAKER_00: Because rewrites just aren't practical.
• 7:55
  SPEAKER_00: As I said, it's a hundred man years, which whether that's the equivalent of is a hundred years of one person working in this project or one year of a hundred people working in the project.
• 8:06
  SPEAKER_00: Now we know as developers that it's not just about throwing more people at the project makes things go faster.
• 8:12
  SPEAKER_00: That's not how it works.
• 8:13
  SPEAKER_00: But that's the equivalent of how much time is already in the project.
• 8:18
  SPEAKER_00: And that's an iterative process where they had time to get feedback on every step along the way.
• 8:25
  SPEAKER_00: So you can't just say we're going to redo that and expect to be a hundred man years of time.
• 8:31
  SPEAKER_00: It's going to be a lot more than that if you're doing a true rewrite.
• 8:35
  SPEAKER_00: Well, that's just not practical.
• 8:37
  SPEAKER_00: I mean, think of the cost of a hundred years, just the same amount of time, a hundred years of developer time at a pretty good rate.
• 8:46
  SPEAKER_00: You're talking about millions and millions and millions of dollars.
• 8:50
  SPEAKER_00: In the meantime, all your customers are waiting on that.
• 8:54
  SPEAKER_00: That's going to take four or five, six years to do.
• 8:57
  SPEAKER_00: Well, in the meantime, TypeScript can't pause.
• 9:01
  SPEAKER_00: It's got to continue to evolve, which means that your new version of it has to evolve along with it.
• 9:08
  SPEAKER_00: It took.NET years to get back up to speed from.NET Core.
• 9:13
  SPEAKER_00: So.NET Core, even.NET Core 1, was not exactly a usable product.
• 9:18
  SPEAKER_00: It was more of a prototype.
• 9:20
  SPEAKER_00: And then.NET Core 2 started with some web stuff and three kind of solidified some things.
• 9:25
  SPEAKER_00: And we've made a lot of progress since then.
• 9:28
  SPEAKER_00: But it's a long time to move when you're redoing everything.
• 9:33
  SPEAKER_00: So rewrites just don't happen that often because it's way too expensive for an organization, which means, again, going back to point one, your early decisions are going to have some long-term impact, long-term consequences.
• 9:47
  SPEAKER_00: Now, number three, the best option depends on more than just a language.
• 9:54
  SPEAKER_00: There is a possibility that, and it's probably a good possibility, that C sharp could run faster than Go does for compiling TypeScript.
• 10:04
  SPEAKER_00: But the difference is it's going to take years to rebuild that.
• 10:09
  SPEAKER_00: Well, as I heard one person say, Do you want to wait six years for a 12x speed increase or one year for a 10x speed increase?
• 10:19
  SPEAKER_00: You see, it's more than just about the language, it's about a lot of other factors that go into it.
• 10:24
  SPEAKER_00: In this case, it's about trying to get that same functional approach and trying to do a port that would take a short period, relatively short period of time to get into place.
• 10:35
  SPEAKER_00: In which case, Go is the logical choice.
• 10:38
  SPEAKER_00: And even if it's not the absolute fastest choice out there, it would give an incredible speed difference.
• 10:47
  SPEAKER_00: And that's what they're looking for.
• 10:48
  SPEAKER_00: They're looking for a new solution, a native solution as opposed to a TypeScript solution that'll allow them much more performance overhead, much more ability to be much more performant with their build process.
• 11:04
  SPEAKER_00: But even though Go might not have been, I'm not saying it isn't, but it might not have been the fastest choice in a vacuum, that's not what we're talking about.
• 11:15
  SPEAKER_00: It's more than just the language itself.
• 11:17
  SPEAKER_00: You can't just say which language is fastest.
• 11:20
  SPEAKER_00: That's where we see all these benchmarks.
• 11:21
  SPEAKER_00: Well, this language is a little bit faster than this language.
• 11:24
  SPEAKER_00: And we try and figure this out as developers, and it's fun to learn and it is important to see how can we make our language better.
• 11:33
  SPEAKER_00: And so the teams working on those languages do try and make their language more performant.
• 11:38
  SPEAKER_00: But at the end of the day, the decision about which language to choose, it's not about just which one is best.
• 11:46
  SPEAKER_00: It's about which one is best for this specific situation.
• 11:51
  SPEAKER_00: And if you think it's just a, if you think that that one specific situation then has bearing on every other situation, then you are really not experienced enough as a developer.
• 12:03
  SPEAKER_00: Because you would add the more experience you have, the more you realize, oh, we should be taking a more pragmatic approach to this.
• 12:11
  SPEAKER_00: It depends, really does apply to more than just the language.
• 12:15
  SPEAKER_00: Now, number four, not all experience is the same.
• 12:20
  SPEAKER_00: So when I hear people talking about this, and people are saying, oh, you should do this, you should do that, and they're making definitive statements about what should have been done by the team.
• 12:28
  SPEAKER_00: Um, this just shows me that I don't think they have the experience in this, the depth of experience, to go, oh, let me learn more because I'm sure they had a good reason for it.
• 12:40
  SPEAKER_00: Or I would like to figure out more about this reasoning process because I must be missing something if I don't agree.
• 12:48
  SPEAKER_00: Because sometimes people might have 20 years experience.
• 12:53
  SPEAKER_00: You might see someone that's a senior developer.
• 12:55
  SPEAKER_00: They had 20 years experience in, let's say, C sharp.
• 12:58
  SPEAKER_00: Well, is that 20 years of experience going deeper and deeper and deeper for 20 years, or is that basically one year of experience 20 times?
• 13:11
  SPEAKER_00: Okay.
• 13:11
  SPEAKER_00: Are you still at that same shallow level and it's bouncing around from place to place, doing that shallow level?
• 13:18
  SPEAKER_00: And in these situations, that kind of thing comes out.
• 13:22
  SPEAKER_00: Because what happens is you kind of show off your lack of depth of experience in these situations when you have a definitive statement, you think there's only one good way, there's only one solution, or that this reflects on a larger ecosystem.
• 13:37
  SPEAKER_00: You know, one of the big outcries was okay, Microsoft is declaring that C sharp is no longer a valid language or something like that.
• 13:45
  SPEAKER_00: And of course, a lot of that is just people trying to get clickbait titles and all the rest.
• 13:49
  SPEAKER_00: But no, that's absolutely not the case.
• 13:53
  SPEAKER_00: In this specific case, this specific choice was the best one.
• 13:59
  SPEAKER_00: In fact, they did do tests.
• 14:00
  SPEAKER_00: They did prototypes in Rust and C sharp and other languages to try and figure out what was going to be best for their specific situation.
• 14:08
  SPEAKER_00: They made the best possible choice for their specific situation, and that's what it applies to, that specific situation.
• 14:18
  SPEAKER_00: Number five, time to completion is a key metric.
• 14:22
  SPEAKER_00: This is often missed.
• 14:24
  SPEAKER_00: You know, which is the fastest language, which is the best language, which is the best choice?
• 14:29
  SPEAKER_00: Time to completion is a key metric.
• 14:32
  SPEAKER_00: So, like I said before, a 10x speed improvement next year is better than a 12x speed improvement five years from now.
• 14:40
  SPEAKER_00: Getting out the door is a key metric.
• 14:44
  SPEAKER_00: Getting something to the market, getting something in place now is important.
• 14:50
  SPEAKER_00: It's an extremely valuable piece of overall software development.
• 14:56
  SPEAKER_00: So when you look at a situation, you can't just look at what is objectively in a bubble, in a vacuum, the best solution.
• 15:06
  SPEAKER_00: You have to look at what is the best solution for my situation where speed is an important metric that we're measuring.
• 15:17
  SPEAKER_00: Time to completion, time to market, that's an important metric.
• 15:21
  SPEAKER_00: That has to go into your calculation, not just in a vacuum.
• 15:24
  SPEAKER_00: And number six, developers need to be pragmatic.
• 15:29
  SPEAKER_00: So no solution works for every problem.
• 15:32
  SPEAKER_00: No language works for every problem.
• 15:35
  SPEAKER_00: Now, I'm a big fan, big proponent of C.
• 15:38
  SPEAKER_00: I love C.
• 15:39
  SPEAKER_00: And part of it is just personal preference.
• 15:42
  SPEAKER_00: And part of it is when you're learning C sharp.
• 15:46
  SPEAKER_00: My assertion is that you should learn one language deeply before you just start spreading out and doing that 20 times one year experience.
• 15:57
  SPEAKER_00: You know, one year experience 20 times.
• 15:59
  SPEAKER_00: Um, so instead of doing that and bouncing around, I encourage you to go deep, get 20 years' experience, maybe not 20 years, but get years of experience in one language.
• 16:08
  SPEAKER_00: And C sharp does so many different things.
• 16:11
  SPEAKER_00: It applies to so many different places, you know, uh Mac, Linux, Windows, uh Web, uh iOS, Android, the cloud, Xbox, IoT, you know, all these different places you can put C sharp so that it feels like sometimes it might sound like I'm saying the C sharp is the answer to every problem.
• 16:32
  SPEAKER_00: Well, it's not.
• 16:33
  SPEAKER_00: There may be times when C sharp isn't the answer.
• 16:36
  SPEAKER_00: I had a discussion earlier this week with a person who said, wait, you're saying I should learn JavaScript too?
• 16:41
  SPEAKER_00: Why don't I just learn JavaScript and not C sharp then?
• 16:45
  SPEAKER_00: Because the answer would be, well, then you have to learn C sharp in order to support your JavaScript, right?
• 16:50
  SPEAKER_00: Like, yes, as a C sharp developer, if you're gonna work with the web at all, and you probably are, then you should learn JavaScript at some point.
• 16:58
  SPEAKER_00: Not as deep necessarily as C sharp, but you should still learn JavaScript.
• 17:02
  SPEAKER_00: Because not every solution can be answered with one language.
• 17:08
  SPEAKER_00: But one language can do a lot of things, and so you have a higher percentage of solutions that work with C sharp.
• 17:16
  SPEAKER_00: So developers need to be pragmatic.
• 17:19
  SPEAKER_00: I'm not saying use a different language for every problem.
• 17:22
  SPEAKER_00: That would also be unwise.
• 17:25
  SPEAKER_00: You have to look at your specific situation to determine what's best, but you have to be pragmatic about it.
• 17:32
  SPEAKER_00: And finally, number seven, hype and drama isn't a good decision maker.
• 17:38
  SPEAKER_00: So when you're looking at how to make a decision, don't look at the memes to help determine what you should do.
• 17:46
  SPEAKER_00: Okay.
• 17:47
  SPEAKER_00: When it comes to what should I learn, don't just follow what the hype is.
• 17:52
  SPEAKER_00: Don't follow the most hyped thing out there, the flavor of the day.
• 17:58
  SPEAKER_00: That's not going to be a great solution.
• 18:00
  SPEAKER_00: You need to look at what is what is solid, what's a good decision for you, what is right for it for your desires, for your market, for all these different things.
• 18:10
  SPEAKER_00: Basically, it depends.
• 18:12
  SPEAKER_00: Okay?
• 18:13
  SPEAKER_00: So hype and drama, not a good decision maker.
• 18:16
  SPEAKER_00: Now, just as a bonus here, I just want to be clear: C sharp is here to stay.
• 18:22
  SPEAKER_00: A large portion of the projects built at Microsoft are built in C sharp.
• 18:26
  SPEAKER_00: All right.
• 18:27
  SPEAKER_00: So it's not like Microsoft is saying, oh, we're using every other language just because they're the right choice for the job and we never come around to using.NET ever or C sharp.
• 18:36
  SPEAKER_00: That's not true.
• 18:37
  SPEAKER_00: The majority of the projects at Microsoft are built in C.
• 18:41
  SPEAKER_00: The Roslyn compiler itself, the tool that C is compiled with, is written in C sharp.
• 18:49
  SPEAKER_00: Microsoft is heavily invested in.NET and C Sharp specifically.
• 18:53
  SPEAKER_00: But there's a lot more that goes into any language decision than just which is the theoretical best, or even the one we like the most or want to promote.
• 19:02
  SPEAKER_00: There's more to it than that.
• 19:03
  SPEAKER_00: Now, hopefully that answers some questions around this TypeScript move, but also helps you think differently about enterprise software development and what goes into the decision-making process at that level.
• 19:15
  SPEAKER_00: Thanks for listening.
• 19:16
  SPEAKER_00: And as always, I am Tim Corey.
• 19:18
  SPEAKER_01: Thank you for joining us for this episode of Dev Questions.
• 19:21
  SPEAKER_01: When you're ready to learn to think and code like a professional developer, head over to IamTimCorey.com and enroll in a course.