Chris Lattner: Future of Programming and AI | Lex Fridman Podcast #381

On one axis you have more hardware coming in. On the other hand you have an explosion of innovation in AI. And so what happened with both TensorFlow and PyTorch is that the explosion of innovation in AI has led to. It's not just about matrix multiplication and convolution. These things have now 2000 different operators. And on the other hand you have, I don't know how many pieces of hardware there are out there. It's a lot. Part of my thesis, part of my belief of where computing goes, if you look out, 10 years from now is not going to get simpler. Physics isn't going back to where we came from. It's only going to get weirder from here on out, right? And so to me the exciting part about what we're building is it's about building that universal platform which the world can continue to get weird because again, I don't think it's avoidable, it's physics, but we can help lift people scale, do things with it and they don't have to rewrite their code every time a new device comes out. And I think that's pretty cool.

The following is a conversation with Chris Lattner, his third time on this podcast. As I've said many times before, he's one of the most brilliant engineers in modern computing, having created LLM compiler infrastructure project, the Clang compiler, the Swift programming language, a lot of key contributions to TensorFlow and TPUs. As part of Google he served as vice president of Autopilot software at Tesla, was a software innovator and leader at Apple and now he co created a new full stack AI infrastructure for distributed training, inference and deployment on all kinds of hardware called Modular and a new programming language called Mojo that is a superset of Python, giving you all the usability of Python, but with the performance of C C In many cases Mo Mojo code has demonstrated over 30,000x speed up over Python. If you love machine learning, if you love Python, you should definitely give Mojo a try. This programming language, this new AI framework and infrastructure and this conversation with Chris is mind blowing. I love gets pretty technical at times, so I hope you hang on for the ride. This is the Lex Friedman podcast to support it, please check out our sponsors in the description. And now dear friends, here's Chris Lattner.

It's been I think two years since we last talked and in that time you somehow went and co created a new programming language called Mojo. So it's optimized for AI. It's a superset of Python. Let's look at the big picture, what is the vision for Mojo?

For Mojo? Well, so, I mean, I think you have to zoom out. So I've been working on a lot of related technologies for many, many years. So I've worked on LLVM and a lot of things, and mobile and servers and things like this. But the world's changing and what's happened with AI is we have new GPUs and new machine learning accelerators and other ASICs and things like that that make AI go real fast. At Google, I worked on TPUs. That's one of the biggest, largest scale deployed systems that exist for AI. And really what you see is if you look across all of the things that are happening in the industry, there's this new compute platform coming. And it's not just about CPUs or GPUs or TPUs or NPUs or IPUs or whatever, all the PUs. It's about how do we program these things right? And so for software folks like us, right, it doesn't do us any good if there's this amazing hardware that we can't use. And one of the things you find out really quick is that having the theoretical capability of programming something and then having the world's power and the innovation of all the, all the smart people in the world get unleashed on something can be quite different. And so really where Mojo came from was starting from a problem of we need to be able to take machine learning, take the infrastructure underneath it, and make it way more accessible, way more usable, way more understandable by normal people and researchers and other folks that are not themselves like experts in GPUs and things like this. And, and then through that journey, we realized, hey, we need syntax for this, we need to do a programming language.

So one of the main features of the language, I say so fully in jest, is that it allows you to have the file extension to be an emoji, or the fire emoji, which is one of the first emojis used as a file extension I've ever seen in my life. And then you ask yourself the question, why in the 21st century we're not using Unicode for file extensions. This, I mean, it's an epic decision. I think clearly the most important decision made the most. But you could also just use Mojo as the file extension.

Well, so, okay, so take a step back. I mean, come on, Lex, you think that the world's ready for this? This is a big moment in the world, right?

This is, we're releasing this onto the world.

This is innovation I mean, it really.

Is kind of brilliant. Emojis are such a big part of our daily lives. Why is it not in programming?

