From Skeptic to Advocate, Scaling Effect at Vercel
#4: From Skeptic to Advocate, Scaling Effect at Vercel
In this episode of Cause & Effect, Johannes Schickling is joined by Dillon Mulroy, Domains Lead at Vercel, who shares his personal journey with Effect and how Vercel gradually adopted it across their Domains platform. Dillon explains why Effect feels like having superpowers for error handling, observability, testing, and more.
In this episode of Cause & Effect, Johannes Schickling is joined by Dillon Mulroy, Domains Lead at Vercel, who shares his personal journey with Effect and how Vercel gradually adopted it across their Domains platform. Dillon explains why Effect feels like having superpowers for error handling, observability, testing, and more.
Song: Dosi & Aisake - Cruising [NCS Release]
Music provided by NoCopyrightSounds
Free Download/Stream: http://ncs.io/Cruising
Watch: http://ncs.lnk.to/CruisingAT/youtube
- (00:00) - Intro
- (03:00) - How Vercel Adopted Effect
- (10:57) - Dillon’s background
- (16:27) - Effect DX
- (22:13) - Lessons from other stacks
- (25:18) - From Skeptic to Advocate
- (31:13) - Effect’s Incremental Adoption
- (42:31) - Effect ≠ RxJS, Effect vs Ramda
- (48:24) - Effect’s superpowers at Vercel
- (52:31) - Wrap-Up & What’s Next
Transcript
00:00
One of the points I've made in my
00:01
conference talks this year is that to
00:04
scale TypeScript on
00:05
the server effectively,
00:07
it requires discipline and discipline
00:09
doesn't scale at the
00:10
organization level, unfortunately.
00:12
the very
00:12
primitives and foundations of the
00:14
language make it easy to have
00:17
happy path blindness,
00:18
where it's very easy to neglect all the
00:20
things that can go wrong in our software
00:22
and just write the happy path and not
00:25
consider the error states we can get in,
00:26
which over time just leads to slop.
00:29
And on top of that, we don't have a
00:31
framework. Well, we do now with Effect,
00:33
but traditionally, Node hasn't had a
00:35
framework like Spring Boot or Ruby on
00:37
Rails or Laravel, right?
00:39
So we are consistently and constantly
00:41
downloading dependencies and trying to
00:43
mix and match them where they were never
00:45
designed together or cohesively.
00:48
And you end up reinventing the wheel for
00:49
all of the things that
00:50
Effect provides out of the box.
00:55
Welcome to Cause & Effect,
00:57
a podcast about the TypeScript library
00:58
and ecosystem called Effect,
01:01
helping engineers to build
01:02
production-ready software.
01:04
I'm your host, Johannes Schickling,
01:05
and I've been building with
01:06
Effect for over four years.
01:08
With this podcast, I want
01:09
to help others understand
01:10
the powers and benefits of using Effect.
01:13
In this episode, I'm
01:14
talking to Dillon Mulroy,
01:16
a software engineer at Vercel working on
01:18
their Domains product.
01:20
In this conversation,
01:21
Dillon shares his path to Effect
01:23
after years of using
01:24
other programming languages
01:25
such as Golang and OCaml.
01:27
We dive deep on how Vercel
01:29
incrementally adopted Effect
01:30
and which new
01:31
superpowers it had unlocked.
01:33
Let's get into it.
01:34
Hey Dillon, so great to have you on the
01:36
show. How are you doing?
01:37
I'm doing well. It's an
01:39
honor to finally be here.
01:41
You're probably a person who really
01:43
doesn't need an
01:44
introduction in the Effect community,
01:47
but for those who are very
01:48
new to the Effect community,
01:50
would you mind introducing yourself and
01:52
sharing what you do?
01:53
Yes. So my name is Dillon Mulroy.
01:56
I am a Software Engineer at Vercel,
02:00
and I am the Technical Lead in our
02:03
Domains Product areas.
02:05
So Domains, Registrar, Buying domains,
02:07
managing DNS, TLS and certificates,
02:10
aliasing domains to deployments.
02:13
We've been going all in this year on
02:15
Effect on all NetU domains work,
02:18
and we're starting to see the fruits of
02:20
that labor and are very exciting times.
02:22
That is awesome. I want to dive a lot
02:24
deeper on all of those aspects.
02:27
I want to also hear
02:28
about what led you to Effect,
02:30
but maybe we remain for a few minutes on
02:33
Vercel on a high level.
02:35
Like how should I think about Effect
02:38
being adopted at a company like Vercel,
02:41
which is very cutting edge. It builds
02:43
developer tools itself,
02:45
and I think it really needs to moderate
02:47
where it can take a lot
02:48
of risk on new technologies
02:50
and where it needs to be
02:51
a bit more conservative.
02:53
So maybe you can share on a high level
02:55
already how Vercel
02:57
started to adopt Effect.
02:59
Yeah. So I actually admit I was not
03:01
the first person to write
03:03
lines of Effect at Vercel
03:05
It was probably either Toby or Schnez,
03:08
have a couple small Lambdas that run,
03:10
that they probably
03:11
wrote a year or so ago now.
03:13
But I was certainly the first person to
03:16
build larger services and
03:18
kind of take it on holistically.
03:21
I think as is with the story with Effect,
03:24
there is apprehension when you first see
03:26
it and read it. I had
03:28
the same apprehensions.
03:29
But as I talked about, both
03:32
Effect Days and React Miami,
03:35
Effect solves the pain points that makes
03:37
writing TypeScript at scale difficult.
03:41
And we, at least my team, is truly
03:44
starting to see the
03:45
benefits of that with Effect.
03:48
I'm sure we'll dive into more specifics
03:50
on that, but it has truly made us faster.
03:53
It has made us ship more reliable
03:55
software across the
03:56
board with better telemetry.
03:58
We have distributed tracing that just
04:01
works without headaches.
04:03
And I would argue we have some of the
04:05
best DX across any team at Vercel for
04:08
shipping internal services.
04:10
That is awesome. Well,
04:11
TypeScript wasn't your first love.
04:13
I'm not sure whether it is a love at all.
04:16
From what other people might know you
04:18
from is from the OCaml community, also in
04:21
the NeoVim community.
04:23
So I'm curious, maybe we can take a few
04:25
steps back and take a look at your
04:28
personal background.
04:29
You worked previously at Formidable, and
04:31
I think you worked in
04:32
consulting before that.
04:34
Maybe you can just share a bit more about
04:35
your background and the
04:37
trajectory that's had you on.
04:39
Yeah, I've kind of had a
04:41
pretty unique background.
04:43
I've had the opportunity and privilege to
04:45
work in a lot of different
04:48
companies through consulting.
04:49
And I've also got to work in a lot of
04:51
different tech stacks.
04:53
And maybe most importantly, I've got to
04:56
work in and experience many different
04:59
engineering cultures and engineering
05:01
organizations within companies.
05:03
I'm in my 11th or 12th, 11th year. I
05:07
started in 2014 full time.
05:09
As an engineer, my first job was at State
05:11
Farm. I was doing full stack dev, Java on
05:14
the server and
05:15
JavaScript on the front end.
05:17
I was like on one of the teams that made
05:18
their first step into span apps.
05:21
And I actually got to start writing React
05:24
at that job very soon
05:26
after it was announced.
05:27
from Jordan and Tom. So I've been
05:30
writing React for over a decade now.
05:32
I've seen it from the days of mixins and
05:34
class components up through now to we're
05:36
at RSEs and server
05:37
components and server functions.
05:39
So most of my career, like my bread and
05:41
butter truly is
05:42
TypeScript and JavaScript.
05:44
But I worked in Go for two years. I had a
05:50
contract doing some Elixir.
05:52
I notably had a two year gig at a startup
05:54
doing OCaml full stack both
05:56
in the front end and back end.
05:58
And then at Formidable, that Formidable
06:00
was certainly the job that changed the
06:01
trajectory of my career.
06:03
And Formidable back in 2016 to 2021 era
06:08
had kind of a similar
06:09
reputation, I think, as Vercel.
06:12
We had a lot of very notable developers
06:14
in the open source JavaScript community.
06:17
So I got to cut my teeth alongside people
06:19
that were on the React Native Core team
06:21
that were involved
06:22
with GraphQL super early.
06:25
And then again, I think the most valuable
06:26
thing that came from working at
06:27
Formidable was the fact
06:29
that it was a consultancy.
06:30
And I was getting dropped into all these
06:31
different engineering organizations and
06:33
not only having to
06:34
figure out technical problems,
06:36
but also like people and process
06:38
problems, which end up being the harder
06:40
problems in tech and
06:42
ironic, maybe not ironically,
06:43
but I think Effect actually
06:44
helps address some of that.
06:48
Actually, that's a very interesting
06:49
topic. How would you say
06:51
that Effect helps with that?
06:53
I think it's very hard to manage
06:54
TypeScript and specifically TypeScript on
06:57
the server at scale, probably past.
07:01
If you're in an engineering organization,
07:02
I'm just going to throw out
07:03
an arbitrary number, like 100.
07:05
If you have over 100 engineers and you're
07:07
starting to get tens of services, I think
07:09
that's where Node
07:10
really starts to break down.
07:13
One of the points I've made in my
07:15
conference talks this year is that to
07:18
scale TypeScript on
07:19
the server effectively,
07:21
it requires discipline and discipline
07:24
doesn't scale at the
07:25
organization level, unfortunately.
07:27
And what I mean by that is just the very
07:31
primitives and foundations of the
07:33
language make it easy to have whatever to
07:38
refer to as happy path blindness,
07:39
where it's very easy to neglect all the
07:42
things that can go wrong in our software
07:44
and just write the happy path and not
07:47
consider the error states we can get in,
07:48
which over time just leads to slop.
07:52
And on top of that, we don't have a
07:54
framework. Well, we do now with Effect,
07:57
but traditionally, Node hasn't had a
07:58
framework like Spring Boot or Ruby on
08:00
Rails or Laravel, right?
08:02
So we are consistently and constantly
08:04
downloading dependencies and trying to
08:07
mix and match them where they were never
08:09
designed together or cohesively.
08:11
And you end up reinventing the wheel for
08:13
all of the things that
08:14
Effect provides out of the box.
08:16
So would you say that Effect forces
08:19
engineering teams to be disciplined or
08:21
would you say that it
08:23
makes being disciplined easy?
08:25
Oh, man, that is great. I would say both.
08:28
Honestly, I think the
08:29
rigidity of Effect forces discipline.
08:34
But at the same time, like it makes all
08:37
the hard things of
08:38
writing Node on the server easy,
08:40
whether that's testing and mocking or a
08:42
dependency injection,
08:44
telemetry in one line,
08:46
having things like semaphores
08:49
and just nailing concurrency easy.
08:51
It's just all of like all the hard things
08:53
you end up reinventing in
08:54
every project and every service.
08:56
It's just there and it's like bulletproof
08:58
and it's composable and it just works.
09:00
So I think it almost
09:01
tackles it from both angles.
09:03
What I think is really interesting about
09:05
your career so far, there is a few
09:07
parallels that I can relate
09:10
to from my own experience,
09:12
having used many different
09:14
languages over the years.
09:16
And I'm still sort of emotionally
09:17
confused how I feel about
09:19
JavaScript in that regard,
09:21
that it's certainly not by far not the
09:24
most beautiful language I've ever used.
09:26
For that, I think my heart is still in
09:29
Haskell land, but Haskell is not
09:32
practical for all the
09:34
different things that we want to do.
09:36
And then I've also like having done quite
09:39
a lot of Rust development and Swift
09:40
development, also a fair amount of Go.
09:43
And all of those languages
09:45
kind of feel better to me.
09:48
But at the same time, I'm still doing
09:51
most of my stuff in TypeScript and
09:54
there's a reason for that.
09:55
I think one is just the ubiquity of
09:58
TypeScript and like where it can run.
10:00
And then also just like JavaScript
10:02
runtimes. there is
10:03
probably very little
10:05
where so much economical value has gone
10:07
into making it fast compared to
10:10
JavaScript runtimes.
10:11
And it's like very hard to beat.
10:13
And I think there's just so many factors
10:15
that are going in that favor.
10:17
But at the end of the day, it's still
10:19
sort of like a crappy environment.
10:21
And so this is why I've always kind of
10:23
felt, OK, well, I should
10:25
rather use a better language.
10:27
And when I then found out about Effect, I
10:29
think that's now over five and a half
10:31
years ago, this is where I
10:33
saw the inklings of hope.
10:35
Could I get off the things that I'm like
10:38
jealous about other proper program
10:40
languages in JavaScript and TypeScript?
10:43
And TypeScript also
10:44
wasn't as far along back then.
10:46
First,
10:46
I want to hear like how did you first
10:48
hear about Effect and whether the sort of
10:50
the same thing spoke to you.
10:53
I mean, that mirrors my experience like
10:55
perfectly, as I said, my
10:58
bread and butter TypeScript.
10:59
I love and loathe
11:00
TypeScript all at the same time.
11:02
Until I found Effect and especially
11:04
having spent two years working in OCaml
11:07
full time, I was feeling pretty
11:09
disenfranchised about
11:10
writing TypeScript and Node,
11:13
especially after having really felt like
11:15
what a type system and errors as values
11:17
and all the nice things
11:19
that OCaml provides you.
11:21
I felt so much more confident shipping
11:23
quality software with OCaml
11:25
than I did with TypeScript.
11:28
And it's really not even just OCaml.
11:30
The other language that brought the same
11:32
feeling to me, even though I don't have
11:34
as much fun writing it, is Go.
11:36
Like the two software stacks that I've
11:39
felt I've built the most scalable and the
11:41
most reliable technology with both on
11:44
like the technology scaling side and the
11:48
engineering or scaling side
11:49
has been OCaml and Go and they both have
11:52
similar traits for what I consider
11:54
important properties in production software.
11:58
Errors as values. They kind of force you
12:02
to consider the error path at every turn.
12:05
And that's just
12:06
distinctly missing from Effect.
12:08
So like I had I had lost my job.
12:11
I got laid off for my OCaml job and
12:13
basically came right to Vercel.
12:15
And at the time I was like, oh, man, I'm
12:17
going back to like to stop writing OCaml
12:20
on the server and I have to
12:22
start writing TypeScript again.
12:24
Certainly, I was excited to be working
12:25
at Vercel, right? There's a million interesting
12:27
problems here every day.
12:28
But around that same time, I had started
12:31
to see Effect and like many people, my
12:34
knee jerk reaction
12:34
was like, this is gross.
12:36
I don't want to touch
12:36
this. This reminds me of RxJS.
12:39
I've, you know, as a junior dev
12:42
I've made very sloppy
12:44
code bases with Ramda.
12:45
So I was initially very apprehensive.
12:47
But like you, I saw the shimmers of hope
12:51
in it that just like displayed the
12:54
properties that I found
12:55
valuable from Go and OCaml.
12:57
And then on my Twitch stream, I decided,
13:00
you know, let's give this a real shot.
13:02
Let's build something with it.
13:03
That's more than just a
13:04
toy app or a to do list.
13:06
And that's when I was
13:08
like, OK, I see it. I get it.
13:10
This brings the things that I value in
13:14
building software to the table and makes
13:16
it accessible for TypeScript and Node.
13:18
Yeah. TypeScript and Node,
13:19
it just the ecosystem draws you in.
13:21
It has like this gravity.
13:22
Yeah, I don't know if I would love
13:24
writing software as much as I do
13:25
currently without Effect, because
13:28
it makes writing
13:29
TypeScript enjoyable again.
13:30
Totally. There's a couple of interesting
13:33
points that I want to
13:34
follow up on, like namely,
13:35
RxJS, but also the comparison to the other
13:38
program languages, maybe
13:39
starting with the latter.
13:41
It's interesting that Effects on the one
13:44
hand is like an absolute marvel of like
13:47
engineering on like it
13:49
basically unlocked for me,
13:51
kind of like multiply the value of the type
13:53
system provides like previously,
13:56
the type system only was applicable to
13:58
the happy path and even there like only
14:00
to a certain degree,
14:02
like it could still like
14:03
give you a false sense of safety and then
14:06
things would blow up.
14:08
But like the non happy
14:09
path wasn't a model at all.
14:12
But if you think about it the other way
14:14
around, it is like Effect also doesn't
14:17
really do so much on a technical level,
14:20
but it's actually rather forces like a
14:23
different perspective on the
14:25
language we're already using.
14:27
And I think very similar to how React has
14:30
done it, I think it basically
14:31
offers just like a different
14:34
constrained perspective on like how you
14:36
should think about like
14:37
opinions, how you should write code.
14:40
And through those constraints, you
14:42
actually gain a lot of freedom and a lot
14:46
of like emergent properties.
14:49
And so when you think about like values,
14:52
errors as values, it's not like that this
14:54
is like a unique new capability that was
14:57
now brought to TypeScript.
14:59
Honestly, we could have written
15:00
JavaScript like from the get go.
15:03
I think it was basically just no there
15:05
was no cultural critical mass
15:08
that really made that a thing.
15:09
It could have been another like popular
15:12
library, let's say like underscore JS
15:14
would have enforced that more
15:16
or let's say another length.
15:18
Another library would have enforced that
15:20
and it would have kind of picked up as
15:23
a cultural movement.
15:24
But it didn't like people rather like,
15:26
for example, maybe
15:28
you still remember T.J.
15:30
Holloway Chuck, like
15:30
the creator of Express
15:32
JS et cetera. And I
15:34
learned so much from him.
15:36
And he I think was at some point like fed
15:38
up with that cultural
15:40
perspective that he went into and to Go
15:42
land and embrace that very fully.
15:45
I think there could have been a different
15:47
parallel universe where maybe Effect
15:49
wouldn't be as relevant today if we would
15:52
have already kind of taken those
15:54
inspirations from other languages and
15:56
embedded it more in JavaScript, even
15:58
without any feature changes in terms of
16:02
the syntax of JavaScript, et cetera.
16:04
As Effect currently like proves, there is
16:07
no different syntax.
16:08
It's all there. We just need to use it.
16:11
This is where maybe my react analogy
16:13
isn't as perfect because
16:14
it also introduced JSX.
16:16
But I think it's the same
16:17
sort of perspective on it.
16:19
So I'm curious what are
16:20
your thoughts on that?
16:21
I mean, I completely agree with you.
16:24
And like I think going back to like the
16:26
beginning of this, one thing I think
16:28
people don't realize and maybe that we
16:31
don't talk about enough is that we focus
16:34
a lot of the time talking about like
16:35
errors as values and how
16:36
it's tracked in the type system.
16:38
But like Effect is insanely good at type
16:43
inference for the happy path to like
16:45
you're getting the same level of DX as
16:47
you're getting from things like TRPC or,
16:50
you know, Drizzle or Prisma, like all
16:53
these top of the line, very popular
16:55
libraries today that people talk about
16:57
how good the type reference
16:59
is from the front to the back.
17:00
Like that is present in
17:02
Effect too, if not more.
17:04
Table stakes.
17:05
Yeah. And I don't think people talk
17:07
about that enough, but it brings that
17:09
same level of like amazing DX for type
17:11
inference from just like the happy path
17:14
and co-generating clients from their
17:17
front end and back end to the error path
17:19
and dependency injection.
17:21
And that kind of ties
17:23
back to the culture, like.
17:24
Error handling and both dependency
17:26
injection and like the JavaScript
17:27
TypeScript node ecosystem, it just like
17:30
haven't really been a thing.
17:34
And people even experienced developers
17:36
that have been working in this ecosystem
17:37
forever, like this reaction of like, have this reaction like
17:41
why don't I just throw the errors?
17:43
And then it's like once
17:45
you start writing Effect.
17:46
And I've seen this every developer that
17:48
I've introduced to Effect.
17:49
At first, it's like, this
17:51
is like a lot of resistance.
17:52
And then they're like, wow, I did not
17:54
realize how many things could and were
17:59
actually going wrong in my software.
18:01
And it's like
18:02
pulling back the curtain.
18:04
It's like, oh once you look
18:06
behind that curtain of seeing how error
18:07
prone software really is and that like we
18:10
have this culture of not handling errors.
18:12
If you go back to writing just TypeScript
18:14
with try catch, like you're going to be
18:17
writing a lot more try catches and a lot
18:19
more granularity because you can't unsee
18:23
how error prone everything is.
18:26
And it's always the question of like,
18:28
well, does this function throw?
18:29
I have to go check the implementation.
18:31
Does it dependency throw?
18:33
I have to go check their implementations.
18:35
And it's like
18:36
once you have that realization, it just
18:38
makes you want to
18:38
reach for Effect naturally.
18:40
And I think that's that
18:42
aspect is so interesting.
18:44
Like people are different. Right.
18:45
So some people are naturally kind of like
18:48
truth seeking and some others are rather
18:51
like already barely getting
18:53
by with what they need to do.
18:55
And they don't have energy to like learn
18:57
something new or maybe they if it's
18:59
really required of them,
19:00
maybe they they learn something.
19:01
maybe they they learn something.
19:01
And I mean, this is well reflected in
19:03
sort of the crossing the
19:04
chasm adoption curve, etc.
19:07
But I, for example,
19:08
I get very frustrated if I
19:11
realize, OK, there's something is like
19:14
something could be better.
19:15
But then I what I get mostly frustrated
19:17
with is if I can't quite see yet how it
19:20
could be done better.
19:21
And this is where I basically then start
19:23
just exploring in sometimes I like leave
19:26
the metaphorical country of JavaScript
19:28
land to go to other languages, to other
19:31
literal languages and see,
19:34
hey, how are things done here?
19:36
And this is as much of a technical thing
19:38
as a cultural thing.
19:40
And this is where like in 2020 I started
19:43
again, like looking around from like
19:45
Haskell to like Scala,
19:48
which I've used in the past.
19:49
And this is where I stumbled across Zio
19:52
and John De Goes, the author of
19:54
Zio, has in a very humble move at last
19:58
year's Effect Days conference, has sort
20:01
of, I guess, paraphrasing here,
20:05
like admitted defeat in that regard that
20:09
the biggest impact
20:10
Zio had is like to inspire Effect, which
20:12
now brings it to to a
20:14
much wider audience.
20:15
But I think this is where I can't give
20:17
people like Mike Analdi, etc., enough
20:20
credit that they managed to like
20:23
take that inspiration and be like
20:26
resilient and determined and crazy enough
20:29
to like take those ideas and like bang it
20:31
against a TypeScript type
20:32
system until it kind of fits.
20:35
And in a way where it basically like in
20:39
2020, I would have thought, OK, like
20:41
we've kind of reached the peak, what you
20:44
can do with TypeScript.
20:45
And that's like, OK,
20:47
that's just how we do it.
20:48
And we do a bit more like unit testing
20:50
over here and we do a little bit more
20:52
like micro front ends
20:54
and like tRPC, etc.
20:57
But only once you've seen how much better
20:59
it can be, then you realize, oh, my gosh,
21:02
it's like this big, big delta.
21:04
And and I think this is exactly that
21:05
describes exactly the experience that
21:08
like people who start working with you on
21:10
on Effect things, they realize like where
21:13
they basically thought like, OK, there's
21:14
like this little little bit of
21:16
improvement that I could
21:17
make to like layer after layer.
21:20
You realize, oh, my gosh, I can write
21:22
code so much better.
21:24
And this for me is like one of the best
21:25
feelings about programming when it's
21:27
basically not like you learned once and
21:29
then you OK, you know how to like need to
21:32
like have a hammer, a nail
21:34
and you need to like bang it in.
21:36
OK, that's it. But for for programming,
21:39
like this has now for like decades showed
21:42
me time and time again that there is more
21:44
elegance to kind of be mined.
21:46
And Effect has been like like on the same
21:49
level of like React to me in terms of
21:52
like how much elegance
21:53
could be exploited here.
21:55
So, yeah, maybe you want to share a bit
21:57
more about the typical experience someone
22:00
has working with you of
22:02
being introduced to Effect.
22:05
Yes. Yeah. I want to one
22:06
thing I want to go back to and.
22:07
I think one thing I used to and I still I
22:11
don't talk about as much anymore, but
22:12
like I think some of the most one of the
22:13
most valuable exercises, somebody who has
22:16
exclusively worked in the TypeScript
22:19
ecosystem can do is step outside of the
22:22
language and learn something else.
22:24
Like without a doubt in my mind, working
22:27
in OCaml and working in Go and working in
22:31
Elixir have made me such a better
22:35
TypeScript developer because I've learned
22:39
practices and patterns from those
22:42
ecosystems where they might
22:43
emphasize on something more.
22:45
But that can apply equally to TypeScript
22:47
and just like learning to look at
22:49
problems differently, whether that's
22:51
concurrency or error handling or how you
22:53
manage dependencies.
22:55
It's a cheat code, actually. It really it
22:58
really is. So, yeah, for anyone listening
23:00
that has only ever worked in TypeScript,
23:02
learn something new, step outside of the
23:03
ecosystem, I
23:05
think, and be really valuable.
23:06
But working with me on Domains, I'm
23:09
kind of in this kind of privileged
23:11
position where I got Ethan and Elliot on
23:13
my team who are also two very notable
23:15
Effect developers in the community.
23:16
But we also have Rhys Sullivan on our
23:19
team who has started writing Effect.
23:21
And like when I was speaking earlier of
23:23
people starting to write and, you know,
23:26
peeling back the curtains or having these
23:27
aha moments like I was thinking of Rhys.
23:30
It just becomes so clear like the
23:33
minute even like so up until maybe like a
23:36
month ago, Rhys hadn't written a lot of
23:38
Effect code just because he is working on
23:40
different kind of more legacy priorities
23:42
than a lot of our Effect code is.
23:45
But he's been reviewing the PRs that the
23:46
whole team has been writing in Effect and
23:48
like he's become very
23:49
capable very quickly.
23:51
I think there is a there's a perception
23:52
problem of Effect on like how hard it is
23:56
and how different it actually looks,
23:57
which we should probably talk about.
23:59
But yeah, like he's at the point now
24:01
where like I notice him starting to
24:04
reach for Effect first to solve problems
24:06
because he's seeing the value it brings.
24:09
And it's so funny, every
24:11
developer that I have
24:13
convinced to try Effect.
24:15
Ends up falling in love with the fact
24:17
even if they have no
24:19
FP background.
24:21
And I also don't think it's
24:24
fair to categorize Effect necessarily
24:26
fully as like an FP thing.
24:28
And that's a disservice to what it is.
24:31
And I think these people I'm thinking
24:32
about on Twitter or other people I just
24:34
know tangentially that
24:34
have tried Effect like.
24:36
They don't know or they don't care that
24:37
there's underlying FP
24:39
foundations. Same for React. Right.
24:42
React tricked the entire world into using
24:47
functional programming
24:48
principles and concepts.
24:49
I would like to hear more about like
24:51
those anecdotes I now with the
24:54
benefit of time have like seen quite a
24:58
few of like those of conversion cycles.
25:00
And I think every time it sort of like
25:03
goes in like a bigger splash radius gets
25:06
bigger and like some like you are very
25:08
notable example for that.
25:10
I think you've been also like you had
25:11
also your phase of being skeptical.
25:13
And then over time, you saw more
25:16
where the value is.
25:17
But I think also maybe it was a good time
25:20
to talk a bit more about like your
25:22
own transition from like
25:24
initially being skeptical to like what
25:26
were the things that
25:27
like made a click for you.
25:28
And I think maybe it's similar for some
25:30
people. Maybe it's dissimilar because
25:33
like you obviously saw the you know
25:35
already what better programming paradigms
25:39
and like practices are.
25:41
So maybe you didn't need to be convinced
25:43
about those. Those are those probably had
25:45
like validity for you in the first place.
25:48
But maybe you wouldn't
25:50
like what gave you pause.
25:52
So what gave me pause upfront.
25:54
Was obviously syntax it's weird to
25:57
see the first time but I
25:59
had also gotten to a point.
26:01
Maybe a maturity as a developer were like
26:04
OCaml looks weird like if you look at
26:06
OCaml it doesn't look like anything
26:08
you've ever written ever because there's
26:09
no parentheses or brackets or anything.
26:12
But in my experience writing OCaml like.
26:14
Someone learning OCaml gets past that in
26:16
two to three days. So like I've learned
26:19
to set aside like if I have a knee jerk
26:21
reaction because of syntax I set that
26:24
aside regardless of the
26:25
language or ecosystem now.
26:27
I've, I don't know through experience
26:29
have just come to recognize that it
26:31
does matter for adoption but it doesn't
26:33
matter as much as we think it does.
26:37
I think some people refer
26:38
to it as Tailwind Effect.
26:40
Yeah exactly.
26:42
So initially skeptical of the syntax. I was like
26:45
When I first started trying it
26:47
I was skeptical because like I was that
26:48
over eager young dad that made a mess
26:50
with Ramda. I have worked in and cleaned
26:52
up through consulting
26:53
large RxJS code bases.
26:56
So like, going into Effect I was like
26:58
this ain't it. This isn't going to work.
27:00
But because I recognize some of those
27:03
patterns from Go and Elixir and OCaml.
27:05
I was like I want to
27:07
give this a real shot.
27:08
And like almost immediately day one it's
27:11
just like the syntax kind of just melt
27:13
away you realize that it's not that
27:16
different at all like looking at.
27:19
all of our Effect at Vercel.
27:21
It looks so close to regular TypeScript
27:25
like the only things that.
27:26
Look kind of distinctly different is
27:29
like setting up our layers like
27:31
that is the piece that.
27:33
Ends up not looking like.
27:34
What you're used to in the JavaScript or
27:36
TypeScript ecosystem and even then that's
27:38
the kind of thing that takes.
27:39
One or two days you see the pattern over
27:42
and over again and
27:43
it's like okay I get it.
27:44
But like for all of our
27:45
business logic like it.
27:47
Really just looks like normal TypeScript
27:49
and every dev I've showed that doesn't
27:51
know Effect can read our code and
27:53
understand what's
27:54
going on very very quickly.
27:55
Despite everyone
27:56
saying that is not the case.
27:57
So I had that same experience right so
28:00
the first thing one of the things I built
28:02
to learn a new language or
28:04
stack is I like building a.
28:06
Basically the OAuth flow for
28:08
Spotify and like pulling playlists.
28:11
So that looks like I'm doing the whole of
28:13
flow launching a browser spinning up a
28:14
temporary HTTP server hitting the call
28:17
back and I did that.
28:19
That was the first thing I built with
28:20
Effect and immediately I was
28:23
like oh this makes sense like.
28:25
Just I got introduced to the platform
28:27
package very early I got introduced to
28:30
like a bunch of the concurrency
28:32
primitives like deferreds or mailboxes.
28:34
The error handling obviously is always there
28:38
in front of you you're forced to deal
28:39
with it and it's just like within writing
28:42
a couple hundred lines
28:43
of Effect I was like.
28:44
This feels good this feels like.
28:48
There's something here and then you just
28:50
kind of keep going and as you need
28:52
different parts of the ecosystem you pull
28:54
it in and you keep having these.
28:56
Kind of like oh this gets better and
28:58
better and it all just.
29:00
Is designed in mind with each other so it
29:02
composes together from the error handling
29:04
to the tracing with Otel to.
29:07
Schemas much like Zod and
29:10
It ends up making you more productive and
29:12
able to develop faster and develop way
29:14
higher quality software faster.
29:16
So I love the example that you keep going
29:19
back to when you try out a new technology
29:21
or a new language and more
29:23
comprehensive technology.
29:24
you didn't
29:25
need to learn what concurrency is you
29:27
didn't need to learn like what are
29:29
handling is when http server like you knew
29:31
a lot about those concepts and so on like
29:33
you had a strong intuition for those.
29:34
Yet I guess if you've all done that on
29:37
one day there you need to like learn
29:40
about the surface area and quite a bit of
29:42
the surface area of
29:43
Effect there in one day.
29:45
And presumably you didn't have another
29:47
Dillon there who's already up and running
29:49
with Effect he says like don't worry
29:50
don't worry like yes looks like quite a
29:53
bit but like it's very simple like just
29:55
over here you do that
29:56
over there you do that.
29:57
You did that presumably all by yourself
29:59
so what help you to kind of like not
30:03
get lost in the big forest and that you
30:06
basically could take it one step at a
30:08
time and what advice would you give to
30:10
people who might feel a sense of being
30:12
overwhelmed by Effect
30:14
being very comprehensive.
30:15
Yeah so there was definitely overwhelmed
30:18
with like you type Effect dot and you
30:20
just see the whole API and your lsp offer
30:23
docs and there's a lot
30:24
there but if you just.
30:25
focus on doing the task at
30:27
hand, I think, and only taking the pieces
30:30
that are obvious that you need.
30:32
It's a relatively straight forward path,
30:37
especially if you are an experienced
30:38
developer like I think Effect would be
30:40
really hard to learn.
30:42
Just like right off the rip for a junior
30:43
gym like I don't think that's very
30:45
different than like if you threw somebody
30:46
into Go standard library and
30:48
say go build the same things.
30:49
But like if you have any amount of
30:52
experience like building stuff like we
30:54
talked about like it you'll have.
30:56
The natural inclination to know what to
30:58
look for I guess
31:01
that just comes with experience.
31:03
But just like onboarding like it's so
31:06
this is another thing that I don't think
31:08
we do a great job at talking about or
31:10
advertising or teaching or
31:11
documenting is that like.
31:12
It is so easy to integrate Effect into
31:16
existing code bases and it's
31:18
also very easy to integrate.
31:21
Effect well the other way around right
31:23
like you can incorporate it into a sync
31:26
await code very easily and then you can
31:29
also take Effect code and use it in a
31:31
sync await very easily it's not
31:33
like this problem where like.
31:34
It doesn't force Effect on the rest of your
31:37
code base like you can isolate it to.
31:39
One function a couple lines of code in a
31:41
function and you can kind of control how
31:44
you want to start
31:45
leveraging it over time and it never.
31:49
Really has this forcing function that I
31:51
think people seem to think it will where
31:53
it's like this all encompassing like all
31:55
or nothing framework.
31:56
we have like
31:57
a one great example we have a internal
32:00
RPC client that hits one of our
32:02
domain services that we use in our back
32:04
office and it's all built with Effect
32:06
under the covers it uses Effect RPC but
32:09
we have a really thin maybe.
32:12
50 lines of code wrapper around that that
32:16
puts in a sync await interface in front of
32:18
it so anyone can use it and it feels like
32:20
promises or it is promises
32:22
so it doesn't have this like.
32:23
Life over your code base you think
32:26
it would it's very easy to
32:28
incrementally adopt and
32:29
likewise, if you build out like a service
32:32
or even an endpoint or even just a little
32:34
client or function and you don't like it.
32:36
You can constrain it there it's not like
32:38
you're stuck with it, but
32:40
I have never seen someone start using Effect
32:42
and not want to keep using it.
32:44
Yeah, I think that there's a couple of
32:47
interesting points to remark there maybe
32:50
one is that given that JavaScript has
32:53
been around for such a long time we have
32:55
like seen many waves of like different
32:58
frameworks different kind of like
32:59
approaches falling like becoming
33:03
mainstream and then falling out of favor again
33:06
and I think every time when that happened.
33:08
like the JavaScript ecosystem at large
33:11
has formed like the equivalent of an
33:14
immune system and forms like antibodies
33:16
of like OK oh like that looks like that
33:19
thing and we had a bad experience with us
33:21
and it's kind of like it's rarely like
33:24
wears off and it all just like compounds
33:27
in skepticism and like raises the bar
33:30
which is great but I think
33:32
Also for some ideas that maybe look a
33:34
little bit like this but are different
33:36
now have a hard time to kind of get
33:38
through and so I think it's also
33:40
worthwhile to dispel a couple of myths
33:43
about Effect to like
33:45
notably about like RxJS and so on.
33:48
We'll come to that in a second, but I
33:50
just want to highlight again like how
33:52
like I think the perception of like oh
33:54
Effect is not easy to
33:56
incrementally adopt.
33:57
That I think is also a big myth because
34:00
it's one of the easiest technologies to
34:02
incrementally adopt like it's easier to I
34:05
still remember when like promises were
34:08
introduced to JavaScript and you had to
34:10
basically go from like just call back
34:13
hell to promises and you didn't have
34:15
promises right away but you actually like
34:18
you had to go through like well
34:20
generators you had to go like through
34:22
like generators through bubble etc.
34:25
And now when you started introducing that
34:28
that had like also ripple effects for
34:30
your entire code base also still when you
34:33
now when promises are even top level
34:36
support top level await is supported
34:39
everywhere now you do like one async
34:41
function anywhere and you have that
34:43
function coloring problem.
34:44
So that's one aspect where I think
34:46
incremental adoption is like very very
34:49
difficult or another one would be if you
34:52
want to interface with another language
34:54
so if you want to use ReScript or if you
34:57
want to use PureScript
34:59
or one of those things.
35:00
Then you have like your whole tool thing
35:02
you need to like generate some code you
35:04
need to do like something that's really
35:06
like actually like FFI and so with
35:10
Effect it couldn't be
35:11
simpler right so you have like.
35:13
You have your effect and you run it as a
35:15
promise or you have your run it you have
35:17
your promise and you run it as an effect
35:19
like simple one liner yeah.
35:22
Well Malte who's the CTO at Vercel
35:25
recently had some like.
35:27
Apprehensions to us using Effect and like
35:29
some of the points he brought up is like
35:30
well we need to be sure we're making
35:32
using like everyone's using our auth and
35:34
rate limiting and permission checks and I
35:37
was like Malte like we're using all of
35:39
this stuff like we're using it the same
35:40
as everybody else it's just.
35:42
TypeScript like we're
35:43
just wrapping it in like
35:46
Try catch effectively and wrapping it in
35:48
our own values it really truly is just
35:51
TypeScript we don't have some extra
35:54
compilation phase we don't have that FFI
35:57
layer where you have to write bindings to
35:58
JavaScript functions you just.
35:59
Call JavaScript functions because it is
36:01
JavaScript and like I said
36:04
The weirdness of the syntax goes away in
36:07
literally a day or two and it becomes so
36:09
easy to read it becomes easier to read
36:11
than your typical TypeScript code bases.
36:15
Just because of the
36:15
structure it enforces on you.
36:17
Yeah I don't know how to teach that or
36:20
get that light bulb moment to people
36:21
earlier but it once people get it it's
36:25
yeah it's a beautiful thing and I think
36:27
it like just becomes easier over time
36:30
like we've already formed that nucleus of
36:32
critical mass were first a small amount
36:35
of people it has clicks and that has led
36:37
to a larger group of people who it has
36:39
clicked for and now like
36:41
larger educators like Matt Pocock
36:45
For example have also like there it also
36:47
like you saw a clear trajectory like it
36:50
was exposed to Effect and like didn't
36:52
quite get it yet and I think then you
36:53
have to really like hit the right problem
36:56
then you realize okay I still remember
36:58
like someone said
37:00
Effect this problem okay.
37:02
Let me give it a try what is this and
37:05
like it's sort of like this meme where it
37:07
were like you first reaction like.
37:11
I was living for Matt Pocock's journey
37:15
through Effect because like you know
37:17
people I mean I was tagging him I was
37:20
encouraging him to check it out for like
37:21
the past year and a half and slowly bit
37:23
by bit like he and I had some
37:25
conversations about never throw he found
37:26
value in never throw and he started using
37:29
that and it's like
37:30
As soon as I knew he found value in
37:32
never throw I was like the minute he
37:34
tries Effect like for something real it's
37:37
game over ant then over the past couple
37:39
months on Twitter you saw him diving.
37:41
Day by day tweet by tweet into the
37:44
different aspects of Effect and sure
37:47
enough it had hooked
37:49
him and he had the same.
37:52
The same roller coaster ride is all of us
37:53
is where it's like I just looks like
37:55
overkill like a lot and it looks weird I
37:58
don't know I'm fine just using a result
38:01
type from another library and then you're
38:02
like oh no this actually does
38:04
bring some model things that.
38:07
Actually are very easy to use despite
38:10
what your gut reaction might be to them.
38:12
So given that you have your number
38:15
of dead bodies under the rug from the
38:17
past of all it like introducing Ramda
38:19
somewhere RxJS and I'm not sure whether
38:21
you've like used Redux
38:22
Saga at some point.
38:25
I loved Redux Saga. So maybe we can talk
38:28
briefly about each of those technologies
38:30
since I hear them like every time when
38:33
like a more notable person brings up
38:35
Effect there's guaranteed a group of
38:38
people who say like oh this is just RxJS
38:40
over again or like some a smaller
38:42
group of people remember about Ramda.
38:44
And so like someone has like their past
38:47
experience like their trauma from the
38:50
past and now like matches is on top of
38:53
Effect so maybe we can go through the
38:55
most notable ones here and like maybe
38:58
talk about like the commonalities and
39:01
talk about like where
39:02
they're very very different.
39:03
Yeah totally done.
39:05
So let's start with with RxJS
39:08
probably the biggest one here.
39:09
given you've used it in the
39:10
past maybe we can talk about where RxJS
39:14
and Effect is similar like spoiler
39:18
alert both are both have a thing for
39:21
streams are just as exclusively about
39:23
streams. Effect has amongst many other
39:26
things streams and
39:28
where they're different.
39:29
So I think I've I've already given
39:31
spoiled the tldr but maybe
39:32
you can go more into depth.
39:34
So like RxJS almost has the same problem
39:38
as like a sync await like it's almost has
39:42
a function coloring property of its own
39:43
where it forces streams and observables
39:46
on you and if you want to get all the
39:49
benefits from you know Rx you have to
39:53
percolate that everywhere.
39:54
And there's kind of like a jarring cutoff
39:56
point where you get
39:57
outside of Rx.
39:59
I think the
39:59
pipe operator we have is like one of the
40:02
things that people immediately see and
40:03
just make the assumption that.
40:05
Like Effect is just streams and
40:06
observables the whole way down just like
40:08
RxJS does which couldn't be further from
40:11
the truth like type is literally just
40:13
function application in our case.
40:16
Which is something you know it's funny if
40:19
we would have gotten like a pipe operator
40:21
in JavaScript like I don't think this
40:23
would be a problem at
40:24
all but here we are.
40:25
Effect
40:26
almost causes like the exact opposite
40:28
thing almost like we were talking about
40:30
earlier like you don't have one you
40:32
literally don't have function coloring
40:33
because you can treat asynchronous
40:35
programming and synchronous
40:37
programming as the same thing.
40:38
But because it integrates so seamlessly.
40:41
With a sync await like that cut off line
40:45
or integrated incrementally or getting
40:47
the full benefit of Effect is really easy
40:50
to do in these
40:51
isolated chunks where RxJS
40:53
That's not necessarily true certainly you
40:54
can do that but
40:56
you're just using for observables
40:57
and streams where Effect is giving you
41:00
all these other benefits whether it's.
41:03
Data structures built in or rate limiting
41:05
or structure concurrency or dependency
41:09
injection like there's a lot more there I
41:11
think people just see dot pipe and.
41:13
Make an assumption there.
41:15
So maybe if we want to lean a little bit
41:17
into the argument where people say like
41:20
it's just RxJS all over again let's
41:23
let's imagine like four years ago they
41:25
were very excited about RxJS maybe
41:27
they were the person
41:28
in a team who is like.
41:30
Tried us out over over the weekend it
41:32
made some problems that were notoriously
41:34
tricky very elegant with streams and
41:37
maybe the thing that they've been working
41:39
on was like very stream oriented and like
41:42
you could actually live that dream
41:44
that like hey everything is a stream.
41:46
But at some point reality caught up and
41:49
not everything is a stream some things
41:51
got more more difficult and then they had
41:54
to rip it out they had a very hard time.
41:56
And when you know say like hey it's like
41:59
they have that RxJS trauma and
42:02
they think like Effect will
42:04
be that like all over again.
42:05
I think their skepticism is coming from
42:08
the right place but where Effect is very
42:11
very different is like
42:13
if RxJS was only like a tiny sliver of
42:16
Effect and you didn't have all the other
42:18
pieces sure that means like if
42:20
you have a different problem.
42:22
you don't have an
42:23
elegant solution for that but Effect has
42:25
kind of like thought that through in all
42:28
different perspectives in all different
42:30
directions. RxJS is like
42:31
this narrow tunnel of
42:33
problems that it makes.
42:35
Super nice to solve with and elegant to
42:38
solve with and can certainly be the right
42:41
solution but like Effect like I call it a
42:44
standard library like missing standard
42:45
library for Effect like
42:48
I like to compare it to working in Golang
42:50
because when you're working in Golang you
42:52
very seldomly have to reach for like
42:55
third party packages because.
42:57
What you need is probably going to be in
43:00
the standard library with a really well
43:02
designed interface and API and it's just
43:05
there to use it's easy to use it matches
43:07
the semantics of Go and the best patterns
43:10
in Go and it just works.
43:12
And like if you try to view that part with
43:14
RX you're going to just run into a whole
43:16
headache and make these kind of very
43:18
spaghetti code very messy abstraction
43:21
type things trying to force.
43:22
RX to be this general purpose thing
43:24
because it's distinctly not and it
43:27
shouldn't be but
43:28
Effect is, Effect has the.
43:32
You know prefix tree it
43:33
has the rate limiter.
43:35
It has like any HTTP RPC like it's all
43:38
there it has database interfaces it has.
43:42
file system to work across Bun, Deno, the
43:45
browser like it's all there and it's all
43:47
designed to feel the same way and work
43:49
the same way so like once you paid the
43:51
small learning curve price of the two or
43:55
three baby four patterns
43:56
that you haven't seen before.
43:58
It's all the same. So basically
44:00
to react generously to the it's RxJS all over
44:04
again I would say yes,
44:06
but this time it works.
44:07
And in that regard that the dream that
44:09
people got excited about RxJS
44:11
initially this time it actually
44:13
works with like let's see in hindsight
44:15
like let's say in 10 years.
44:17
new technology comes along people say
44:19
Effect all over again, but I'm pretty
44:21
confident that Effect will fulfill the
44:25
promises that we have here.
44:26
Maybe briefly to cover Ramda for the
44:29
people who used it in the past I think
44:31
Ramda is like has a different shape so
44:34
instead of like being like super like
44:37
being like RxJS as like one very narrow
44:39
but like super elegant long thing
44:42
Ramda has rather been like.
44:44
a much smaller scope much more like you
44:48
had to really like buy into the buy into
44:51
the philosophy is like much more of like
44:53
hey like functional programming like
44:56
we'll bring functional programming to
44:58
JavaScript to TypeScript and will
45:00
like if you buy into that everything will get better.
45:03
But I think it's kind of suffered a
45:04
little bit from like the how Haskell is
45:07
impractical in that regard once you want
45:09
to do a real world
45:10
thing like the spotify.
45:12
auth thing and you're like oh well well
45:15
in that consideration you need to do
45:17
something impure so what was your
45:20
experience back then how would you
45:22
compare it to Effect.
45:23
Yeah It requires the commitment to
45:26
functional programming that Effect does not.
45:29
Like Ramda I will say is functional
45:32
programming in like just its essence
45:35
Effect is not Effect like they're like I
45:39
said there are certainly definitely
45:40
things in Effect and patterns that are
45:43
inspired by functional
45:44
programming but like honestly.
45:46
there are almost just as many
45:48
OOP things in Effect as well like i'm
45:51
writing more classes than I
45:52
ever have with Effect right.
45:54
So I think that's an misconception is
45:56
just that like a bunch of the underlying
45:58
ideas in functional programming make
46:01
really good foundations for abstractions.
46:03
That can scale and are easy to use and
46:06
can expose maybe imperative interfaces
46:09
right like this has been
46:10
a popular idea for years.
46:12
functional core imperative shell right
46:14
and like that is like the essence of
46:16
Effect like you can do that you can have
46:18
your cake and eat it to here.
46:20
Where with Ramda it truly is like you
46:22
have to buy into understanding like
46:25
monads and applicatives and
46:27
how all of this stuff works.
46:29
And that.
46:30
It's very present to you in the code when
46:33
you use it and that's very jarring
46:36
encountering code like that in a code
46:39
base if you've never seen it where.
46:42
Like you almost have to.
46:44
Learn the mental model to be effective
46:47
and like while there is some mental model
46:50
shift in Effect it's.
46:52
Not a that far of a departure from just a
46:55
sync await and regular JavaScript.
46:58
And I think the best thing about
46:59
acquiring that mental model is like I
47:03
call it a time like pain driven when you
47:05
have a particular problem.
47:07
Then and maybe it's true however you
47:09
realize what the solution is to a problem
47:11
maybe through a more experienced
47:13
colleague or a friend or through an AI
47:17
agent or however you realize OK here's a
47:19
problem diagnosis and here's secure.
47:22
Once you realize OK the cure the solution
47:25
is shaped this way then like maybe you
47:28
like take the solution term.
47:30
Whatever structure concurrency typescript
47:34
and just start googling that or ask Chat GPT
47:37
and then you already have an a
47:41
mental model for what you want.
47:42
And if you have that mental model you
47:44
have your problem you have your solution
47:46
mental model and then you start using it
47:49
everything just fits
47:50
like a glove.
47:51
And I think that is the the best starting
47:55
point to adopt Effect like have a real
47:58
problem that's really annoying that is
48:00
like actually like business level like
48:03
meaningful and then that makes it
48:05
worthwhile I think that makes it for the
48:06
best argument also to your colleagues
48:09
that like taking the
48:10
risk might be worth it.
48:12
So maybe with that segue let's spend a
48:15
few more minutes before we come
48:17
to a close about like some of the
48:20
superpowers that Effect has
48:22
unlocked for you at Vercel.
48:24
Yeah I think one of the biggest ones
48:25
is telemetry like all of our services at
48:30
Vercel have like pretty
48:31
decent telemetry with data dog.
48:33
But our team in our
48:35
service is in particular have.
48:37
Distributed tracing just working like we
48:39
can see traces from our front end RPC or
48:43
HTTP clients down through the HTTP layer
48:46
into the services into our data access
48:48
layers if we kick off.
48:50
You know asynchronous jobs on like a job
48:52
queue or a workflow or something we can
48:54
connect the traces over
48:55
there very easily so we just.
48:58
Get this easier picture of how our
49:01
systems relate how the data flows makes
49:03
debugging so much easier so like
49:04
observability out of the box is like just
49:07
a huge unlock with
49:08
Effect. Other thing is
49:10
for our domain search in particular we
49:13
are doing a lot of optimizations around.
49:17
Making it really fast that require kind of more complicated.
49:22
Concurrency patterns
49:23
and caching patterns and.
49:25
The tools we need are just there with
49:27
Effect like we would have to be bringing
49:31
in at least half a dozen
49:34
external libraries to be.
49:36
Kind of managing these same solutions and
49:39
implementations and with Effect it's just
49:42
a couple lines of code and it just
49:43
you said fits like a glove and like that
49:45
like not only is that great for
49:47
productivity and like consistency of code
49:51
across a code base but it also like.
49:53
You went back to like I don't know when
49:55
you said this earlier but wanted fitting
49:57
like a glove and like when you land on
49:59
like an elegant solution that it just
50:01
feels like it fits and it flows well like
50:03
that feels good like that's.
50:05
Like dopamine it's like you're getting
50:06
dopamine kicks from that all day long
50:09
writing Effect because it's just like
50:11
that just worked and like it wasn't
50:14
complicated was a hard and just flows
50:15
correctly is like oh that it feels really
50:19
really good to write Effect.
50:20
Yeah, I think there the more experience I
50:23
got over the years the more I kind of
50:26
like also had to come to terms like okay.
50:29
No things are not as as like easy and
50:31
simple as I want them to be there's just
50:34
like inherent like a high and like
50:36
there's more complexity.
50:38
And more entropy and whatever we're
50:41
dealing with then we initially thought
50:43
and then it comes all about like modeling
50:46
it that we say like hey this entropy this
50:48
complexity here we can like ignore
50:50
probably not important.
50:51
But that complexity those aspects those
50:54
we really need to account for and then
50:57
comes to basically the point of like your
50:59
software tries to model like your domain.
51:02
And this is where you just need to
51:04
account for certain things and things how
51:07
things go wrong and how things should
51:08
happen at the same time how like
51:11
performance looks like another thing to
51:13
model for and to basically
51:15
come to terms with like the.
51:17
Harsh complex reality Effect is stands
51:20
out in the way for you to do that but
51:23
empowers you to do that and I think this
51:25
is what like like lets you stay in the
51:27
flow and gives you
51:28
joy doing the hard work.
51:30
Yeah yeah it makes doing the hard and
51:33
right things first class and natural and
51:36
easy the other really big unlock is I
51:40
think the testing story for us.
51:42
Like many large enterprise TypeScript
51:45
Node code bases most of our testing
51:47
framework isn't just with these kind of
51:49
implicit mocks or file
51:50
this is a module level mocks.
51:52
But by being able to have true and real
51:55
dependency injection like we're one of
51:57
the few teams that has a legitimate.
51:59
end to end local dev experience
52:00
because we can write implementations of
52:02
our interfaces against local stat or we
52:05
can write a in memory client and just
52:07
dependency injection for
52:08
Redis so it just makes testing.
52:10
So much easier I've never had a better
52:14
testing or easier testing experience them
52:17
with Effect so that's another thing that
52:19
has been a huge unlock for us.
52:21
So I think this already gives us some
52:23
really concrete ideas for what we should
52:26
talk about in the future since
52:28
firstly you have a hard stop so we need
52:30
to let you go at this point but we're
52:32
already in the process of
52:34
scheduling a follow up episode.
52:36
Where we might also have some of your
52:38
colleagues join as well maybe this is the
52:40
time where we dive deeper into dependency
52:43
injection into testing some of those like
52:45
superpowers that Effect gives you maybe
52:47
some other topics one topic that's really
52:49
top of mind for me these
52:51
days is like
52:52
How we build with AI and how we built for
52:55
AI and I think Effect is both the perfect
52:58
fit for for both of those so some great
53:01
topics to explore but.
53:03
I need to let you go at this point, so
53:06
thank you so much Dillon for coming on the
53:08
show today and having such a nice
53:10
conversation. Yeah Thank you for having me
53:12
and i'm looking
53:13
forward to the continuation.
53:15
Thank you for listening to the
53:16
Cause & Effect Podcast.
53:18
If you've enjoyed this episode, please
53:20
subscribe, leave a review
53:21
and share it with your friends.
53:23
If you haven't done so already, you can
53:25
join our Discord community.
53:27
And if you have any questions, feedback
53:29
or suggestions about this episode or
53:31
about Effect in general,
53:33
don't hesitate to get in touch.
53:35
See you in the next episode.