In today's episode, they dive deep into the world of JavaScript and TypeScript. They explore the innovative message-passing style between components using Effect Cluster, a game-changing alpha product that integrates seamlessly with solutions like Remix and React Server Components.

Join them as Michael sheds light on the ease of transitioning TypeScript developers familiar with frameworks like React and Svelte to Effect, thanks to JavaScript’s component-based mindset and features similar to async/await. They also talk about the role of TypeScript and Effect in ensuring code maintainability and correctness amidst legacy JavaScript at Sisense.

As they navigate through topics like performance optimization, multithreading in JavaScript, and backend development,  discover how the Effect framework simplifies testing, enhances type inference, and boosts code stability. Plus, they touch on coding challenges, error handling, and the importance of proper monitoring with tools like OpenTelemetry.

But it's not all code! They share fun anecdotes from personal experiences with go karting, discuss the NBA draft, and even delve into some light-hearted humor with dad jokes and comedic analogies. This episode is packed with insights, laughter, and invaluable advice for developers and tech enthusiasts alike.

Tune in now for a comprehensive discussion filled with expert knowledge, practical tips, and community insights, exclusively on Top End Devs!

Socials

Picks

Charles Max Wood [00:00:05]:
Hey, folks. Welcome back to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neil.

AJ O'Neil [00:00:12]:
Yo. Yo. Yo. Coming at you live from death by common cold.

Dan Shappir [00:00:18]:
Oh my.

Charles Max Wood [00:00:19]:
We also have Dan Chapir. It's been, like, 90 degrees here, AJ.

AJ O'Neil [00:00:23]:
Yeah. It's it I had 2 sets of family coming to town. I I caught something somehow. It put me on bed rest for 3 days.

Dan Shappir [00:00:33]:
Well, it's definitely over it's definitely over 90 degrees here in in Israel and Tel Aviv, and it's also kind of humid. So, yeah, me from here.

Charles Max Wood [00:00:45]:
Awesome. We also have Steve Edwards.

Steve Edwards [00:00:49]:
Yo. Coming at you from, as always, cloudy Portland. Look. I'm wishing for some heat dancing, some heat my way, please.

Dan Shappir [00:00:58]:
We sent a basketball player your way.

Steve Edwards [00:01:01]:
Oh, in the draft?

Dan Shappir [00:01:03]:
Well, not exactly. He was traded to, Portland right before the draft. He was playing at in Washington before, and Denny Abdiye is an Israeli basketball player.

Steve Edwards [00:01:14]:
Oh, cool. Yeah. I mean, boy, the international players are ruling the draft anymore.

Dan Shappir [00:01:20]:
Yeah. France dominated

Steve Edwards [00:01:21]:
Oh, yeah.

Dan Shappir [00:01:22]:
This year's draft.

Steve Edwards [00:01:23]:
Yeah. For sure.

Charles Max Wood [00:01:25]:
Yeah. I I watch sports ball. The the Euros are still going on. Anyway, I'm Charles Max Wood from Top End Devs. And, Yeah. I've had family come into town. It's been 90 degrees here. I'm not sick.

Charles Max Wood [00:01:39]:
I just have seasonal allergies. Different story. Anyway, we have a special guest, and that is Michael Arnaldi. And, yeah, do you wanna introduce yourself? Let us know, what effect effect you're having on the JavaScript community. That was worthy of you, Steve.

Michael Arnaldi [00:01:56]:
Yes. We are starting on that jokes, and they are Yeah. Very funny topic.

Steve Edwards [00:02:01]:
Hold on. Hold on. There we go. Sorry. I was doing something else.

Michael Arnaldi [00:02:05]:
That's too late. I'm I'm from Italy. I'm currently sitting in Siena. I I have no idea how much, it is in Fahrenheit, but it's definitely hot. And Mhmm. What is it? Feeling well, sir?

Charles Max Wood [00:02:19]:
Celsius.

Michael Arnaldi [00:02:20]:
Celsius. Yes. You know, you we're European. We work on

AJ O'Neil [00:02:23]:
Mhmm.

Michael Arnaldi [00:02:24]:
A normal measurement. No?

Dan Shappir [00:02:29]:
I I have to I have to say that, you know, we also use this in Israel, but generally speaking, the metric system makes, you know, makes more sense in my opinion. But for, actually, in the case of temperature, I think Fahrenheit might be a more human scale.

AJ O'Neil [00:02:48]:
Yeah. Primogen was mentioning this because you can say something like, oh, it's in the seventies today. And that kinda gives you a, you know, that gives you a brain AAA broad range, like high seventies, low seventies. Whereas Celsius, it's like, it's 23 or it's 24 or it's 25 or whatever it is, but, like, the range is the number.

Dan Shappir [00:03:10]:
Yeah. It's it's kind of like, you know, the grades you get in school where, you know, you graded from 0 maybe you're graded from 0 to 100, but literally everything below 50 is basically essentially fail in the same. So it's you're really graded from something like 60 to 90.

Charles Max Wood [00:03:32]:
Yeah. Well, when I lived in Italy yeah. I mean, there's a huge difference between 3040. There's much less difference between 7080

Steve Edwards [00:03:42]:
Yeah.

Dan Shappir [00:03:42]:
For

Charles Max Wood [00:03:42]:
sure. In Fahrenheit. So So it's sort of

Steve Edwards [00:03:44]:
like the Richter scale where you go up, it's a magnitude of 10 every time a number goes up?

Charles Max Wood [00:03:49]:
No. We should do that.

Steve Edwards [00:03:50]:
Works. Yeah.

Dan Shappir [00:03:51]:
No. So this is linear. It's just that it goes from of water freezing to water boiling. Right. And so so yeah. So anything about 5th above 60 is your dead. Mhmm.

Charles Max Wood [00:04:04]:
Yep.

Michael Arnaldi [00:04:05]:
Yeah. And in in very hot summer, it goes to, like, 45 sometimes.

Charles Max Wood [00:04:11]:
Oh, yeah.

Michael Arnaldi [00:04:12]:
You are basically a a nonhuman at that point.

Charles Max Wood [00:04:16]:
Yeah. When I lived in Ancona for 103 or it was like a 103 here. It was it was 42, and it was a 100% humidity. And so, you know, I was a missionary for the church, and so I could only take off so many of my clothing articles before. Right? I could not take off enough to get comfortable. Let's put it that way. So

Steve Edwards [00:04:41]:
Yeah. My daughter's been in, in Thailand for the last year as a teacher. And before she came home, we're you know, I'd look at the weather, and it was, like, you know, about 100 with 90% humidity or something like that. She sort of got used to it. So it's you know, she comes back here and like, oh, man. This is nothing. I want my heat back. I'm like, well, I don't know about that much.

Steve Edwards [00:05:04]:
But, I look at I look at the temperature. So it's only 75 in in Chiang Mai, and then my wife would say, but that's at night. Right? I was like, oh, yeah. That's at night.

Dan Shappir [00:05:13]:
Yeah. Well, before we get to into Type script and whatnot, I'll just mention that my daughter is currently in Sri Lanka. So yeah.

Charles Max Wood [00:05:20]:
Yeah. Oh, fine. Yeah. Yeah.

Michael Arnaldi [00:05:24]:
So none of us in cold places currently.

Charles Max Wood [00:05:27]:
Nope. Go do it in a shirt and tie. That's fun. Anyway, so we're we're talking about effect, and just for our listeners, if you're wondering, because if you Google it, effect is kind of a common word. It's effect. Website is the web page you're looking for, so you can get into, okay, what is this and what does it do? But, we're on a podcast, and we're gonna assume that you haven't done that. So, Michael, what is it and what does it do?

Michael Arnaldi [00:05:55]:
Oh, that's a that's a broad question. I would I would have to say that in general, it's a kind of a TypeScript framework to write production grade code. It really came to exist out of out of needs on a on a company I was working with, when we migrated a lot of system from the JVM to JavaScript in the back end. Because, you know, we were crazy people run about 5 or 6 years ago. Why would you why would you ever use, TypeScript on a on a serious on a serious back end project? Well, it it ended up costing way less than the JVM, and productivity was skyrocketing. The only issue is there was nothing to write really production grade code.

Dan Shappir [00:06:42]:
I have to interrupt you here because Yes. The previous company that I worked at, which is Next Insurance, I left them about, about and a half ago. The the front end was obviously, you know, web. So it's, it's it's JavaScript, it's React, or it's Angular, or React Native if it's a mobile device. But the back end was all JVM. It was implemented in Cortland, and it was all JVM. And, you know, when I jokingly mentioned the possibility of implementing that stuff, that business project in, in Java JavaScript, I was met with hysterical laughter.