Well, and like, you take a step back and look, look at what file extensions are, right? They're basically metadata. Right. And so why are we spending all the screen space on them and all this stuff Also, you know, you have them stacked up next to text files and PDF files and whatever else. Like, if you're going to do something cool, you want to stand out. Right. Emojis are colorful, they're visual, they're beautiful.

Right. What's been the response so far from. Is there support on, like, Windows on operating system in displaying, like, File Explorer?

Yeah, yeah. The one problem I've seen is the git doesn't escape it. Right. And so it thinks that the fire emoji is unprintable and so it like, prints out weird hex things if you use the command line Git tool. But everything else, as far as I'm aware, works fine. And I have faith that Git can be improved. So I'm not working.

Git Hub is fine.

GitHub is fine. Yep, GitHub is fine. Visual Studio, Code, Windows, like, all this stuff. Totally ready. Because people have internationalization in their normal part of their path. So this is just like taking the next step, right. Somewhere between. Oh, wow, that makes sense. Cool. I like new things to. Oh, my God, you're killing my baby. Like, what are you talking about? This can never be. Like, I can never handle this. How am I going to type this? Like, all these things? And so this is something where I think that the world will get there. We don't have to bet the whole farm on this. I think we can provide both paths, but I think it'll be great.

When can we have emojis as part of the code, I wonder.

Yeah, so, I mean, lots of languages provide that, so I think that we have partial support for that. It's probably not fully done yet, but yeah, you can do that, for example, in Swift. You can do that for sure. So an example we gave at Apple was the dog Cow. So that's a classical Mac heritage thing. And so you use the dog and the cow emoji together, and that could be your variable name. But of course, the Internet went and made pile of poop for everything.

Yeah.

So, you know, if you want to name your function Pile of Poop, then you can totally go to town and see how that gets through code review.

Okay, so let me just ask a bunch of random questions. So is Mojo primarily Designed for AI or is it a general purpose program?

Yeah, good question. So it's AI first. And so AI is driving a lot of the requirements. And so Modular is building and designing and driving Mojo forward. And it's not because it's an interesting project theoretically to build, it's because we need it. And so at Modular, we're really tackling the AI infrastructure landscape and the big problems in AI and the reasons that it is so difficult to use and scale and adopt and deploy and like all these big problems in AI. And so we're coming at it from that perspective. Now, when you do that, when you start tackling these problems, you realize that the solution to these problems isn't actually an AI specific solution. And so while we're doing this, we're building Mojo to be a fully general programming language. And that means that you can obviously tackle GPUs and CPUs and like these AI things, but it's also a really great way to build numpy and other things like that. Or, you know, just if you look at what many Python libraries are today, often they're a layer of Python for the API and they end up being C and C code underneath them. That's very true in AI. That's true in lots of other domains as well. And so anytime you see this pattern, that's an opportunity for mojo to help simplify the world and help people have.

One thing optimized through simplification by having one thing. So you mentioned Modular. Mojo is the programming language. Modular is the whole software stack.

So just over a year ago, we started this company called Modular. Yeah, What Modular is about is it's about taking AI and up, leveling it into the next generation. Right? And so if you take a step back, what's gone on in the last five, six, seven, eight years is that we've had things like TensorFlow and, and PyTorch and these other systems come in, you've used them, you know this. And what's happened is these things have grown like crazy and they get tons of users, it's in production deployment scenarios, it's being used to power so many systems. I mean, AI is all around us now. Now, it used to be controversial years ago, but now it's, it's a thing. But the challenge with these systems is that they haven't always been thought out with current demands in mind. And so you think about it, when, where were LLMs eight years ago? Well, they didn't exist. Right. AI has changed so much, and a lot of what people are doing today are very different than when these systems were built. And meanwhile, the hardware side of this has gotten into a huge mess. There's tons of new chips and accelerators and every, every big company is announcing a new chip every day, it feels like. And so between that you have like this moving system on one side, moving system on the other side, and it just turns into this gigantic mess, which makes it very difficult for people to actually use AI, particularly in production deployment scenarios. And so what Modular's doing is we're helping build out that software stack to help solve some of those problems, so then people can be more productive and get more AI research into production. Now what Mojo does is it's a really, really, really important piece of that. And so that is, you know, part of that engine and part of the technology that allows us to solve these problems.

