YouSaid · the spoken record

Chris Lattner

lines on the record
301
first
2023-06-02
most recent
2023-06-02
sittings or episodes
1
sources
podcast

Every line below is reproduced as it was said and linked to the record it came from. Nothing here is summarised or generated. Directory · Search · Corrections

  1. Yeah. So let me take a step back and talk about status quo. Okay. And so if you go back to TensorFlow 1, PyTorch 1, this kind of time frame, and have all evolved and gotten way more complicated. So let's go back to the glorious simple days, these things basically were CPUs and CUDA. And so, what you do is you say, Go do a dense layer, and a dense layer has a matrix multiplication in it, right? And so when you say that, you say, go do this big operation, a matrix multiplication, and if it's on a GPU, kick off a CUDA kernel. If it's on a CPU, go Like an Intel algorithm or something like that with the Intel MKO. Now, that's really cool if you're either NVIDIA or Intel, but then more hardware comes in. And on one axis, you have more hardware coming in. On the other hand, you have an explosion of innovation in AI.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  2. So, you know, if you look at this mission, you need a syntax. So, yeah, she needed programming language, right? And we wouldn't have to build the programming language if one existed. So, if Python was already good enough, then cool. We would just used it. We're not just doing very large scale expensive engineering projects for the sake of it. It's to solve a problem, right? It's also about accelerators. It's also about exotic numerics and BFLOT 16 and matrix multiplications and convolutions and this kind of stuff. Within the stack, there are things like kernel fusion. It's a esoteric but really important thing that leads to much better performance and much more general research hackability together.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  3. Well, so it's not really about a programming language. I mean, the programming language is a component of the mission. And the mission is not literal, but our joking mission is to save the world from terrible AI software.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  4. And because there are all these point solutions, it means that as your product evolves, you have to switch different technology stacks or switch to different vendor. And what that does is that slows down progress.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  5. Right? I mean, again, I'm generally a software person too. I love hardware, but software people want to build applications and products and solutions that scale over many years. They don't want to build a solution for one generation of hardware with one vendor's tools. And because of this, they need something that scales with them. They need something that works on cloud and mobile. Because their product manager said, hey, I wanted to have lower latency, and it's better for personalization or whatever they decide, right? Products evolve. And so the challenge with the machine learning technology and the infrastructure we have today in the industry is that it's all these point solutions.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  6. And you look at accelerators. Well, we know there's a bunch of different weird kind of accelerators, but they actually cluster together. And you look at GPUs. Well, there's a couple of major vendors of GPUs, and they maybe don't always get along, but their architectures are very similar. You look at CPUs. CPUs are still super important for the deployment side of things. You see new architectures coming out from all the cloud providers and things like this, and they're all super important to the world, but they don't have the 30 years of development that the entrenched people do, right? And so what modular can do is we're saying, okay, all this complexity. It's not bad complexity. It's actually innovation, right? And so it's innovation that's happening. And for good reasons, but I have sympathy for the poor software people.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  7. It's incredible. And so you look at the technology that goes into that, and the algorithms are actually quite general. And so lots of other hardware out there and lots of other teams out there don't have the sophistication or maybe the years working on it or the budget or whatever that Google does, right? And so they should be getting access to the same algorithms, but they just don't have that, right? And so what modular is doing is we're saying. Cool. This is not research anymore. We've built auto tuning in many systems. We've built programming languages. And so have implemented C++, have implemented Swift, have implemented many of these things. And so it's hard, but it's not research.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  8. And nobody's been given a chance to actually do that step back. And so we as an industry, we didn't take two steps forward. We took like 18 steps forward in terms of all this really cool technology across compilers and systems and runtimes and heterogeneous compute and all this kind of stuff. And all this technology has been I wouldn't say beautifully designed, but it's been proven in different quadrants. You know, you look at Google with TPUs, massive, huge exaflops of compute strapped together into machines that researchers are programming in Python in a notebook. That's huge. That's amazing.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  9. Right. And why is that? Well, it's because, again, these systems have been built up over many years. They haven't been rethought. There hasn't been a first principles approach to this. And so what Modular is doing is we're saying, okay, we've built many of these things. So I've worked on TensorFlow and TPUs and things like that. Other folks on our team worked on PyTorch Core. We've worked on Onix Runtime. We've worked on many of these other systems. And so built systems like the Apple accelerators and all that kind of stuff. team is quite amazing. And so one of the things that roughly every modular is grumpy about is that when you're working on one of these projects, you have a first order goal. Get the hardware to work. Get the system to enable one more model. This product out the door, enable the specific workload or make this problem for this product team, right?

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  10. Also, huge amounts of complexity. It turns out that all the cloud providers have all their very weird but very cool hardware for networking and all this kind of stuff. And it's all very complicated. People aren't using that. You look at classical serving. There's this whole world of people who know how to write high-performance servers with zero copy networking and all this asynchronous IO and all these fancy things in the serving community. Very little that has pervaded into the machine learning world.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  11. All these accelerators, all these software stacks that go with the accelerator, all these massive complexity over there. You look at what's happening on the modeling side. Massive amount of complexity. Like things are changing all the time. People are inventing, it turns out, the research is not done, right? And so people want to be able to move fast. Transformers are amazing, but there's a diversity even within transformers. And what's the next transformer? And you look into serving.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  12. The bitter thing that we have to destroy that we're all struggling with, and it's like fish can't see water, it's complexity.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  13. Exactly doing some OGP. Yeah, Alex Net, right? The major breakthrough. And the world has changed, right? And so now the challenge is that TensorFlow PyTorcy systems, they weren't actually designed for LLM. So that was not a thing. And so where Tensefield actually has amazing power in terms of scale and deployment and things like that. And I think Google is, I mean, maybe not unmatched, but they're incredible in terms of their capabilities and gigantic scale. Many researchers using PyTorch, right? And so PyTorch doesn't have those same capabilities. And so what Modular Can does it can help with that. Now, if you take a step back and say, like, what is modular doing? So modular has a bitter enemy that we're fighting against in the industry. And it's one of these things where everybody knows it, but nobody is usually willing to talk about it.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  14. You look at serving models. Well, a gigantic model won't fit on one machine. And so now you have this model. It's written in Python. It has to be rewritten in C++. Now it also has to be carved up so that half of it runs on one machine, half of it runs on another machine. Or maybe it runs on. So now suddenly the complexity is exploding, right? And the reason for this is that if you look into TensorFlow PyTorch, these systems, they weren't really designed for this world, right? They were designed for back in the day when we were starting and doing things where it was a different, much simpler world. Like you want to run ResNet 50 or some ancient model architecture like this, it was a completely different world than

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  15. It's not atypical, right? I talk to lots of people, and you talk about VPF software at some internet company trying to deploy a model. And they're like, why do I need a team of 45 people? It's so easy to train a model. Why can't I deploy it? And if you dig into this, every layer is problematic. So if you look at the language piece, I mean, this is tip of the iceberg. It's a very exciting tip of the iceberg for folks, but you've got Python on one side and C++ on the other side. Python doesn't really deploy. I mean, can theoretically, technically in some cases, but often a lot of production teams will want to get things out of Python because they get better performance and control and whatever else. So Mojo can help with that.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  16. Anything about the hardware or deployment or C or things like this, right? And so what's happened is you get people who train the model, they throw it over the fence, and then you have people that try to deploy the model. Well, every time you have a team A does X, they throw it over the fence and Team Y does B does Y like you have a problem because of course it never works the first time. And so you throw over the fence, they figure out, okay, it's too slow, won't fit, doesn't use the right operator, the tool crashes, whatever the problem is, then they have to throw it back over the fence. And every time you throw a thing over a fence, it takes three weeks of project managers and meetings and things like this. What we've seen today is that getting models in production can take weeks or months.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  17. TensorFlow is all about graphs, PyTorch, I think pretty unarguably ended up winning, and why did it win? Mostly because of usability. And the usability of PyTorch is, I think, huge. And I think, again, that's a huge testament to the power of taking abstract theoretical technical concepts and bring it to the masses. Now, the challenge with what the TensorFlow versus the PyTorch design points was that TensorFlow is kind of difficult to use for researchers, but it was actually pretty good for deployment. PyTorch is really good for researchers. It kind of is not super great for deployment, right? And so I think that we as an industry have been struggling. And if you look at what deploying a machine learning model today means, is that you'll have researchers who are, I mean, wicked smart, of course, but they're wicked smart at model architecture and data and calculus. They're wicked smart in various domains.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  18. Yeah, so one of the really interesting tensions. So there's a whole bunch of stuff that goes into that. If you go back and replay the history of machine learning, the brief, most recent history of machine learning, because this is, as you know, a very deep. I knew Lex when he had an AI podcast. Right. So if you look at just TensorFlow and PyTorge, which is pretty recent history in the big picture, right?

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  19. I'm super inspired by the fact that, you know, on the face of this, those machine learning people invented this idea of a tensor. And was the tensor? A tensor An arithmetic and algebraic concept. It's like an abstraction around a gigantic parallelizable data set. Right, and because of that, and because of things like Tensville and PyTorch, we're able to say, okay, well, express the math of the system. Enables you to automatic differentiations, enables you to do all these cool things. And it's an abstract representation because you have that abstract representation, you can now map it onto these parallel machines without having to control, okay, put that byte here, put that byte there, put that byte there. And this has enabled an explosion in terms of AI, compute, accelerators, like all the stuff. And so that's super, super exciting.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  20. Moore Sloss' idea that computers for a long time, single thread performance just got faster and faster and faster and faster for free. But then physics and other things intervened and power consumption, like other things started to matter. And so what ended up happening is we went from single core computers to multi-core. Then we went to accelerators. This trend towards specialization of hardware is only going to continue. For years, us programming language nerds and compiler people have been saying, okay, well, how do we tackle multicore, right? For a while, it was like multi-core is the future. We have to get on top of this thing. Then it was multi-core is the default. What are we doing with this thing? And then it's like there's chips with hundreds of cores in them. What happened, right? And so.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  21. So, this is where you jump into again, you zoom out and get out of programming languages or compilers, and you just look at what the industry has done, my mind is constantly blown by this, right? And you look at what Moore's Law.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  22. But if you talk to a normal Python, a typical Python programmer, you're typically not thinking about this, right? This is a lower level of abstraction. Now, if you talk to a C++ programmer, certainly if you talk to a Rust programmer, again, they're not weird. They're delightful. These are all good people, right? Those folks will think about all the time. And so I look at this as there's a spectrum between very deep, low level systems. I'm going to go poke the bits and care about how they're laid out in memory all the way up to application and scripting and other things like this. And so it's not that anybody's right or wrong. It's about how do we build one system that scales.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  23. So, okay, well, what happens? How do you copy a database handle? Do you copy the whole database? That's not something you necessarily want to do. There's a lot of types like that where you want to be able to say that they are uniquely owned. There's always one of this thing. And or if I create a thing, I don't copy it. And so, what Mojo allows you to do is it allows you to say, hey, I want to pass around a reference to this thing without copying it. And so it has borrowed conventions. So you can say you can use it, but you don't get to change it. You can pass it by mutable reference. And so if you do that, then you can get a reference to it, but you can change it. And so it manages all that kind of stuff.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  24. Things like this, right? So these types you can't necessarily copy. Sometimes you can't necessarily even move them to a different address. And so what Mojo allows you to do is it allows you to express, hey, I don't want to get a copy of this thing. I want to actually just get a reference to it. And by doing that, what you can say is you can say, okay, if I'm defining something weird, like an atomic number or something, it's like, it has to be an atomic number is an Aryan memory that multiple threads can access at a time without locks. And so the definition of an atomic number is multiple different things have to be poking it. Therefore, they have to agree on where it is. So you can't just like move it out from underneath one because it kind of breaks what it means. And so that's an example of a type that you can't even copy. You can't move. Once you create it, it has to be where it was, right? Now, if you look at many other examples, like a database handle, right?

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  25. Yeah. So if you go deep into systems programming land, this isn't, again, this is not something for everybody, but if you go deep into systems programming land, what you encounter is you encounter these types that get weird. So if you're used to Python, you think about everything I could just copy it around. I can go change it and mutate it and do these things. And it's all cool. If you get into systems programming land, you get into these things like I have an atomic number or I have a mutex or I have a uniquely owned database handle.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  26. And so there's a whole system called ownership. And so, this is related to work done in the Rust community. Also, the SWIFT community has done a bunch of work, and there's a bunch of different other languages that have all kind of C actually has copy constructors and destructors and things like that. And C++ has everything. So it has move constructors. It has this whole world of things. And so this is a body of work that's kind of been developing for many, many years now. And so Mojo takes some of the best ideas out of all these systems and remixes it in a nice way so that you get the power of something like the Rust programming language, but you don't have to deal with it when you don't want to, which is a major thing in terms of teaching and learning and being able to use and scale these systems.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  27. And so you have to make sure that you're efficient and you transfer ownership instead of duplicating references and things like that, which is a very low level problem. You also have to adopt this and you have to build these data structures. And so if you say Mojo has to be compatible with Python, so of course the default list is a reference semantic list that works the way you'd expect in Python. But then you have to design a value semantic list. And so you just have to implement that. And then you implement the logic within. And so the role of the language here is to provide all the low-level hooks that allow the author of the type to be able to get and express this behavior without forcing it into all cases or hard coding this into the language itself.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  28. Yeah, well, so you need a couple of things. So, this concept has existed in many different worlds, and so again, it's not novel research at all, right? The magic is getting the design right so that you can do this in a reasonable way. And so there's a number of components that go into this. One is when you're passing around, so we're talking about Python and reference counting at the expense of doing that, when you're passing values around, you don't want to do extra reference counting for no good reason.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  29. But we want to do that lazily. And so what we do is we say, okay, if you pass something into a function, it doesn't actually make a copy. What it actually does is it just increments a reference to it. And if you pass around, you stick in your database. It can go in the database, you own it, and then you come back out of the stack. Nobody's copied anything. You come back out of the stack, and then the caller lets go of it. Well, then you've just handed it off to the database. You've transferred it, and there's no copies made. Now, on the other hand, if your coworker goes and hands you a record and you pass it in, you stick it in the database, and then you go to town and you start modifying it, what happens is you get a copy lazily on demand. And so what this does is gives you copies only when you need them. So it defines away the bugs, but it also generally reduces the number of copies in practice.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  30. Every time you add it. And so what ends up happening is you say, okay, I will do what's called a defensive copy inside the database. And then that way, if somebody passes something in, I will have my own copy of it. And they can go do whatever and they're not going to break my thing. Okay, this is usually the two design patterns. If you look in PyTorch, for example, this is cloning a tensor, there's a specific thing and you have to know where to call it, and if you don't call in the right place, you get these bugs This is state of the art, right? Different approach. So it's used in many languages. So I worked with it in Swift is you say, okay, well, let's provide value semantics. And so we want to provide the view that you get a logically independent copy.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  31. You just have to kind of know that, right? And so you roll out version one of the database, you just kind of have to know that. Of course, Lex uses his own database, right? Right, because you built it. You understand how this works, right? Somebody else joins the team. They don't know this. And so now they suddenly get bugs. You're having to maintain the database, you shake your fist. You argue the 10th time this happens, you're like, okay, we have to do something different. And so what you do is you go change your Python code and you change your database class to copy the record.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  32. Not magic. It's just actually pretty cool. Well, so first before we talk about how that works, let's talk about how it works in Python, right? So in Python, To find a person class, or maybe a person class is a bad idea. You define a database class, right? And a database class has an array of records, something like that, right? And so the problem is that if you pass in a record or a class instance into the database, it'll take a hold of that object and then it assumes it has it. And if you're passing an object in, you have to know that that database is going to take it, and therefore you shouldn't change it after you put it in the database. This is just a problem

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  33. Generally not, if you implement it the right way, but it requires a lot of very low level getting the language right bits.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  34. Collections like arrays, like dictionaries, also tensors and strings and things like this that are much higher level and make them behave like proper values. And so it makes it look like if you pass these things around, you get a logical copy of all the data. If I pass you an array, it's your array. You can go do what you want to it. You're not going to hurt my array. Now, that is an interesting and very powerful design principle. It defines away a ton of bugs. You have to be careful to implement it in an efficient way.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  35. Yeah, so one of the things that is useful, and it's not always required, but it's useful, is knowing whether something can change out from underneath you. And so in Python, you have a pointer to an array, right? And so you pass that pointer to an array around to things. If you pass into a function, they may take that and scroll away in some other data structure. So you get your array back and you go to use it. Now somebody else is like putting stuff in your array. How do you reason about that? Gets to be very complicated and at least a lot of bugs. And so one of the things that again this is not something Mojo forces on you, but something that Mojo enables is a thing called value semantics. And what value semantics do is they take

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  36. Or something, and you look at this, and it's like, okay, well, how different are we We all want beautiful things. We all want something that's nice. We all want to be able to work together. We all want our stuff to be used, right? And so if we can help heal that, now I'm not optimistic that all people will use Mojo and they'll stop using C++. That's not my goal, right? But if we can heal some of that, I think that'd be pretty cool.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  37. So here's the test. Again, it's super funny for something that's only been out for two weeks, right? People are so impatient, right? But, okay, cool. Let's fast forward a year. Like in a year's time, Mojo will be actually quite amazing and solve tons of problems and be very good. People still have these problems. And so you look at this and you say, and the way I look at this at least, is to say, okay, well, we're solving big longstanding problems. To me, I, again, working on many different problems, I want to make sure we do it right. There's a responsibility you feel because if you mess it up, there's very few opportunities to do projects like this and have them really have impact on the world. If we do it right, then maybe we can take those feuding armies and actually heal some of those wounds.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  38. So it's very cool. But what that means is that 10,000, 11,000 people will want something different. And so what we've done is we've tried to say, okay, cool, here's our roadmap. And the roadmap isn't completely arbitrary. It's based on here's the logical order in which to build these features or add these capabilities and things like that. And what we've done is we've spun really fast on bug fixes. And so we actually have very few bugs, which is... Cool? I mean, actually, for projects in the state, but then what we're doing is we're dropping in features very deliberately.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  39. And so, yes, it can be frustrating, can be challenging for lots of people involved. If you mention our Discord, we have over 10,000 people on the Discord, 11,000 people or something. Keep in mind we released Mojo like two weeks ago.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  40. Had the language monk sitting in the cloister up on the hilltop, beavering away trying to build something. But in my experience, you get something that's way better if you work with the community.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  41. So I've been doing open development and community stuff for decades now. Somehow this has happened to me. So I've learned some tricks. But the thing that always gets me is I want to make people happy. And so this is maybe not all people all happy all the time, but generally I want people to be happy, right? And so The challenge is that again, we're tapping into some long, some deep seated, long tensions and pressures, both in the Python world but also in the AI world and the hardware world and things like this. And so people just want us to move faster. And so again, our decision was let's release this early. Let's get people used to it or access to it and play with it. And let's build in the open, which we could have.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  42. Yep. That's very fair. It is very useful, but it's very useful if you're super low level programmer right now. And what we're doing is we're working our way up the stack. And so the way I would look at Mojo today in May in 2023 is that it's like a 0.1. So I think that a year from now, it's going to be way more interesting to a variety of people. But what we're doing is we decide to release it early so that people can get access to it and play with it and we can build it with the community. have a big roadmap fully published being transparent about this and a lot of people are involved in this stuff and so what we're doing is we're really optimizing for building this thing the right way and building it the right way is kind of interesting working with the community because everybody wants it yesterday and so sometimes it's kind of you know there's some dynamics there but I think it's the right thing

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  43. Yeah, so we're still building all that stuff out, so we provide integers and floats and all that kind of stuff. We also provide buffers and tensors and things like that that you'd expect in an ML context. Honestly, we need to keep designing and redesigning and working with the community to build that out and make that better. That's not our strength right now. Give us six months or a year, and I think it'll be way better. But the power of putting in the library means that we can have teams of experts that aren't compiler engineers that can help us design and refine and drive this forward.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  44. And so, if you look at certain other languages like C, one I also love and use a lot, int is hard coded the language. But complex is not. And so it was kind of weird that you have this STD complex class, but you have int. And Complex tries to look like a natural numeric type and things like this. But integers and floating point have these special promotion rules and other things like that that are magic and they're hacked into the compiler. And because of that, you can't actually make something that works like the built-in types.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  45. And so, what Mojo does is says, okay, well, we can have this notion of structs. So you have classes in Python. Now you can have structs. Classes are dynamic. Structs are static. Cool. We can get high performance. We can write C++ kind of code with structs if you want. These things mix and work beautifully together. But what that means is that you can go and implement strings and ints and floats and arrays and all that kind of stuff in the language. And so that's really cool because to me as idealizing compiler language type of person, what I want to do is I want to get magic out of the compiler and put in the libraries. Because if somebody can build an integer that's beautiful and has an amazing API and does all the things you'd expect an integer to do, but you don't like it, maybe you want a big integer. Maybe you want to like sideways integer. I don't know. What all the space of integers are. Then you can do that.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  46. Is pretty hardcore in terms of what it tries to do in the language, which is the philosophy there is that we Again, if you look at Python, Python's a beautiful language because it's so extensible. All of the different things in Python, like for loops and plus and all these things can be accessed through these underbar, unbar methods. So you have to say, okay, if I make something that is super fast, I can go all the way down to the metal. Why do I need to have integers built into the language?

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  47. Exactly. And this all comes back to the design principle, they're kind of hints. The definition is a little bit murky. It's unclear exactly the interpretation in a bunch of cases. And so because of that, you can't actually, even if you want to, it's really difficult to use them to say it is going to be an int. And if it's not, it's a problem. Right, a lot of code would break if you did that. So in Mojo, right? So you can still use those kind of type annotations, it's fine. But in Mojo, if you declare a type and you use it, then it means it is going to be that type. And the compiler helps you check that and force it, and it's safe. And it's not best effort hint kind of a thing.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  48. Also, because they're added late and they're not checked by the Python interpreter, it's always kind of more of a hint than it is a requirement. Also, the CPython implementation can't use them for performance.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  49. So, according to the Python spec, you can write pretty much anything in a type position. And technically, you can write any expression. Now, that's beautiful because you can extend it. You can do cool things. You can build your own tools. You can build your own house linter or something like that, right? But it's also a problem because any existing Python program may be using different tools and they have different interpretations. And so if you adopt somebody's package into your ecosystem, try to run the tool you prefer. It may throw out tons of weird errors and warnings and problems just because it's incompatible with how these things work.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source

  50. And so, what they started to do is they started to standardize the syntax for adding types to Python. Now, one of the challenges that they had is that they're coming from kind of this fragmented world where there's lots of different tools, they have different trade-offs and interpretations, and the types mean different things. And so if you look at types in Python, according to the Python spec, the types are ignored.

    2023-06-02 · Lex Fridman Podcast · #381 – Chris Lattner: Future of Programming and AI · IDENTIFIED FROM THE TRANSCRIPT · source