Convince us that Effect.ts is good

The guardrails were really necessary because humans are bad at coding. If you can't convince a human to be disciplined for a long time, you have no chance of convincing an AI to stay disciplined beyond the context window. Like this this was the the most useless optimization we've ever done in my in my humble opinion. But like how are you templating things? No, just functions.

Just functions. But come on, you're not looking at it anyway. Yeah. Like, who looks at HTML? When is the last time you open an HTML file?

Effect is having a moment, and I feel completely unprepared to talk about it. So we've brought Michael Arnoldi on, the benevolent dictator for life of effect, to talk all about what the latest version means for effect, but also why you should be checking it out because I've heard it's sick. Michael, welcome to Syntax. Thank you for having me. It's a pleasure to be here. Yes. So let's get into it. Effect v four just came out. People have been talking about effect long before this latest version, but I wanna know first and foremost, like, what does effect do that makes it different? Effect

is kind of providing guardrails, and the guardrails were really necessary because humans are bad at coding.

Mhmm. That was eight years ago. I'm... First and foremost, I'm a developer. I've been developing for my whole life, and I always strived to write software in a modular, reusable way and so on and so forth, but I never really got to do that.

Any time I would kick off a new project, it would start nice and it would end up in a mess pretty quickly. And I think that's a feeling that's familiar with for most developers who've been around

enough to have seen a project grow. What are the types types of things that you see in a project that you start off with all the best practices and you think it's going to be nice and then, I don't know, you're six months into something, you need to push it out and things just start to get messy and weird and hacky. Like, what are the most common things that you start to see? Well, the reality is it goes back into being agile with with development.

There's no way you know all the requirements upfront or, you know, all of the complexity that hides in the details of a project when you start.

So you always start thinking, okay, this is going to be easy life.

What am I building? A login system? Oh, I've done it a million times. That's going to be easy. And then you hit production and you realize that there are edge cases all over the place. People start to use your application and they tell you it's slow.

You have no idea why it is slow. The famous saying, it works on my computer.

Yeah, it's because you never you're never able to reproduce everything that happens once once you push the production button in your own system.

So to me, the only property that is needed for software to evolve into a good place is the fact that you can always refactor it with ease.

Software is a malleable thing. It has to change with the life of the product you're building.

I've never seen the same piece of software stay intact for forty years, except maybe COBOL in the banking system. But apart from a few edge cases, most of what we build is there to change. It's not there to stay intact exactly how we thought of it at the beginning.

And to safely evolve software, you need to prevent mistakes and you can't just rely on discipline.

There's a saying from a friend of mine, which is Dylan Morroy, who's currently a principal engineer at Cloudflare.

He used to say this when he was at Vercel to justify his effect adoption.

It was like discipline doesn't scale.

You need more. You can't start without a single person being disciplined, but as the project grows, new people lean, it's going to get messy.

Just the nature of Is it fair to say, like, you're building an application and you choose effect early on and you use effect. So instead of writing all of your code in just normal JavaScript, like, would kinda just start YOLO ing writing functions, catches for error handlers, having to, like, recreate all of this stuff is you sort of buy into the effect way of doing things. Right? All of your logic, flow control, error handling, requests, concurrency, promises, all of that stuff is you do it in the effect way. And when you do it in the effect way, it all works together. You make sure that you have your fallbacks, your error handling for absolutely everything, as well as I'm sure there are observability benefits and whatnot. Is a fair

thing to say about what effect is? Well, the adoption story of effect usually goes with a developer first hacking their own solutions together and then realizing that, yes, in their application, they need to do error handling.

They need to do observability.

They need to care about concurrency.

They need to do logging.

They need to have metrics.

They basically need so much stuff that has nothing to do with what they're building. You might be building a product.

Why should you care about how you're doing error handling? You should just have a way of doing it that works, and you follow that. And there were languages and frameworks in the past that have heavily inspired my early work on the fact that Rails in the Ruby ecosystem, Spring in the Java ecosystem, and so many.

And those are imperfect by nature, but we don't really care about the fact that they are imperfect.

We care about the fact that they work and they're probably better than what we can hack ourselves with with a small team while also having to build everything else. And the fact was my way of doing that in in in TypeScript with the limitations of TypeScript.

