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