Chris Lattner

But as the language gets more mature, in parallel with that, you have new people starting new projects.

So when the language is mature and somebody's starting a new project, that's when they say, okay, cool, I'm not dealing with a million lines of code.

I'll just start and use the new thing for my whole stack.

Now the problem is, again, you come back to where communities and where people that work together, you build a new subsystem or a new feature or a new thing in Swift or you build a new thing in Mojo, then you want to end up being used on the other side.

And so then you need to work on integration back the other way.

And so it's not just Mojo talking to Python, it's also Python talking to Mojo.

And so what I would love to see, and I don't want to see this next month, but what I want to see over the course of time is I would love to see people that are building these packages, like NumPy or TensorFlow, these packages that are half Python, half C++,

And if you say, okay, cool, I want to get out of this Python C++ world into a unified world, and so I can move to Mojo, but I can't give up all my Python clients, because these libraries get used by everybody, and they're not all going to switch all at once, and maybe never, right?

Well, so the way we should do that is we should vend Python interfaces to the Mojo types.

And that's what we did in Swift, and it worked great.

I mean, it was a huge implementation challenge for the compiler people, right?

But there's only a dozen of those compiler people and there are millions of users.

And so it's a very expensive, capital intensive, like skill set intensive problem.

But once you solve that problem, it really helps adoption.

It really helps the community progressively adopt technologies.

And so I think that this approach will work quite well with the Python and the Mojo world.

All right, so take a step back.

So I wear many hats.

So you're angling in on the Mojo side.

Yes.