Latest / Agentic Conversations (formally mlops.community) / The Next Programming Language Is English

Transcript

The Next Programming Language Is English · Agentic Conversations (formally mlops.community)

0:00
All right, so at the beginning of April I went to New York for
0:03
the MCP Dev Summit, and while I was there I got the chance to
0:07
record a few podcasts with attendees that were at the
0:11
event. This is one of those
0:12
conversations. Hope you enjoy.
0:14
Developers in the last, up until very recently have had to
0:18
understand not the physical processor, but they had to
0:21
understand the notion of a process.
0:23
There's the correctness side of. Well, when I write this line of
0:26
code, it is going to translate into the right assembly language
0:29
down under the covers. I think this big transformation
0:32
that we have going into the AI space where we're now
0:34
programming with the natural language, that's not a formal
0:37
language, you get to think about the logical process.
0:40
We will ensure that we give you durability underneath that
0:44
abstraction, so that as the infrastructure is doing all
0:47
sorts of chaotic weird things, we will compensate for all those
0:51
weird things. You just get to think about this
0:53
logical process. The idea of programming
1:07
languages and justice programming models has evolved
1:10
over time. You have been deep in the weeds
1:15
studying it, being part of it, helping shape it.
1:19
Tell me about what you see as like the evolutionary through
1:23
through line or thread that goes through it.
1:26
So I recently did a an internal developer conference for one of
1:30
our our users, one of our customers.
1:34
And the very first slide that I showed them was a slide of a
1:37
processor. And I asked in the room, how
1:39
many of you have programmed an assembly language?
1:42
And there were about 50 people in the room.
1:44
Surprisingly, half of them raised their hands.
1:47
I was like, wow, really? I thought I was the oldest one
1:50
in the room, right? I did.
1:52
And when I was in school, I programmed assembly.
1:55
And, and then the second question was, how many of you
2:00
still program an assembly? And unsurprisingly, no one
2:04
raised their hands. And so nobody programs an
2:08
assembly anymore because we came up with a higher level
2:12
abstraction. It's there's still assembly
2:15
language running, there's still program counters and instruction
2:18
registers and memory, you know, registers and all of those types
2:21
of things. Those, those physical components
2:24
are still there, but we have a different abstraction.
2:27
And so that's the through line is that we're always moving up
2:31
the level of abstraction. But I'll tell you honestly that
2:35
for the most part, the last, I would say certainly the time
2:40
that I've been doing this, which is more than three decades,
2:43
sure, we moved from assembly language and our languages got
2:46
incrementally better and a little bit higher level.
2:50
And in terms of abstraction, so C used to you have to had to do
2:54
your own memory management. Then we had an abstraction that
2:56
allowed you to not have to do your memory management.
2:58
So you Java did did the memory management for you.
3:03
And then where I work now, Temporal kind of raises that
3:05
abstraction as well. But in the AI space, we are
3:11
radically changing the programming model because now
3:14
we're programming with natural language and eventually that
3:18
turns into code that eventually gets all the way down to
3:21
assembly language and is running on a processor.
3:25
One of the interesting things though, is that in those those
3:30
other abstractions where we had a formal programming language,
3:34
we had ways. And I studied programming
3:36
languages in grad school for a while.
3:38
And to a large extent that's hardcore math because you're
3:41
proving these programming languages and the compiler's
3:44
correct and complete, so you can express everything you want to
3:48
express. That's the completeness side.
3:50
And then there's the correctness side of, well, when I write this
3:53
line of code, it is going to translate into the right
3:55
assembly language down under the covers.
3:58
I think this big transformation that we have going into the AI
4:01
space where we're now programming with the natural
4:04
language, that's not a formal language, it's not
4:07
deterministic. It's not an abstraction that is
4:09
deterministic down to the next level of granularity, you know,
4:13
the next level of abstraction. And so that changes everything.
4:16
So we have to figure out what the programming model is for
4:19
this. Well, I remember when we were
4:22
first starting to do like text to SQL and I had a little bit of
4:26
a gripe with it because it was like, but why would you want to
4:29
do that be? It's so fuzzy.
4:32
Language itself is really hard to interpret, and if I want
4:38
something to happen, there's so many different words that I can
4:41
use to express just a fairly simple idea.
4:47
It feels like it's going to be easier if you just use the bound
4:53
language that we've already created.
4:56
But I was proven wildly wrong. That is not correct.
5:00
I do not feel that same way now. I've changed my mind completely
5:04
because anybody who has Vibe coded or just tried to use
5:08
coding agents, they go, well, this is very good, right?
5:11
So it's different now we don't have that.
5:15
It is different, but and we also know about hallucinations,
5:19
right? So it is different.
5:22
You're right. It does a pretty good job
5:24
interpreting that. The the models have gotten
5:26
really good at interpreting that.
5:28
And then of course, depending on the way that you use them, you
5:30
use them iteratively and you converge on something and
5:33
hopefully you're paying attention to what it's doing and
5:36
that it isn't totally hallucinating something
5:37
completely wacky. But we're seeing plenty of cases
5:40
where it is. And so that's my concern as
5:43
somebody who studied formal languages.
5:46
English is not a formal language.
5:48
And So what are we going to do as an industry to show that?
5:51
And I think we have to find other ways of compensating for
5:54
that. I don't think that we're going
5:56
to get it to the point where it is as rigorous as the math that
5:59
we did under the covers with programming languages before.
6:02
So now we have to be. I guess that's the.
6:04
Big question. I don't think so that the
6:07
mathematician in me is like that, that that was the kind of
6:11
initial like AI skeptic, like, Oh my gosh, like I am so used to
6:15
deterministic code. I'm happy in that space.
6:18
I'm happy with the fact that 1 + 1 is always equal to two, you
6:22
know, that type of thing. And now it's probabilistic 1 + 1
6:25
might be 3. And so I think what we're going
6:28
to figure out is we're going to find figure out different ways
6:30
of compensating for it. And so we will, we have to build
6:35
safety Nets. So this is the way things are
6:38
working. There is a certain level of non
6:40
determinism, so how do you deal with that nondeterminism?
6:43
How, how what, what type of safety net do you have when the
6:46
translation from this higher level abstraction down to the
6:49
concrete thing goes haywire? How do you compensate for that?
6:53
Well, in one way you could look at the idea of durable execution
6:58
as one of those safety Nets, right?
7:00
Absolutely. And so it's and that's why so,
7:03
so durable execution. As you know, durable execution
7:07
is pre Gen. AI craze.
7:09
So the company that I work for Temporal Temporal, the open
7:14
source project has been around for 6 1/2 years or something
7:17
like that. And it definitely represents
7:20
this higher level abstraction. Now it still falls into that
7:24
category until you start using it in the AI space.
7:27
It falls in that category of it's deterministic.
7:30
It is we we know exactly how this is going to map from the
7:34
way that you write and the programming model.
7:36
So just to very quickly describe the programming model, the
7:39
programming model there is that as developers for the last 30,
7:45
more than 30 years, remember we talked about the physical
7:48
processor before, right? Developers in the last, up until
7:52
very recently have had to understand not the physical
7:55
processor, but they had to understand the notion of a
7:58
process, Yeah, like my code is running in a process.
8:02
As we went into the cloud, in cloud native, we had multiple
8:05
processes. So we had to start figuring out
8:09
how multiple processes would communicate and what happens
8:12
when the network goes down and all of those types of things.
8:14
But we as developers had to think about those infrastructure
8:18
abstractions. I had to think about a process.
8:21
I had to think about the network.
8:23
And what Temporal does is it moves that level of abstraction
8:26
higher and it says, no, you as a developer, you get to think
8:29
about a process as a logical process.
8:32
We'll map it down to physical processes for you.
8:35
That's what durable execution does.
8:37
And So what it says is you get to think about the logical
8:40
process. We will ensure that we give you
8:43
durability underneath that abstraction so that as the
8:47
infrastructure is doing all sorts of chaotic weird things,
8:50
we will compensate for all those weird things.
8:53
You just get to think about this logical process.
8:56
That's fundamentally what durable execution is.
8:58
So it is that level. And now we're layering AI on top
9:02
of it. So it is kind of a deterministic
9:05
tier that we can leverage your right as kind of a safety part
9:09
of the safety net that's going to allow us to compensate for
9:12
that. I'm sure you've heard a lot of
9:15
the like the chaos monkey or chaos engineering this in a way
9:20
is that, but having folks not even worry about chaos
9:24
engineering because you're going to be doing the chaos on your
9:27
side and make we. Compensate for the chaos?
9:29
Yeah, exactly. I didn't think about that
9:32
before, but it makes a lot of sense.
9:34
Yeah, it's really interesting. So I spent a lot of time, I was
9:38
around when we moved over into container architectures.
9:40
So I worked on Cloud Foundry, and Cloud Foundry was the
9:43
technology that was self healing before Kubernetes came along.
9:48
And it had containers under the covers.
9:50
And so you could deploy multiple instances of an app.
9:53
And if the container went away, we just brought it back.
9:56
And I worked with sometimes users and customers who said,
10:00
yeah, my developers would come in and say, I saw a dashboard
10:05
that said the container went away.
10:06
What are we going to do about that?
10:08
And the people who understood that technology were like, does
10:11
it matter? Is your app still running?
10:13
And they're like, yeah, I guess it is.
10:16
So maybe it doesn't matter anymore that the container went
10:19
away. It's that same concept.
10:21
OK. So then going back to the
10:23
original idea of, hey, durable execution is a way to make
10:30
almost make up for the fact that we're now communicating with our
10:34
machines in natural language. There feels like there's other
10:38
ways that we're making up for it too.
10:40
I guess one way is MCP and then other ways are I I'm sure like
10:48
if I really think about it right now, there's, there's probably
10:50
plenty of ways that guardrails putting those into place, other
10:56
ones that maybe I'm not able to think about.
10:59
Yeah, I mean, I'd love that you bring up MCP because when we
11:02
start thinking about the way that applications are being
11:04
written, these AI applications, we've got the agents, right?
11:07
They're running their agentic loop.
11:09
And so part of the programming model there is we've got these
11:12
agents running an agentic loop and they're going to use tools.
11:15
Tools is one of the first class abstractions in the AI space,
11:18
right. Even LLMS, even if you're not
11:20
running an agent and LLM has tools as an abstraction, you,
11:25
you also pulled, you know, called out guardrails, those
11:27
types of things. And so now we've got these
11:31
tools, there's an abstraction and durable execution plays
11:35
across that entire gambit. And so for example, if you have
11:39
a long running agent that might be running for 5 minutes or 10
11:42
minutes or five hours or five days, you want some durability
11:46
around that. Remember we talked about how
11:48
durable execution says, well, you could think about a logical
11:50
process. So in that case, my logical
11:52
process is my agent and the fact that it's going to run for five
11:56
days, it's a logical process. I don't have to worry about what
12:00
happens with the infrastructure over those five days because
12:02
temporal will compensate for it. Well, that same durability is
12:07
valuable when you think about the tools.
12:10
So are the tools going to be long running?
12:12
And increasingly they are, because increasingly tools are
12:15
themselves agents, so they're going to be long running.
12:18
So we want to apply durability in the agents, we want to apply
12:21
durability in MCP, which is why we refer to it as the concept as
12:26
durable MCP. Yeah, let's talk more about
12:28
durable MCP because you mentioned that it's now almost
12:32
becoming first class citizen. It is so prior to November.
12:38
So the first kind of early versions of the MCP spec didn't
12:42
say anything about durability and in fact they were mostly
12:45
request response. So their whole and that's pretty
12:48
natural. Like I grew up in like the micro
12:50
services era as well. And initially our micro services
12:53
were all request response. And I like to say that the
12:56
poster children of micro services in that era was Netflix
13:00
and they built a whole bunch of services around the request
13:03
response protocol. So they had things like retries,
13:07
retry libraries and service discovery.
13:09
They had circuit Breakers to keep you from D Dosing things.
13:12
So it's completely natural to start with request response
13:15
because it's kind of a natural way of us programming and like
13:19
our mental model around these things.
13:21
But in November, they released something called The Task, which
13:27
doesn't change. It's not a new concept.
13:31
It's still the core thing with MCP is of course, you've got
13:35
resources and prompts, but those aren't used a whole lot.
13:38
It's mainly the tools, right? That's the main thing that's
13:40
used out of Temple. I'm sorry, out of MCP tasks
13:45
don't add a new type of it doesn't add a new resource.
13:49
It says a tool can be request response or it can be async.
13:55
So it can be long running. You fire off a tool, you make a
13:59
tool call and you don't expect a response right away.
14:02
It's not request response, you just you're waiting and you're
14:06
maybe never. Maybe it's fire or forget.
14:09
And the cool thing about SO on the one hand, they could have
14:13
just defined that protocol and said instead of doing a request
14:18
and getting back a result, you do a request, you get back a
14:21
handle. Now you can interact with that
14:24
handle by asking for status, getting a result.
14:28
When the when you get back a status that says, OK, you're
14:31
done. Now you can get back a result.
14:34
That's kind of OK, that's great. But the first line in the
14:38
specification says tasks are durable, which is wicked cool
14:42
because it's this recognition that tools run for a long time
14:46
and that if something goes wrong, you don't want to have to
14:49
start all over again you. Don't want to send the request
14:51
again. You don't want to have to start
14:53
exactly send the request again. Imagine that you've burned
14:57
through millions or billions of tokens and then something goes
15:01
wrong when you're 90% complete. You don't want to have to start
15:04
that over again. And so the tasks, them being
15:07
durable, the requirement is that they're durable.
15:12
That change, that's the thing that changes a lot.
15:15
Because you can guarantee that it's going to come back.
15:19
Yeah, exactly, Exactly. So by being durable, what that
15:23
means is that the client that just it connected with the MCP
15:27
server to invoke that tool, the client could go away, the
15:30
network could go away, and in fact the tool itself could go
15:34
down. And remember, we were talking
15:35
about durable execution says think of your process as
15:39
logical. It's always once you start it,
15:41
it lives. It just lives.
15:44
Infrastructure can come and go. All sorts of things can happen.
15:47
So the MCP server itself can go down, but the specification says
15:52
tasks are required to be durable.
15:54
So that means that not everything is lost.
15:57
So you keep, you mentioned before these long running agents
16:01
and you're also talking about tasks.
16:04
It feels like that is very much long running Tye of.
16:09
Exactly. What are the what are being done
16:13
with these long running agents? Like what are you seeing out
16:17
there that needs such long running agents?
16:20
Yeah. So there's quite a number of
16:23
different use cases. There's some of this same batch
16:26
type of use cases that we've done all along.
16:28
So you know, tools don't have to be themselves be AI
16:31
applications. It could be.
16:33
I'm going to go off and do an analysis.
16:35
I was in a session earlier today that was given by a couple of
16:40
folks in Amazon and they were with Prime Video and they had a
16:44
just a fantastic use case that they talked about where they
16:46
said it used to be that we did analysis on the streaming, the
16:51
quality of the streaming only for the premier events, only the
16:55
for the events where there were millions or 10s of millions of
16:59
viewers because humans were involved in that analysis.
17:04
Well, they've now created agents that can do that analysis.
17:09
And so they're, they're not constrained by human, human
17:11
bandwidth anymore. So the created agents, and so
17:14
now they're doing that same kind of streaming analysis on tiny
17:17
little niche things. All the videos.
17:20
But that's all long running because what they're doing is
17:23
they're crunching through a lot of data.
17:25
So a lot of. So you were asking about use
17:27
cases, data analytics, data analysis.
17:30
Now in that particular case, they are using an agent to do
17:33
that, but there's a lot of use cases even that are pre agent
17:37
that are just long running. Another thing that makes things
17:41
long running is as soon as you have some type of human in the
17:44
loop, humans are bottlenecks, right?
17:48
So you could be part of the way through processing some tool and
17:52
now all of a sudden the tool, the MCP server, the tool says,
17:56
oh, I need some human input. And now you've got to wait for
18:01
the human to come back. Well, that might be days and but
18:05
the process, let's say it's 50% of the way through and now it's
18:08
waiting for the human. The, you want that process to be
18:11
durable and so that when the human finally does and you don't
18:15
not only want it to be durable, you want it to be efficient.
18:18
You don't want to like hold that in memory for five days while
18:21
you're waiting for the human. So you want to make sure that
18:24
your infrastructure is being used efficiently as well and
18:27
that that's not a requirement of durability, but it is a
18:31
requirement of a really good durable execution platform.
18:34
Yeah, and just resource management.
18:36
Exactly. So can we go back to this
18:40
Netflix or sorry, the Amazon Prime example, Amazon's not
18:45
going to be happy. I mean same same streaming
18:48
example. Streaming example.
18:51
It's long running because the whole time that they are
18:55
streaming it, they're, I assume they're constantly streaming it
19:00
and so they're just taking snippets of time.
19:03
Yeah, I I don't actually know the details of the
19:06
implementation. I think it could be a continual
19:09
process, which I think is a super interesting use case,
19:12
which is just it that it's like an ambient agent.
19:17
It's always watching and it's always responding.
19:20
I don't know for sure whether that's what they were referring
19:23
to or whether they were saying we're always collecting data for
19:27
that from the number of times that it has streamed and then
19:29
they do it in a batch situation. I don't know for sure.
19:33
We were asking about use cases for tasks.
19:36
One of the interesting things about the MCP tasks is that it
19:39
is largely about batch, so it is not.
19:44
It does support a human in the loop, but the human in the loop
19:49
is triggered by the MCP tool itself.
19:53
It is not one of those things where the MCP tool is doing its
19:56
thing. It gives you some interim result
19:59
and then the external agent is making the decision on the human
20:03
in the loop and progressing it. It is pretty much a, hey, we've
20:07
defined this long running process again, it could be an
20:10
agent, but now it's the tool that's in charge.
20:14
It the the tool is, is the the main player there, which
20:18
surprises me because I come from a world where long running
20:22
processes can be interacted with from the outside.
20:25
Yeah, but there is no. Without getting into all of the
20:29
details of the protocol, the the task protocol allows you to
20:33
create a task. It allows you to get status on
20:36
the task, it allows you to cancel the task, and it allows
20:39
you to get the result. It does not allow you to
20:42
essentially put into there like you can't from the outside say,
20:46
hey, here's some more information.
20:49
The tool can say, hey, I need more information and it'll come
20:54
out to the client and say, hey, I need this more information,
20:58
but the client can't offer additional information.
21:01
Oi was actually quite surprised about that because I thought,
21:04
oh, tasks. I thought they were going to be
21:06
like, we do that in temporal, but it's actually, it's a little
21:10
bit more constrained. There's lots of use cases where
21:13
you send it over the tool and now the tool is in control like
21:16
these batch processes that we talked about, but it's it
21:19
doesn't have a protocol. These are some of the things
21:22
that I'm definitely going to be trying to influence.
21:24
The protocol's only experimental right now, so there's an
21:27
opportunity to influence that. I.
21:29
Would want the ability, yeah. Yeah, there are ways of doing
21:34
it, but it it's a little bit odd you have to define other tools
21:38
with the same server and that might be a best practice.
21:42
I haven't quite gotten that far yet.
21:44
We'll see. Can you break down?
21:47
I'm still trying to wrap my head around the tasks and the
21:50
different use cases, so different batch processes that
21:53
you've seen being done with tasks.
21:56
Yes. So there might be.
21:58
For example, it could be like in invoice processing example,
22:03
which is exactly what I did it in my talk, was invoice
22:06
processing. So you're going to submit an
22:08
invoice. You've got a tool that is an
22:10
invoice processor for the most part.
22:13
You submit the invoice and what does it need to do?
22:15
It needs to do some validation. Then maybe it needs to ask the
22:19
human for approval. You know, you've got some policy
22:22
there that says anything under 500 bucks, just go ahead and
22:26
process it. Anything above that, or if
22:28
there's some other policy, some weirdness about the invoice,
22:32
then you have to have human in the loop.
22:34
The tool would be the thing that decides that's where the policy
22:37
is running. The tool can come out and say,
22:39
hey client, I need approval. And then you could be paying
22:44
parts of that and maybe the entire invoice doesn't need to
22:47
be paid at once. Maybe you've got a complex
22:49
invoice where you say I'm going to, I'm going to pay this in
22:52
increments. So that is a long running tool
22:55
where let's say you're going to pay it quarterly.
22:58
You can model that as a single tool, a single invoice that
23:02
you're processing. You pay this quarter's and then
23:05
the thing goes to sleep and next quarter it wakes up and it pays
23:08
the next installment. Wow.
23:10
So that is what I mean by a long running thing that you can
23:14
imagine an agent saying, hey, go ahead and process this batch of
23:17
invoices for me and that's the the process that's going on in
23:21
the background. And that's where you talk about
23:23
the resource management is important because you don't want
23:26
it for a whole month to be there thinking about that.
23:29
You want it to go to sleep. Exactly.
23:32
Exactly. And so, yeah, scale to 0 is
23:36
important here on these tasks. That's right.
23:39
And so and then you're thinking, wow, wouldn't it be great if I
23:46
could add more invoices to that while it's happening instead of
23:50
having to kick off a new task with new extra invoices?
23:55
Is that kind of the idea with the I?
23:57
Think there's a number of different ways to do it.
23:59
The way that I did it very, very naively in the beginning is that
24:03
each task was, each invoice was its own task.
24:07
You can also imagine batching those things and saying actually
24:10
a batch of invoices is a task. And within that you can break
24:15
it, break it down into, you know, subtasks or because each
24:20
one might have its own schedule. So there might be an invoice
24:23
that is paid quarterly and another one that's paid weekly
24:26
and those types of things. And so going back to the
24:29
durability conversation that we've had been having all along,
24:32
you're right, it needs to scale to 0.
24:35
And remember I said the infrastructure can go away.
24:38
So where does that timer live? The timer has to survive that
24:42
that infrastructure failure as well.
24:45
And so we like to call those things durable timers.
24:47
And so we have this notion of like timers need to be durable,
24:50
human in the loop needs to be durable, the compute needs to be
24:53
durable, all of those things. So durability isn't just retries
24:57
or state management. It's a whole complex set of
25:01
things. And that's what I mean by
25:02
programming language, right? It's like, here's this new
25:05
abstract fraction of durability that you can alley across a
25:08
bunch of different programming elements, and as soon as you
25:11
have the notion of a durable timer, then you no longer have
25:14
to program that. Yeah, so.
25:17
Yeah, you. You have to keep the time
25:19
though, because otherwise when is it going to know when to wake
25:22
up? That's what it, that's what, for
25:25
example, Temporal has durable timers and they live in the
25:29
Temporal server so it knows when to wake up.
25:32
Your process can go away. That's what allows us to be
25:35
efficient with that is the processes go away, the timer
25:38
fires, and now a worker process that's always checking to see is
25:43
there anything new is like, oh, I see this timer fired.
25:47
Oh, that timer corresponds to this thing that's asleep over
25:50
here. I'll wake it up now.
25:51
Yeah. And so I'm starting to get a
25:54
better picture. And in my head, I'm kind of
25:56
envisioning it as like different things happening that are
26:01
creating chain reactions. And you have to make sure that
26:04
each one of those things is working because if you have some
26:09
kind of a problem, then the domino is not going to go to the
26:12
next domino. And so everything has to be
26:17
durable. Yes, that's that's why I'm
26:19
understanding the the idea of, OK, durable execution doesn't
26:22
mean just durable execution. It means durable timers, durable
26:26
compute all of that. Exactly.
26:28
Exactly. Yep.
26:30
OK. So, so that's tasks and a little
26:34
bit of like MCP being more durable and bringing that to its
26:40
own DNA in a way. Hopefully we see more of it.
26:45
And so that most things are durable.
26:47
Is there ever times where you wouldn't necessarily need like
26:50
durable execution is overkill? Oh definitely.
26:54
I think that there are some places where the cost of
26:58
recomputing something is so small that you don't necessarily
27:03
need to to take on that burden because what we're essentially
27:06
doing is we're pushing some concerns that used to be
27:09
application concerns down into the infrastructure.
27:11
That's what we're effectively doing.
27:13
Of course, that means your infrastructure is a little bit
27:15
more complex. So like I said, short running
27:19
things where the the cost to recompute that over again is,
27:23
is, you know, very, very small. Other things are things like
27:27
embedded systems. So if you aren't necessarily
27:31
running a distributed system, so you're not deploying your
27:35
application out into the cloud and have multiple instances
27:39
embedded on like let's say a car for example, probably not needed
27:44
there in part because everything's different there.
27:47
You're doing embedded systems, you're probably programming in C
27:51
and C++ and those types of things.
27:53
You're still doing your own memory management because things
27:55
need to happen really quickly. You're, you're operating in a
27:59
level where you're still operating at that low, lower
28:01
level of abstraction. So there's, there's a number of
28:04
those things. But one of the things with
28:07
durable execution is we've seen this with some of our, you know,
28:11
the early adopters of durable execution is that they come in
28:16
and they adopt it for a use case.
28:17
And once they understand this new programming model, all of a
28:21
sudden they're like, they can't. They can't.
28:23
Unsee it they. Can't Unsee it now.
28:25
They want everything to be built that way and we hear stories.
28:29
One of one of our most vocal champions is from Yum Brands,
28:33
Matt McDowell, and he tells this great story of product manager
28:37
came to them. They had been talking about a
28:39
feature for a while and they had estimated that it would take
28:45
weeks or months to implement. And the reason that it was going
28:49
to take that long was because it was this highly distributed
28:52
application where like we talked about earlier, the the
28:56
developers were going to have to worry about all these like, OK,
28:59
I've got this process over here, this process over here that
29:01
might go away. So I have to make sure to store
29:04
some state over here and I need a message bus over here.
29:08
And it was just a complicated topology and a complicated like
29:12
workflow that they needed to wire together themselves, little
29:16
bit of a Rube Goldberg machine that they had to build.
29:18
And Rube Goldberg machines metaphorically are really hard.
29:22
They're hard to operate. And when they rethought about it
29:25
in this model where they're like, well, if I think about it
29:27
in terms of a process that doesn't go away, something else
29:30
is taking care of that resilience they were able to
29:33
implement in a couple of days. Like that's the power of a
29:36
different programming model. Like we couldn't build the, we
29:40
couldn't build AI systems and assembly anymore.
29:43
We just couldn't do it. So this developer couldn't Unsee
29:45
it because there was such this and there was such complex
29:49
topology, but he was able to say, let's imagine that these
29:55
are always there, like we can take them for granted.
29:58
And so now if we are able to take this for granted that it's
30:01
going to be there, we don't have to make it as complex as we
30:08
thought we did. Exactly.
30:09
But I, I guess I where's that parallel or where's the?
30:13
I'm not drawing the conclusion of OK, if it's always there then
30:18
it's less complexity. Because the complexity is moved
30:22
down the the higher level abstraction is, they get to deal
30:26
with this abstraction. That makes it less complex for
30:28
them. And what we do in temporals, we
30:31
map it down. It's complex.
30:33
The runtime topology is just as complex.
30:36
It's that the developer doesn't have to wire all that up
30:40
themselves and create all of those components themselves.
30:44
Temporal does that. So one of the things that I like
30:48
to say is that event driven systems and event source
30:52
systems, which is an added complexity on top of event
30:56
driven systems, they are it's an incredibly powerful paradigm
31:01
that we need for runtime resilience.
31:05
But it's so hard for humans and non humid coders to understand
31:12
because there's so many moving parts and it is each one of
31:15
those is a little bit different. It is truly a Rube Goldberg
31:18
machine. They're all a little bit
31:20
different. And like you said, Domino's
31:22
falling on Domino's. And so that's another one of the
31:26
things I've not done any like tests of it, but I am being
31:31
somebody who uses coding agents. If you give a coding agent a
31:35
simpler programming model, they're going to do a better job
31:38
writing the code in that simpler programming model as well.
31:41
So the simpler programming model up until recently was a huge
31:44
benefit for our early adopters. And we have a few 100,000 people
31:48
are using Temporal. It's it just, which is still
31:52
small compared to I think it should be in everybody, every
31:55
developer's toolbox and will be in a few years, but it is now.
32:00
I think the even bigger thing is like coding agents wouldn't do a
32:04
very good job writing, you know, some complex thing in assembly.
32:09
You give them higher level abstractions so that they the
32:12
LLMS can reason through that. And so that's another thing with
32:16
durable execution and that change in programming model is
32:19
that that we give that programming model the
32:21
understanding of that programming model to the agents
32:24
and then they can write that code better as well.
32:27
And how does it work if I now have all of this very complex
32:32
topology and I install temporal, I have to have temporal map
32:37
everything and then almost give a guarantee that all right,
32:40
we're going to secure this or we're going to durable fi this?
32:44
Ah, so it's actually that temporal brings that complex
32:49
topology. So Temporal brings the messaging
32:54
substrate, Temporal brings things like durable timers and
32:58
stuff. So it is that the developer gets
33:02
to write in this abstraction and when they deploy it, when they
33:05
deploy those applications, Temporal takes what looks like a
33:09
single process application because it is logically a single
33:12
process and it maps it down to that complex topology.
33:17
So it's not that the developer has to think about the complex
33:22
topology. Temporal basically does that for
33:24
for them. So that developer that you were
33:26
saying Matt was his name? Matt McDowell, Yeah.
33:29
He had to worry about everything in his former life where he's
33:36
looking at it and he's trying to map out story points and saying
33:39
this is going to take six months.
33:41
And then he says, oh, no, well, maybe we'll just hit Temporal
33:45
instead. And then you are in the
33:48
background bringing the all of that that he thought he was
33:52
having to wire up. Exactly.
33:55
And so in a way, you're sitting in between his system and that
34:04
complexity in the system, and he's just interfacing with you.
34:08
And now everything's making sense.
34:11
It took me a minute, but yeah, I'm getting it.
34:13
While you're like, yeah, that's a higher level of abstraction.
34:16
That's where we're what we've been talking about.
34:18
Yeah, in, in, in Demetrius. That is that aha moment.
34:22
I'm brilliant that you had it. It takes a while because we have
34:26
spent, like I said, decades thinking about building systems
34:31
with these lower level abstractions.
34:33
Even as our programming languages gave us higher level
34:35
abstractions, we still fundamentally still had to
34:38
understand the architecture of the computer and the
34:42
architecture of the network and things like that.
34:44
What I'm saying is you don't have to anymore.
34:46
Yeah. Yeah, just like you don't have
34:48
to learn TypeScript or Python anymore.
34:52
Yep, Yep, absolutely. If you know it and you can debug
34:55
through it, but it's all, you can also create a lot of stuff
34:58
without knowing it. Yep, that's right.
35:00
So, yeah, all right. Well, yeah, that kind of drives
35:04
it home and brings me full circle to, OK, we started this
35:08
conversation with the evolution and the thread that has been
35:12
going on these abstractions and programming models and
35:16
recognizing how we're just continuously moving up and up
35:19
and up and how durable execution is bringing a new level of
35:24
abstraction to this, just like we have natural language
35:29
bringing a new level of abstraction to the way that
35:31
we're interacting. Yes, exactly.
35:33
And I think that the probably the way of layering it is that
35:36
we've had these traditional programming languages temporal
35:39
layers and abstraction on top of that which is durable execution.
35:43
That's what allows temporal to like figure out the abstract
35:48
away the the physical processes and though, you know, network
35:52
connections and all of that stuff, we handle that for you
35:54
and then AI that the natural language programming sits over
35:59
the top of that. So because Temporal isn't a
36:02
language per SE, it's more of just like a helper.
36:06
It's yeah, it's AII refer to it as a programming model.
36:10
It's we, we, our SDKS are in a bunch of different languages.
36:14
We're not giving you new programming language, but what
36:16
we are doing is we're giving you a new set of abstractions.
36:19
So a new programming model where instead of you deciding, oh,
36:22
here's a process boundary, you basically break up your code
36:27
into the, the things that where things could go wrong.
36:31
Like I'm going to make a network call here or I'm going to go
36:33
down to a database, or maybe it's a long running thing where
36:37
you you don't want to have to re recompute it if something goes
36:42
wrong. You put those things into
36:44
activities. That's one of our primary
36:46
abstractions. And then you wire the activities
36:49
together in what we call workflows.
36:51
And so that's the new programming model and it takes a
36:54
while to like, it's so fundamentally different that it
36:58
takes a while to kind of do that minds mindset shift.
37:01
So I had something similar where I, I did my undergraduate in the
37:05
greater LA area state school, learned all sorts of programming
37:09
languages. They were really focused on
37:11
getting you ready for industry. So it was learned half a dozen
37:14
different programming languages. And then I worked for a few
37:17
years and then I decided to go back to grad school and I went
37:19
to Indiana University, which is a research university in
37:23
southern Indiana. Programming languages is their
37:25
thing. So that's really where I got
37:27
hardcore into programming models.
37:29
Well, because they're more research oriented, the first
37:31
language that they teach their students as undergraduates is
37:35
Scheme. And you could always tell the
37:38
students who came in as freshmen who had already programmed in
37:42
iterative programming languages like Pascal and Fortran and C
37:46
and those types of things, because they had a hard time
37:47
shifting their mindset over to a functional model.
37:51
Very similar with Temporal is that.
37:53
But once you make that shift, then you're like, oh, that's a
37:58
different programming model. I can do totally different
38:00
things with that now. It enables you.
38:02
Yeah, That's a perfect place to finish it.
38:04
Thank you for doing this with me.
38:06
Thank you, it's been so fun.