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