Hey, folks, welcome back to another episode of JavaScript Jabber. This week, on our panel, we have Aj O'Neill yo, yo yo, coming at you live from death by common cold. Oh my. We also have Dan Shapier. It's been like ninety degrees here, aj Yeah, I had two sets of family come in to town. I caught something somehow. It put me on bed rest for three days. Well, it's definitely over and it's definitely over ninety degrees here in Israel, in Tel Aviv, and it's
also kind of humid. So yeah, me from here. Awesome. We also have Steve Edwards yo, coming at you from as always cloudy Portland. Look, I'm wishing for some heat, dance and some heat my way. Please. We sent a basketball player your way, oh, in the draft, well not exactly. He was traded to Portland right before the draft. He was playing in Washington before. And Danny amdeeyes, an Israeli basketball player. Oh cool, yeah, I mean boy, the international players are rule
in the draft anymore. Yeah, France dominated, Oh yeah draft, yeah for sure. Yeah, I watched sports ball. The Euros are still going on anyway. I'm Charles Maxwood from Top End Devs and yeah, I've had family come into town. It's been ninety degrees here. I'm not sick. I just have seasonal allergies. Different story. Anyway. We have a special guest and that is Michael Arnaldi. And yeah, do you want to introduce yourself. Let us know what effect you're having on the JavaScript community. That
was really Steve. Yes, we're starting on dead jokes and yeah, very funny topic. Hold on, hold on, here we go. Sorry, I was doing something else. That's too late. I'm promitedly. I'm currently sitting in Siena. I have no idea how much it is in Feirenheit, but it's definitely hot. And what is it peaning? Well, Celsius, Celsius, Yes, you know, we're European. We work on normal measurements.
No, 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. Yeah. Primagen was mentioning this because you can say something like, oh, it's in the seventies today, and that kind of gives you a you know that gives you a brain a broad range, like how seventies, low
seventies, where's celsius? It's like it's twenty three, or it's twenty four, or it's twenty five or whatever it is, But like the range is the number. Yeah, it's kind of like you know the grades you get in school, where you know you're graded from zero, and maybe you're graded from zero to one hundred, but literally everything below fifty is basically essentially fail in the same so it's you're really graded from something like sixty to ninety.
Yeah. Well when I lived in Italy, yeah, I mean there's a huge difference between thirty and forty. There's much less difference between seventy and eighty. Yeah. Sure in fahrenheit. So so it's sort of like the Richter scale where you go up it's a magnitude of ten every time a number goes up. Oh, we should do that. It works. No, Celsius is linear, it's just that it goes from water freezing to water boiling. So yeah, so anything about fifty, about sixty as you're dead yeah yeah,
and in very hot summer it goes to like forty five sometimes. Oh yeah, you are basically a non human at that point. Yeah, when I lived in on Kona for basically the entire month of August, it was one hundred and three, it was like one hundred and three. Here it was it was forty two, and it was a hundred percent 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 just put it that way. So, yeah, my daughter's been in Thailand for the last year as a teacher, and before she came home, we you know, I look at the weather and it was like, you know, about one hundred with ninety percent humidity or something like that. She sort of got used to it. So it's you know, she comes back here like, oh man, this is nothing. I want my heat back. I'm like, well, I don't know about that much, but I look at I look at
the temperature, so it's only seventy five in Chang Mai. And then my wife would say, but that's at night, right, Oh yeah, yeah. Well, before we get to into typescript and whatnot, I'll just mention that my daughter is currently in Sri Lanka, so yeah, yeah, oh fine, Yeah, so normalizing cold places currently, no, go do it 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. That website is the web page you're looking for, so you can get into Okay, what is this and what does it do? But uh, we're on a podcast and we're going to assume that you haven't done that. So Michael, what is it and what does it do? Well, 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 great code. It really came to exist out of out of needs on a company I was working with when we migrated a lot of system from the JVM JavaScript in the back end. Because you know, we were crazy people around about five or six years ago. Why would you why would you ever use a typescript on a serious on a serious back end project. Well, it ended up costing way less than the
JVM, and productivity was kih rocketing. The only issue is there was nothing to write really production grade code. I have to interrupt you here because the previous company that I worked at, which is Next Insurance, I left them about one and a half ago. Uh. 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 eate if it's a mobile device. But the back end was all JVM.
It was implemented in Courtlin and it was all JVM. And you know when I jokingly mentioned the possibility of implementing that stuff that business project in uh in JavaScript, I was met with hysterical laughter. Well you see I was CEO, so the hysterical laughter 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's really hard to use it when you care about the software you write, and I mean writing testable software, writing software debt can be monitored well, stuff like observability and so on and so forth.
It's a recent brand, but even six years ago 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 open telemetry as a as a larger effort, and we had promite us for metrics we had well we had to do
that stuff. So our code was basically a hell of fright catches. Try open span, catch closed span if there is an error. Finally, you're talking about the typescript code, right, You're not. I'm talking about the typescript code. Can I Before we dive into typescript and obviously affect, 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 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 a closing keynote something like that about how Effect came to be high. 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 JavaScript or typescript, you're basically talking about Note, maybe band maybe Dino, but
you know, essentially it's more or less more the same. You know, one of the reasons that I mentioned, like about the circa laugh is not necessarily about the programming language itself. I guess that comes to play into it as well, But it's also about like whether or 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? Well, for so, 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, I know a lot of back and developers who six seven years ago they would never think of writing back in dye script with no JS. At that point in time, there was no other choice. There was only no JS. Only more recently came to exist other run times such as Bando and so on and so forth.
So at that point in time, it was really targeting purely no JS. And the usual complaints are like, that's not multi Threddit, But on the other side, you actually need multi threading. Uh, probably not. And and there has been a more recent wave of I don't know how to explained,
but people, that's saving us a goal. Pull me I was crazy, Now tell me I'm right in hammurgers, I could make out of the sacred cows you guys have been slaughtering to be To be fair, with regard to multi threading, 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 multi threading kind of goes out the window in a lot
of ways. So the event loop mechanism that you know jobscript uses is very, very effect active for this type of thing. And people forget that note was created with JavaScript initially because Ryan Dahl was looking for something like an event loop and this whole mechanism, especially now with the sink a weight, it becomes much easier. But my point is actually something else. It's more about the robustness of the platform itself. Like you know how the garbage collector for
example, or the networking stack. I mean, 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. 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 A b M itself. There's more enterprise
y implementations, there's more open source implementations. The two things changed quite drastically, at least at least in my in my experience when when working with the JBM, I think overall no JS and specific can be trusted a lot. I'm not too familiar with the other newer run times. I've tribe them, but I have never deployed services that were serving millions and millions of customers based on one Ortino, so I wouldn't be able to say with the same level
of confidence that they can be trusted. I'm sure they can, given that they are. They are based on very similar jawstript run times. But the advantage of JavaScript, and it might sound ridiculous, but it is a highly specified language that almost from their one had very different browsers implementing it, and
it has survived in browsers for a long time. And UI development is I disregarded UI development for years, but I think to realize that it is actually very complex and very performance intensive, because you know, in a javastript, eventually in the browser you've got only one thread, so if you block that thread, the interface stopped. But there are interfaces that have to do a
lot of things. I was developing trading dashboards in JavaScript. There's a lot going on in the UI of a trading dostboard that requires careful management of memory and so on and so forth, and Childscript was always very fine. And when developing back ends, to be honest, they never had an issue with the garbage collector. You may have some that's totally that's totally normal, but also it's it's always a trade of on how much memory you are located 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. So it goes back to your argument of parallelism. If you parallyze at the schedular level with multiple containers and so on and so forth, that'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 see few 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 are like ninety plus percent of what we are all developing, take the data from one database, push it in another API, you call calf to stream out the events,
and you know whatnot. It's basically taking data from place A to place B. JavaScript piece is always very effective in doing that type the type of job. One thing that I want to point out though, is JavaScript is multi threaded, or at least the implementations that we have are multi threaded. So it's not like the old Python or the old Ruby. I believe that there may be some implementations of Python and Ruby that that do take advantage of
multi threadedness, like what Ryan Dahl was working on in Ruby. Before he was working a note, there was a I forget what it was called. I think it's called a vet machine especially, but you know, it actually is multi threaded, and there is a performance difference whether you run on single
core or you run on two cores. You will get better performance running on two cores, because 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 one 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, that the most famous clip that we got from the show was me saying something not quite right in the right context about this exact scenario. So I'll try to say and the primogen picking then best basically picking up on that, I would slightly modify the statement as saying that JavaScript itself is single threaded. The JavaScript engine that runs JavaScript is not a single threaded and is able to leverage multiple cores for greater efficiency. For example,
you know we talked about garbage collection. It can it actually for example V eight 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 Before we move on back to effect, which is why we're all here, I would like to say that I totally agree with what you said, Michael, and I would also slightly add that also everything that's been happening with you know, on on you know in in cloud environments like k W s LAMBDAS and edge computing has also greatly
contributed to JavaScript as a middleware slash server side programming language and platform. I mean, JOSKIP has been almost from from D one content center in in what we call BFFs beaconds for front and so basically the first back and aggregating multiple different APIs that thing was always jaskop was always very natural for that thing, to the point where now with full stop frameworks we sort of get that embedded
in the normal architecture because if you develop enop with I don't know XJS remix or so on and so forth, And I'm not a front end developer, so apologies if I haven't named other very well designed frameworks, I just luck knowledge in that specific area. But I have investigated a lot both next ys and bmix and the fact that you have these sort of server actions or server functions however you want to call them, call them, it is the classical
middleware in between your databases. Your other APIs and so on and so forth that plut that together exactly for the purpose of serving serving the front end. This is an io bound job to do, 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 and back, and
so it's moving progressively taking slices and slices of the stack. I would also slightly correct what was said before about multi threading in JavaScript, just just for the point of obsessive correctness. It is multi threaded as an interpretation of the language, but the language itself is not multi threaded, so there's no observability of different threads in JavaScript. It's the engine that may or may not the
site to allocate stuff on thread pulls. Usually for example five system operations and so on and so forth. They were backed by thread pulls up until recently, where the kernels support a synchronous processing of files. So the access to the flight system is now no longer using thread pulls. It's just using straight up a non blocking, a non blocking interface, and that is completely right V eight. But also I think also spider Monkey, but I might be
wrong in the internal details. Sometimes garbage collection is notoriously one thing that is uploaded a lot of other threats. So by no means it's backed by a single thread, but you can only observe a single threat from the language, which makes all sense. 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, because 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 NOTE 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 magic happening? Because first of all, another big part of the reasons why we moved no js was not only the architecture of note that actually made sense 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 and developers trained in Typescript, we didn't
have a lot of JVM developers. We had been using both Skala and cootling, Coughtlin's a bit easier to get for example, for Java people, Scala might be a bit more tedious, but still for a small team, having to hire into two completely different landscapes is hard, not only for the language but also for the runtime, you know, optimized writing code in a way that is optimized in the JVM. It's hard. It's a hard topic.
It's a very valuable topic that many do very well. But if you have five developers in totally, it's going to be very hard that you have all the skills across the word required to write very productive software from back to front and the so on and so forth. So the decision was on two different two different main reasons. One reason was the JAM 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 style and not have them in silos. So both of those reasons where were present in the decision of moving over. We moved over progressively and we started to write plain and normal type script. But as I was describing, we were reaching a point where the code was no longer maintainable and we didn't have any tools such as for example, in Java, you have runtime reflection. In Rust and similar languages. You have macros.
You can, for example, say I want all my functions to be unnotated with spans. There's nothing similar that you can do in JavaScript or pipescript. I used the two interchangeably. At this point in time, doing all that work manually meant that our code was really not maintainable and let alone testability. Testability was a horror story. So that motivated what then became effect 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 Skull and Zeo and and and started taking some of the ideas into typescript land. So looking again, 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 the things that you did. Weren't things that I kind of know v test or even then you know that testing library, Well that maybe didn't exist at the time, but you certainly had things like like mocau or Jasmine or jest or stuff like that. Weren't they enough in terms of testability? Well, the issue is when you want to 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 there's there's actually no guarantee that that you mock up the module at the right point in time for your application to load the module, and so on and so forth and point Q. There's no explicitness in the dependency rap. 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 the 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. It is possible. 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 those problems that I've described don't 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 that point in time exactly much and chin if I if I recall correctly that we still ended up using later, it's just the the monkey patching element that that isn't that isn't great. And if you have explain dependencies an explicit dependence injection, you can say in a very simple way, well, I have this piece of code, just provide to it a
test dependence instead of a real dependency. 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 doing higher order dependence injection and so on and so forth 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 very diligent and precise way, but it's it's very hard and you're naturally screw up over over time. Effect sort of forces you into into that golden path 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. So the point, per se is not it's not really about testing, it's it's rather about having it testable, which is which is more of an architectural point of view instead of the the practice of writing the tests. Per see. So I'll go for a chuck. I was just gonna say, it feels like we're kind of 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 can you give us like a concrete example of how effect actually leads us to right testable or maintainable software. Well, it does explicit dependence injection. So you see when you have a function or when you have an effect, which we should say it's a key to a smarket promise to some extent, a promise that when you create it doesn't just start right away, but you have to invoke it to make it execute the code.
And that smart promise also attracts other two 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 god, you have your piece of code to invoke it, you have to provide everything. If you don't provide everything, it complains that it doesn't compile. It's not complaining in the sense that it fails at run time. It doesn't even compile. So the LSP gives you instantaneous feedback and 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 case where you are in testing forcing you to do this. It really has complete control over the execution environment of that specific of that specific piece of code. But beyond that you can do observability, you can do it or handling and so on. And so for you might say I want this piece of code with a spam that is called pool, and that span will be automatically added.
If you have open telemetry configured, it's going to be exported to open telemetry and you can see your code from open telemetry dashboards such as A's many open sources many products. I don't want to give user hints on what to be, but I've loved many of different open telemetry based dashboards I personally like to use sometimes Honeycomb, sometimes Data Dog, and so on and so forth. 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 writing the production great piece of software and putting you on track of saying, okay, you can do all of this. This is prefect. And in my experience, if if users or 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 pre production stage that does not use EFFECT.
Most of the people who use Effect end up doing open telemetry from day want. In the company that I'm actually working at right now called size Sense, we're in the process of integrating open telemetry 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 business logic parts within the code.
So you know, you're monitoring things like CPU usage and memory consumption and stuff like that, and not necessarily execution of let's say particular business processes. Well, monitoring stuff like CPU usage and memory consumption has nothing to do with geometry. That's metrics. Telety is metering how long the specific invocation takes. Yeah, with that environment level, which means for example, tracing the lumbus. But you're not instrumenting your code, which means if you have a button neck,
you have no idea where the bottleneck is. Still I totally I totally agree with that. And by the way, I did instrument stuff using in the past, using just the Prometheus client for node that with you know its direct APIs. 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 a runtime exception. It's that if you don't properly invoke your code, the code will not compile, you will not be able to deploy it to begin with. And I think this is an extremely important point because I this school of thought, when when talking about compilers 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 different extremes. The second school of thought, which is more more mindful of thought, which is like use the compiler as a friend, ends up developing stuff like dependent type, dependent type type checkers and so on and so forth, which our audience can can check out if they are curious. But in reality, what it means is not even confiding
prevents you from running the code. But when you edit in vs code or in the editor that you prefer, you're going to see real time back 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's straight away from es code directly. Oh I'm calling it with the wrong pharmeter.
I'm supposed to use this other thing. Well, imagine that for errors and dependencies, and it really brings type level safety to the contract flow of managing dependencies and errors, which are notoriously very hard things to do. And if we, for example, isolate 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 type exceptance.
I would say right to be so why because when you think about errors, you're actually thinking about two different things, stuff that can happen but really shouldn't. Like I'm running out of DISC, there's nothing to do. If I'm running out of DISC, the program should crash. There's no way to recover from death. This is more a kin to an acceptance or get stuff like I'm making an HTTP cale and the services down. Is that surprising? No,
that's a normal. It is completely expected that services from time to time may be offline for one or two seconds, just retry or you know, you have these two 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 that you at the same level, which is what JavaScript exceptions and Java checked exceptions and so on and so forth do, you're going to have a nightmare because then you're going to have You're handling logic has to differentiate between between the two with effect, we have those as independent things. If if your program explodes, you have a defect. If your program raises an error, you can handle the
error very in a type manner. 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 difference the
show users. Yeah, it's kind of the difference 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 the function, which is something that should not happen. Uh and And basically Typescript was
kind of created in order to prevent from happening at run time. Uh 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 a Haskell, or not necessarily from a language like typescript. So the fact that you were able to achieve that sort of safety on type of typescript is quite an achievement, honestly, was surprising to me.
Again, they started by developing in Scala by myself, so I was considering Typescript as a you know, as a lesser of a type system. But to be honest, since I've started developing of effects, I've realized that
typescript is an extremely powerful language, and it's extremely well designed. And the hopes that they had to go through to type the dynamic part of JavaScript made it such that the type system has some incredible fichues, 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 Scala. For example, in Scala, you didn't have union types up until version three, which did not exist at that point in time, And that means the error channels had to be an enom with a single name. But you can't say, for example, I have an enom which is composed of three potential branches or a er or BO or see if I'm handling it or see, that should be removed from the type and that wasn't possible in scalap In types. We were able
to do that from day one. 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 other type systems. If anything, I still have to find another type system that gives me the same level of
confidence. Even if we go to languages such as hospital and so on and so forth, those things have to be implemented on top of the type system, and open unions and open intersection and partial erasure of members of open unions and open intersections are not are not present in those in those type systems. So even though the languages are more restrictive, they are not powerful enough to represent those concepts the way that they are represented in effecting typescript. I know
this is more theoretical and gential. Yeah, and it'll take us to a practical place 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 has been able to effectively implement a static type system on top of the poster child 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 use the terms interchangeably. Most such developers these days are using some framework. They might be using like you mentioned Remix and xt JS, or they might be using something lower level like a s JS,
or they might be using a client site framework like Angular. Where does affect fit into this ecosystem? Is it like an alternative to one of these? Is it something that you would use in conjunction with one of these? How does it play into the JavaScript framework ecosystem? It sort of depends. I've used the term framework, I should it probably use the term composer framework because it's rather a huge tool box where you can you can choose what you use.
You don't have to use it all. 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, your main function is an effect. To reach that point at the moment, I believe it's only possible in a back end scenario. I wouldn't. I would never
attempt to do it on a front end. I'll buy there are people developing rendering stacks on top of Effect. There's a guy called Tyler Stemberger that's developing a project called type which uses techt andlay leader roles, and it's basically a full rendering staff based on Effect, which is type safe with that context proparation in a type safe way. It's a really interesting project, but it's very
often and very experimental. I would not I would not use any anything like that for any production use case at the moment, at least, so I would say it depends what you do. 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 huh, so it's a replacement too for Express. So the next time we have HTTP servers, so you could use it as a replacement to Express, but a replacement that does even even more.
For example, if you're developing an h T t P a p I, you might want to generate an open AI open ah I specification. We do that by default. So if you write a web server in using effected CDP, 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, and open API specification from which you can generate clients in every language. You get a real type safe client that you can use to call your server from type script.
So you get more 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 falstified, but not not too far off with a with the fish set of an effect first of an effect native
solution. So again everything is open teometry compliant. You have type 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 effect 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, and I would almost think of it as an MPM two point zero. You don't know, 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 are, what you're able to do with for example, ACTA in ACORPECO in the JDM, or erline elis here, and so on and so forth. Clusterize a number of instances in JavaScript and do message passing style between them, which is pretty amazing that you can even get to that point in JavaScript and that's already in Alphine. In effect, it's called effect cluster, so it is very broad.
It can replace some of the pre existing solutions, and it can compound some other solutions, for example 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 fairly well. So both what you said, both
compounds and replace. So a question about that. As you said, one 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 and developers that 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 would React or something like that or maybe SVELT, and I bring them on board to a project that uses Effect, what's the onboarding uh 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, two different so that in effect, it's like I might as well have been using the JVM
because it's going to be Greek to them. That's a great question. Surprisingly, just bick. People have a brain which is already wired in thinking in terms of components. I believe that thanks to the developments in react, where reacty is really widely used. Why, because it's simplified UI development and allowed you to think in terms of composable UI components. When you think about the effect, you think in terms of composable back end components or composable business logic
components. So the brain doesn't have to do a huge suite, a huge switch. And the second element that makes the adoption path easier is that job stript has a syncle wave. Like you mentioned that that before we were living in an era where a sincle wave did not exist. Promises did not exist. For I mean, I was, I was writing callbacks 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. A sinca way makes
that easy. Why it brings back imperativeness to an otherwise declarative model, which is promised dot them 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 passed down a way of continuing your program. A sinkle weight makes that easy. Now you might ask is a syncle weight available for effect? I would say no, So why have you even set a synca weight
in the first place If you can't use a synca weight. Well, there's another feature in jawstrip which is lesser known than a synca weight, which are generators. So you can mentally swalk a sink with function star and a weight with guild star, and your whole mental model works. You can use effect in the same way as you use a synca weight, just by using generators. So if a newcomer reads the pod, they're going to be able to understand it. They might not be able to jump in and write it.
But just as if they are experiencing REALT, they'll probably not be able to adopt view 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. But they cross the concept. They can read the library code from the very beginning again. I'm not a front end developer, but I've seen code basis that use the realcity code basis that use view code basis that use Angular. I can read the code, I can
reason about the code without knowing the details of it. 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 you don't have to again. It's like wanting to learn javastrip by having to learn every single module on NPM might be a bit too much, but the learning curve is very, very progressive, and it is
very linear. The only non linear part is the first few hours. The first few hours you're going to be in a shot and you're gonna tape yourself for the decisions you've taken. But then that that stops. That stops very quickly. And the what what I've seen is is a trend where people that start us effect that was a fun and react here know that drugs. People that started doing the effecting there usually don't come back. I've never seen anyone
removing Effect 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 playing JavaScript or playing typescript without that. It's the same thing when you
learn typescript, you can't anymore write JavaScript. I wrote jawastript forageous. I would prefer to change jobs then write JavaScript without typescript. Again, like if you want to tell me you have to beat mine, if you want to stay employee, you have to write JavaScript. I would probably become I don't know, it's something or or a different I would not. I would Funnily enough, where I at size sense there's this piece of core legacy code that's
unfortunately very much still in JavaScript, and people are very touching it. Ah, it scares you to touch it, isn't it. Yeah, you found no if you're changing something you don't know if you're bringing anything else. Is a very good step forward in the direction of giving you confidence in maintaining the code base. It was effect you could quite literally refactor thousands and thousands of
lines of code and be sure that if it comprises words. Yeah. One of the challenges though with typescript uh, and I think both THEO and the Primagenes have spoken about it, is that there are like two 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 in to 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 possible, then it can become a challenge. And 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 so my question in this context is where
where does effect fall in that spectrum? Like is it is? How challenging is the typing when I'm writing code in effect, especially given that it's kind of like type safety insure correctness, so kind of like you like, as you said, kind of like you would get in languages like ELM. Well, that is again a great question and a a great point which is arguable.
I think I agree more with the sentiment that Matt Pocock has brought out, which is, yes, both the two different types strips exists library level and up level, but in up level you have that lead directory where you have the mix and match, where you do have to write a little bit of library level code in the app Effect. The usage of Effect surprisingly requires almost no manual type. Like when you write a function using a Synca weight,
you don't have to annotate the promise return type manually. The same thing is with Effect, with the difference that you're going to get inference for the errors and inference for the dependencies. Oh very cool. So basically you've done most of the heavy lifting, and when I use the FACT, I just get most of the benefits out. Just buy out straightforward. In fraence, I think I wrote thousands of lines of effect code in examples and and so
forth without ever specifying a 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 me how it should be. Even with promises, you can annotate a return type if you want to be sure that this is the actual return type, and sometimes you have to do that 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 going to have perform one's issues. But this has nothing to do with effect. This is very very general type strip points. The same applies with the fact So sometimes you have to write 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 teacher that grades your your correctness. I feel more in the in the space of the compiler 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 infir and I realize from that, oh, i've this is what I've done. This is the error cases that my program may m may issue when when main counter, when when
it's executed. And then if I handle one of those, the type system will tell me that that error is no longer present all by inference, not not by specifying the types, so by no meaning it's a type heavy element. We have also, I mentioned briefly before, schema effects schema, which is a similar approach to zo I, U, O, T S and so on and so forth. That's really where where a user starts with defining the types in their system. Those are more domain level types. You're you're
modeling your user base. If you are doing a two do NBC, you're going to have a two doo type. Those are the types, the concrete types that that you use. There's there's almost never a generic in those, as you pointed out rightfully. So and a very effect based code base would use schema to define the data model of their application and would infer the hell out of everything else in my the Way Highway 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. It's like it. I've seen the Clint configured tss slint configured to require that, and I, like you, I dislike it. I prefer as much type in for ince as possible whenever I need to explicitly specify the type of a return type of a function, so it almost feels like a failure. Yes, and we've done a lot of works so that you don't have all Right. Well, 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 guess my question is, Michael, because you've talked about moving off the JVM to something like like Effect or The other one is just if I started a new project today, what are the best ways to kind of roll into this and make it work how I want. Well, we have our website, which is incredibly easy to remember because the
website of Effect is called the fat Top website. And we have an amazing discord community which is by now more than three thousand people and those are not just numbers. They constantly write and help each other, and the teammates also help. So definitely join the sport and definitely try out tryout Effect. If there is another question that I would like to address, it came from twits and other podcasts, and I think we had a small exchange we've done 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 the c 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 bring composibility to higher levels of infrastructure where it's not going
to be at anymore. They're really gonna be plain and simple commercial services. Effect these 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 founded company, this was a was a question I intended to answer on a on a podcast, but I was like other people got that question asked and like, maybe I should answered
that specific question here. And I'm probably the only one who knows 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 five years without a company behind and without VC money behind. So even if the company burns, which is highly probable given that BC 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. We'll 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. There was one one
other point I wanted to cover. That's that's good to hear. It reminds me a little bit of like next Jas and Versail, right, you know, it's it's next Jas completely open source, you know, community run blah blah blah. Yeah, a lot of the people work for Versail that work on it, but at the end of the day, when you want to deploy your next JS app, versaill is your happy place kind of thing,
right, They specifically go after the things that you're going to want. It seems to have become a fairly popular model of having an open source project and
alongside it a commercial company. So obviously Versaill is kind of like the poster child, but also the Astro project is doing something similar, and even a million JS is a new upstart project are I think are hy Combinator funded, 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 looking to make revenue in some sort of a way in adjacent to that project. So it will be interesting to see how successful this model is over time. I think that discussing that would definitely require probably a different episode or or rock very long conversation. I'm not sure the model is gonna be successful at all.
If anything, I don't believe in that in that model in general, you might say, but if you've done the same, yes, I believe Versaill with next Years is a very peculiar example of a model that can work because Versaill is the best best place to deploy any front them, not only if you use next right. That's the that's the key differentiation. And I'm gonna stop here otherwise than revealing too much of the road where we are pointing, but it's gonna I appreciate Versaill a lot as a as a company, and
I take a lot of inspiration from it. So I just have one more quick question. You mentioned that you have a website that affects dot website. And we mentioned that there was a conference and you can find the talks I think on YouTube. Yes. Do you also have a discord channel where people can ask questions stuff like that? We absolutely have a discord community. It's
an amazing place where people help each other. There's there's almost three thousand there's actually more than three thousand users on it that are constantly writing themselves, helping themselves and so on and so forth. All of our development happens on this word, so that that is the central That the central place where I spend
most of my day. So also if you want to chat with me either Twitter or the new name X, always feel strange only X hope even it's not listening to us the chance if I ask again, I actually hope. Well, we should all hope that he does, because if he tweets it then or exit it or whatever it's called these days, posts it, then the podcast and effect will explode. He I'm totally fine with Elon asked actually coming out and going these guys are idiots, right, because we would still
get that same effect. So PU non 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? Well, I became a motorcyclist. I have a motorcycle now, and uh I would recommend to anybody the the MSF Basic Rider Course, if anybody's in the United States least, if you're interested in becoming one of the organ donors, then then the best way to prevent actually having to to uh donate your organs would be to
take that course. It already save my bacon when a semi cut in front of me, and since I'd already low sided the bike during 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. Ay, J. 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, donorcycle? Yeah, yeah, yeah, So anyway, it what was it? What was the other thing? I was going to mention, there's gonna be there something else I think related to that. Give me just a second. My brain's a little slower today because
of the cold. Oh. One of the pieces of protection that people often don't think about, or at least it wasn't one 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 a brand of hearing protection called Alpine Moto Safe. And 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, 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 ear plugs in and someone 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 cheap o foam ones are rated at something like thirty three dB and these are only rated at twenty. But part of that, I think is because of they're not they're very effective at reducing 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 want to have really really long discussions with your wife over a period of weeks or months or possibly even years, get in a motorcycling. It's a sense of freedom that is amazing, absolutely amazing. That's that's my picks for the day. Awesome, Dan, what are your picks? I don't have a whole lot in terms of picks for today. I you know, I do have
one. So obviously, there's the ongoing conflict in the Middle East, both 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 a
Pillar of Fire. It's an is it's an Israeli documentary, so obviously it represents the the Israeli view on things, but they did try very hard to also to be first of all fact base and also present a lot of the Palestinian side or the Arab side as well. It's it's talks about the origins of Zionism going back to the eighteen fifties and all the way to the founding
of the State of Israel, and covering all that period in between. We're talking about over one hundred period of over one hundred years, and it, like I said, it's from the eighties. So on the one hand, it's 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. Uh. 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 some of the episodes that are actually available on YouTube. So if this topic is interesting to you, I highly recommend this, uh this series, And that's my pick for today. By the way, uh, Ken, do you know where the where the phrase pillar fire comes from?
Oh? Heck, yeah, I know it, So you can also so you can also understand why it's been used in this context, like, uh, uh yeah, 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? Uh? Before my pre planned one, I have a couple of picks that came up inspired by our initial conversations here. One comes from one of my favorite sources of puns and jokes is called the pun Bible. It's pretty
short. It says it's a conversation between a student and teacher, and it says, student, thirty two degrees fahrenheit is equal to zero degrees celsius. Right, future says yes. In other words, so I said so. In other words, zero degrees celsius post zero degree celsius equal sixty four degrees fahrenheit. Thank you now, in honor of aj and the absolute torture that
he's been going through with his cold over the past week. One of my favorite sources of humor is the Babylon b They're so good, so good, Oh I love to be And anyway, one series of posts that they are always doing over the years about how men will suffer from a cold and as compared 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 Flutell's wife who has pushed three children out of body.
And so it starts out, I'll give you the first couple of paragraphs. Local man Aj O'Neill became better ridden 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 three whole children out of her body. The content reportedly led to a brief spat in which is the
suffering man edge precariously towards death door. Anyway, it goes on from there so I'll put the link in the notes hopefully, but it's it's classic Babylon d It kind of is not Sally by the way. By the way, it kind of reminds me of this thing that said that 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 your lower lip, yes, then and then pull it over your head. Yes.
Back before Bill Cosby went nuts, he has a classic routine called Himself that was an HBO special for eighty five and there's a section in there where he's talking about his wife's giving birth to the childbirth hysterical and he in that sketch he brings up that quote and then when he's talking about his wife giving birth, he talks about how she stood up in the stirrups and grabbed his lower lip and started to pull it up over his head. So that's a great
one. And finally the dad jokes of the week. So one day I went I changed the light bulb across the road and I walked into a bar, and that's when I realized my whole life was a joke. Yeah, question, what dating app do cannibals use it's called tender. Right. So the other day, speaking of a biblical reference, I found thirty dollars in the parking lot, and I thought to myself, what would Jesus do? So I turned it into wine. That's a good one. Those are my
picks for the week, all right. 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 one I want to pick. I'm going to go a little bit different direction. So my eighteen year old really likes retro games video games, especially video game consoles. So he actually walked like six or seven miles down to the retro game store in American Fork
and bought himself a Wii. And so we've been playing we Sports around here lately. And yeah, we Sports Resort, well we Sports are sort of boring. We Sports Resort is a little better. I don't think I've done the Wee Sports Resort, but I will tell you that it's been fun, you know, doing the bowling and astball anyway, So I'm gonna pick that. I'm gonna pick a video game instead of a board game today. A few other things that I'm gonna throw out, so one 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. And so I was talking to my new stepdad my mom got remarried a couple months ago, and he was like, well, if you tried. He told me to try two different things. I haven't tried one of them. I haven't tried ancient
grains, but I He's like, if 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 sour dough starter that lives in her fridge, and so she gave me some of that and I've been doing sourdough ever since, and I'll tell you what, 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 sour dough 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 going to put out there. So we already had a KitchenAid mixer, and there's a there's a website this lady does. 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 kind of walk you through the whole
process. 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, which anyway, so so yeah, so I'm gonna shout that out. One of the things that you need is also a it's a Dutch oven, and I don't know outside the US really have. It's a cast iron pot and the ones that you want stup 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. So I'm trying to find the website where all this stuff is at. Oh, here we go. And she's been super helpful too as far as like just figuring out, Okay, this didn't turn out the way I wanted, so anyway, I'll put
these links in here. But it's such good bread, and even when it doesn't come out looking just like this lady's bread, it was still oh 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. And then I'll put this at simplesourdough bread dot 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 one last thing that I'm gonna pick, and this is
just 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 Rails and Stimulus Codecs, and it basically walks you through writing an application in Ruby on Rails with the Stimulus front end and with Turbonative so that you can get quasi hybrid native apps out of your Ruby on Rails applications, and you can do it for other applications too, write because it basically just wraps around a web application and then it uses Strata to give you which is the Italian word for road, but it gives you that pathway
to get native elements into your Turbonative app. And then Turbative just gives you the wrapper around your web application so you can have the mobile app. And yeah, so so far I've got the Turbinative stuff. I'm just getting into Strata now and then we'll be getting into the rest of the stuff with Stimulus and Turbo. Turbo's kind of like HTMX, but anyway, I'm really really digging it. So I'm gonna pick the Rails and Stimulus, Rails and hot
Wire code X by Ayush Nuatia and Terminative. You should probably come on this podcast called JavaScript Jabber to talk about this stuff. Yeah, I should, I should, maybe I'll get I used to come on. He's one of our new panelists on Ruby Rogues. But yeah, and he's a former Native developer in Swift and Colin. So anyway, that's what I've been playing with lately. Michael, what are your picks? Oh? So I have a
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 got to train them very well. I was lucky enough to get my first bike when I was six years old, so I kind of have sec second nature instincts by now. But it's definitely not not normal, and especially if you if you get into biking at a leader age, do a safety course, actions
and everything else. What AJ said, it's it's good. I didn't know about the year. I think I'll try it out. Please send me a link, maybe offline. I'm curious, And so I have doubled down what Aj said and in a in a relatively similar fashion, but a different, completely different thing. I recently got into go karting. Mm fun do do do? Start to go karting? I purchased a Hazy card, which is
a shifter card with six gears, and it's killing me. I go there on the weekend, I feel like I'm the best driver in the war. And of course the low west on the track and Monday, Monday, like today, I'm in pain my whole body due to the physical exercise. But it's a very good way to get out of your concert zone, out out in the open and have fun. So my teak is go karting. How how fast do these go cards go? Well, that depends do you want
to know? In American terms or European terms terms? Last time I clocked like one hundred and thirty seven kilometers per hour on the track. Yeah. See, in America, go cart means children's toy or perhaps family recreational or not. That's true. I was gonna say, I go carting at a place hide here on the west side of Portland. And you know the cars that you can just go rent and drive around their track or you don't get it, like sixty miles an hour. And there's some there's some serious cart
there's races. Are people with their own cares, you know, and they go really fast. I have never heard of a go cart that goes more than like twenty miles an hour. Oh no, the carting, Oh I've I have some neighbors that have some that. Oh yeah, they whip around the neighborhood faster than the cars go. Right awayrat, this isn't just around the neighborhood. One hundred and thirty seven miles or kilometers per hours, about eighty five five hours, so that that sucker is moving that a pretty good
speed. It has six geas, so like it's it's serious force follower. Yeah, that's fast enough to take on the freeway here in the US and get a speeding ticket. Yes, you can get speeding people, not in Utah, but in other places and everywhere. Here's seventy miles an hour, seventy five miles an hour. That sweet. You get out of town and sadie. Because the trock is is not long. If you write long long shifts, it goes up to two hinds. But easily it's the closest thing
to a Formula one. You can ride. Wow, if you serve on. I can't wait to tell my wife she's going to be so excited to hear about this. Yeah, typically because it costs a lot of money overall, but it's very fun. 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 of stuff. And then you get, Yeah, you get the off road vehicles net that you know, you go down to there's a there's some sand dune south of the lake here that people go out and do that. Or we also don't live terribly far from the uh Boto the salt salt flats where you could probably go do something really fast there. Just don't forget, just don't forget to wear a helmet. Don't forget to wear a helmet. That's the only thing you wear on a gogle
cart. You don't have safety anything else. You just have a helmet and that's pretty much it. Yeah, and then it's that roll bars, right, so you like you just strap in and the roll bars are your safety net. Well, you don't have roll bars. Yeah, if you just don't wreck it. You just don't wreck it. That's your SA. Just
don't cry. Yeah. When I when I first asked about how to drive a Google cart proficiently on a on a track, the truck manager, who used to be number four in the World Championship in the maximum category of carting look at me, and I was like, Mike, the green, just don't go there the weed. Yeah, there was there was his advice. Don't go in the grass. That don't go in the grass. Yes,
that's the that's the advice on how to drive a go card. I really want to go now, yeah, go karting and CNA that I'm so in. All right, Well, let's go ahead and wrap this up. Thanks for coming, Michael. If people want to connect with you online, We've already said effect that website, But I'm guessing you're on Twitter and things like that. Where where do people find you? Tweeter or Discord? Discord is
better. I usually spend more time on Discord than Tweeter because then I start reading tweets, I get angry, close down on my laptop and so on and so forth, and the whole cycle rest. But I'm more on on on Discord, but also tweeter 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 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. But discord doesn't have that problem. Yeah, I have opened 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, I'm up there. Two Yeah, anyway, sorry, Yeah, what what's your Twitter handle? That might another? Oh? Easy, easy to
remember. All right, Well, we'll go ahead and wrap it up until next time. Folks max out