So Mojo is a programming language that allows you to do the higher level programming, the low level programming. They do all kinds of programming in that spectrum that gets you closer and closer to the hardware.

So take a step back. So, Lex, what do you love about Python?

Oh boy, where do I begin? What is love? What do I love about Python?

You're a guy who knows love. I know this.

Yes. How intuitive it is. How it feels like I'm writing natural language English, how when I can not just write, but read other people's code, somehow I can understand it faster. It's more condensed than other languages, like ones I'm really familiar with, like C and C. There's a bunch of sexy little features. Yeah, we'll probably talk about some of them, but list comprehensions and stuff like this.

Um, well, so, and, and don't forget the, the entire ecosystem of all the packages.

Oh, yeah, there's probably huge.

Because there's always something. If you want to do anything, there's always a package. Yeah.

So it's not just the ecosystem of the packages and the ecosystem of the humans that do it. That, that, that's a really, that's an interesting dynamic.

That's good.

I think something about the, the usability and the ecosystem makes the thing viral. It grows and then it's a virtuous cycle, I think.

Well, and there, there's many things that went into that. Like, so I think that ML was very. And so I think that TensorFlow and Pytorch and these systems embracing Python really took and helped Python grow. But I think that the major thing underlying it is that Python's like the universal connector. It really helps bring together lots of different systems so you can Compose them and build out larger systems without having to understand how it works. But then what is the problem with Python?

Well, I guess you could say several things, but probably that it's slow.

I think that's usually what people complain about. Right. And so I mean other people complain about tabs and spaces versus curly braces or whatever, but I mean those people are just wrong because it is actually just better to use indentation.

Wow, strong words. So actually on a small tangent, let's actually take that, let's take all kinds of tangents.

Oh come on, Lex, you can push.

Me on, I can take it Design. Listen, I've recently left Emacs for VS code and the kind of hate mail I had to receive because on the way to doing that I also said I've considered Vim and chose not to and went with VS code and just.

Touching on deep religions. Right.

Anyway, Tabs is an interesting design decision and so you've really written a new programming language here. Yes, it is a superset of Python, but you can make a bunch of different interesting decisions here.

Totally, yeah.

And you chose actually to stick with Python as in terms of some of the syntax.

Well, so let me explain why. You can explain this in many rational ways. I think that the annotation is beautiful, but that's not a rational explanation. But I can defend it rationally. First of all, Python 1 has millions of programmers. It is huge. It's everywhere. It owns machine learning. Factually, it is the thing. Second of all, if you look at it, C code, C code, Java, whatever, Swift curly brace languages also run through formatting tools and get indented. And so if they're not indented correctly, first of all, we'll twist your brain around. It can lead to bugs. There's notorious bugs that have happened across time where the indentation was wrong or misleading and it wasn't formatted. Right. And so it turned into an issue. Right. And so what ends up happening in modern large scale code bases is people run automatic formatters. So now what you end up with is indentation and curly braces. Well, if you're going to have the notion of grouping, why not have one thing and get rid of all the clutter and have a more beautiful thing. Also you look at many of these languages, it's like, okay, well you can have curly braces or you can omit them if there's one statement, or you just enter this entire world of complicated design space that objectively you don't need if you have Python style indentation.

So yeah, I would love to actually see statistics on errors made because of indentation, like how many errors are made in Python versus in C that have to do with basic formatting, all that kind of stuff, I would love to see.