My goal was to write TypeScript.

Many people ask, why is effect not a language? Like, I wanted to write TypeScript.

If I wanted to create a new language, I would create a new language.

Like, my objective was let's use the same language across the full stack and let's have sane practices.

And that has evolved way beyond my initial needs and vision because it turns out when you have a lot of people building in different spaces, they also need a lot of things that are common and that are not so specific to what they build.

So, Effect ended up being a fairly large ecosystem.

Turns out AIs are even dumber than humans at writing code.

Well, that was my next question is like, is this better now in the AI world? Both because I think like the biggest, like the reason why people didn't want to learn effect is that it's like, you gotta go all in, you gotta learn all of these new things, there's generators, which nobody Yeah, else is it's different and scary, right? Yes. But nobody likes to look at effect the first time they No, see no, but like, is that better now with AI?

I mean, it goes back to discipline doesn't scale.

If you can't convince a human to be disciplined for a long time, you have no chance of convincing an AI to stay disciplined beyond the context window.

Mhmm. And like now we are in a phase where we are all yellowing lots of code all over the place.

Yeah. If you don't have verification and guardrails, like...

Oh, yeah. If you look behind the curtain on what you've built, like, you're scared.

I think that's the thing that's the most attractive to me about it is that we are in this area era of needing more deterministic checks, needing more verification and validation. In fact, like my for me right now, the the barrier is how much compute I have running for all my verification and validation scripts. So the fact that these systems really need that and this works better

in that way is the most appealing part about effect to me personally. Yeah. Like, one thing that AI code does quite a bit right now is you build a function to do something, and then you say, ah, I I need to handle this use case. So it it will throw... It'll either duplicate the function or throw, like, an if statement in there for that little edge case. And then like six months later, without looking at the code, if you do look at the code, you realize there's a lot of little if statements, little edge cases.

It's just like this, like house of cards that has been built on. So giving something that is a lot more rigid and structured to an AI will potentially help that type of thing. Is that true? I think it is true. Empirically,

from my own experience, it is definitely true.

In itself, it's not like effect gives you everything you need to have the guardrades in place. But the basis of it, like you have much more types, you can create way more rules on top of it that really target your own taste on what you want to build.

The parallel is kind of like React versus jQuery.

Like why React took over and jQuery took over at the beginning but then was displaced from the most important JavaScript framework by React.

With your own mental context of, yeah, I want to do HTML and I want to create HTML stuff and so on and so forth. It looked similar. You could read it, but really you could understand it and it composed very well and it detangled the complexity of when you're looking at a component, you don't need to know the whole system to understand how it works.

And that gives you the primitives to scale UI development in a similar fashion effect. Does it across the stack? It's like you can still write an if statement and do a hockey procedure while using effect, but usually refactoring it is much easier and your agents do it too. That's just a property of, like, doing less side effect things.

Because, for example, if you take a promise and you move it to a different place, the execution of your program changes and that can lead to bugs because now something starts before it used to.

And if you use effect and you move something in a different place, nothing changes. It's like extracting one component to a different file. It doesn't change the behavior of your application. So you can do it. So you can build hockey stuff, and usually you do it to do quick development, but you can transform that hockey stuff into more reliable stuff.

And usually how you do it nowadays is you look at the code and you tell the agent, hey, this looks like code that is horrible. Please stop doing this. Write a rule.

And if you have a linting infrastructure and so on and so forth, the agents are fairly good at writing those rules for you. It's really about giving you the primitives that allow for this type of development.

And I think what changes with AI is the tolerance that people have for code they don't like.

Because if you're not looking at code too much, you're not so bothered by looking at a yield star instead of And an to be clear, like, it's not that I'm in love with this peculiar style of program. I couldn't care about yield start. I haven't rolled effect because I like generators.

I ended up using generators because I wanted to write procedural code, imperative code, and that was the only way to do it. So, it's like, yes, it's not perfect, but it's much better than writing normal TypeScript in my own experience.

And everybody's writing TypeScript today.

I was checking npm downloads on the on the TypeScript package.

