Welcome to the GOTO Podcast. Each episode covers the brightest and boldest ideas from the world's leading experts in software development.

Tune in for practical lessons, compelling theories, and plenty of inspiration.

GOTO gathers the brightest minds in the software community to help developers tackle projects today, plan for tomorrow, and create a better future.

Stay up to date with the latest in tech through GOTO's top-rated events in cities like Amsterdam, London, Copenhagen, and Chicago, and by subscribing to the GOTO Conferences YouTube channel where you can find thousands more high-quality dev talks.

Learn more at gotopia.tech. So, welcome to another GOTO book club.

I'm Andrew Harmel-Law, and this week we've got the three authors of Effect-Oriented Programming with us. So just a little bit about me, because it kind of maybe introduces how I know Bill, James, and Bruce.

So there is an open space conference up in Crested Butte in Colorado, where I think actually I think all three of you live, right?

I'm guessing you all live there now, 'cause some of you were all saying.

>> So it's this is how it's an open space conference, which so and everyone should definitely attend it, because it's the the best open space conference I've ever been to.

But I first met Bill and James and Bruce at this open space conference.

And one of the cool things is is that at that conference, I was introduced to effect-oriented programming.

And I'm kind of interested to find out—this might be one of my questions—how lots of those conversations and those sessions led to this thing.

But first, I should let you introduce yourselves. So, do you want to go, do you want to go first, Bill?

Just tell everybody who you are and, uh, how you ended up here.

I am Bill Frasure. I have known these guys for about 10 years now. Mainly just as friends, but eventually we found our way into finding a project we were all interested in.

I worked at Ziverge for a few years, which is the company behind ZIO, which is the effect system of choice for our book, which we'll get more into later.

I, yeah, I've just slowly become more and more interested in functional programming via Scala or whatever language might come in the future.

And yeah, I'm definitely the most junior of the authors here. I've got the most experience in ZIO, definitely the one small pond that maybe I have the deeper experience in.

Cool. Cool. Cheers, Bill. Uh, Bruce, do you want to go next?

Sure. Um, Bruce Eckel. I've mostly written books. Uh, sometimes I do consulting.

Yeah, there's some of the books back here. Been doing this for a long time. Have mostly focused on languages in the past.

Trying to broaden my perspective now. And also conference organization is something I've been involved with for a long time. The upcoming Winter Tech Forum is the first week of March here in Crested Butte, which is a ski town.

>> Yes. Which, hopefully, we've been wanting to get Andrew to come back here for every, every year. He's going, maybe I can come and then something happens and he can't.

Yeah, that's me. Nice. >> Yeah. Thanks, James. >> Sorry, Bill.

I should stop reading the names at the bottom. The names are in the wrong order on the screen. And James, sorry. Do you , want to introduce yourself quickly though?

>> We'll align the names on the screen. >> No, the names should be aligned with who like it's confusing.

>> Yes. Right. >> Yes. I'm James Ward. I work on agentic AI stuff at AWS. And Rich and I have a podcast together called Happy Path Programming.

So that's a fun little hobby. And >> we wrote a book together.

>> We wrote a book long ago together. >> Long ago that immediately >> It's up here on the shelf. We hid it behind this.

Yeah. >> Yeah. >> That was on dead technology. >> Yeah. Well, it was dead as soon as the book got published.

Yeah. >> Yeah. >> Yeah. So, yeah. So, I think one of the things Andrew, you'd said that you started exploring effects up here at uh, one of the conferences we did up here and that was my first experience with effects and and it's called ZIO.

Actually, that's where I first started getting into effects was was here at one of our conferences. And so, it was early days for ZIO.

I think it had just been announced as, you know, the first, you know, pre-release of it. And so we spent a couple days during the conference just diving in, trying to learn it, and it took us a little while to kind of wrap our heads around what in the world is this and why do we need it and why is it better?

And so, um, so yeah, I think our journey's >> taken me all of those years to try and figure out that we're still working on it.

>> So that, that actually, that's, that really that leads perfectly on into my first question.

So, 'cause the book is, and this is a thing I've noticed kind of like in more and more books recently, the, the book is not very thick, but it's obviously taken you like a number of years to figure out, right?