I think it's probably pretty minor because once you get, like, you use VS code, I do too. So if you get VS code set up, it does the indentation for you generally. Right. And so you don't, you know, it's actually really nice to not have to fight it. And then what you can see is the editor is telling you how your code will work by indenting it, which I think is pretty cool.

I honestly don't think I've ever. I don't remember having an error in Python because I indented stuff wrong.

Yeah. So, I mean, I think that there's. Again, this is a religious thing and so I can joke about it. And I love, I love to kind of, you know, I realize that this is such a polarizing thing and everybody wants to argue about it. And so I like poking at the bear a little bit. Right. But, but frankly. Right, come back to the first point. Python 1, like, it's huge. It's an AI. It's the right thing for us. Like, we see Mojo as being an incredible part of the Python ecosystem. We're not looking to break Python or change it or quote, unquote, fix it. We love Python for what it is. Our view is that Python is just not done yet. And so if you look at, you know, you mentioned Python being slow. Well, there's a couple of different things that go into that, which we can talk about if you want, but one of them is that it just doesn't have those features that you would use to do C, like programming. And so if you say, okay, well, I'm forced out of Python into C for certain use cases, well, then what we're doing is we're saying, okay, well, why, why is that? Can we just add those features that are missing from Python back up to Mojo, and then you can have everything that's great about Python, all the things you're talking about that you love, plus not be forced out of it when you do something a little bit more computationally intense or weird or hardwarey or whatever it is that you're doing?

Well, a million questions I want to ask, but high level again, Is it compiled or is it an interpreted language? So Python is just in time compilation. What's Mojo?

So Mojo, a complicated answer, does all the things. So it's interpreted, it's jit compiled, and it's statically compiled. And so this is for a variety of reasons. So one of the things that makes Python beautiful is that it's very dynamic. And because it's dynamic, one of the things they added is that it has this powerful metaprogramming feature. If you look at something like Pytorch or tensorflow or even a simple use case like you define a class that has the plus method, you can overload the Dunder methods, like Dunder Add, for example, and then the plus method works on your class. And so it has very nice and very expressive dynamic metaprogramming features. In Mojo, we want all those features to come in. Like, we don't want to break Python, we want it all to work. But the problem is you can't run those super dynamic features on an embedded processor or on a gpu, or if you could, you probably don't want to just because of the performance. And so we entered this question of saying, okay, how do you get the power of this dynamic metaprogramming into a language that has to be super efficient in specific cases? And so what we did was we said, okay, we'll take that interpreter. Python has an interpreter in it, right? Take that interpreter and allow it to run at compile time. And so now what you get is you get compile time metaprogramming. And so this is super interesting and super powerful because one of the big advantages you get is you get Python style expressive APIs, you get the ability to have overloaded operators. And if you look at what happens inside of like Pytorch, for example, with automatic differentiation and Eager mode, and like all these things, they're using these really dynamic and powerful features at runtime. But we can take those features and lift them so that they run at compile time.

Because C has metaprogramming with templates. But it's really messy.

It's super messy. It was accidentally, I mean, different people have different interpretations. My interpretation is that it was made accidentally powerful. It was not designed to be Turing complete, for example, but that was discovered kind of along the way accidentally. Um, and so there have been a number of languages in the space, and so they usually have templates or code instantiation code copying features of various sorts. Some more modern languages or some more new, newer languages, let's say, like, you know, they're fairly unknown. Like Zig, for example, says, okay, well let's take all of those types that you can run it, all those things you can do at runtime and allow them to happen at compile time. And so One of the problems with C, I mean, which is one of the problems with C. There we go. Is wrong words.

We're going to offend everybody, too.

Oh, that's okay. I mean, everybody hates me for a variety of reasons anyways, I'm sure. Right.

I've written it up the way they show love.

