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. End of the program. You now get into garbage collection, you get into all these long debated, you talk about religions and trade-offs and things like this. This is a hugely hotly contested world. If you look at C++, the way this works is that if you define a variable or a set of variables within a function, they get destroyed in a last-in, first out order. So it's like nesting. This has a huge problem because if you have a big scope and you define a whole bunch of values at the top and then you use them and then you do a whole bunch of code that doesn't use them, they don't get destroyed until the very end of that scope. And so this also destroys tail calls. So good functional programming, right?

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

  2. So you have a string, right? Whatever that means, like in your local function, right? And so you say, whether it be in a defense hello world, right? Well, if your string type requires you to allocate memory, then once it's destroyed, you have to deallocate it. So in Python and in Mojo, you define that with a Dell method, right? Where does that get run Well, it gets run sometime between the last use of the value.

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

  3. Yeah, and so, but also you look into it's amazing how much is also there, and you take it for granted that a value, if you define it, it will get destroyed automatically. Like that little feature itself is actually really complicated given the way the ownership system has to work and the way that works within Mojo is a huge step forward from what Rust and Swift have done.

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

  4. And so this comes back to the where Mojo came from and the fact that this is your point one, right? And so we're building, so modular is building an AI stack, right? And an AI stack has a bunch of problems working with hardware and writing high-performance kernels and doing this kernel fusion thing I was talking about and getting the most out of the hardware. And so we've really prioritized and built Mojo to solve modular problem. Now, our North Star is build out and support all the things. And so we're making incredible progress. By the way, Mojo is only like seven months old. That's another interesting thing

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

  5. And so this is a again, it's a widely known thing. It's been implemented in Swift and Rust in many languages. So it's not Haskell, which is where everybody learns their tricks from. But we need to implement that, and that'll enable a new level of expressivity.

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

  6. The bigger features are things like traits So traits are when you want to define. So when you get into typed languages, you need the ability to write generics. And so you want to say, I want to write this function, and now I want to work on all things that are arithmetic-like. Well, what is arithmetic-like mean? Well, arithmetic-like is a categorization of a bunch of types. And so again, you can define many different ways, and I'm not going to go into ring theory or something. But you can say it's arithmetic-like if you can add, subtract, multiply, divide it. For example, right? And so what you're saying is you're saying there's a set of traits that apply to a broad variety of types. And so they're all these types arithmetic-like, all these tensors and floating point and integer. And there's this category of types. And then I can define on an orthogonal axis algorithms that then work against types that have those properties.

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

  7. Yeah, it is. So nested functions are joking aside, actually really great. And for certain things, right? And so these are also called closures are pretty cool. And you can pass callbacks. There's a lot of good patterns.

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

  8. Wait a second. Wait a second. I love Lisp. I love Lisp. Okay. Yeah, I was going to say you're afraid of me irritating the whole internet?

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

  9. Alex, I'm merely an implementer, and so this is again one of the trade-offs you get when you decide to build a superset is. You get to implement a full fidelity implementation of the thing that you decided. Good, and so Yeah, I mean, we can complain about the reality of the world and shake our fist, but.

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

  10. Exactly. And so the competitor does all this for you. And I mean, one of the things if you dig into how this stuff works in Python, it gets a little bit more complicated because you have finally blocks, which now you need to go into, do some stuff. Those can also throw in return.

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

  11. Return the variant that is I'm an error, right? So when you get to the call, you say, okay, cool, I called a function. Hey, I know locally I'm in a try block. And so I call the function and then I check to see what it returns. Aha, if it's that error thing jump to the accept block.

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

  12. Actually, start simpler. What happens if it returns? Well, if it returns, it's supposed to go back out and continue executing and then fall off the bottom of the try block and keep going and all's good. If the function throws, you're supposed to exit the current function and then get into the accept clause and then do whatever code's there and then keep following on and going on. And so the way that a compiler like Mojo works is that the call to that function, which happens in the accept block, calls a function, and then instead of returning nothing, it actually returns a variant between nothing and an error. And so if you return normally, fall off the bottom or do a return. You refer nothing, and if you throw an error, you

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

  13. Yeah, so the way to think about it is think about a function that doesn't return anything, just as a simple case, right? And so you have Function one, calls function two, calls function three, calls function four along that call stack that are try blocks. And so if you have function one, calls function two, function two has a try block, then within it, it calls function three. Well, what happens if function three throws?

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

  14. And so, you know, one of the things I learned from Apple and ISO love is the art of API design is actually really profound. I think this is something that Python's also done a pretty good job at in terms of building out this large-scale package ecosystem. It's about having standards and things like this. And so we wouldn't want to enter a mode where there's this theoretical feature that exists in language, but people don't use it in practice. Now, I'll also say one of the other really cool things about this implementation approach is that it can run on GPUs and it can run on accelerators and things like this. And that standard zero cost exception thing would never work on an accelerator. And so this is also part of how Mojo can scale all the way down to little embedded systems and to running on GPUs and things like that.

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

  15. And so, this is actually, I mean, it's a fairly nerdy thing, right? Which is why I love it. But this has a huge impact on the way you design your APIs. In C++. Huge communities turn off exceptions because the cost is just so high, right? And so the zero cost is so high, right? And so that means you can't actually use exceptions in many libraries. And even for the people that do use it, well, okay, how and when do you want to pay the cost? If I try to open a file, should I throw an error? Well, what if I'm probing around looking for something, right? I'm looking it up in many different paths. Well, if it's really slow to do that, maybe I'll add another function that doesn't throw an error or turns an error code instead. And now I have two different versions of the same thing. And so it causes you to fork your APIs.

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

  16. Now, programmers generally don't want to deal with all the typing machinery and pushing around a variant. And so you use all the syntax that Python gives us, for example, try and catch and it functions that raise and things like this. You can put raises decorator on your functions, stuff like this. And if you want to control that, and then the language can provide syntax for it, but under the hood, the way the computer executes it, throwing an error is basically as fast as returning something.

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

  17. Also, it's called zero cost exceptions, but it's not zero cost by any stretch of the imagination because it massively blows out your code, your binary. It also adds a whole bunch of different paths because of structures and other things like that that exist in C++ and it reduces the number of optimizations. It has like all these effects. And so this thing that was called zero cost exceptions really ain't. Now if you fast forward to newer languages and this includes Swift and Rust and Go and now Mojo Well, in Python's a little bit different because it's interpreted, and so it's got a little bit of a different thing going on. Many newer languages say, okay, well, let's not do that zero cost exception handling thing. Let's actually treat throwing an error the same as returning a variant, returning Either the normal result or an error.

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

  18. And so zero cost exception handling the way it works is that it's called zero cost because if you don't throw an exception, there's supposed to be no overhead for the non-error code. And so it takes the airpath out of the common path. It does this by throwing an error extremely expensive. And so if you actually throw an error with a C++ compiler using exceptions, it has to go look up in tables on the side and do all this stuff. And so throwing an error can be like 10,000 times more expensive than referring from a function

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

  19. So, we mean, we use the same as Python. But we implemented a very different way. And so if you look at other languages, like we'll pick on C, our favorite, right? C++ has a thing called zero cost exception handling. In my opinion, something to learn lessons from.

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

  20. Usually. Well, so I mean, it's again lessons learned in looking at the ecosystem, it's really, I mean, I think it's if you study some of these languages over time, like the Ruby community, for example. Now, Ruby is a pretty well-developed, pretty established community, but along their path, they really invested in unit testing. So I think that the Ruby community has really pushed forward the state of the art of testing because they didn't have a type system that caught a lot of bugs at compel time. You can have the best of both worlds. You can have good testing and good types and things like this. But I thought that it was really interesting to see how certain challenges get solved. And in Python, for example, the interactive notebook kind of experiences and stuff like this are really amazing. And if you typo something, it doesn't matter. It just tells you it's fine, right? And so I think that the trade-offs are very different if you're building a large-scale production system versus you're building and exploring a notebook.

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

  21. And I love other Like strict things, right? But I don't want to say that that's the right thing because Python's also very beautiful for hacking around and doing stuff and research and these other cases where you may not want that.

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

  22. It depends again, it depends on your mentality, right? It's not that deaf is Python and FN is mojo has both and it loves both, right? It really depends on Yeah, exactly. Are you playing around and scripting something out? Is it a one-off throwaway script? Cool. Python is great at that.

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

  23. And so what FN does is it turns on, as you say, it's a strict mode. And so it says, okay, well, you have to actually intentionally declare your variables before you use them. That gives you more predictability, more error checking and things like this, but you don't have to use it. And this is a way that Mojo is both compatible because defs work the same way that defs have already worked, but it provides a new alternative that gives you more control and allows certain kinds of people that have a different philosophy to be able to express that and get that.

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

  24. Now, I say some long name equals seventeen. Print out some long name. Oops, I typoed it. Well, the compiler, the Python compiler doesn't know in all cases what you're defining and what you're using. And did you typo the use of it or the definition? And so for people coming from type languages, again, I'm not saying they're right or wrong, but that drives them crazy because they want the compiler to tell them you typoed the name of this thing.

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

  25. So here you get into what is the trade off with the superset? So, superset, you have to, or you really want to be compatible, like if you're doing a superset, you've decided compatibility with existing code is the important thing. Even if some of the decisions they made were maybe not what you would choose. So that means you put a lot of time and compatibility, and it means that you get locked into decisions of the past, even if they may not have been a good thing. Now, systems programmers typically like to control things. And they want to make sure that not all cases, of course, and even systems programmers are not one thing. But often you want predictability. And so one of the things that Python has, for example, as you know, is that if you define a variable, you just say x equals 4. I have a variable named to x.

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

  26. Yeah, well, this is also one of the challenges with the existing Python typing systems is that in practice, like you take subscript, like in practice a lot of these functions, they don't have one signature. They actually have different behavior in different cases. This is why it's difficult to retrofit this into existing Python code and make it play well with typing. You kind of have to design for that.

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

  27. And so every time you call the function, you'd have to say is an integer, is it a string? And so you'd have to figure out where to do that test. And so in a dynamic language, overloading is something you don't have to have. But now you get into a typed language in Python if you subscript with an integer, then you get typically one element out of a collection. If you subscript with a range, you get a different thing out. And so often in typed languages, you'll want to be able to express the fact that cool, I have different behavior depending on what I actually pass into this thing. If you can model that, it can make it safer and more predictable and faster and like all these things.

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

  28. I think it's as simple as that. And so now why do they never fix this? Like, why do they not change it to not be a dictionary? Do other things. Well, you don't really have to in Python because it's dynamic. And so you can say, I get into the function. Now, if I got past an integer, do some dynamic test for it. If it's a string, go do another thing. There's another additional challenge, which is even if you did support overloading, you're saying, okay, well, here's a version of a function for integers and a function for strings. Well, even if you could put it in that dictionary, you'd have to have the caller do the dispatch.

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

  29. So I can speculate. So Python is a dynamic language. The way it works is that. Python and Objective C are actually very similar worlds if you ignore syntax. And so objective C is straight line derived from small talk. Really venerable, interesting language that much of the world has forgotten about, but the people that remember it love it generally, and the way that small talk works is that every object has a dictionary in it, and the dictionary maps from the name of a function or the name of a value within an object to its implementation. And so the way you call a method in an objective C is you say, go look up, the way I call foo is I go look up foo, I get a pointer to the function back, and then I call it. That's how Python works. And so now the problem with that is that the dictionary within a Python object, all the keys are strings.

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

  30. Well, and again, what are the benefits of standards, right? Standards allow you to build these next level up ecosystem and next level up infrastructure and next level up things. And so, again, come back to, I hate complexity. C++ Python is complicated. It makes everything more difficult to deal with. It makes it difficult to port, move code around, work with, all these things get more complicated. And so, I mean, I'm not an expert, but maybe Mojo can help a little bit by helping reduce the amount of C in this ecosystem and make it therefore scale better.

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

  31. Yeah. Maybe that's because GitHub doesn't want to replace Google search. I think there is room for specialized solutions to specific problems. I don't know. I don't know the right answer for GitHub either. They can go figure that out.

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

  32. YouTube calls it. Well, I mean, it's kind of funny because this is one of the challenges of these intentionally decentralized communities. And so, I don't know what the right answer is for Python. I mean, there are many people that, I don't even know the right answer for Mojo. There are many people that would have much more informed opinions than I do. But it's interesting if you look at this, right? Open source communities, there's Git. Git is a fully decentralized, anybody can do it any way they want, but then there's GitHub. And GitHub centralized commercial in that case, right? Thing really help pull together and help solve some of the discovery problems and help build a more consistent community. And so maybe there's opportunities for something.

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

  33. So, if you have this problem where you have code split between Python and C, now not only do you have to package the C code, you have to build the C code. C doesn't have a package manager, right? C doesn't have a dependency versioning management system, right? And so I'm not experienced in the state of the art and all the different Python package managers, but my understanding is that's a massive part of the problem. And I think Mojo solves that part of the problem directly heads on. Now, one of the things I think we'll do with the community, and this isn't, again, we're not solving all the world's problems at once. We have to be kind of focused to start with, is that I think that we will have an opportunity to reevaluate packaging. Maybe there's other innovations we can bring together and maybe we can help solve that.

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

  34. Or you want to build on top of a bunch of other people's packages, and then they get updated, it's like this. Now, I'm not an expert in this, so I don't know the answer. I think this is one of the reasons why it's great that we work as a team, and there's other really good and smart people involved. But one of the things I've heard from smart people who've done a lot of this is that the packaging becomes a huge disaster when you get the Python and C together.

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

  35. So that's another really interesting problem that I knew about, but I didn't understand how big of a problem it was. Python packaging. Lot of people have very big pain points and a lot of scars with Python packaging. Oh

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

  36. And so as a consequence of that, he's always, he again, he makes time, but he spends time to understand things at a depth that a lot of people don't. And as you say, he then brings it and teaches people And his mission is to help lift his website says making AI uncool again. It's about, forget about the hype. It's actually practical and useful. Let's teach people how to do this, right? Now the problem Jeremy struggled with is that he's pushing the envelope. Research isn't about doing the thing that is staying on the happy path or the well-paved road. And so a lot of the systems today have been these really fragile, fragmented things or special cases in this happy path. And if you fall off the happy path, you get eaten by an alligator.

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

  37. Right? And he'll go survey and understand what are all the activation functions and the trade offs and why is it that everybody that does. This model picked that thing.

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

  38. So, a lot of AI and AI research ends up being that it has to go fast enough to get scale. So a lot of people don't actually care about performance, particularly on the research side, until it allows them to have a bigger data set. And so suddenly now you care about distributed compute and all these exotic HPC. You don't actually want to know about that. You just want to be able to do more experiments faster and do some with bigger data sets, right? And so Jeremy has been really pushing the limits. And one of the things I'll say about Jeremy, and there's many things I could say about Jeremy because I'm a fanboy of his, but it fits in his head. Jeremy actually takes the time where many people don't to really dive deep into why is the beta parameter of the atom optimizer equal to this.

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

  39. Exactly. And so, I mean, the first time, so I met Jeremy pretty early on, but the first time I sat up and I'm like, This guy is ridiculous is when I was at Google and we were bringing up TPUs, and we had a whole team of people. And there was this competition called Dawn Bench of who can train Image Right. Yes And Jeremy and one of his researchers crushed Google, not through sheer force of the amazing amount of compute and the number of TPUs and stuff like that. That he just decided that progressive imagery sizing was the right way to train the model. If you were epochs faster and make the whole thing go vroom, right? Like, this guy is incredible. So you can say, anyways, come back to where's Mojo coming from? Chris finally listened to Jeremy.

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

  40. Yeah, and also I would also say that let me cast blame out to people who deserve it These terrible people who. Convinced me to do some of this. Jeremy Howard That guy

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

  41. Here's a pretty credible team that has built some languages and some tools before. And so they have some lessons learned and are tackling some of the deep problems in the Python ecosystem and giving it the love and attention that it should be getting. And I think people got very excited about that. And so if you look at that, I mean, I think people are excited about ownership and taking a step beyond Rust, right? And there's people that are very excited about that. There's people that are excited about just I made Game of Life go 400 times faster, right? And things like that. And that's really cool. There are people that are really excited about the, okay, I really hate writing stuff in C++. Save me.

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

  42. Yeah, yeah. Well, so I mean, I've been very pleased. In fact, I mean, we've been massively overwhelmed with response, which is a good problem to have. It's kind of like a success disaster. A sense, right? And so, I mean, if you go back in time, when we started modular, which is just not yet a year and a half ago, so it's still a pretty new company, new team, small but very good team of people. We started with extreme conviction that there's a set of problems that we need to solve. And if we solve it, then people will be interested in what we're doing. But again, you're building in basically secret, you're trying to figure it out. The creation's a messy process. You're having to go through different paths and understand what you want to do and how to explain it. Often when you're doing disruptive and new kinds of things, just knowing how to explain it is super difficult, right? And so when we launched, we hoped people would be excited. But, you know, I'm an optimist, but I'm also don't want to get ahead of myself. And so when people found out about Mojo, I think their heads exploded a little bit.

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

  43. Two months is worth waiting. And so doing it right and not being overwhelmed with technical debt and things like this is, again, war wounds, lessons learned, whatever you want to say, I think is absolutely the right thing to do, even though right now people are very frustrated that you can't download it or it doesn't have feature X or something like this.

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

  44. Process. And so, what we're doing is we're not launching it when it's hopefully azero.9 with no testers. Launching it and saying it's 0.1, right? And so we're saying expectations of saying, okay, well, don't use this for production. If you're interested in what we're doing, we'll do it in an open way. And we can do it together, but don't use it in production yet. Like, we'll get there, but let's do it the right way. And I'm also saying we're not in a race. The thing that I want to do is build the world's best thing. Right, because if you do it right and it lifts the industry, it doesn't matter if it takes an extra two months

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

  45. No, what that meant practically is that the push from launch to, first of all, the fall, but then to 2.0 and 3.0 and all the way forward was super painful for the engineering team and myself. It was very stressful. The developer community was very grumpy about it because they're like, okay, well, wait a second. You're changing and breaking my code. And like, we have to fix the bugs. And it was just a lot of tension and friction on all sides. There's a lot of technical debt in the compiler because we have to run really fast. You have to go implement the thing and unblock the use case and do the thing. And you know it's not right, but you never have time to go back and do it right. I'm very proud of the Swift team because they've come, I mean, we, but they came so far and made so much progress over this time since launch, it's pretty incredible. And SWIFT is a very, very good thing. But I just don't want to do that again, right? And so.

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

  46. It was also very exciting because everybody was excited about that. The other thing I learned is that when that happened, roughly every software engineer who did not know about the project at Apple, their head exploded when it was launched because they didn't know it was coming. And so they're like, wait, what is this? I signed up to work for Apple because I love Objective-C. Why is there a new thing?

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

  47. So a secret. Apple's good at secrecy, and it was a secret project. And so we launched this at WWC, a bunch of Hoopla and excitement, and said, developers are going to be able to develop and submit apps to the App Store in three months. Several interesting things happened, right? So first of all, we learned that, A, it had a lot of bugs. It was not actually production quality. And it was extremely stressful in terms of trying to get it working for a bunch of people. And so, what happened was we went from zero to I don't know how many developers Apple had at the time, but a lot of developers overnight and they ran to a lot of bugs and it was really embarrassing and it was very stressful for everybody involved, right?

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

  48. That's what everybody expects. And so we're working on that right now. And so we just want to make sure that we do it right. And I think this is one of the lessons I learned from Swift also, by the way, is that when we launch Swift, gosh, it feels like forever ago. It was 2014. And it was super exciting. I and we, the team, had worked on Swift for a number of years in secrecy. And four years into this development roughly of working on this thing, at that point, about 250 people at Apple knew about it.

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

  49. Browser. And so, what that's running on Yeah, what that's drawing on is that's running on cloud VMs. And so you share a machine with a bunch of other people. But it turns out there's a bunch of them now because there's a lot of people. And so what you're doing is you're getting free compute and you're getting to play with this thing. And kind of a limited controlled way so that we can make sure that it doesn't. Totally crash and be embarrassing, right Now, a lot of the feedback we've gotten is people want to download it locally. So we're working on that right now.

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

  50. Yeah, so right now here we are two weeks after launch. We decided that, okay, we have this incredible set of technology that we think might be good, but we have not given it to lots of people yet. And so we were very conservative and said, let's put it in a workbook so that if it crashes, we can do something about it. We can monitor and track that, right? And so again, things are still super early, but we're having one person a minute sign up with over 70,000 people two weeks in. It's kind of crazy.

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