And having been someone who's written a book which is far too long and is could potentially be a lot thinner.

Do you maybe want to just quickly explain to us a little bit about that journey because it's, it's very, and I mean this in the best way, it's super terse.

It's very focused, right? >> Yeah. Well, I think there's a few motivating factors.

One of which is just how much knowledge and background seem to be required to get into functional programming and effects in particular.

And it was always these very intimidating texts with all sorts of assumed knowledge about, you know, you must be this smart to read this book.

And our goal was to really just lower that as much as we could and really aim for if you've written any amount of code in a language, hopefully this book is approachable.

You know, it's, it's not going to be perfectly understood by anyone who picks it up, but we just tried more and more.

What can we strip out of this? And I think at the high water mark, the book was about two and a half times as long as it ended up being in the final published version.

And once we realized like, oh, we can remove this.

Oh, we can remove this. And that became its own kind of addicting feeling of just like, oh wow, we just removed 10 pages and the quality of the book did not drop at all.

Like we didn't leave anything behind by doing that. And I think this was a really good exercise because it helped us kind of strip down to, you know, what is really the essence of this thing.

And because there's so much like when you wade into the documentation, you get all kinds of it's this, it's that.

And this process of saying, "Well, what can we take out and still have it be what it is really helped and and I mean for me, I was just kind of hanging on by my fingernails the entire process.

It wasn't until a year and a half or two years ago where lights started to come on and I started to maybe see, oh, maybe this is what we're doing.

Maybe that is what we're doing." It was definitely a mental exercise and challenge. Yeah. And it took us a while to get to the mission that we ultimately got to.

Like we went through a number of iterations. At one point we were going to write a Scala 3 book and then we were going to write a Scholo book and then we came to Effect Oriented Programming and we're like the the mission that we have is to teach people the value of effects, why they should use them, why they're better than what you're currently doing, how they help you create more reliable, testable software, more composable software.

And so then that became the driving mission of the book was let's teach people effects, and ZIO, you know, just became a vehicle to do that.

And then it became very easy to kind of decide what goes in the book. Is this helping people understand effects and the concepts of effects, not ZIO, like we're not going to teach you how to use ZIO.

Like, you can go learn that, read the documentation, read other books, but we want to teach you the concepts of effects and how they're going to benefit you and your code.

>> Yeah. Nice. I mean, and this is just to give props to my editor.

So, I like what you've just said. My editor used to summarize by saying, it's important, Andrew, but is it essential?

And I obviously didn't spend enough time trying to find the essential. But I like to anyone who's listening to this who thinks, is this book worth reading?

Like in my, like the fact that you've like super succeeded in distilling it down to that kind of thing.

You don't it's not suspended on its own that it doesn't kind of apply to the real world, but it's it's very, you know, you could find the stuff that's underpinning it if you wanted to, but you don't need to.

It's very it's very pure. And so that's leads some evidence of of this working.

So there's a new AI framework that the Kotlin JetBrains folks came up with, and they actually just I ran into them last week at DevOps, and they told me that their design for how they designed the like workflow definition system within this Kook AI thing was actually inspired by factoring, and that they wanted to isolate the the the side-effecting pieces from the workflow definition.

And and so I was like, cool, like that's like a totally different realm from what we kind of were in when we wrote the book.

But it inspired somebody to like take an effect-oriented approach to designing this this library, which was really cool to hear. I'm going have to ask you more about that later.

Yeah, that's that's like, so my next question is just because I we've teased this enough.

So what are effects? This is the thing, right? So I I thought I knew what they were, but I didn't. But now I do because I've read the book.

For people who are interested in this, what are effects really? Kind of what are the if you can if you can distill your your very thorough book into an even shorter quick explanation.

Yes. Um, okay, my current way of thinking about it is that effects are operations that can be composed.

So rather, I mean, we we talk about composition with uh object-oriented programming, we stick objects together, but this these rather than objects, these are operations and you can compose them.

And when you do, you get a new operation that can be composed.

So it's kind of a holy grail sort of thing that we've been chasing throughout computer science from the beginning.

How do we make bigger pieces out of smaller pieces? And the challenge here has been predominantly how side effects mess things up when you try and do composition.