I have written enough C code to earn a little bit of grumpiness with C. But one of the problems with it is that the metaprogramming system templates just a completely different universe from the normal runtime programming world. And so if you do metaprogramming and programming, it's just like a different universe, different syntax, different concepts, different stuff going on. And so, again, one of our goals with MoJo is to make things really easy to use, easy to learn. And so there's a natural stepping stone. And so as you do this, you say, okay, well, I have to do programming at runtime, I have to do programming at compile time. Why are these different things?

How hard is that to pull it off? Because that sounds to me, as a fan of metaprogramming in C even, how hard is it to pull that off? That sounds really, really exciting because you can do the same style programming at compile time and at runtime. That's really, really exciting.

Yep. And so, I mean, in terms of the compiler implementation details, it's hard. I won't be shy about that. It's super hard. It requires. I mean, what Mojo has underneath the covers is a completely new approach to the design of the compiler itself. And so this builds on these technologies like MLIR that you mentioned, but it also includes other, like caching and other interpreters and JIT compilers and other stuff like that.

So you have like an interpreter inside.

The compiler, within the compiler. Yes. And so it really takes the standard model of programming languages and kind of twists it and unifies it with the runtime model.

Right.

Which I think is really cool. And to me, the value of that is that, again, many of these languages have metaprogramming features, like they grow macros or something. Lisp, right? Yes, I know your roots. Right. And this is a powerful thing. And so if you go back to Lisp, one of the most powerful things about it is that it said that the metaprogramming and the programming are the same. And so that made it way simpler, way more consistent, way easier to understand, reason about, and it made it more composable. So if you build a library, you can use it both at runtime and compose all the time, which is pretty cool.

Yeah. And for machine learning, I think metaprogramming, I think we could generally say is extremely useful. And so you get features. I mean, I'll jump around, but there's the feature of auto tuning and adaptive compilation just blows my mind.

Yeah, well, so, okay, so let's come back to that. Sure. All right, so what is machine learning? What is a machine learning model? Like you take a Pytorch model off there, right? It's really interesting to me because what Pytorch and what tensorflow and all these frameworks are kind of pushing compute into is they're pushing into this abstract specification of a compute problem which then gets mapped in a whole bunch of different ways. And so this is why it became a metaprogramming problem. You want to be able to say, cool, I have this neural net now run it with batch size 1000, do a mapping across batch or okay, I want to take this problem now run it across a thousand CPUs or GPUs. Right. And so this problem of describe the compute and then map it and do things and transform it, actually it's very profound and that's one of the things that makes machine learning systems really special.

Maybe can you describe autotuning and how do you pull off, I guess adaptive compilation is what we're talking about as metaprogramming. How do you pull off autotune? Is that as profound as I think it is? It just seems like a really mentioned list comprehensions to me from a quick glance at Mojo, which by the way, I have to absolutely like dive in as I realize how amazing this is. I absolutely must dive in. That looks like just an incredible feature for machine learning people.

Yeah, well, so what is auto tuning? So take a step back. Auto tuning is a feature in mojo. Very little of what we're doing is actually research. Like many of these ideas have existed in other systems and other places. And so what we're doing is we're pulling together good ideas, remixing them and making them into hopefully a beautiful system. And so auto tuning. The observation is that it turns out hardware systems, algorithms are really complicated. Turns out maybe you don't actually want to know how the hardware works. Right. A lot of people don't. And so there are lots of really smart hardware people, I know a lot of them where they, they know everything about, okay, the cache size is this and the number of registers is that. And if you use this length of vector, it's going to be super efficient because it maps directly onto what it can do. And like all this kind of stuff, or the GPU has SMS and it has a warp size of whatever. Right? All the stuff that goes into these things where the tile size of a TPU is 128, like these factoids, right? My belief is that most normal people, and I love hardware people also, I'm not trying to offend literally everybody on the Internet, but most programmers actually don't want to know this stuff. And so if you come at it from the perspective of how do we allow people to build both more abstracted but also more portable code? Because it could be that the vector length changes or the cache size changes, or it could be that the tile size of your matrix changes or the number an A100 versus an H100 versus a Volta versus a whatever GPU have different characteristics. A lot of the algorithms that you run are actually the same, but the parameters, these magic numbers you have to fill in end up being really fiddly numbers that an expert has to go figure out. And so what auto tuning does, it says, okay, well guess what, there's a lot of compute out there, right? So instead of having humans go randomly try all the things, or do a grid search, or go search some complicated multidimensional space, how about we have computers do that? Right? And so what auto tuning does is you can say, hey, here's my algorithm. If it's a matrix operation or something like that, you can say, okay, I'm going to carve it up into blocks, I'm going to do those blocks in parallel and I want this, this with 128 things that I'm running on, I want to cut it this way or that way or whatever. And you can say, hey, go see which one's actually empirically better on the system.