Is it is it 400,000,000 downloads per week? Yeah. A year ago, they were like 25

ish, maybe two Yeah. Unbelievable. I think a lot of people don't even know they're running TypeScript.

Right. Yeah. Of course. Yeah. But I also think a lot of people don't know they're running Effect, because Effect is at 75,000,000 downloads per week. It's it's a fifth of TypeScript.

75,000,000.

Wow. Yeah. Yeah. It's insane.

Yeah. Fifth of TypeScript.

Yeah. Holy. And, like, who's using Effect? Can you can you drop a couple names? Obviously, you said Cloudflare earlier.

Cloudflare, OpenCode, t three code, lots of companies.

X.com, Zendesk.

Like, you you have pretty much any... From the smaller start up to the most boring enterprise.

Yeah. Think rogo.ai...

Man. Truly manny.

So, like, thinking of... I'm just trying to, like... Somebody listening right now is trying to place, like, okay, I'm looking at something like x.com.

What would they what would they use it for? Obviously, the answer is you can use it for everything.

But, like, like, what are the big problems that someone like x.com would have? And what are, like, the primitives in effect that would, like, make it so much better?

In x.com, they started using it for their streaming platform and for their analytics platform, and it started in the back end and then rippled through the through the front end.

Especially at X, you have very independent teams. So I'm not claiming that all of X is using effect.

Some engineers decided that it was the best technology for that specific use case.

But on the other side of the spectrum, there's like super base, the CLIs, what we'd effect.

It goes back to a person being able to maintain the software they write.

And usually if you used effect in the past, you're way more likely to restart a new project by using effect from day zero.

It used to be a very unlikely case that you never used effect and you would start a project with effect.

You would have to hit some level of pain and then go through it.

But now it looks like least anthropic models are picking it up sometimes by themselves.

Surprising because I don't even know why technically.

Going back to the reasons is always weird.

It's mostly about building with production grade software in mind. Yeah. Like telemetry, for example. It's so useful to be able to observe what happens in your program, both at development time and in production.

And most of the people only use telemetry if the platform they deployed into gave them some telemetry by default, but like the entry point of just understanding how much a request take.

But if you know how much a request take and you don't know what composes the request, what are you even looking at? And agents have a wonderful time with looking at traces and they like to optimize.

Like, as soon as you set up a loop to like, okay, this is low, make it fast, and they have the data, oh my God, they can go nuts.

I want to get into that observability and telemetry in just a sec. But like one comment, you said that X is using it for their analytics platform.

And that that was really interesting to me because React was built out of, I think the Facebook ads platform because like these dashboards that have hundreds of requests, the data is always changing, everything is dependent on another thing. They're a very complicated thing to build. If you've never built like an analytics or ads like dashboard for, it's a very hard thing to build. And the problem of the UI was solved a lot with with React, but the actual business logic part of it of how to build something like this is is a hard problem to solve. And I was in Facebook's, like like, I think it was like business dashboard or some BS the other day, and the thing is so slow now. And I was like, man, what happened? It renders quick because of React, but, like, certainly, they've But the data doesn't come in quick. Yeah. The data doesn't come in quick. The things don't refresh. There's just so many little bugs that I just hate using, and it is absolutely awful to just click around inside of it. And that just shows that it's been probably what? Like twelve years of just tacking stuff on, and it's just it's such a beast now that it would be really hard to rebuild that type of thing. And I think using effect in a similar project like this would would certainly help.

I think what you're hinting at is that highly integrated and distributed systems are hard, and the entropy of them tends to grow beyond what's manageable.

And to be frank, that's exactly the problem I was facing when I first built Effect. I was building a fintech startup, and we were in the business of aggregating multiple lenders and securitizing loans.

And that's a very boring business case, but it translates into a highly integrated system where I had to mesh together hundreds of APIs.

And if you mesh together hundreds of APIs, be sure some API will fail, some will not return the data in exactly the same shape that they promised you the data is in and so on and so forth. And all of this then translates to a poor user experience of the product you're building because you open an interface and, like, sometimes you have errors or, as you describe, data renders fast, but then it's unusable after it's Is it important that it renders fast if you can't use it later? I don't know. Yeah.