Michael Arnaldi [00:07:21]:
Well, you see, I was CEO, so the hysterical laughter was was less less present in that case, but, yes, it is a hysterical laugh. But that's the point. It's it's a very nice language, but it it's really hard to use it when you care about the software you write. And, I mean, writing testable software, writing software that can be monitored well, stuff like observability and so on and so forth. It's a recent trend. But even 6 years ago, when when I started developing effect as an internal project, my main goal was clean up the mess that we were building. And we had we had been developing banking applications, and everything needed to be monitored properly. We had, at the time, what was called open tracing, which later got, sort of merged into OpenTelemetry as a as a larger effort.

Michael Arnaldi [00:08:31]:
And, we had Prometheus for metrics. We had, well, we had to do that stuff. So our code was basically a hell of try catches. Try, open span, catch, close span if there is an error. Finally

Dan Shappir [00:08:49]:
You're talking about the TypeScript code. Right? You're not Yes.

Michael Arnaldi [00:08:52]:
I'm talking about the TypeScript code.

Dan Shappir [00:08:54]:
Can can I ask you about the before we before we dive into TypeScript and obviously effect, which is, like, the gist of this conversation, I do want to talk a little bit more, if I may, about that decision to move off of, the JVM and and move over to TypeScript. Now I watched your the talk that you recently gave an excellent talk at the, effect conference. I think it was the closing keynote, something like that about how effect it came to be. Highly, you know, obviously, we'll discuss it here as well, but it's still a highly recommended, talk in my opinion. But I do have to ask, like, a general question about, JVM versus node. Because if you're talking about back end in in JavaScript or TypeScript, you're basically talking about node, maybe BAN, maybe Dino, but, you know, essentially, it's more or less more the same. You know, 1 of the reasons that I mentioned, like, about the circle laugh is not necessarily about the programming language itself. I guess that comes to play in it into it as well.

Dan Shappir [00:10:00]:
But it's also about, like, whether or not, you know, JVM being an enterprise grade platform and doubting JavaScript or the JavaScript engines as enterprise grade platforms. What do you think about that?

Michael Arnaldi [00:10:17]:
Well, first of all, I would challenge the fact that the JVM is generally enterprise ready. And the second element is I would challenge what enterprise ready means, actually. III know a lot of back end developers who 6, 7 years ago, they would never think of writing a back end in in in TypeScript with Node. Js. At that point in time, there was no other choice. There was only Node. Js. Only more recently came to exist other runtimes such as BAN, BNO, and so on and so forth.

Michael Arnaldi [00:10:53]:
So at the at that point in time, it was really targeting purely Node. Js. And the usual complaints are, like, that's not multithreaded. But on the other side, do you actually need multithreading? Probably not. And and there has been a more recent wave of I I don't know how to explain it, but people that 7 years ago told me I was crazy now tell me I'm right in

Charles Max Wood [00:11:26]:
in Do you know how many hamburgers I could make out of the sacred cows you guys have been slaughtering?

Dan Shappir [00:11:33]:
To be to be fair with regard to multithreading, I totally agree with you. I think especially in this day and age of containers and the fact that in many cases, you're you're intentionally limiting the number of cores per container, then especially then then the whole point of of multithreading kind of goes out the window in a lot of ways. So the event loop mechanism that, you know, JavaScript uses is very, very effective for this type of thing. And people forget that node was created with JavaScript initially because Ryan Dahl was looking for something like an event loop and and this whole mechanism. And especially now with with the sync away, it it becomes much easier. But my my point is actually something else. It's more about the robustness of the platform itself. Like, you know, how, the the garbage collector, for example, or the networking stack.

Dan Shappir [00:12:33]:
I mean, how how far do you trust them compared to quote unquote enterprise grade solutions, you know, whether they be the JVM or Go or something like that?

Michael Arnaldi [00:12:46]:
Well, I mean, if you speak about garbage collection, you should also pick a specific algorithm to target against in the JVM. There's many different garbage collectors in the JVM, and there's many different implementations of the JVM itself. There's more enterprise y implementations. There's more open source implementations. The 2 things change quite drastically, at least, at least in in my in my experience when when working with the JVM. I think overall, Node. Js in specific can be trusted a lot. I'm not too familiar with the other, newer run times.

Michael Arnaldi [00:13:26]:
I've tried them, but I have never deployed services that were serving millions and millions of customers, based on. So I wouldn't be able to, say with the same level of confidence that they can be trusted. I'm I'm sure they can, given that they are they are based on very similar JavaScript runtimes. But the the advantage of JavaScript, and it might sound ridiculous, but it is a highly specified language that almost from day 1 had very different browsers implementing it, and it has survived in browsers for a long time. And UI development is I I've disregarded UI development for years, but I came to realize that it is actually very complex and very performance intensive. Because, you know, in in in a in a JavaScript event loop in the browser, you've got only 1 thread. So if you block that thread, the interface is stuck. But there are interfaces that have to do a lot of things.

Michael Arnaldi [00:14:35]:
I was developing trading dashboards in JavaScript. There's a lot going on in in the UI of a trading dashboard that requires careful management of memory and so on and so forth. And JavaScript was always very fine. And when developing back ends, to be honest, they never had an issue with the garbage collector. I you may have some pauses. That's totally that's totally normal. But, also, it's it's always a trade off on how much memory you allocate to the Jazz process and so on and so forth. If you don't allocate much memory, there's not gonna be a lot of stop the word.

Michael Arnaldi [00:15:16]:
So it goes back to your argument of parallelism. If you parallelize at the scheduler level with multiple containers and so on and so forth, there's not really there's not really any, any huge problem with, with JavaScript per se, at least from from what I've seen. I've been mostly developing, IO intensive applications. So I wouldn't make the same argument when when we talk about CPU intensiveness and and other, you know, other places in the in the scale between memory allocations and so on and so forth. But for IO bound applications, which to me are, like, 90 plus percent of what we are all developing, Take the data from 1 database, push it in another API, call Kafka to stream out events and, you know, whatnot. It's basically taking data from place a to place b. JavaScript is is always very effective in, in doing that type that type of

Dan Shappir [00:16:23]:
job. 1

AJ O'Neil [00:16:24]:
thing that I wanna point out, though, is JavaScript is multithreaded or at least the implementations that we have are multithreaded. So it's not like the old Python or the old Ruby. I I believe that there may be some implementations of Python and Ruby that that do take advantage of multithreadedness, like what Ryan Dahl was working on in Ruby before he was working in Node. There was, I forget what it was called. It I think it was called event machine.

Steve Edwards [00:16:50]:
Event machine.

AJ O'Neil [00:16:52]:
But, you know, it it actually is multithreaded, and there is a performance difference. Whether you run on a single core or you run on 2 cores, you will get better performance running on 2 cores. Cause when you're running on a single core that means that the background tasks can't actually run-in the background. That everything has to be on 1 single core and there's no there's no ability to use the optimizations that it has. And, you know, this is something that Go suffers from this as well. In fact, the most famous clip that we got from this show was me saying something not quite right in the right context about this exact scenario. So I'll try to

Dan Shappir [00:17:36]:
see the rest of the picking then that's basically picking up on that. I would slightly, modify the statement of saying that JavaScript itself is single threaded. The JavaScript engine that runs JavaScript is not a single threaded and is able to leverage multiple course for greater efficiency. For example, you know, we talked about garbage collection. It can act it actually for example, v 8 actually offloads some of the, garbage collection activity off of the main thread if it, to to a separate thread. And if you've got multiple cores, then obviously, you bet you the benefit is greater. I I before we move on back to effect, which is the why we're all here, I I would like to say that I totally agree with what you said, Michael, and I would slightly add that, also everything that's have been happening with, you know, on on, you know, in in cloud environments like AWS, Lambdas, and and edge computing is also greatly contributed to to JavaScript as a middleware slash server side programming language and and platform?

Michael Arnaldi [00:18:54]:
I mean, JavaScript has been almost from from day 1 front end center in in what we call BFS, back ends for front ends. So, basically, the first back end aggregating multiple different APIs, that thing was was always was always very natural for, for that thing, to the point where now with full stop frameworks, we sort of get that embedded in the in in normal architecture. Because if you develop an app with, I don't know, Next. Js, Remix, or so on and so forth. I'm I'm I'm not a front end developer, so apologies if I haven't named, other very well designed, frameworks. I I just lack knowledge in in in that specific area, but I have investigated a lot both Next. Js and. And the fact that you have these sort of server options or, server functions, however you wanna call them call them, It is the classical, middleware in between your databases, your other APIs, and so on and so forth that plug that together exactly for the purpose of serving serving the front end.