And then the result of that, you cache for that system.

Yep.

Save it.

And so come back to twisting your compiler brain, right? So not only does the compiler have an interpreter that used to do metaprogramming, that compiler, that interpreter, that metaprogramming now has to actually take your code and go run it on a target machine, see which one it likes the best, and then stitch it in and then keep going. Right.

So part of the compilation is machine specific.

Yeah. Well, so I mean, this is an optional feature, right? So you don't have to use it for everything. But yeah, if you're. So one of the things that we're in the quest of is ultimate performance.

Yes.

Right. And ultimate performance is important for a couple of reasons. Right? So if you're an enterprise, you're Looking to save costs and compute and things like this. Ultimate performance translates to fewer servers if you care about the environment. Hey, better performance leads to more efficiency. I mean, you could joke and say Python's bad for the environment. And so if you move to Mojo, it's like at least 10x better just out of the box and keep going. Right? But performance is also interesting because it leads to better products. And so in the space of machine learning, if you reduce the latency of a model so that it runs faster, so every time you query the server running the model, it takes less time, well, then the product team can go and make the model bigger. Well, that's actually makes it so you have a better experience as a customer. And so a lot of people care about that.

So for auto tuning for like tile size, you mentioned 128 for TPU, you would specify like a bunch of options to try just in the code, just simple statement. And then you can just set and forget and know depending wherever it compiles, it'll actually be the fastest and.

Yeah, exactly. And the beauty of this is that it helps you in a whole bunch of different ways, right? So if you're building so often, what will happen is that, you know, you've written a bunch of software yourself, right? You, you wake up one day, you say, I have an idea. I'm going to go code up some code. I get to work, I forget about it, I move on with life. I come back six months or a year or two years or three years later, you dust it off and you go use it again in a new environment. And maybe your GPU is different, maybe you're running on a server instead of a laptop, maybe, whatever, right? And so the problem now is you say, okay, well, I mean, again, not everybody cares about performance, but if you do, you say, okay, well, I want to take advantage of all these new features. I don't want to break the old thing though, right? And so the typical way of handling this kind of stuff before is, you know, if you're talking about C templates or you're talking about C with macros, you end up with if defs, you get like all these weird things, get layered in, make the code super complicated, and then how do you test becomes this crazy complexity multidimensional space that you have to worry about. And that just doesn't scale very well.

Actually, let me just jump around before I go to some specific features. Like the increase in performance here that we're talking about can be just insane. You write that Moja can provide a 35,000x speed up over Python. How does it do that?