Google might be satisfied with the benchmark, but after that, nobody's happy. Yeah.

Yeah. So, okay. So in the latest version of Effect, v four was just released somewhat recently here, end of September. Right? And one of the big things that we we talked about when it was released that it went to zero dependencies.

So what was that transition like? Because it's not like I I don't know what the dependency situation on effect was before the version four rewrite. This kind of trend of of trying to remove our dependencies, simplify things in that way. Did that make, working on effect easier by removing these dependencies, and how how difficult of a transition was that? Look. It's something that years ago we would have never done,

to be to be clear. Effects started as a general purpose library, so it was very thin, but then it grew into an ecosystem of things where you have SQL drivers, where you have caching, where you have distributed rate limiters, and you have schemas.

And there's so many things that require the level of dependencies to be added.

Alternative was, are we going to build an XML parser? Like, why would you? Now, in today's world, what we found is that many times by buying like by by depending on something, we're buying all the choices they've done, they've made all over the dependency history.

For example, with EffectSQL Postgres, which is the connection to a Postgres database, used to be based on Pg.

Sorry. It used to be based on Node Postgres.

Then we realized there were some bugs around it. We switched to PG to realize there were other bugs around.

Then we we added query pipelining.

It would break transactions.

There were so many edge cases that at some point were like, what does it actually take to build an SQL driver to spec? It's highly testable.

It's not like we're building something that we don't know if it works reliably.

And the answer is it took three days of working with AI.

That's not a lot.

And the end result is we control 100 of the code, which means if there's a bug to fix, it's just a PR to fix it. We don't need to interact with many other library maintainers, go through RFCs, RFCs, go through endless discussions about should we even do this and sometimes you just want to get things done. Having zero dependencies turns out to also be quite important in a world where supply chain attacks are critical.

Like we put a lot of effort in be sure our pipeline for publishing is safe, but we can't do so because we have a fairly sizable team at this point.

There's a lot of eyes on the repo. There's a lot of resources between OpenAI and Anthropic. I think they gift us like 12 subscriptions each, and we consume through all of those.

Wow. Like those are not things you can easily do as a a solo maintainer of a library that people forgot that, you know, is running the whole infrastructure of the world.

Yeah. And maintainers in the open source space are always underpaid, stressed out, insulted all over the place because a random guy didn't like a line of code that they wrote.

So it's generally much safer to rely on a single provider versus having to rely on the surface, a single team. But behind the scenes, it's really 100,000 different developers who might be Yeah. In different states. You know, it's actually crazy because

if you go to the package JSON on the effect GitHub repo, there's literally no dependency entry.

There's there's dev dependencies. That's what's zero dependencies? It's not even there. I know I know what that means, but, like, literally nothing. You know? Yeah. Know. It's not even there. Oh, that's great. Means controlling your code. Yeah. And now the cost of doing that is so cheap.

Like, we're doing most of our work through AI infrastructure that our team has built, and it's so easy to develop at this scale that is insane.

I would have never thought this was possible.

We asked Kyle Daggle from GitHub about this, about future of dependencies.

Now that you can simply just like, vibe up any dependency that you want, do you think that, like, more projects should be going this way? Or do you think that, like, you guys have a really good test structure? Because the the benefit of using existing dependencies... Obviously, there's supply chain attacks, but they're also, like, super well battle tested, and they cover a lot of edge cases.

The thing is, it depends a lot by what you use of a specific dependency.

Sometimes I see dependencies installed, your use is literally the 0.5%.

Maybe at that point, it's better for you to control that 0.5 and avoid fighting the 99.95 of the rest of the library. If you just need a small subset, I don't really have an answer on like, is it better to go zero dependency or is it better to depend on something? I feel like if you are getting enough value out of a dependency, use it by all means.

If it's peripheral to your use case and it's just a matter of a few days of work and you can be reliably sure that it works the way you want it to work, vibe it.

Yeah. You you got a five times smaller bundle with effect four, so it's down to... It looks like 7.1 kilobytes for the entire bundle. Was that mostly from removing dependencies, or was that from taking a a new approach? No. So effect

has a has a runtime, basically.

