So they should be used in some areas and not used in others.

If you remember you when you were back in school, they used to go in and teach you the equations.

Why is equal to X squared minus one?

Either your calculation.

And then you figured out what?

Why was on DDE that worked fine until you started teaching it to program.

All of a sudden, when they were teaching you to program, what you got was X is equal to X squared minus one, and all of a sudden they introduced mutability into the holy creation where you had values.

But then you went in and change the values.

This started causing kind of confusion.

It's wrong.

That kind of defies the laws of mathematics.

This is wrong.

You know, it shouldn't be that way.

Even when you program, you should have, you know why is equal to X squared minus one, and this is your example of any mutable state.

So Pete's ability that's the idea of something can change, right?

So excuse something, and then it can become something else that that is so mutability.

What you do, you change some parts of it.

Andi.

You retain that some common bits.

So no, that's mutability.

Basically, the value changes or some parts of that value change in mutability.

Basically, you share what you can and copy what you can't.

That's a way of seeing it.

Let's look at how in mutability mutability affect your concurrence.

Immortals.

Concurrent guarantee programming is when you have processes as your main building block of your system and concurrent itself.

You know what you do is you don't have to run the same time, but you model it that way so they could, in theory, be running at the same time.

Andi.

It's an easier way to reason on Danny's away to code and program, And this goes in contrast to parallelism, where you actually have processes which are running at the same time, so see it as a subset.

See, secret currency has a subset of parallelism, so they're two ways off doing concurrency.

One is based immutable state where we've got processes and processes, usually friends When it comes to mutable state, we'll go in and share memory.

So that means any Fred you know which has access to the shared memory can go in and edit it.

And this is where your program with locks you program with Sema fours and the likes.

Then you've got notion memories.

So you've got concurrency models with immutable state, and in those cases you've got processes on DDE.

Processes do not share memory, but they communicate with each other from message passing, so they communicate with each other by copying the data from one process to the other.

And so now they'll each have their own copy, and you're able to do whatever they want with it.

So you know the only entity, the only item which is allowed to mutate the process state is the process itself.

If we're dealing with a mutable state, you've got a friend or a process running in a critical section, so basically right into the shed memory.

What happens if something goes wrong?

So what happens if the process terminates?

What you didn't need to do is you need to go in and terminate all of the friends which have access to the shared memory because you do not know you know what state?

The process which terminated, left the chair memory and it could be a potential to be corrupt.

So you basically lose everything in their immutable state.

What happens if the process, you know, state gets corrupted?

Your crashes or something goes wrong with it, is that you just lose the state of that particular process, which was corrupt in the first place or other processes are not affected by it because they'll have their own copy of the data, hopefully not corrupted, and you'll continue executing.

So it's a way off isolating failure.

Your second problem with mutable state is you, where you locate your debt, you've got share memory where you located.

So you've got a process running in Notting him and you've got one process running in London on the need to share memory where you place your shared memory becomes a bit hard versus immutable state, where you've got Nottingham and you've got London.

You don't share memory, you copy to stay, so they'll each have their own copy off.

The data on you can execute without social.

You're avoiding problems off locality here assume you figure out with immutable state between Nottingham in London, you'll praise your shared memory in Leicester.

What happens all of a sudden when the network goes down between them?

You know, because here in the middle, you've got your share data.

All of a sudden you can't accept it.

There's one thing you need to be aware when your programming in life they're free certainties.

One is taxes, death and network petitions.

So you can be sure that, you know, if you've got a network, something will go wrong with it versus Immutable State.

You've got a copy Nottingham.

You've got a copy in London.

So even if the network goes down, they'll each have their own copy of the data to continue running on DDE.

What you need to do is when the network does come back up, you will have to go in and synchronize the date again, and their many tools distributed databases and techniques to do that.

It's very clear that if you're dealing mutable state, the mutability will work.

But it will work only if you're running a friends on a single machines that without a network and assuming nothing goes wrong on many, many use cases where you need that approach, especially those use cases where coping memory is not efficient near where your computations have be extremely fast.

So it's not a question off one of the other.

It's it's a question very much of using the right tool for the job.

Andi.

Yeah, it's no always mutable state, and it's not always immutable.

State thes air decide decisions you need to make when you go along with some examples of where you might choose a mutable state, most likely, I mean, you would use a mutable state where saying the finance base where you're doing a great me trading computation time is critical and complex as well, where if something crashes and go wrong, just don't do the trade.

But if you do get your results, you know you need to be fast on DDE.

Yeah, get you execute that trade as quickly as possible, as as an example, or you're rendering of graphics, for example, or you know where you might want to split it up.

But you do do as much as you want as much as possible in parallel.

So so it's a critical time.

Critical applications absolutely, which can run on a single machine and don't need to be distributed.

So let's step back a second.

You have been using the terms mutable state and immutable state.

You probably recognize them with the notion memory approach versus the shared memory approach.

Andi, I think you're very commonly shared memory approach is where, for example, job coaches pride 72 friends will go into shared a memory.

And what I'm seeing happening a lot out there, though, is applying techniques from immutable state to process and friends with mutable state.

So what happens is that here you only allow the friend you know which owns the data, to go in a mutated and and that resolves and addresses a lot of issues.

When you we've discussed now.

So it's again, you're very much the right tool for the job.

So if you look at more than architectures today, I mean everything from embedded devices to supercomputers.

They are based on your heterogeneous multiple architectures, and most of them are by nature distributed.

So, you know, thinking what we've been looking at today is basically the future off programming.

Your future programming languages will be concurrent.

They have to be concurrent, and they'll have a concurrency model based on immutable state.

So immutable state being one of the properties they've inherited from functional programming languages.

You might not be using personal programming languages on a day to day basis, but using the paradigms and the principles and adopting them with your means.

Well, you mainstream technologies will make you much better programmer, and they'll make you much more efficient and productive.

Early.

Wrong.

We mentioned, though, that mutability there was a speed penalty.

Right?

So how do we address that?

So with immutable, indeed, you have a speed penalty, but the speed penalty becomes even more serious when you start looking at ambles law.

Um, every 1.5 years until mid two thousand's, chips were getting becoming twice as fast.

Uh, then and those law, because of unresolved, have hit the limit on dhe.

Now you need to deal.

You gain speed from multi core, and with multiple programming, you need a different approach.

And what you do is you start paralyzing your computations.

So, you know, desktops with very soon of 64 corners will be seeing machines with 1,000,000 cores within our lifetimes.

You know you start you till I instead of your making a single Freddie program, which firms extremely fast, you know, stop paralyzing your programs on DSO you start breaking up your computations into many smaller computations.

And this note the only way to do that is ah, concurrently programming with immutable state with the concurrence of model based on a beautiful state.

Uh, yeah, that you seem to have Ah, yeah.

You see, Been home by your own.

Was it called Busted?

Yes.