Michael Arnaldi [00:20:11]:
This is an IO IO bound job to do, and and JavaScript has always been perfect for that. I think now JavaScript is also getting adopted in the layers more closer and closer to the actual the actual back end back end. So it it's moving progressively, taking slices and and slices of, of of the stack. I would also slightly correct what was said before about multithreading in JavaScript just just for the point of, obsessive correctness. It is multithreaded as an interpretation of the language, but the language itself is not multi threaded. So there's no observability of different threads in in JavaScript. It's the engine that may or may not decide to allocate stuff on thread pools. Usually, for example, file system operations and so on and so forth, they were backed by, thread pools up until recently where the kernels support a synchronous processing of, of files.

Michael Arnaldi [00:21:24]:
So the access to the file system is now no longer using thread pools. It's just using straight up, a non blocking a non blocking, interface. And Dan is completely right. VA, but also, I think also SpiderMonkey, but I I might be wrong in the internal details. Sometimes garbage collection is notoriously 1 thing that that is offloaded, a lot while threads. So by no mean, it's backed by a single thread, but you can only observe a single thread from the language,

Dan Shappir [00:21:59]:
which makes

Michael Arnaldi [00:22:00]:
total sense.

Dan Shappir [00:22:01]:
Yeah. Also, parsing the actual JavaScript into bytecode can happen off the main thread as well. But getting back to effect, per my understanding of what you were starting to say before I so rudely diverted you to other topics, you were kind of in the process you decided to move your company off of the JVM and onto, node based back end, and that resulted in you writing a lot of code, and that kind of evolved into effect eventually. So how did that that magic happen?

Michael Arnaldi [00:22:39]:
A step of being, because, first of all, another big part of the reasons why we moved Node. Js was not only the the architecture of Node that actually made stands for the services that we were running, but also it made sense as an organization decision in the company because most of our developers were front end developers trained in TypeScript. We didn't have a lot of JVM developers. We had been using both Scala and Kotlin. Kotlin's a bit easier to get for, for example, for Java people. Scala might be a bit more tedious, but still for a small team having to hire into 2 completely different landscapes is is hard, not only for the language, but also for the runtime. You know? Optimize writing code in a way that is optimized within the JVM. It's hard.

Michael Arnaldi [00:23:39]:
It's a hard topic. It's a very valuable topic that many do very well. But if you have 5 developers in total, it's gonna be very hard that you have all the skills across the board required to write very productive software from back end to front end and so on and so forth. So the decision was taken on 2 different, 2 different main reasons. The 1 reason was the JVM was a bit heavy for us, And the second reason was we really had TypeScript developers, and I wanted to use those developers across the stack and not not have them in in in silos. So both of those reasons were, were present in the decision of moving over. We moved over progressively, and we started to write plain and normal TypeScript. But as I was describing, we we were reaching a point where the code was no longer maintainable.

Michael Arnaldi [00:24:36]:
And we didn't have any rules such as, for example, in in Java, you have runtime reflection. In in Rust and similar languages, you have macros. You can, for example, say I want all my functions to be annotated with spans. There's nothing similar that you can do in JavaScript or TypeScript. I I use the 2 interchangeably at at this point in time. Doing all all that work manually meant that our code was really not maintainable and let alone the stability. The stability was a was a horror story. So that motivated what then became effect.

Michael Arnaldi [00:25:21]:
And it really started with me having a look at different languages and solutions available in different languages. That's when when I found out about and and and started taking some of the ideas into into TypeScript land.

Dan Shappir [00:25:39]:
So looking again, I I watched your talk, which, like I said, is excellent, and you kind of emphasized several times there that testing and testability was a significant motivator for for the things that you did. Weren't things like, I don't know, v test or even the new node testing library. Well, that maybe didn't exist at the time, but you certainly had things like, like, Mocha or Jasmine or Jess or stuff like that, weren't they enough in terms of the stability?

Michael Arnaldi [00:26:13]:
Well, the the issue is when you wanna test using monkey patching, you're already in a in a place that that is exposed to a lot of problem. Mainly, you have to hook up into into the loading time of modules, and you might have side effects all over the place. So it doesn't there's actually no guarantee that that you mock up the the module at the right point in time for your application to load the mock module and so on and so forth. And point 2, there's no explicitness in the dependency graph. You have no idea if a piece of code depends on the database, depends on something else. You actually have to read the code to understand that, that thing. So to write the test, you have to read the implementation. You have to know the implementation very well, and you have to patch yourself at the right point in time to be able to test.

Michael Arnaldi [00:27:14]:
It is possible, but I haven't said that it's impossible. I said that it was a lot of pain. A lot of pain in making sure that all of these programs that I've described don't end end up happening. We were doing testing. We were not doing as much testing as we were doing later, but we were we were testing a little bit using, I think, at the that that point in time, exactly Mocha and Chai, if I if I recall, correctly, that we still ended up using later. It it's just the the monkey packing element that that isn't that isn't great. And if you have explicit dependencies and explicit dependency injection, you can say in in a in a very simple way, well, I have this piece of code. Just provide to it a test dependency instead of a real dependency.

Michael Arnaldi [00:28:16]:
Later on, I even got to the point of doing more of end to end testing through the same tooling. I was creating database through test containers, taking the configuration from the created container, embedding the configuration into my application, and everything was running just fine. So the ability of of doing higher order dependency injection and so on and so forth are are really key to have an architecture that can be well tested. And it really means an architecture that is modular enough. You could do everything without effect in a in in a very diligent and and precise way, but it's it's very hard. And you naturally screw up over, over time. Effect sort of forces you into into that golden path of of writing software that can be tested even if you then decide not to test it. The properties of good testable software are properties of good software, good good maintainable, and good software in general.

Michael Arnaldi [00:29:27]:
So the point per se is not is not really about testing it. It's it's rather about having it testable, which is which is more of an architectural point of view in in instead of the the practice of writing the tests per se.

Dan Shappir [00:29:44]:
So So Oh, go for it, Chuck.

Charles Max Wood [00:29:46]:
I was just gonna say, it feels like we're kinda talking about these theoretical properties of effect. Right? It's testable. It's easy to follow along with. You know, it works in these specific ways. Can you give us, like, a concrete example of how effect actually leads us to write testable or maintainable software?

Michael Arnaldi [00:30:07]:
Explicit dependence injection. So you see when, when you have a function or or when you have an effect, which we should say it's it's akin to a smarter promise to some extent, a promise that when you create it, doesn't just start right away, but you have to invoke it to to make it execute the code. And, that smart promise also tracks other 2 things. The errors that the program may arise and the dependencies that the program consumes. So if I have a piece of code that uses a database, I see that the piece of code uses a database, but it gets more specific if I have a piece of code that uses the user repository or the to do repository or, any other service that you might want, I see that explicitly in the code itself, in the type of that of that effect. And I cannot run that effect unless I provide all the requirements. And, that means when you get to test a piece of code, you have your piece of code. To invoke it, you have to provide everything.

Michael Arnaldi [00:31:16]:
If you don't provide everything, it complains that it doesn't compile. It's not complaining in in in the sense that it fails at runtime. It doesn't even compile. So your the LSP gives you instantaneous feedback in saying, hey. This piece of code needs a user repository, but for this test, you're not giving me a user repository. What should I do? So you have to specify user repository, which is the the case where you are in testing, forcing you to do this. It really has complete control over over the execution environment of that specific, of that specific piece of code. But beyond that, you can do observability.

Michael Arnaldi [00:32:00]:
You can do error handling and so on and so forth. You might say, I want this piece of code with a span that is called pool, and, that span will be automatically added. If you have OpenTelemetry configured, it's gonna be exported to OpenTelemetry, and you can see your code from, from OpenTelemetry dashboards such as as as many open source, as many products. I I don't wanna give user hints on on on what to pick, but I've I've loved many of different open telemetry based dashboards. I personally like to use sometimes Honeycomb, sometimes Datadog, and so on and so forth.

Charles Max Wood [00:32:45]:
Mhmm.

Michael Arnaldi [00:32:46]:
But the point is this is this is not only testable. It's also observable and so on and so forth. It's kind of taking all the necessary requirements of of writing a production grade piece of software and putting you on track of saying, okay. You can do all of this. This is pre packed. And in my experience, if if users or rather if developers can do something good and it's easy, they do it. If it's hard, they really need a huge justification to end up doing it. Like, I don't know any developer who does open telemetry in development, preproduction stage that does not use effect.

Michael Arnaldi [00:33:35]:
Most of the people who use effect end up doing open telemetry from day 1.

Dan Shappir [00:33:42]:
The company that I'm actually working at right now called Sisense, We're in the process of of integrating, OpenTelemetry both into our, Java JVM based stuff and into our, node based stuff. And currently, we're not using effect. But I think it's currently mostly like an external type of integration, meaning that it's mostly looking at the environment itself rather than at business logic parts within the code. So, you know, you're monitoring things like CPU usage and, memory consumption and stuff like that, but not necessarily execution of of, let's say, particular, business processes?