Eventually, you know, it's a little easier, but then eventually side effects come in and make it harder and require the programmer to do lots of repetitive custom work every time they want to make these changes.

And I want to jump in and make sure we emphasize that it has an effect on the real world. It is something that operates outside of the realm of your processor because if you're adding two numbers, sure that's an operation that composes.

But if you are adding two numbers and then sending a message about that to another system, okay, well now the situation has fundamentally changed.

You had an effect on the outside world and that just brings new types of risk and consequences to these things of, you know, I think one important part is an effect can't be just universally undone.

You know, once you have sent a message out into the world, you have kicked off, the butterfly has flapped its wings, you don't know what is going to come out of that.

So that's why you need to treat these things with special care is because it can just cascade out into all these unexpected places.

And so effects you want to be very deliberate about when and how you execute them, right?

You can't with when the way Bill described it, oh, you've got all this stuff going on the outside.

That's what makes it hard to compose these operations. So, the effect has to encapsulate its own side effects so that it keeps track of everything, and that's what makes the composition possible.

And I think it's just the difference in, okay, this code puts something in a database or this code, when it is executed, will put something in the database.

And just that slight shift of, okay, well now we have something that we can execute or we can manipulate it further.

We can clamp it down more. We can add some new behavior to it. Just the fact that it is not executed in an unprincipled way.

You always have to be very deliberate about when is this going to be acted upon. And that deferred execution is pretty fundamental to empowering you to compose and alter the behavior in all sorts of arbitrary ways.

Yeah, because that was something that struck me was when I, as all three of you definitely know, I spent many years struggling trying to understand and wrap my head around functional programming.

And because lots of my world was the kind of the side effects bit, which when you do FP, like core FP, they're like, don't worry about that.

That's like, you know, they're bad. We don't think about these. And I was like, but everything I do is side effects.

But then, like you said, kind of Bill, right, then then this is extending kind of types and some kind of determinism into the world, the nondeterministic world of all of this unpredictable stuff, right?

Like you said, when the butterfly flaps its wings, but I really like giving you the right handles to manage the unpredictability of what happens once you talk to the outside world.

So it doesn't like, it doesn't turn the unpredictable into predictable, but it gives you the tools to manage the unpredictable pieces.

So you can easily put on like a timeout or a retry or these different things that you're like, okay, this thing may go wrong.

I may get an error, which is unlikely to happen if I have a pure function.

Um, but I'm now now things can can go a different way than I expect them to. How do I deal with that?

And and then how do I deal with that at a single level or at the composed level of things? Because how do you you know, every time you've got one unpredictable piece, you put them all together now you seem to have something very large and unpredictable, you know, more unpredictableness.

And so like, how do you deal with that at at the small and at the big and use the same foundational pieces to do that?

>> And this was the thing because this is what kept striking me again after having spent, you know, time sitting in open space sessions with with all three of you, like the whole you kept saying the compiler can check this and I was like, this is this is a big, like, this is a big deal, right?

Like suddenly a lot more, like you said, it's not you're not making the nondeterministic deterministic, but you can check that you've thought about these things and that they compose together and I think that's, I mean, is that maybe the aha, sorry, Bill, is that is that feels to me like one of the big things, right?

That you that you want to get >> Yeah, just all the things the compiler can do for you of in ZIO the particular effect system we're using for this book as you execute a series of operations, if they have different failure modes, those all are tracked and assembled at the end.

Effect Oriented Programming • Bill Frasure, Bruce Eckel, James Ward & Andrew Harmel-Law

GOTO gathers the brightest minds in the software community to help developers tackle projects today, plan for tomorrow and create a better future.

Learn from thought leaders and innovators with top-rated videos released daily, and at our year-round conferences, masterclasses and meetups.

Get started: https://gotopia.tech

GOTO is produced by Trifork, a leading full-service supplier of high-quality, custom-built applications and end-to-end solutions.

GOTO YouTube Channel Code of Conduct: https://blog.gotocon.com/yt-coc


Effect Oriented Programming • Bill Frasure, Bruce Eckel, James Ward & Andrew Harmel-Law

Scripts