Chris Lattner

Or whatever that means, like in your local function, right?

And so you say, like whether it be in a def, and so you just say x equals hello world, right?

Well, if your string type requires you to allocate memory, then when it's destroyed, you have to deallocate it.

So in Python and in Mojo, you define that with the del method, right?

Where does that get run?

Well, it gets run sometime between the last use of the value and the end of the program.

Like in this, you now get into garbage collection.

You get into like all these long debated, you talk about religions and, 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 define, 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?

This has a bunch of different impacts on, you know, you talk about reference counting optimizations and things like this, a bunch of very low level things.

And so what Mojo does is it has a different approach on that from any language I'm familiar with, where it destroys them as soon as possible.

And by doing that, you get better memory use, you get better predictability, you get tail calls that work, you get a bunch of other things, you get better ownership tracking.

There's a bunch of these very simple things that are very fundamental that are already built in there in Mojo today that are the things that nobody talks about generally, but when they don't work right, you find out and you have to complain about.

Yeah, well, I mean, it's generally trivial.

It's after the last use of it.