Michael Arnaldi [00:34:25]:
Well, monitoring stuff like CPU usage and memory consumption has nothing to do with telemetry. That's metrics. Telemetry is is metering how long a specific invocation takes.

Dan Shappir [00:34:39]:
Yeah. I'm I'm I'm

Michael Arnaldi [00:34:40]:
environment level, which which means, for example, tracing the Lambdas. But you're not instrumenting your code, which means if you have a bottleneck, you have no idea where the bottleneck is still.

Dan Shappir [00:34:53]:
I I totally I totally agree with that. And and by the way, I did instrument stuff using, in the past, yeah, using just, the, Prometheus client for node that would, you know, the it's direct APIs. But but I think the key thing that you said, and we I, hopefully, you know, our listeners noticed it, is that it's not being enforced by runtime errors. It's being enforced by the actual type system. And I think that's, a key point that it's not, that if you, you know, don't properly invoke your code, then you will get the runtime exception. It's that if you don't properly invoke your code, the code will not compile. You'll not be able to deploy it to begin with.

Michael Arnaldi [00:35:52]:
And I think this is an extremely important point because I this 2 school of thoughts when when talking about compilers and and in general, in no specific terms, type checkers. You could use the type checker as a way to check that everything is right or as a friend that tells you what's going on. Different those different school of thoughts end up in in different extremes. The second school of thought, which is more more my school of thought, which is, like, use the compiler as a friend, ends up developing stuff like dependent type dependent type checkers and so on and so forth, which our audience can can check out if they are curious. But in reality, what what it means is not even combining prevents you from running the code. But when you add it in in Versus Code or or in the editor that you prefer, you're gonna see real time feedback of of what you do. The same way that you can if you type a function to take an argument of a number, you can't pass it a string. And it's very helpful not to pass it a string because you know it straight away from from Versus Code directly.

Michael Arnaldi [00:37:16]:
Oh, I'm calling it with the wrong parameter. I'm supposed to use this this other thing. Well, imagine that for errors and dependencies, it really brings tight level safety to the control flow of managing dependencies and errors, which are notoriously very hard things to do. And if we if we, for example, isolate on on errors, there are other languages that have type errors. Java, for example, they have typed exceptions. They haven't been really nice, though. A lot of people complain about that exceptions. I I would say rightfully so.

Michael Arnaldi [00:38:03]:
Why? Because when you think about errors, you're actually thinking about 2 different things. Stuff that can happen but really shouldn't. Like, I'm running out of disk. There's nothing to do if I'm running out of disk. The program should crash. There's no way to recover from from that. This is more akin to an exception. Or, yes, stuff stuff like I'm making an HTTP call, and the service is down.

Michael Arnaldi [00:38:30]:
Is that surprising? No. That's a normal it it is completely expected that services from time to time may be offline for 1 or 2 seconds, but just retry. Or, you know, you have these 2 different types of errors that can occur. Errors that you should deal with those and errors that you really don't care about and that should explode. If you have a single error model and you're pushing the queue at the same level, which is what JavaScript exceptions and Java checked exceptions and so on and so forth do, you're gonna have a nightmare because then you're gonna have your handling logic has to differentiate between between the 2. With effect, we have those as independent things. If if your program explodes, you have an effect. If your program raises an error, you can handle the error very in in a tight manner.

Dan Shappir [00:39:27]:
Yeah. I think it's a really important distinction that you're making. And, again, just maybe to clarify to users or listeners users. It's kind of the yeah. It's kind of the different

Charles Max Wood [00:39:39]:
Welcome to the show, users.

Dan Shappir [00:39:41]:
Yeah. It's kind of the diff exactly. It's kind of the difference, like you said, between, running out of disk space or network problem, which are things that, like you said, can happen and can reasonably happen within the lifetime of an application versus, undefined is not a function, which is something that should not happen. And and, basically, TypeScript was kind of created in order to to prevent from happening at at run time. And and I guess that effect basically takes it to the next level, which is something that you expect from certain programming languages, like, I don't know, like Elm maybe or like Haskell or not necessarily from a language like TypeScript. So the fact that you were able to achieve that sort of safety on top of type script is is quite an achievement.

Michael Arnaldi [00:40:39]:
Honestly, what's surprising to me? Again, III started by developing in Scala by myself. So I was considering TypeScript as, you know, as a lesser of a of a type system. But to be honest, since I started developing of effective, I've realized that TypeScript is an extremely powerful language, and it's extremely well designed. And the hops that they had to go through to type the dynamic part of JavaScript made it such that the type system has some incredible features. Like, we even got to the point where the amount of things we could do in TypeScript was greater than the amount of things that were possible in in in Scala. For example, in Scala, you didn't have union types up until version 3, which did not exist at that point in time. And that means the error of channel had to be an with a single name. But you can't say for example, I have an which is composed of 3 potential branches, error a, error b, or error c, if I if I'm handling error c, that should be removed from the type, and that wasn't possible in Scala.

Michael Arnaldi [00:42:09]:
In TypeScript, we were able to do that from day 1. So, actually, I realized that, no, it is a very powerful type system, and I was completely wrong in thinking that it was, in any way less powerful than than other type systems. If anything, I still have to find another type system that gives me the same level of con confidence. Even even if we go to languages such as Haskell or and so on and so forth, those things have to be implemented on top of the type system. And open unions and open interception and partial erasure of members of open unions and open intersections are not are not present in in in those, in those type systems. So even though the languages are more restrictive, they are not powerful enough to to represent those concepts the way that they are represented in effect in TypeScript. I know this is more theoretical and and tangential.

Dan Shappir [00:43:14]:
Yeah. And and I'll take us to a practical, place in in a in a second. I just want to mention again that I totally agree with you. And in fact, I, recently tweeted that it's pretty amazing how TypeScript have been has been able to effectively implement a static type system on top of the poster chart for dynamic typing and dynamic types. It's like herding cats, and they've literally been successful at it. So it's pretty amazing. But taking us to indeed a more practical level, you kind of described, effects as a framework. Now most JavaScript or TypeScript developers and, again, like you, I won't make the difference.

Dan Shappir [00:43:59]:
I I'll use the terms interchangeably. Most, such developers these days are using some framework. They might be using, like you mentioned, remix and next JS, or they might be using something lower level like, Nest JS, or they might be using a client side framework like, Angular. Where does, effect fit in into this ecosystem? Is it like an alternative to 1 of these? Is it something that you would use in conjunction with 1 of these? How how how does it play into the JavaScript framework ecosystem?

Michael Arnaldi [00:44:40]:
It sort of depends. I've used the term framework. I should have probably used the term composable framework because it's rather a huge toolbox where you can pick and choose what you use. You don't have to use it all. I know I I don't know of any application that needs the the entirety of effect. I know a lot of people that use it in conjunction with those full stack frameworks that you referenced. I know some other people, especially in the back end, who ended up with almost an effect only solution. That means effect to the very main.

Michael Arnaldi [00:45:29]:
Your main function is an effect. To reach that point, at the moment, I believe it's only possible in a in a back end scenario. I wouldn't I would never attempt to do it on a on a front end, albeit there are people developing rendering stacks on top of effect. There's a guy called Tyler Stan Stanberger that's developing a project called type, which uses, tech template leader roles. And it's basically a full rendering stuff based on effect, which is type safe, with does does context propagation in a type safe way. A really interesting project, but it's very often very experimental. I would not I would not use any anything like that for for any production use case at the moment, at least. So I I would say it depends what you do.

Michael Arnaldi [00:46:24]:
If you are in the back end, it is very possible that you might be able to just use effect because we have HTTP servers. We have

Dan Shappir [00:46:35]:
So it's a replacement to for express to an extent?

Michael Arnaldi [00:46:38]:
We have HTTP server. So you could use it as a replacement to express, but a replacement that does even even more. For example, if you are developing an HTTP API, you might wanna generate an open AI open API specification. We do that by default. So if if you write a web server, you mean, using the effect HTTP, you're gonna get for free a test client. You're gonna get for free arbitraries for your testing. You're gonna get for free an open API specification from which you can generate clients. In every language, you you get a real, type safe client that you can use to call your server from TypeScript.

Michael Arnaldi [00:47:25]:
So you get more. And and the performance of it, it's it was an interesting journey because everybody expected the native HTTP server of effect to be slower than the alternatives. We are actually beating express by a lot, and we are closer to Fastify, a little bit slower than Fastify, but not not too far off with a with the feature set of an effect first of an effect native solution. So, again, everything is OpenTelemetry compliant. You have, like, errors across the board, even across the network because we can serialize both responses and, and errors. Just they're just objects, so you can serialize them in the same way. We have our own internal replacement of, ZOD, which is called effects schema, which is bidirectional, can do both encoding and decoding. It is really a solution that, as you said at the very beginning, it's very broad in scope.