We have to create the equivalent of a virtual machine inside JavaScript to execute your code. It's both simpler and more complex at the same time. The reality that piece of software used to be much bigger.

And this goes into the history of like how effect was first built.

I was taking a lot of inspiration from libraries in the Scala ecosystem.

So there was a lot of porting of some of the assumptions of those other libraries directly into TypeScript.

What motivated Effect four at the beginning was actually projects like upload thing from Theo Brown and his team started to use effect in the back end and then they wanted to use it in the front end but were like we can't add 45 kilobytes or more of bundle to every consumer just because we use effect behind the scenes. So we quickly prototyped a very small version of effect that targeted only their use case.

It was just literally targeting what they needed.

And we called that effect micro. And at some point I was like, okay, but if effect micro works, why can't we add the features of effect into effect micro? We ended up trialing the idea for a few months and it turns out that yes, you can actually do 95% without increasing the bundle size materially.

And to be clear, that is the minimum bundle size. If you use the full of the effect ecosystem, you might even get multiple megabytes of stuff. There's hundreds of libraries in the ecosystem and so on and so forth. But currently, if you're using effect plus schema and streams, you're still smaller than using Zod, for example, to put things in reference. The argument is should you really care about a five, 10 ks of bundle size difference? I don't think so.

Like, this was the most useless optimization we've ever done, in my humble opinion. Let's

talk about that. Like, alongside effect, like like, where does, like, your UI frameworks, reactors felt? How how does that fit into this type of thing? Or, like like something like Xod, like a lot of project, does does it replace Xod, or do you use it with Xod? You can do both. The the real answer, it replaces it. Specifically, Zod. For for stuff like React,

not yet, but I see a future where that is possible.

There is a UI framework that got some hype recently, which is called FoldKit.

Yeah. That is 100% wrote.

In effect, doesn't use any of the old UI frameworks, made the choice of not using JSX, which is a hard pill to digest.

After you've used it, I think at least I've digested

that pill. I never liked JSX anyways, personally. So

is it using? I'm just looking into it. Just functions.

Just functions. It's all functions all the way down.

Like, how are templating things? You love a function that returns a string? Function. Template literals?

No. Just functions.

Just j... JSX invocation, you are invoking a function.

Yeah. You just you just like to look at the at the brackets that remind you of the old days of HTML.

Yeah. Come on. You're not looking at it anyway.

Yeah. Like, who looks at HTML? When is the last time you opened an HTML file?

It's a hard truth. It's a hard truth.

Because we were, you know, we've been longtime front end guys, longtime HTML guys, and all that stuff. But the Fold Kit does make a lot of sense too. And I'm I'm gonna be getting deeper into Fold Kit myself just with the general...

It's almost like it's it's a very Redux style of of working.

And it it... For me, like, looking at Fold Kit initially, you're like, oh, this is very different. But then once you really contemplate, like, what it's doing for you, I personally have been more excited about Fold Kit than I have other front end frameworks strictly because of state inside of these applications.

So there... There's quite a bit of, like, projects in the ecosystem, like Fold Kit or Alchemy. In fact, we're gonna be having Sam from Alchemy on the show.

What are some of your your favorite community effect libraries or or projects?

I think you mentioned the two that are most...

That raised my interest more than anything else for different reasons, starting with Fault Kit.

It's a background story, sort of personal story. When Dylan used to be at Vercel, they were working on the domain's UI and back end. It was together with Reese and Ethan on the same team, and we were collaborating to help them with some weird caching problems so on and so forth.

And I know firsthand how hard it was to make that UI feel fast, and I know how much work was put with the pursuit of making the UI fast.

And then in the other day in a private channel before he publishes on Twitter and now this is public on Twitter. So I can't say that. Ping's a link. We opened the link and it's basically the Vercel domain's UI and it's fast as hell.

It was fast by default without having to fight any Next. Js weirdness than they had to fight before.

Like, I I I like JSX.

I like React. I'm a React guy.

But if this is the result...

And and the the funny thing is that the reason agents are so good is because, well, state is in a single place. Testing state transitions is about just testing a pure function.

The guy even has dev tools exposed via MCP that the agent can introspect and drive.