Yeah, so you can even do more, but we'll get to that. So, first of all, when we say that, we're talking about what's called CPython. It's the default Python that everybody uses. When you type Python 3, that's like typically the one you use, right? CPython is an interpreter. And so interpreters, they have an extra layer of, like, bytecodes and things like this that they have to go read, parse, interpret, and it makes them kind of slow from that perspective. And so one of the first things we do is we move to a compiler. And so just moving to a compiler, getting the interpreter out of the loop is 2 to 5 to 10x speed up, depending on the code. So just out of the gate, just using more modern techniques now, if you do that, one of the things you can do is you can start to look at how CPython started to lay out data. And so one of the things that CPython did, and this isn't part of the Python spec necessarily, but this is just sets of decisions, is that if you take an integer, for example, it'll put it in an object. Because in Python, everything's an object. And so they do the very logical thing of keeping the memory representation of all objects the same. So all objects have a header, they have payload data. And what this means is that every time you pass around an object, you're passing around a pointer to the data. Well, this has overhead. It turns out that modern computers don't like chasing pointers very much. And things like this, it means that you have to allocate the data, means you have to reference count it, which is another way that Python uses to keep track of memory. And so this has a lot of overhead. And so if you say, okay, let's try to get that out of the heap, out of a box, out of an indirection, and into the registers, that's, that's another 10x.

So it adds up. If you, if you're reference counting every single, every, every single thing you create, that adds up.

Yep. And if you look at, you know, people complain about the Python gil, this is one of the things that hurts parallelism. That's because of the reference counting. So the GIL and reference counting are very tightly intertwined in Python. It's not the only thing, but it's very tightly intertwined. And so then you lean into this and you say, okay, cool. Well, modern computers, they can do more than one operation at a time, and so they have vectors. What is a vector? Well, a vector allows you to take one. Instead of taking one piece of data, doing an add or a multiply and then picking up the next one, you can now do 4 or 8 or 16 or 32 at a time. Well, Python doesn't expose that because of reasons. And so now you can say, okay, well, you can adopt that now you have threads, now you have, like, additional things, like you control memory hierarchy. And so what Mojo allows you to do is it allows you to start taking advantage of all these powerful things that have been built into the hardware over time. And it gives, the library, gives very nice features. So you can say, just parallelize this, do this in parallel. Right? So it's very, very powerful weapons against slowness, which is why people have been, I think, having fun, like just taking code and making it fast, because it's just kind of an adrenaline rush to see, like, how fast you can get things.

Before I talk about some of the interesting stuff with parallelization, all that, let's. Let's first talk about, like, the basics. We talked to indentation, right? So this thing looks like Python. It's sexy and beautiful. Like Python, as we mentioned, is it a typed language? So what's the role of types?

Yeah, good question. So Python has types, it has strings, has integers, it has dictionaries and like all that stuff, but they all live at runtime, right? And so because all those types live at runtime in Python, you never, or you don't have to spell them. Python also has like this whole typing thing going on now, and a lot of people use it. Yeah, I'm not talking about that. That's kind of a different thing. We can go back to that if you want. But, but typically the, you know, you just say, I take. I have a def. And my def takes two parameters. I'm going to call them A and B, and I don't have to write a type. Okay, so that is great. But what that does is that forces what's called a consistent representation. So these things have to be a pointer to an object with the object header. And they all have to look the same. And then when you dispatch a method, you go through all the same different paths, no matter what the receiver, whatever that type is. So what Mojo does is it allows you to have more than one kind of type. And so what it does is, allows you to say, okay, cool, I have an object. And objects behave like Python does. And so it's fully dynamic. And that's all great. And for many things, classes like that's all very powerful and very important, but if you want to say, hey, it's an integer and it's 32 bits or 64 bits or whatever it is, or it's a floating point value and it's 64 bits, well then the compiler can take that and it can use that to do way better optimization. And turns out again, getting rid of the indirections, that's huge, means you can get better code completion because you have. Because compiler knows what the type is and so it knows what operations work on it. And so that's actually pretty huge. And so what Mojo does is allows you to progressively adopt types into your program and so you can start again, it's compatible with Python and so then you can add however many types you want, wherever you want them, and if you don't want to deal with it, you don't have to deal with it. Right. And so one of, one of, you know, our opinions on this is that it's not that types are the right thing or the wrong thing, it's that they're a useful thing.

Wait, so it's kind of optional? It's not strict typing, you don't have to specify a type.