Michael Arnaldi [00:48:41]:
And I would almost think of it as an NPM 2.0. You don't know you you don't have to know everything to use it. You can just start with a few modules, but then you have HTTP servers and so on and so forth. The next level thing that we are developing now is clustering. You're gonna be able what you what what you're able to do with, for example, in in the JVM or Erlang, Elixir, and so on and so forth. Clustarize a number of instances in JavaScript and and

AJ O'Neil [00:49:13]:
and

Michael Arnaldi [00:49:14]:
do message passing style between them, which is pretty amazing that you can even get to that point in, in JavaScript. And that's already in in in alpha. In in effect, it's called effect cluster. So it is very broad. It can replace some of the preexisting solutions, and it can compound some some other solutions. For example, III have very I have seen very pleasant code bases that use remix and effect. I've seen some prototypes of effect together with React Server Components, and it also plays pretty well. So both.

Michael Arnaldi [00:49:55]:
What what you said, both compounds and replace.

Dan Shappir [00:49:59]:
So a question about that. As you said, 1 of the primary motivations for ditching the JVM in favor of, node was the fact that you could leverage the knowledge and capabilities of your existing front end developers. They could transition easily from being front end to being full stack and do the BFF stuff. Then my question is, if I take a TypeScript developer that's familiar, let's say, you know, with TypeScript, obviously, but also, let's say, with React or something like that or maybe Svelte. And I bring them on board to a project that uses effect. What's the onboarding, challenge like? I mean, will it when they look at the code, will they recognize that code as being TypeScript, or will it be, you know, too different so that in effect, it's like I might as well have been using the JVM because it's gonna be Greek for Greek to them.

Michael Arnaldi [00:51:14]:
That's a great question. Surprisingly, JavaScript people have a brain which is already wired in thinking in terms of components. I believe that's thanks to the to the developments in React where React is really widely used. Why? Because it simplified UI development and allowed you to think in terms of composable UI components. When you think about effect, you think in terms of composable back end components or or composable business logic components. So the brain doesn't have to do a huge suite a huge switch. And the second element that that makes the adoption path easier, is that JobStreet has a single weight. Like, you mentioned that that before, we were living in in an era where a SyncAway did not exist, promises did not exist for for I I was I was writing callbacks, and and they're not really they're not really nice, and you get this this meme of callback hell or or promise hell and so on and so forth.

Michael Arnaldi [00:52:31]:
AsyncAway makes that easy. Why? It brings back imperativeness to an otherwise declarative model, which is promised dot then or, CPS continuation passing style, which is got renamed to callbacks in in in JavaScript land. But the original name is really continuation passing style because you pass down a way of continuing your your program. A sync await makes that easy. Now you might ask, is a sync await available for effect? I would say no. So why have you even said a sync away in the first place if you can't use a sync away? Well, there's another feature in JavaScript which is lesser known than than a sync await, which are generators. So you can mentally swap a sync with function star and await with yield star, and your whole mental model works. You can use effect in the same way as you use a sync await just by using generators.

Michael Arnaldi [00:53:36]:
So if a if a newcomer reads the port, they're gonna be able to understand it. They might not be able to jump in and ride it, but just as if they are experiencing react, they're probably not be able to adopt Vue in half an hour. Might take them slightly more than half an hour to say, oh, okay. This library works in this specific way and so on and so forth, but they grasp the concept. They can read the library code from from the very beginning. I again, I'm not a front end developer, but I've seen code bases that use React, code bases that use Vue, code bases that use Angular. I can read the code. I can reason about the code without knowing the details of it.

Michael Arnaldi [00:54:19]:
Pretty much the same experience you get, with effect. And then takes, I would say, a few hours to be able to use effect productively and probably a few decades to learn the whole thing. And and you don't have to again, it it's like wanting to learn JavaScript by having to learn every single module in NPM might be might be a bit too much. But the the learning curve is very, very progressive, and it is very linear. The only nonlinear part is the first few hours. The first few hours, you're gonna be in a shock, and you're gonna hate yourself for the decisions you've taken. But then that that stops that stops very quickly. And and the what what I've seen is a is a trend where people that start useEffect, that was a panel on React here.

Michael Arnaldi [00:55:22]:
No. People that started doing the the effect thing, there we go, usually don't come back. I've I've never seen anyone removing the effect from, from the code base. That's a very interesting element because there's a lot of I mean, I've never seen a stable code in general. People swap libraries constantly. They rewrite and so on and so forth. If they started integrating effect, effect is there and most likely took over their whole application, and that person or that team will tell you that they can no longer write plain JavaScript or plain TypeScript without effect. It's the same thing when you learn TypeScript.

Michael Arnaldi [00:56:15]:
You can't anymore write JavaScript. I wrote JavaScript for ages. I would prefer to change job than write JavaScript without TypeScript again. Like, if you wanna tell me you have to pick Mike. If you wanna stay employed, you have to write JavaScript. I will probably become, I I don't know, pizza maker or or a different. Okay? I would not I would not lie to do that.

Dan Shappir [00:56:44]:
Funnily enough, and where I at Sisense, there's this piece of core legacy code that's unfortunately very much still in JavaScript, and, people are wary of touching it.

Michael Arnaldi [00:57:03]:
It scares you to touch it, isn't it? It Yeah. You you can't know if you're changing something. You don't you don't know if you're breaking anything else. TypeScript is a very good step forward in the direction of giving you confidence in maintaining the code base. If that code was effect, you could quite literally refactor 1, 000 and thousands of lines of code and be sure that if it compiles, it works.

Dan Shappir [00:57:34]:
Yeah. 1 of the challenges, though, with TypeScript, and I think both, Theo and the Primagints have spoken about it, is that there are, like, 2 levels of using TypeScript. There's, like, the app developer level, and there's the library level. Like, you can, you don't need to dive too deep into TypeScript and generic types and stuff like that in most cases if you're just working at the application level. But if you really want to make, library code as type safe as as possible, then it it can become a challenge. And III I'm sure that you have spent a lot of hours with the fact thinking about what would be the best type signature for particular APIs. And and so my question in this context is where where does effect fall in that spectrum? Like, is it is how how challenging is the typing when I'm writing code in effect, especially given that it it's kind of like type safety ensure correctness So kind of like you like, as you said, kind of like you would get in languages like Elm.

Michael Arnaldi [00:58:54]:
Well, that is, again, AAA great question and a and a a great point, which is arguable. I think I I agree more with with the sentiment that Matt Pocock has brought out, which is, yes, both the 2 different TypeScript exists, library level and up level. But in up level, you have that that lead directory, where you have the mix and match where you do have to write a little bit of library level code in in the app. Effect, the usage of effect surprisingly requires almost no manual type. Like, when you write a function using a, you don't have to annotate the promise return type manually. The same thing is with effect. With the difference that you're gonna get inference for the errors and inference for the the dependencies.

Dan Shappir [01:00:00]:
Oh, very cool. So, basically, you've done, most of the heavy lifting. And when I use effect, I just get most of the benefits out just by out straightforward inference.

Michael Arnaldi [01:00:12]:
I think I I wrote thousands of lines of effect code in examples and so on and so forth without ever specifying the type manually. Of course, sometimes you might want to specify a type manually, but the point is you don't have to, which is the which is, to me, how it should be. Even with promises, you can annotate a return type. You wanna be sure that this is the actual return type. And sometimes you have to do that for, for performance reasons, like, especially if you have functions that are reused in a lot of places in your code. If you use inference on those functions, then the LSP is gonna have performance issues. But this has nothing to do with the fact this is very, very general TypeScript points. The same applies with the fact.

Michael Arnaldi [01:01:09]:
So sometimes you have to write type or or work. Sometimes you want to write types, but usually you don't. Usually, you don't have to. And to me, this sort of goes back to the point of having the compiler as a friend that tells you what's going on versus the compiler as a, you know, as a math math teacher that grades your your correctness. I I feel more in the in the space of the compiler as a as a friend that helps you discover what your program is doing. When I write a fact code, I then look at the type signature, which is completely inferred, and I realize from that, oh, I this is what I've done. This is the error cases that my program may may issue when when may encounter when when it's executed. And then if I handle 1 of those, the type system will tell me that that error is no longer present, all by inference, not not by me specifying the the types.

Michael Arnaldi [01:02:19]:
So by no means, it's a type heavy element. We have also I've mentioned briefly before schema, effect schema, which is similar approach to Zod, UTS, and so on and so forth. That's really where where a user starts with defining the the types in their system. Those are more domain level types. You're you're modeling your user base. If you are doing a to do MVC, you're gonna have a to do type. Those are the types, the concrete types that that you use. This this will almost never a generic in in those as you pointed out rightfully so.

