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