So it's so easy for agents to operate on that set of constraints without messing up that the end result is a UI that looks as fast, if not faster than a UI that I've seen the pain of developing firsthand.

So that's what excites me about FoldKit, how good it is to develop UIs with it.

Alchemy is the next level of infrastructure as code, which fully blends the idea of runtime and infrastructure at time. The And I don't want to spoiler too much if you're having some future No. Here's a little preview.

I think it'll make people listen to that one.

SAM is not new to this problem. SAM has tried to find the right balance in infrastructure as code, I think, for the past six or seven years at the very minimum.

And he was not a big believer of effect at first.

That's the last of the reincarnations of what alchemy used to be. Today, it's another of those projects where it kind of looks like the zero dependency argument.

It would be completely insane to do a few years ago because the guy had to rewrite all of the clients to AWS, GCE, Azure.

If you have any idea about how large the AWS API is, it's beyond.

And they have a almost fully autonomous infrastructure that is able to generate bindings for the major cloud platforms so that when you use Alchemy today, like you can use any cloud providers just fine, and the level of support is at the level of support that you would get with a Terraform or a different thing.

It's just TypeScript.

If you find something that is not already in there, for example, for our website, the search of our website is managed by MixPrep, which is a fairly cool AI search engine that can index code very well.

And well, there was no support for mixed spread buckets.

We told an agent to add support for mixed spread buckets, in a matter of five minutes, we were able to control those via Alchemy. The fact that it is just TypeScript also means it's very easy to extend, which makes the whole thing a self fulfilling prophecy. You make things fast, easier to change, and then agents are better at changing them, and it's like a loop.

Together with full kit, alchemy, and effect, together, like, they cover the whole stack from infra to front end in a single unified way of programming.

Yeah. It's been really enticing to be...

It's actually funny because it's not that I've resisted effect. I just didn't, you know, like you said, it's better build from the ground up with effect, and I I was so effective with my current stack that I never it never was, like, something like, oh, I I gotta really take the time. But Fold Kit was it for me when I was diving into it, just being like, oh, this this makes so much sense to me as a... An improvement plus alchemy.

It's like, oh, these things to me are are are what has gotten me mostly interested in in effect in the first place. So really, really, I think, a cool little grouping of of projects.

I'm I'm curious about, like, what are some of the best parts about effect that people don't often talk about? You know, you see YouTube videos and sometimes they're AI slop or whatever, and it's just reading from the docs.

But personally, what is your favorite corner of effect that you think doesn't get enough praise? Currently,

to me, it's effect cluster.

All good ideas to me are usually old ideas.

I really haven't seen many good ideas come out recently.

Effect, the idea of monadic types is from 1994.

The effect cluster is based on ideas from Erlang and the Beam Virtual Machine is literally what ended up powering a lot of telecom lines.

Was initially built, I believe, by Ericsson and its technologies from the eighties.

The core idea is a distributed Actor system.

And the fact that parallel processes should communicate via messages shouldn't share memory, should just like we are together currently. We are three people around the world that don't even know where you're sitting.

I call you by name, not by location, and we share memory, what we have in the brain via sharing messages.

That is a model that can scale a lot and you can develop a lot of cool stuff, namely in more recent times.

It's the perfect model to build AI agents because they are also autonomous entities that you share messages with that replies to you with messages.

Effect Cluster brings that to TypeScript.

It used to require a little bit of infrastructure, namely persistent node processes or BUN.

We got it to the point of even working in Cloudflare Durable Objects, and we're making it easier and easier to deploy stuff with effect cluster.

And again, it's basically a distributed actor system that allows you to model problems in terms of actors and in terms of sharing messages.

And on top of that, there's also being developed effect workflows, which is something similar to a temporal, restate, ingest.

Any time you do distributed systems, durability is the other part of the equation.

If you call two independent systems, there's no transaction between them. When you just talk to a single database, you can say begin transaction, do stuff, then commit transaction in a distributed system that doesn't exist.

And the way of approaching that is through durable workflows.

So cluster plus workflows gives you effectively the primitives to build distributed systems at scale.

It's beta, so it's not part of the stable release.

Please don't use it in production.