Michael Arnaldi [01:03:05]:
And a very effect based code base would use schema to define the data model of of their application and would infer the hell out of, everything else, in in my the way I would use it. Of course, there are users who write explicit types for everything. I don't I don't agree with that with that way you I

Dan Shappir [01:03:32]:
dislike it. I've seen the SCLINT configured or TSC SCLINT configured to require that, and I like you. I dislike it. I I prefer as much type inference as possible. I whenever I need to explicitly specify the type of a of a return type of a function, it's all it almost feels like a failure.

Michael Arnaldi [01:03:54]:
Yes. And and we've done a lot of work so that you don't have to.

Charles Max Wood [01:04:00]:
Alright. Well, I'm I'm wondering if there's more to get into before we do picks because we're kind of getting to that amount of time. I I guess my question is, Michael, because you've talked about, moving off the JVM to something like, like effect or the other 1 is just if I started a new project today, what what are the best ways to kinda roll into this and make it work how I want?

Michael Arnaldi [01:04:33]:
Well, we have our website, which is incredibly easy to remember because the website of the fact is called the fact. Website. And we have an amazing Discord community, which is by now more than 3, 000 people. And those are not just numbers. They constantly ride and help each other, and and the teammates also help, newcomers. So definitely join Discord and definitely try out try out the fact. If there is another question that I would like to address

Dan Shappir [01:05:10]:
Mhmm.

Michael Arnaldi [01:05:11]:
It came from, from tweets and other podcasts. And I think we had a small exchange with Dan, at some point in time, and it is about the company behind, Effect. There is a company now which is called Effectful Technologies, and we've raised VC money, last year. And some people were surprised, and they even said that, you know, monetizing something like effect is crazy. I agree. Monetizing something like effect is absolutely crazy. That's not the plan. The plan is to develop services and and bring composability to higher levels of infrastructure where it's not gonna be effect anymore.

Michael Arnaldi [01:06:01]:
They're really gonna be plain and and simple commercial services. Effect is open source. We always remain open source. The Effect organization is not even owned by by the company. It's owned by the contributors. It hasn't shifted in in ownership when we when we funded only. This was a was a question I I intended to, answer on a on a podcast, but I was, like, other people got that question asked. And I was like, maybe I could answer that specific question.

Michael Arnaldi [01:06:40]:
You know, I'm probably the only 1 who knows the the the plan, but really be sure if you use effect. It's an open source library. It's community first, and it has survived 5 years without a company behind and without VC money behind. So even if the company burns, which is highly probable given that VC backed companies are high risk, high reward, most of them fails. So realistically, we will also fail. I hope not, of course, but that's the that's the default outcome effect will stay alive, will be preserved the way it was preserved before without without any any trouble or change of license or or or any, any of the, you know, weirdness of mixing open source with commercial activities. That was 1, 1 other point I wanted to cover.

Charles Max Wood [01:07:38]:
That's that's good to hear. It reminds me a little bit of, like, Next. Js and Vercel. Right? Where You know, it's it's Next. Js completely open source, you know, community run blah blah blah. Yeah. A lot of the people work for Vercel that work on it. But at the end of the day, when you want to deploy your Next JS app, Vercel is your happy place kind of thing.

Charles Max Wood [01:08:00]:
Right? They they specifically go after the things that you're gonna want.

Dan Shappir [01:08:04]:
It seems to have become a fairly popular model of having an open source project and alongside it, a commercial company. So, obviously, Vercel is kind of like the poster child, but also the Astro project is doing something similar. And, even, 1, 000, 000 JS is a new upstart project are, I think, are y combinator funded, and and there are others as well. So it will be interesting to see if this model how successful this model of, an open source project, which is by definition open source and will remain open source regardless of anything else. But that alongside to it, there's a company that's kind of supporting that project and and looking to make revenue in some sort of a way in a adjacent to that project. So it will be interesting to see how successful this model is over time.

Michael Arnaldi [01:09:00]:
I think that discussing that would definitely require probably a different episode or or or or very long conversation, I'm I'm not sure the model is gonna be successful at all. If anything, I I don't believe in that in that model in, in general, you might say. But you've you've done the same. Yes. I I believe Vercel with NestJS is a very peculiar example of a model that can work because Vercel is the best best place to deploy any front end, not only if you use Nest.

Charles Max Wood [01:09:37]:
Right.

Michael Arnaldi [01:09:38]:
That's the that's the key differentiation. And I'm gonna stop here. Otherwise, I'm revealing much of the road where we are pointing, but it's gonna I appreciate Vercel a lot as a as a family, and I I take a lot of inspiration from it.

Dan Shappir [01:09:55]:
So so I just have 1 more quick question. You mentioned, that you have a a website that's, effects dot website. And we mentioned that there was a conference, and you you can find the the talks, I think, on YouTube. Yes. Do you also have a Discord channel where people can ask questions, stuff like that?

Michael Arnaldi [01:10:15]:
We absolutely have a Discord community. It's an amazing place where people help each other. There's there's almost 3, 000 there's actually more than 3, 000 users on it that are constantly writing, themselves, helping themselves, and so on and so forth. All of our development happens on Discord. So that that is the central the the central place where I spent most of my day. So, also, if you wanna chat with me, either Twitter or the new name x. Always feels strange, Codex. Hope Elon is not listening to us.

Michael Arnaldi [01:10:57]:
There's no chance. If he is he's calling Twitter again.

Dan Shappir [01:11:02]:
I I actually hope well, we should all hope that he does because if he tweets it then or access it or whatever it's called these days, post it, then this the podcast and effect will explode.

Charles Max Wood [01:11:16]:
I was gonna say the case. He I'm totally fine with Elon ask actually coming out and going, these guys are idiots. Right? Because we would still get that same effect. So pun not intended. I wasn't thinking about it. Anyway, let's go ahead and do our picks and then start wrapping up. Let's start with AJ. AJ, what are your picks?

AJ O'Neil [01:11:40]:
Well, I became a motorcyclist. I have a motorcycle now. And, I would recommend to anybody the, the MSF basic rider course, if anybody's in the United States, at least, if you're interested in, becoming 1 of, the organ donors, then then, the best way to prevent actually having to to, donate your organs would be to take that course. It already saved my bacon when a semi cut in front of me. And since I'd already low sided the bike during the the practice course and was already familiar with why not to panic by grabbing the front brake. I panicked instead by swerving, straightening the bike, and then applying the brake. And that got me safely onto the shoulder of the road rather than under the semi. So it's good.

Steve Edwards [01:12:41]:
AJ, do you know what the other word for motorcycles is that traffic cops use along the lines of what you were just saying? No. Donor cycle.

AJ O'Neil [01:12:50]:
Donor cycle. Yeah. That yeah. Yeah. So, anyway, it

Steve Edwards [01:12:57]:
what was

AJ O'Neil [01:12:57]:
the what was the other thing I was gonna mention? There's gonna be there was something else, I think, related to that. Give me just a second. My brain's a little slower today because of, the cold. Oh, 1 of the pieces of protection that people often, don't think about or at least it it wasn't my 1 of the things I first thought about. I knew to get the helmet and the pants and the jacket and the gloves, but the hearing protection, there's, there's a brand of hearing protection called Alpine MOTOsafe, and the the biggest problem is not the muffler or the engine noise. The biggest problem is the wind noise. And these ear plugs are designed in such a way that's kind of interesting. They have a little, stem that comes out of them.

AJ O'Neil [01:13:42]:
And much like you've got the little hair in your ear that transmits the sound, the stem actually helps transmit sound that is in the vocal range and, I guess, other ranges that you need to hear. So when you put the earplugs in and someone's speaking to you, it still sounds weird when you're speaking to someone else, but when someone's speaking to you, you can actually hear pretty darn well. And, they're very effective at blocking out the wind noise. So although they have a lower DB rating, like a lot of the the the cheapo foam ones are rated at something like 33 DB, and these are only rated at 20. But part of that, I think, is because of they're not they're very effective at reducing mid wind noise, but they're not effective at reducing all noise because they're designed to actually let some sound pass through. So I think that they are adequate protection. They're very and they're very comfortable to wear. So, anyway, yeah, if you wanna have really, really long discussions with your wife over a period of weeks or months, or possibly even years, get into motorcycling.

AJ O'Neil [01:14:53]:
It's it's a sense of freedom that is amazing. Absolutely amazing. That's that's, that's my picks for the day.

Charles Max Wood [01:15:03]:
Awesome. Dan, what are your picks?

Dan Shappir [01:15:08]:
I I don't have a whole lot in terms of picks, for today. I, you know, I I do have 1. So, obviously, there's the ongoing conflict, in the Middle East, both in in Gaza and between Israel and Lebanon. And I know that it has made a lot of people, like, interested in or have opinions on, like, the origins of this conflict and, you know, who's at fault and how things came to be and stuff like that. I want to, highlight, a documentary that, came out a long time ago, like in the eighties as I recall. It's called the Pillar of Fire. It's an it's an Israeli documentary. So, obviously, it represents the the Israeli view on things, but they they did try very hard to also to be, first of all, fact based and also present a lot of the, Palestinian side or the Arab side as well.