Exactly.

Okay, so it's starting from the thing that Python's kind of reaching towards right now with trying to inject types into it.

Yeah, with a very different approach, but. Yes, yes.

What's the different approach? I'm actually one of the people that have not been using types very much in Python.

That's okay. Why did you say it's just.

Well, because I know the importance. It's like adults use strict typing and so I refuse to grow up in that sense. It's a kind of rebellion. But I just know that it probably reduces the amount of errors, even just forget about performance improvements. It probably reduces errors when you do strict typing.

Yeah. So I mean, I think it's interesting if you look at that. Right. And the reason I'm giving you a hard time is that there's this cultural norm, this pressure, there has to be a right way to do things. Grown ups only do it one way. And if you don't do that, you should feel bad. Some people feel like Python's a guilty pleasure or. And it's like when it gets serious, I need to go rewrite it. Right, exactly. Well, I mean, cool. I understand history and I understand kind of where this comes from, but I don't think it has to be a guilty pleasure. So if you look at that, you say, why do you have to rewrite it? Well, you have to rewrite it to deploy. Well, why do you want to deploy? Well, you care about performance, you care about predictability, or you want a tiny thing on the server that has no dependencies, or you have objectives that you're trying to attain. So what if Python can achieve those objectives? So if you want types, well, maybe you want types because you want to make sure you're passing the right thing. Sure, you can add a type if you don't care. You're prototyping some stuff, you're hacking some things out, you're pulling some RAM code off the Internet. It should just work. And you shouldn't be pressured, you shouldn't feel bad about doing the right thing or the thing that feels good. Now, if you're in a team, right, you're working at some massive Internet company and you have 400 million lines of Python code, well, they may have a house rule that you use types. Yeah, right, because it makes it easier for different humans to talk to each other and understand what's going on and bugs at scale, right? And so there are lots of good reasons why you might want to use types, but that doesn't mean that everybody should use them all the time, right? So what Mojo does is it says, cool, well, allow people to use types. And if you use types, you get nice things out of it, right? You get better performance and things like this, right? But Mojo is a full compatible superset of Python, and so that means it has to work without types. It has to support all the dynamic things, has to support all the packages, it has to support for list comprehensions and things like this, right? And so that starting point, I think, is really important. And I think that, again, you can look at why I care so much about this, and there's many different aspects of that, one of which is the world went through a very challenging migration from Python 2 to Python 3. Right? This. Yes. This migration took many years and it was very painful for many teams, Right? And there's a lot of. A lot of things that went on in that. I'm not an expert in all the details and I honestly don't want to be. I don't want the world to have to go through that, right? And, you know, people can ignore Mojo and if it's not their thing, that's. That's cool. But if they want to use Mojo, I don't want them to have to rewrite all their code.

Okay? The superset part is just. I mean, there's so much brilliant stuff here that definitely is Incredible. We'll talk about that. First of all, how's the typing implemented differently in Python versus Mojo? So this heterogeneous flexibility you said is differently implemented?

Yeah. So I'm not a full expert in the whole backstory on types in Python, so I'll give you, I'll give you that. I can give you my understanding. My understanding is basically, like many dynamic languages, the ecosystem went through a phase where people went from writing scripts to writing large scale, huge code bases in Python. And at scale kind of helps to have types people want to be able to reason about interfaces, what, what do you expect? String or an int or like, what these basic things. Right. And so what the Python community started doing is it started saying, okay, let's have tools on the side, checker tools that go and like, enforce invariance, check for bugs, try to identify things. These are called static analysis tools generally. And so these tools run over your code and try to look for bugs. What ended up happening is there's so many of these things, so many different weird patterns and different approaches on specifying the types and different things going on that the Python community realized and recognized. Hey, hey, hey, there's a thing here. And so what they started to do is they started to standardize the syntax for adding types to Python. Now, one of the challenges.