But yeah, that's probably the part of effect that excites me the most that nobody's talking about currently.

That said, it's normal. It's fairly early. It's better. It's not well documented.

I said we'd talk about the observability and telemetry a little bit more. I want to get into that.

What's the benefit of or, like, what can you observe when you build everything the effect way?

Are you able to then just peer into every single piece of your application? Like, what does that look like? Let me give you a backstory of my personal relationship with telemetry. So when I first encountered the topic of telemetry, there was no specification of what telemetry meant.

Yeah. There were two parallel process projects called OpenCensus and OpenTracing.

They're both competing standards.

I was developing a highly integrated system and I shipped it to productions. Things started to fail drastically, I had no idea what was failing.

So I was like, okay, let's try to get an understanding of what what is happening in my software. I was not using effect.

Effect did not exist, And I go on and try to integrate OpenTracing.

I get it integrated.

I fix some bugs, but then the code was so horrendous that I could just not ship any more feature. Like, it was literally every single function I had to wrap in try catches, try open span, do the thing, then finally close the span, report the error, pass the span to the child.

Keep in mind at that point in time, was no Node sync context or like this stuff that allows you to propagate spans and so on and so forth. It was all manual.

What I needed was to see if something failed, what failed.

I had one request doing 100 things in it, and I needed to know which one of those 100 failed or what took long. And so I ended up removing it. But I integrated it because I needed the information. And I went a little bit of back and forth trying to find the minimal amount of telemetry that still gave me insights on my program without cluttering my code base.

I think that's the wrong way to look at it. Your full code should be observable.

The way you make your full code observable is by not having to think about telemetry at all. You define a function. The function should lead to a span without you having to say anything else.

Any time you go to debug something, you always look and hope that while developing you added the right logging to see what happened, and most of the time you realize that you actually did not. Those things should be done by default for you.

If everything is observable, you haven't got anything to lose except a few megabytes of network transferring the spans, which you can disable if you don't need to.

I think this is what kind of puts you in the pit of success.

Now we find people also like to use telemetry while developing, not only while looking at production traces.

And here by people, I mean agents, obviously, because there's no people writing code anymore.

But give the agent a local telemetry server, for example, OpenCode that they recently migrated their whole code base to effect. They've integrated a local telemetry back end.

So if you run open code with a specific flag, it runs a local server, collects all the traces locally, and they become available to the agent.

And that's how they debug when things go wrong in their own. It's a CLI.

Telemetry used to be fancy for distributed systems.

CLI is not distributed. It's on your local machine, and they still find so much use for it. Yeah. It should be everywhere.

We'll...

Syntax is brought to you by Sentry, and Sentry does have a effect plugin. I'll do a little I'll do a little a little shout out to them there, but you can... Yeah. You just slap it in into your project and all that data, your metrics, logs, errors, spans, traces, all that data right back to Sentry, and that's gold for debugging with agents.

In fact, let me also plug in Sentry.

Okay. Yeah.

Sounds like it. Yeah.

While integrating creating the Effects Sentry plugin, we figured out that there were some missing primitives, and the reason the error reporter module exists in effect is because of the center integration.

Alright. That's great.

Love to hear that. Some behind the scenes things happening. Yeah. But, yeah, Sentry also hosted our I think one of our Vienna meetups. Oh, Definitely.

They got the Vienna office there. Was pretty sweet. Yeah. You obviously are deep in... Into the TypeScript.

You're deep into the TypeScript. You're using generators.

What are the what are the parts of TypeScript that make your life more difficult, and what would you change about TypeScript if you could?

Completion speed used to be a problem.

That said, it's not only TypeScript.

People like to complain about speed of dev tooling in TypeScript but they've never used stuff like Rust.

Now it's no longer an issue since TSGO and also since last week the void zero folks ended up doing TSRS, which is like 40% faster on real repositories.

Like, it checks the whole effect code base 40% faster. Wow. That's if you give the AI the right feedback loop, it's going to find the weirdest but fastest solution possible.

The spoiler is I don't think it's done. I think there's more there's more there. So completion speed used to be a problem. It's no longer weirdness all over the place, but that's due to JavaScript mostly.