Dan Shappir [01:16:11]:
It's it's, talks about the origins of Zionism going back to the 18 fifties and all the way to the founding of the state of Israel and and and covering all that period in between. We're talking about over a 100 a period of over a 100 years. And, it it like I said, it's from the eighties. So on the 1 hand, it's you you might say that it's a bit dated, but it also means that a lot of people that were involved in that process were still alive back then to be interviewed. And and that documentary includes a lot of such interviews and a lot of the of, amazing original footage that was, shot, like, more or less when they invented the cameras. And, it's it's, it's a great documentary series. You can find episodes of it with in English on YouTube. I'll, I'll link to the some of the episodes that are actually available on YouTube.

Dan Shappir [01:17:16]:
So if this topic is interesting to you, I highly recommend this, this series. And that's my pick for today. By the way, Kent, do you know where the where the phrase pillar of fire comes from?

Steve Edwards [01:17:33]:
Oh, heck. Yeah. I know it.

Dan Shappir [01:17:36]:
Yeah. So you can also so you can also understand why it's been used in this context. Like, yeah.

Charles Max Wood [01:17:45]:
Yep. That's something that I'm interested in, so I'll I'll have to go check those out. Steve, what are your picks?

Steve Edwards [01:17:53]:
Before my preplanned 1, I have a couple picks that came up, inspired by our initial conversations here. 1 comes from 1 of my favorite sources of of puns and jokes. It's called the pun bible. It's pretty short. It says it's a conversation between a student and teacher, and it says, student, 32 degrees Fahrenheit is equal to 0 degrees Celsius. Right? Teacher says yes. In other words so I said, so in other words, 0 degrees Celsius plus 0 degrees Celsius equals 64 degrees Fahrenheit. Thank you.

Steve Edwards [01:18:31]:
Now in honor of AJ and the absolute torture that he's been going through with his cold over the past week, 1 of my favorite sources of humor is the Babylon Bee. They're so good.

Charles Max Wood [01:18:44]:
So good.

Steve Edwards [01:18:45]:
Oh, I love the bee. And, anyway, 1 series of posts that they're always doing over the years about how men will suffer from a cold and and, as compared to to the women. And, this particular post that I looked up was from, last year, and it says it's titled, this is the worst pain any human has ever felt, man with flu tells wife who has pushed 3 children out of body. And, so it starts out I'll give you the first couple paragraphs. Local man, AJ O'Neil, became bedridden bedridden Tuesday after a flu virus brutally assaulted his body with a sore throat, coughing, some body aches, and even a mild fever. This is the worst pain any human has ever felt, he told his wife, Sally, who previously pushed 3 whole children out of her body. The comment reportedly led to a brief spat in which the suffering man edged precariously towards death door. Anyway, it goes on from there.

Steve Edwards [01:19:36]:
So, I'll put the link in in the notes, hopefully, but it's, it's classic Babylon Bee.

AJ O'Neil [01:19:43]:
It's it's kind of is not Sally, by the way.

Dan Shappir [01:19:45]:
By the way, it kind of reminds you of this thing that says that if if you are a man and you want to experience, you know, like, how childbirth feels like, then what you should do is, first of all, grab the your lower lip

Steve Edwards [01:19:58]:
Yes. Careful.

Dan Shappir [01:19:58]:
And then and then pull it over your head.

Steve Edwards [01:20:01]:
Yes. Back before Bill Cosby went nuts, he has a classic routine called himself. That was an HBO special from 85, and there's a section in there where he's talking about his wife giving birth to childbirth. Hysterical. And he, in that sketch, he brings up that quote. And then when he's talking about his wife giving birth, he's talks about how she stood up in the stirrups and grabbed his lower lip and started to pull it up up over his head. So that's a that's a great 1. Yeah.

Steve Edwards [01:20:31]:
Finally, the, the dad jokes of the week. So 1 day, I went I changed the light bulb. I crossed the road, and I walked into a bar. And that's when I realized my whole life was a

Charles Max Wood [01:20:44]:
joke. Yeah.

Steve Edwards [01:20:48]:
Question. What dating app do cannibals use? It's called Tender. Right? So the other day, speaking of biblical references, I found $30 in the parking lot, and I thought to myself, what would Jesus do? So I turned it into wine.

Dan Shappir [01:21:08]:
That's a good 1.

Steve Edwards [01:21:10]:
Those are my picks for the week.

Charles Max Wood [01:21:13]:
Alright. I'll jump in with a few picks. I usually do a board game or a card game. To be honest, I've kind of been heads down on a bunch of other stuff. So let me just think for a second on which 1 I wanna pick. I'm gonna go a little bit different direction. So my 18 year old really likes retro games, video games, especially video game consoles. So he actually walked, like, 6 or 7 miles down to the retro game store in American Fork and bought himself a Wii.

Charles Max Wood [01:21:51]:
And so we've been playing Wii Sports around here lately. And

Steve Edwards [01:21:55]:
Yes. Wii Sports Resort. We well, Wii Sports is sort of boring. Wii Sports Resort is a little better.

Charles Max Wood [01:22:00]:
I don't think I've done the Wii Sports Resort, but I will tell you that it's been fun, you know, doing the bowling and baseball and, anyway, so I'm gonna pick that. I'm gonna pick a video game instead of a board game today. Few other things that I'm gonna throw out. So, 1 of them is and this is going way off the tech train or toys train. But, about a year or so ago, I started no. It's been more than that. It's been a few years. I started having issues where if I would eat wheat products of any kind, I'd get sick.

Charles Max Wood [01:22:35]:
And so I was talking to my new stepdad. My mom got remarried a couple months ago, and he was like, well, have you tried? He he told me to try 2 different things. I haven't tried 1 of them. I haven't tried ancient grains, but I he's like, have you tried sourdough? And I was like, no. And so, I kept meaning to try it, but I didn't know anything about it. And then I was chatting with a friend of mine, and she brought up that she bakes a loaf of bread every few days, and it's sourdough. She has a sourdough starter that lives in her fridge. And so she gave me some of that, and I've been doing sourdough ever since.

Charles Max Wood [01:23:10]:
And I'll tell you what, it it's made a huge difference because I used to have just kind of lingering stomach pain over days, just because I would get whatever wheat product, you know, and, anyway, since I started eating the sourdough about a month ago, that pain's gone away, and I haven't had any issues. And it's also nice because I have real bread to make, like, sandwiches and stuff with. So I'm going to pick sourdough. Now a couple of things I'm gonna put out there, So we already had a KitchenAid mixer, and there's a there's a website this lady does. She she talks all about sourdough. So I'll put links to her Instagram because she's got a series of Instagram stories that you can watch to kinda walk you through the whole process, and she's also got a website where, she makes that work. And I've got Apple assistant on my computer trying to pick up on what I'm saying with this or something. Anyway, so so yeah.

Charles Max Wood [01:24:18]:
So I'm gonna shout that out. 1 of the things that you need is also a it it's a Dutch oven, and I I don't know if outside the US really have weapons. It's a cast iron pot. And the ones that you want put up in your oven are they're enameled. Right? So they've they've got the polish on them. Right? They don't look like cast iron pots. You pick them up, they feel like cast iron pots. But, anyway, so I've been like I said, I've been baking my own bread for the last month, and it's amazing.

Charles Max Wood [01:24:53]:
So I'm trying to find the website where all this stuff is at. Oh, here we go. And and she's been super helpful too as far as, like, just figuring out, oh, okay. This didn't turn out the way I wanted. So, anyway, I'll put these links in here, but it's it's such good bread. And even when it doesn't come out looking just like this lady's bread, it was still, so good anyway. So, I'm dropping it in the comments. It's kind of a long Instagram deal, but that's her stories on on how to make the sourdough.

Charles Max Wood [01:25:44]:
And then, I'll I'll put this at simplesourdoughbread.com, and that's where I get the other stuff. So yeah. So I'm I'm picking bread and stuff like that. And then, 1 last thing that I'm gonna pick in this is just, I I'm just getting into this. Now most of this is focused on Ruby on Rails, which is what I spend most of my time writing code in. There's a book called the the rails and stimulus codex, And it basically walks you through writing an application in Ruby on rails with the stimulus front end and with turbo native so that you can get, quasi hybrid native apps out of your Ruby on Rails applications. And you can do it for other other applications too. Right? Because it basically just wraps around a web application, and then, it uses Strata to give you, which is the Italian word for road.

Charles Max Wood [01:26:39]:
But it it gives you that pathway to get native elements into your, turbo native app. And then turbo native just gives you the wrapper around your web application so you can have the mobile app. And yeah. So so far, I've I've got the turbo native stuff. I'm just getting into Strata now, and then we'll be getting into the rest of the stuff with the stimulus and turbo. Turbo is kinda like HTMX. But, anyway, I'm I'm really, really digging it. So, I'm gonna pick the rails and stimulus rails and hot wire codex, by Ayush Nwatiya and, Germanative.

Dan Shappir [01:27:22]:
You should probably come on this podcast called JavaScript Jabber to talk about this stuff.

Charles Max Wood [01:27:28]:
Yeah. I should. I should. Maybe I'll get Ayush to come on. He's 1 of our new panelists on Ruby Ruby Rogue. But yeah. And he's a former, native developer in Swift and Kotlin. So, anyway, that that's what I've been playing with lately.

Charles Max Wood [01:27:46]:
Michael, what are your picks?

Michael Arnaldi [01:27:50]:
Oh, so I have I I I'm mixed, but, I have to double down what AJ said at the beginning. I am a biker and definitely do safety driving courses because your instincts playing in a in a weird way when you when you get scared, and you gotta train them very well. I was lucky enough to get my first bike when I was 6 years old. So I kind of have second second nature instincts by now, but it's definitely not not normal. And especially if you if you get into biking at the at the leader age, do a safety course. Actions and everything else, what what AJ said, it's it's good. I didn't know about the your thing. I'll I'll try it out.

Michael Arnaldi [01:28:42]:
Please send me a a link. Maybe maybe offline. I'm curious. And so I have double down what AJ said. And in a in a relatively similar fashion, but a different completely different thing, I recently got into go karting. Fun. Do do do start to go karting. I I purchased the AZ card, which is a shifter card with 6 gears, and it it's killing me.

Michael Arnaldi [01:29:13]:
III go there on on the weekend. I I feel like I'm the best driver in the world and, of course, the slowest on the track. And Monday Monday, like today, I'm I'm I'm in pain in my whole body, due to the physical exercise. But it's a very good way to get out of your comfort zone, out out in the open, and and have fun. So So my take is go karting.

AJ O'Neil [01:29:39]:
How how fast do these go karts go?

Michael Arnaldi [01:29:43]:
Well, that depends. Do you wanna know in American terms or European terms? I can't tell you in European terms. Mhmm. Last time, I I clocked, like, a 137 kilometers per hour on the track.

AJ O'Neil [01:29:57]:
Yeah. See, in America, go kart means a children's toy or perhaps family recreational It's

Steve Edwards [01:30:06]:
not not That's kinda actually true.

Charles Max Wood [01:30:08]:
I was gonna say.

Steve Edwards [01:30:10]:
I go karting at a place out here on the west side of of Portland, and, you know, the karts that you can just go rent and drive around their track or, you know, get up to, like, 60 miles an hour. And there's some there's some serious kart. There's races or people with their own karts, you know, and and they I've I've they can go really fast.

AJ O'Neil [01:30:27]:
I have never heard of a go kart that goes more than, like, 20 miles an hour.

Steve Edwards [01:30:31]:
Oh, no. The karting

Charles Max Wood [01:30:32]:
Oh, I've I have some neighbors that have some that, oh, yeah, they they whip around the neighborhood faster than the cars go. Yeah.

Steve Edwards [01:30:38]:
These are on the way. Crack. This isn't just around the neighborhood.

Charles Max Wood [01:30:41]:
Yeah. A 137 mile or kilometers per hour is about 85 miles per hour. So that that sucker is moving.

Steve Edwards [01:30:47]:
Yeah. That's another pretty good speed.

Michael Arnaldi [01:30:49]:
It is moving. It has 6 gears. So, like, it's it's serious horsepower.

Charles Max Wood [01:30:55]:
Yeah. That's fast enough to take on the freeway here in the US Yeah. And and get a speeding ticket. Yeah.

Michael Arnaldi [01:31:01]:
Yes. You can get speeding tickets.

AJ O'Neil [01:31:02]:
Not in Utah, but in other places.

Michael Arnaldi [01:31:04]:
And and by the way,

Charles Max Wood [01:31:05]:
the freeway here is 70 miles an hour. 75 miles an hour.

Michael Arnaldi [01:31:09]:
That's with,

Charles Max Wood [01:31:10]:
You get out of town,

Michael Arnaldi [01:31:12]:
Yeah. Because the track is is not long. If you Right. Put long long shifts, it goes up to 200 easily. It's the closest thing to a Formula 1 you can drive. Wow. If you search on

Dan Shappir [01:31:26]:
Badger or Tesla.

AJ O'Neil [01:31:29]:
I can't wait to tell my wife she's gonna be so excited to hear about this.

Charles Max Wood [01:31:35]:
Yeah. Typically, the

Michael Arnaldi [01:31:36]:
the tax because it costs a lot of money overall, but it's very fine.

Charles Max Wood [01:31:42]:
Yeah. The the go karts that I've seen here, they're typically not road legal. I mean, if you're if you're in your neighborhood or, you know, you're not on the main road. Right? I don't go out to the highway or whatever. Nobody cares. But yeah. I've seen some pretty serious stuff. And then you get, yeah, you get the off road vehicles net that, you know, you go down to there's, there's some sand dunes south of the lake here that people go out and do that.

Charles Max Wood [01:32:11]:
Or we also don't live terribly far from this, Bonneville Salt Salt Flats where you could probably go do some people

Steve Edwards [01:32:17]:
really fast there.

Dan Shappir [01:32:18]:
Yeah. Just don't forget just don't forget to wear a helmet. Yeah.

Michael Arnaldi [01:32:21]:
Right. Don't forget to wear a helmet. That's the only thing you wear on a go kart. You don't have safety, anything else. You just have a helmet, and that's pretty much it.

AJ O'Neil [01:32:31]:
Yeah. And it's got roll bars. Right? Is you'd so you'd, like, you just strap in and the roll bars are your safety net?

Michael Arnaldi [01:32:38]:
Well, you don't have roll bars. Yeah.

Steve Edwards [01:32:42]:
So you're

Michael Arnaldi [01:32:42]:
just open. If you cross

AJ O'Neil [01:32:44]:
don't wreck it. You just don't wreck it. That's your saying.

Michael Arnaldi [01:32:46]:
Just don't crash.

Charles Max Wood [01:32:47]:
Yeah. Okay. Right.

Michael Arnaldi [01:32:48]:
When I when I first asked about how to drive a go kart proficiency on a on a track, the track manager who used to be, number 4 in the world championship in the maximum category of karting looked at me and was like, Mike, the green, just don't go there. The wheat. Yeah. Just stay on track. That was Yeah. That was his advice.

Charles Max Wood [01:33:15]:
Don't go in the grass.

Michael Arnaldi [01:33:16]:
That don't go in the grass. Yes.

Dan Shappir [01:33:18]:
Mhmm.

Michael Arnaldi [01:33:19]:
That's the that's the advice on how to drive a go kart.

Charles Max Wood [01:33:24]:
I really wanna go now. Yeah. Yeah. Go karting in Sienna. That I'm I'm so in. Alright. Well, let's go ahead and wrap this up. Thanks for coming, Michael.

Charles Max Wood [01:33:38]:
If if people wanna connect with you online, we've already said effect dot website, but I'm guessing you're on Twitter and things like that. Where where do people find you?

Michael Arnaldi [01:33:47]:
Twitter or Discord? Discord is better. I usually spend more time on Discord than Twitter because then I start reading tweets. I get angry. I close down my laptop and so on and so forth, and the whole cycle restarts. But I'm more on on, on Discord, but also Twitter is is very fine. The only trouble, I guess, with contacting me on Twitter is recently, I've got, like, people seems like they can't send me or or when they send me a DM, it gets hidden, so I might not I might not reply. I have no idea why. Again, Elon Musk, if he's listening to this, should probably fix that.

Charles Max Wood [01:34:27]:
Mhmm.

Michael Arnaldi [01:34:27]:
But Discord doesn't have that problem.

Charles Max Wood [01:34:29]:
So Yeah. I have open DMs, and if I haven't approved you or I'm not following you, then they won't show up. And so then, yeah, periodically, it's like, oh, you message me a month or 2 or 3 months ago. Yeah.

Michael Arnaldi [01:34:43]:
Anyway 2 months ago. Sorry. Yeah.

Steve Edwards [01:34:46]:
What what's your Twitter handle?

Michael Arnaldi [01:34:47]:
Michael O'Nogu.

Charles Max Wood [01:34:49]:
Oh, easy easy to remember.

Steve Edwards [01:34:52]:
Alright. Well, we'll go ahead and wrap it up. Till next time, folks. Max out.