And I keep going back and forth on the idea that maybe TypeScript should enter the realm of code generation and just add syntax on top of JavaScript that makes life easier.

On the other side, I also like the fact that it doesn't.

Yeah. What... Do you have any syntax that you'd kill for to be added to the language, just add it to TypeScript so we could compile it? Proper enums.

By enum means algebraic data types.

More stuff that is induced by the fact that types exist, like pattern matching and so on and so forth, could all be part of it. That said, agents are fine writing switches. Like, are we at the point of complaining about syntax? Don't I keep getting back and forth.

Know. This syntax is amazing, but syntax in general.

We haven't talked about the types JavaScript or types as comments proposal in so long. And we used to mention that once per show, which is That's because not it's irrelevant.

Yeah. It doesn't matter. It doesn't matter anymore. Doesn't matter. Yeah. It's not something I'm rooting for or against. It's just... It's not something I really care about too much. The ability of saying what goes in the language and not,

I'd be reluctant to do that. We don't even have a pipe syntax, and it's been years of byte shedding on, like, what version of pipe are we even thinking about, and then they come up with the worst possible of all the alternatives.

That's... So that that one has been, like, back and forth. That that is, like, such a a a prime example of one of those proposals that... Well, I mean, the the the reality is JavaScript is two different things. There's the engine implementer

side that think of JavaScript as a compiled target, so you don't need many primitives if you're compiling to it. And there's people using JavaScript at the surface level that think of it as a as a language, and then they wanna add methods to map because it's easier to then just do a reduce.

Who cares? I feel like whatever got added to JavaScript is because the engine implementers did not feel they had to do a lot of work.

That's good because engines have to be fast. Adding a lot of stuff into engines is usually not a good idea.

And so the bar to get it accepted was low, and there was really no big changes to JavaScript since classes. What was it? ES6.

Yeah. I mean, even generators predate asyncawait.

So, I feel like in some the language is great.

The fact that it is fast is unbelievable because it's a purely interpreted used to be a purely interpreted language. Now there's all, like, insane techniques to make it fast. But, yeah, it's a language and a compiled target to two different groups of people, and they keep fighting each other. So that's why nothing of relevance gets gets added to the language.

That's super Now it's good structs, and there are other proposals that are going through the same level of byte shedding as the pipe operator, which I don't think we'll ever get in JavaScript.

And personally, I'm fine with it. I don't care.

Well, Michael, this has been awesome. I... I'm I'm so deeply interested in in diving deeper into effect, so thank you for all all your work there, and I'm super excited.

This is the part of the show where we like to have the guest tell us something that they're just enjoying in life. We call it a sick pick, where it could be just anything that is giving you joy in life. Could be food, could be a podcast, could be a movie, could be a physical item, literally anything that you're loving in life right now.

Well, I I recently got a kids newborn.

So that's Ah. Congratulations.

Yes. Those are great. Yes. That's giving me a lot of joy. Yes.

I don't know if it qualifies as a sick peak.

I could, yeah, no, kids are There's no rules in sick planes. There's no rules. Yeah. Yeah. How old is your kid? Detaching from a... Two months old now. Oh, congrats. Congrats. Literally a baby.

But, yeah, getting out of screen time is is good.

That's my sick pick. Just wait till they, really start moving.

When they start moving, like I can't they get into everything. You got... It's like the the first few months are like, oh, this is not that bad, to an extent besides the sleeping and, you know, the constant effort. But once they start getting into stuff, man, it's... Get get through real nuts real quick.

Thank you so much for coming on, Michael. Is there anything you wanted people to check out or or check out your work anywhere beyond just effect.ts?

We have an amazing Discord community where a lot of work happens every day.

So if you wanna check out something, think it's it's our Discord community.

Beyond the fact, I think we are living through one of the most exciting revolutions in our industry.

It gives us both joys and pain and sense of like, we don't even know what's happening.

But I feel like we should all try to enjoy it a little bit more and and be open minded. And if if we make ourselves obsolete, we're gonna have less screen time and more fun in real life.

But maybe that's good. Beautiful.

Awesome. Thank you so much, for that. And, I don't have anything else. Peace. Peace.

Peace.