@@AbstruseJoker he's not annoying himself. Twitter just has this "aura" around it that makes people annoying as shit - it lets them say too much, the same kind of way YT is riddled with clickbait and it's annoying to anyone. Person itself might be far from it, a lot of them play a character like they do when they are around their friends vs alone.
SAME!! But I'm stoked Ethan made the jump, it definitely adds a dimension to the vids (especially for super educational content like this) and he actually had incredible pacing, clarity, and eye contact with the cam. Ethan idk if you have some speaking experience or something in the back pocket that'd protect my ego a bit here but damn if y'all aren't the most talented freakin generation...
Amazing video! Love the format and you crushed it on the organization, pacing, and editing! Using black shapes to "hide" portions of the diagram while you work through the example was slick. Love how you iteratively explored the solution, and my eyes got big when you hit interrupts. Very very cool way to demonstrate practical application of the Effect library and the usefulness of its primitives and helpers. 4:18 "You'll want to check out some additional resources" - you could definitely add a card for one of your earlier effect videos at this point IMO
A banger of a video indeed! Your Effect videos have been great! The kind of content I *want* to create to express my excitement about Effect, but you're doing it better than I could 😂 👏 🙌
I've been stumbling about trying to create parts of this library from scratch in every project I work on. I'll definitely be using this in future endeavors.
Hey 👋 Great video. As a former Scala dev, also involved in Redux-saga early days, I understand how this kind of lib can be useful, and wrote similar code in the past. But IMHO it's hard to generalize on your dev team unless your team is really skilled in functional programming. A more powerful abstraction can also be more challenging to use correctly.
So? Either you teach them or hire just better devs. This is not thar complicated, and I don't think you want people in your dev team that is not able to learn some new concepts
I don't know, I'm not sold really. I feel the main issue is TypeScript design, where throws and rejects lose the error type. If errors would be possible to annotate, most problems would be solved. With Effect, I'm getting the same vibes as with RxJs - great for the complex concurrency, overengineered for the rest 99% cases.. I don't think it's worth to introduce so much complexity to the codebase, just to make cleaner that one function with crazy concurrent logic. But perhaps if all of a sudden Effect gets an insane adoption and become lingua franca for TypeScript, would be cool! Once me and the majority of devs will grasp its concepts.
I think Effect makes sense in very specific places, rather than littering it around your entire codebase. The same with Rx, actually. It's just that it's easy for people to take a concept or pattern and use it _everywhere_ without considering the drawbacks of doing so-especially when the language is not built for these patterns (e.g. returning a "tuple" with an error/result to handle errors. Lot's of issues with that apart from memory usage. Even worse, then it's used in cases where it doesn't provide any benefits, nor even improves readability. It makes things harder to debug and reason about as well. I could see myself use Effect for handling side-effects outside my main logic; like handling I/O and use simple control flow to hand back control to the main app as any other Promise or Generator. I would be able to utilize all the features of Effect, without having to pay for it. What happens under the hood (handling backpressure, retries, rate limiting, concurrency, etc.) shouldn't leak into the higher level logic, otherwise it becomes hard to test and even more difficult to debug and reason about.
This is how I feel exactly. Way too much going on here. It wouldn't make sense to pull this in for a single use-case, and 99% of the things I've worked on over the years haven't been that complicated. It could make sense in specific applications where you're doing a ton of concurrent I/O, but in general this just feels like overkill.
Defo agree, I'm sure there are some specific cases where this is really useful, but the tradeoff is this is completely unreadable until a decent amount of time is spent learning what all this means, its making use of very unusual JS syntax. Also I don't know why people are so afraid of just adding a .catch to their promises, when you map to promises in a .all by just adding a .catch condition the return type is a union of the promise result and the catch result so there's your type safety, and it will wait for all promises to complete, this way has never failed me
As it stands, this library is very intrusive ; either all of your code uses it, or the overhead will outweigh the benefits. However, there are components that very useful and can be implemented outside, such as using structure (i.e. classes in JS/TS) to define requirements, and returning "results" instead of throwing errors. You could even make a wrapper over results to be able to use generators, as provided in the library, to simplify error bubbling from result types. The rest of it, honestly, is very similar to attemps at providing a Haskell-like workflow to JS (like fp-ts), which has never really worked, and the obsession over functional design purity is doomed to fail in a language that doesn't have anything in the way of syntax to help with that. At the end of the day, JS is JS, and if you want Haskell features, you can use GHCJS.
This is amazing, the only "issue" for me is that this is a external dependency, js/ts should have something like that builtin. You / your team / your company will need to create a culture to use it (not a big deal, just start using it in few parts that requires more concurrency features & better error handling), but who knows if in the future the lib will get abandoned?
I can "guarantee" the library won't be abandoned anytime soon, we've invested lots to build it and we will continue to do so (Effect was made for production usage, if we drop the lib we have to rewrite an insane amount of code ourselves :))
props for shedding light on the nuances of promise handling but real talk, while promise.all settled might seem dope, it's not the be-all-end-all solution effect library lowkey seems like a more solid approach for handling async in typescript but hey, different strokes for different folks, right? big up for diving deep into the topic though
Thanks for the video! ❤ One small correction for 11:45 - Promises start as soon as they are defined. They are not getting startet by Promise.all(), they are just awaited by it. I'm not that happy with the yield syntax, wasn't a big fan when they were used in redux-saga either. I actually prefer the more verbose style of pipes in Effect. :D
I’m aware, I added a correction card and a note in the description. Other than that, pipes are great as well! For this video my goal was to keep the code as similar as possible, using pipes would’ve been too much for people to easily grasp I think.
I really exited about effect, but I dislike his decision with Either/Option, because I faced with serialize/deserialize and just switched to fp-ts for this types And can wait your new video about effect :)
I think that you guys understands the problems of concurrency in JavaScript. Even if funny enough Javascript itself is async by nature, the language doesn’t really provides good primitives for concurrency control and cancellations. Effect seems to try to solve this. Coming from Go, the context api is somewhat what I miss the most in Typescript and how almost everything can be aborted once the context is cancelled. Great job with the Effect library. However, I find it overly verbose. I wish you guys could make things simpler without needing to wrap or convert everything in an Effect. Especially having these wrappers all around business logic, makes it so hard to reason about. Seeing this from a different perspective I would have loved an abstraction which would extends promises them self and add these amazing features. Everyone is already comfortable with promises and somehow having these Effects built ins would have made things simpler from a user perspective. Appreciated the work and the video 👍
12:10 but is it worth it to install a whole library to avoid 36 lines of code that can be copy-pasted and contained within a single asyncQueue function..?
I've seen the Effect lib before, but I really hate that everything has a wrapper. I personally think to solve this issue you need to have a fundamental change to how the language handles errors.
But we can’t change JavaScript and it’s already everywhere. We’re just lucky enough that typescripts type system is robust to allow for something like Effect at a library level, when the language can’t provide itself.
Great video! Effect looks interesting. Error-as-a-value is actually such a powerful pattern compared to exceptions, especially in JS where you get 0 typesafety and insights about exceptions a function might throw, compared to something like Java where a compiler would yell at you for not handling them. What I use at my job is an explicit error return, where a function either returns { success: true, data: T } or { success: false, error: E }, and all return statements are done using as-const. It is especially useful when there are multiple reasons for a function to fail, and error is an object with { cause: C, ... } where C is a union, and different sets of fields based on the cause. When your file upload fails, for example, it might fail during presign-url creation, or later during chunk upload. In the second case you might want to include the number of bytes uploaded and the total file size. AND you can use Promise.all(...) with this approach, so no dependencies needed.
There's many issues with this given that JS doesn't support it out of the box. Firstly, exceptions, while they are a poor choice for handling errors, are the backbone of exception handling within JS and part of the control flow (Promises, generators, loops, et. al.). When you start using such a pattern, it also means that you have to wrap every single library that doesn't conform to your pattern/types. Otherwise you end up with a mess of both worlds. There's no good way to scale this; I've been there, and regret the decision to implement a "Result" and "Option" type into a production codebase. It resulted in higher memory usage, and a ton of garbage collection, since you're creating intermediate objects _all the time_ even, when you don't need to, that needs to be GC'd causing a degradation in performance. When instrumenting the GC we saw a huge spike in old space GC, because those objects were kept around longer. Exceptions has their flaws, but it's better to deal with that than having to affect end-users with poor performance due to bad decisions.
Effect looks a lot like a lisp, meaning that instead of executing statements and expressions we build up a datastructure that runs in a runtime. What I think it's lacking is a DSL for it, it would be perfect
Great video 👍! However, the added layer of abstraction and dependencies might not be necessary for most scenarios. It would be nice if you could showcase a real-world use case you’ve encountered in another video.
Totally agree, but Effect can be implemented one function at a time. So in a big app, if you have only one function that does a whole lot of stuff, you could bring Effect to make it more robust and/or typesafe. You don't need to convert your entire app :)
I both love and hate this. Love it because it enforces errors as values and by extension has type safe errors. Hate it because its a band-aid fix for something that should be a language feature. Also, its TS so theres no guarantees you'll get the type-safety you would expect, ie. The function could fail in an unguarded area which would result in an unknown error.
it's fair, Effect is much better, but I need to know monads and generators! it's a bit much IMO hehe, I'd probably opt for some wrappers great video btw! new subscriber here
Ok, small disagreement with the comment on filtering settled promises and either; both versions do the exact same things (filtering and mapping). The main issue I'm having is that comparaison with string seems to be presented as less clean while the effect library use "unbounded" as a valid alternative for a numeric value; not like there are proper number value that could do the job (like, say `Infinity`), sure having this value out of nowhere would be strange but `left` and `right` are just as arbitrary and considered normal (yes, value being right and error being left is a jump of logic, no matter how normal it sounds to you). The contrast between theses 2 use of string feels like biased to me. Beside that, it was a good video and it's cool to see that Effect handle propagation of abortSignal natively.
I see hiw using a generator would be better in this case... I think the unreadability of the code far surpases the ugly filter code.. Until js find a way to add it internally and have an alias for it .. I dont think i will be using it.. Nor it will be part of the builtin js in its current state
You can use pipes which I would argue is cleaner than any imperative implementation. But really it’s no uglier than async await. Replace await with yield* _() and it’s the exact same code. 5 more characters 🤷🏻♂️
5 more characters, other than: - importing the library - calling effect.pipe - look back at the full code, see how long you can get what it does @@ethanniser just saying..
Great stuff. I can see projects of mine where this could be useful. However, the OCD in me can't unsee all those function names written in UPPER_CASE 🤪
Kinda dangerous typing errors imo. anything could fail so errors should always be unknown and be handled with the instanceof operator in catch I think.
Effect distinguishes between "expected" errors (errors that you see in the type) and unexpected errors (aka defects) and provided tools for handling both. In general though, the only errors that you can reasonably recover from are "expected", errors.
That was just for this video to make the code line up more with the original example. You can just do everything in a functional pipeline which is much much easier to reason about
I've been a software engineer for 8 years and can't remember the last time I had a type error in JS. Beginning to think the cult of typescript is just job security at this point lol.
Just took a quick look at bluebird, appears to have zero typesafety. Effect is a lot more than that, but that is one of its biggest selling points. it’s hard to even compare the two after that distinction.
I said make a RESPONSE video not a BETTER video
theo you're annoying most of the time but I appreciate you pushing better developers
Nah, never annoying. Just always being real
I enjoy and appreciate the different perspectives from you two, thank you.
@@AbstruseJoker he's not annoying himself. Twitter just has this "aura" around it that makes people annoying as shit - it lets them say too much, the same kind of way YT is riddled with clickbait and it's annoying to anyone. Person itself might be far from it, a lot of them play a character like they do when they are around their friends vs alone.
:D
i wasnt prepared for an immediate face reveal when i clicked on the thumbnail, wowzers
SAME!! But I'm stoked Ethan made the jump, it definitely adds a dimension to the vids (especially for super educational content like this) and he actually had incredible pacing, clarity, and eye contact with the cam. Ethan idk if you have some speaking experience or something in the back pocket that'd protect my ego a bit here but damn if y'all aren't the most talented freakin generation...
This videos has the effect of making me feel like I have no idea how to JavaScript anymore
Love your style and ability educate me just enough on effect to make the rest of the content make sense. Subscribed.
Amazing video! Love the format and you crushed it on the organization, pacing, and editing! Using black shapes to "hide" portions of the diagram while you work through the example was slick. Love how you iteratively explored the solution, and my eyes got big when you hit interrupts. Very very cool way to demonstrate practical application of the Effect library and the usefulness of its primitives and helpers.
4:18 "You'll want to check out some additional resources" - you could definitely add a card for one of your earlier effect videos at this point IMO
Hard to read and maintain. Used to write code like this with ramda and other helper libs way back in 2016. Thought I was the bee’s knees lol.
A banger of a video indeed! Your Effect videos have been great! The kind of content I *want* to create to express my excitement about Effect, but you're doing it better than I could 😂 👏 🙌
I've been stumbling about trying to create parts of this library from scratch in every project I work on.
I'll definitely be using this in future endeavors.
Hey 👋 Great video.
As a former Scala dev, also involved in Redux-saga early days, I understand how this kind of lib can be useful, and wrote similar code in the past.
But IMHO it's hard to generalize on your dev team unless your team is really skilled in functional programming.
A more powerful abstraction can also be more challenging to use correctly.
So? Either you teach them or hire just better devs. This is not thar complicated, and I don't think you want people in your dev team that is not able to learn some new concepts
I don't know, I'm not sold really. I feel the main issue is TypeScript design, where throws and rejects lose the error type. If errors would be possible to annotate, most problems would be solved.
With Effect, I'm getting the same vibes as with RxJs - great for the complex concurrency, overengineered for the rest 99% cases.. I don't think it's worth to introduce so much complexity to the codebase, just to make cleaner that one function with crazy concurrent logic.
But perhaps if all of a sudden Effect gets an insane adoption and become lingua franca for TypeScript, would be cool! Once me and the majority of devs will grasp its concepts.
I think Effect makes sense in very specific places, rather than littering it around your entire codebase. The same with Rx, actually. It's just that it's easy for people to take a concept or pattern and use it _everywhere_ without considering the drawbacks of doing so-especially when the language is not built for these patterns (e.g. returning a "tuple" with an error/result to handle errors. Lot's of issues with that apart from memory usage.
Even worse, then it's used in cases where it doesn't provide any benefits, nor even improves readability. It makes things harder to debug and reason about as well.
I could see myself use Effect for handling side-effects outside my main logic; like handling I/O and use simple control flow to hand back control to the main app as any other Promise or Generator. I would be able to utilize all the features of Effect, without having to pay for it. What happens under the hood (handling backpressure, retries, rate limiting, concurrency, etc.) shouldn't leak into the higher level logic, otherwise it becomes hard to test and even more difficult to debug and reason about.
This is how I feel exactly. Way too much going on here. It wouldn't make sense to pull this in for a single use-case, and 99% of the things I've worked on over the years haven't been that complicated. It could make sense in specific applications where you're doing a ton of concurrent I/O, but in general this just feels like overkill.
Defo agree, I'm sure there are some specific cases where this is really useful, but the tradeoff is this is completely unreadable until a decent amount of time is spent learning what all this means, its making use of very unusual JS syntax.
Also I don't know why people are so afraid of just adding a .catch to their promises, when you map to promises in a .all by just adding a .catch condition the return type is a union of the promise result and the catch result so there's your type safety, and it will wait for all promises to complete, this way has never failed me
As it stands, this library is very intrusive ; either all of your code uses it, or the overhead will outweigh the benefits. However, there are components that very useful and can be implemented outside, such as using structure (i.e. classes in JS/TS) to define requirements, and returning "results" instead of throwing errors. You could even make a wrapper over results to be able to use generators, as provided in the library, to simplify error bubbling from result types.
The rest of it, honestly, is very similar to attemps at providing a Haskell-like workflow to JS (like fp-ts), which has never really worked, and the obsession over functional design purity is doomed to fail in a language that doesn't have anything in the way of syntax to help with that. At the end of the day, JS is JS, and if you want Haskell features, you can use GHCJS.
This is amazing, the only "issue" for me is that this is a external dependency, js/ts should have something like that builtin.
You / your team / your company will need to create a culture to use it (not a big deal, just start using it in few parts that requires more concurrency features & better error handling), but who knows if in the future the lib will get abandoned?
I can "guarantee" the library won't be abandoned anytime soon, we've invested lots to build it and we will continue to do so (Effect was made for production usage, if we drop the lib we have to rewrite an insane amount of code ourselves :))
Great video Ethan. I'll definitely use Effect from now on
Great video, kinda a part 2 of Theos video amazing work both of you!!!!!
Btw Effect looks really cool, I’ll try to read more later
Code looks horrible. But I like the idea.
Yes it needs more nested try catches more chains of instance of with hardcoded strings then it will look like proper modern TypeScript
@@meppieomg You're wrong. Real modern typescript just optimistically assumes the code will never throw.
Now this is a great video, super excited to try Effect out :))
I don't know you and I had you on my home page, good job with destroying the algorithm 📈
Really awesome 😎 video! I happened to be working on the same topic. I'll definitely check out Effect 👌.
what a great vid! congrats
anti-theo youtube is now a legit niche
Your awesome, keep up the content.
Now we need Primeagen reaction to this video to complete excellence
Great video! What do you think about RxJs? Don't you think it is a valid more established alternative?
Great video! The algo brought me here FYI...looking forward to more videos
props for shedding light on the nuances of promise handling
but real talk, while promise.all settled might seem dope, it's not the be-all-end-all solution
effect library lowkey seems like a more solid approach for handling async in typescript
but hey, different strokes for different folks, right?
big up for diving deep into the topic though
This was amazing, never really heard of effect before this but I already have so much regrets for not using effect in my work.
this was a banger sheesh
good work!!👍
Thanks for the video! ❤
One small correction for 11:45 - Promises start as soon as they are defined. They are not getting startet by Promise.all(), they are just awaited by it.
I'm not that happy with the yield syntax, wasn't a big fan when they were used in redux-saga either. I actually prefer the more verbose style of pipes in Effect. :D
I’m aware, I added a correction card and a note in the description.
Other than that, pipes are great as well!
For this video my goal was to keep the code as similar as possible, using pipes would’ve been too much for people to easily grasp I think.
I'm a big piper myself.
@@ethanniserI agree with the choice. Telling people yield is like await if you squint is the gateway drug.
I really exited about effect, but I dislike his decision with Either/Option, because I faced with serialize/deserialize and just switched to fp-ts for this types
And can wait your new video about effect :)
blessed video
First 2 seconds I already love the video
I think that you guys understands the problems of concurrency in JavaScript.
Even if funny enough Javascript itself is async by nature, the language doesn’t really provides good primitives for concurrency control and cancellations. Effect seems to try to solve this.
Coming from Go, the context api is somewhat what I miss the most in Typescript and how almost everything can be aborted once the context is cancelled.
Great job with the Effect library. However, I find it overly verbose. I wish you guys could make things simpler without needing to wrap or convert everything in an Effect.
Especially having these wrappers all around business logic, makes it so hard to reason about.
Seeing this from a different perspective I would have loved an abstraction which would extends promises them self and add these amazing features.
Everyone is already comfortable with promises and somehow having these Effects built ins would have made things simpler from a user perspective.
Appreciated the work and the video 👍
I love your videos about effect. Do you plan to do more?
Yes, soon *tm*
I think you did great introducing us to Effect, but still the syntax is the only problem I have!
It feels kinda different.
12:10 but is it worth it to install a whole library to avoid 36 lines of code that can be copy-pasted and contained within a single asyncQueue function..?
I've seen the Effect lib before, but I really hate that everything has a wrapper. I personally think to solve this issue you need to have a fundamental change to how the language handles errors.
But we can’t change JavaScript and it’s already everywhere.
We’re just lucky enough that typescripts type system is robust to allow for something like Effect at a library level, when the language can’t provide itself.
I think @lannoOfAlgodoo just volunteered to be in ECMA and TC39
Great video! Effect looks interesting.
Error-as-a-value is actually such a powerful pattern compared to exceptions, especially in JS where you get 0 typesafety and insights about exceptions a function might throw, compared to something like Java where a compiler would yell at you for not handling them.
What I use at my job is an explicit error return, where a function either returns { success: true, data: T } or { success: false, error: E }, and all return statements are done using as-const.
It is especially useful when there are multiple reasons for a function to fail, and error is an object with { cause: C, ... } where C is a union, and different sets of fields based on the cause. When your file upload fails, for example, it might fail during presign-url creation, or later during chunk upload. In the second case you might want to include the number of bytes uploaded and the total file size.
AND you can use Promise.all(...) with this approach, so no dependencies needed.
There's many issues with this given that JS doesn't support it out of the box. Firstly, exceptions, while they are a poor choice for handling errors, are the backbone of exception handling within JS and part of the control flow (Promises, generators, loops, et. al.). When you start using such a pattern, it also means that you have to wrap every single library that doesn't conform to your pattern/types. Otherwise you end up with a mess of both worlds.
There's no good way to scale this; I've been there, and regret the decision to implement a "Result" and "Option" type into a production codebase. It resulted in higher memory usage, and a ton of garbage collection, since you're creating intermediate objects _all the time_ even, when you don't need to, that needs to be GC'd causing a degradation in performance. When instrumenting the GC we saw a huge spike in old space GC, because those objects were kept around longer.
Exceptions has their flaws, but it's better to deal with that than having to affect end-users with poor performance due to bad decisions.
@@dealloc Thanks for a very insightful comment. I count this as +1 for staying within the idioms of a language.
3:50 You can't call that code ugly and proceed argue that the generator code looks any better 😂
Effect looks a lot like a lisp, meaning that instead of executing statements and expressions we build up a datastructure that runs in a runtime. What I think it's lacking is a DSL for it, it would be perfect
yes!
Wow man, just wow.
Is there a market for a video called “Why Ethan Should Use RxJs”
Great video 👍! However, the added layer of abstraction and dependencies might not be necessary for most scenarios. It would be nice if you could showcase a real-world use case you’ve encountered in another video.
Totally agree, but Effect can be implemented one function at a time. So in a big app, if you have only one function that does a whole lot of stuff, you could bring Effect to make it more robust and/or typesafe. You don't need to convert your entire app :)
@@benocxx7906 It's a fairly large library (~46KB gzipped) to bring in to your project if you only have a limited number of use cases.
I both love and hate this.
Love it because it enforces errors as values and by extension has type safe errors.
Hate it because its a band-aid fix for something that should be a language feature. Also, its TS so theres no guarantees you'll get the type-safety you would expect, ie. The function could fail in an unguarded area which would result in an unknown error.
I think this is about the library than the promise js at all. Totally different. It’s like comparing lodash with js.
it's fair, Effect is much better, but I need to know monads and generators! it's a bit much IMO hehe, I'd probably opt for some wrappers
great video btw! new subscriber here
knew my tinkering with haskell would pay off one day
Can rxjs forkJoin be used as an alternative?
if you dont want any of the typesafety, sure
Ok, small disagreement with the comment on filtering settled promises and either; both versions do the exact same things (filtering and mapping).
The main issue I'm having is that comparaison with string seems to be presented as less clean while the effect library use "unbounded" as a valid alternative for a numeric value; not like there are proper number value that could do the job (like, say `Infinity`), sure having this value out of nowhere would be strange but `left` and `right` are just as arbitrary and considered normal (yes, value being right and error being left is a jump of logic, no matter how normal it sounds to you).
The contrast between theses 2 use of string feels like biased to me.
Beside that, it was a good video and it's cool to see that Effect handle propagation of abortSignal natively.
Hi I saw your RUclips channel How do you have less time you grow a fast RUclips channel ?? please explain me???? 🥺🥺
Great video! On an unrelated note can you share your vs code theme/style?
I’ll find it for you when I get home
ok added to the description of every video, hopefully you find that helpful
thanks for watching
Good stuff, thanks a lot!
2:39 console is hard to read on mobile
yea probably shouldve had my browser zoomed in
for next time
I‘d rather cast the error type than use those yields all over the place. How is that less ugly? yield* _()
It looks way more complicated/overkill than the Promise API
I see hiw using a generator would be better in this case...
I think the unreadability of the code far surpases the ugly filter code..
Until js find a way to add it internally and have an alias for it .. I dont think i will be using it.. Nor it will be part of the builtin js in its current state
You can use pipes which I would argue is cleaner than any imperative implementation.
But really it’s no uglier than async await. Replace await with yield* _() and it’s the exact same code.
5 more characters 🤷🏻♂️
5 more characters, other than:
- importing the library
- calling effect.pipe
- look back at the full code, see how long you can get what it does
@@ethanniser
just saying..
Effects can run on server side ?
Yep! It can run anywhere that JavaScript can.
amazing, ideal combo with tRPC ;)@@jessekelly8625
It may be powerful but man is it tough on the eyes imo lol
To be honest, it's just another abstraction, adding more complexity.
4:11 "Effect is also really big" → Clarification: Big as in ecosystem, not in bundle size (very tree shakeable).
How come that guy's hair is blond and moustache is black?
Just map the promises instead of using leftpad
Great stuff. I can see projects of mine where this could be useful. However, the OCD in me can't unsee all those function names written in UPPER_CASE 🤪
Blame Theo for this one lol, I was just extending his example
(this has nothing to do with actual OCD btw, that's just not how OCD works)
Title of the video got me thinking it's useEffect for some reason 😭
Huh. Algorithm worked on me
Trying find solution in js and in the end you always get new lib/framework. Why I need to learn another Saga or Rxjs. I hate js)
So pretty much an Either monad
Your kind of human robot hahhaha, well explained though!
MONADS
Please update Chrome.
Sorry will do lol
i think now readability kinda sucks here. 😢
At this point you should just use Haskell lol
Kinda dangerous typing errors imo. anything could fail so errors should always be unknown and be handled with the instanceof operator in catch I think.
Effect distinguishes between "expected" errors (errors that you see in the type) and unexpected errors (aka defects) and provided tools for handling both. In general though, the only errors that you can reasonably recover from are "expected", errors.
Yeah, because generator delegation is easier to reason about 🤭
That was just for this video to make the code line up more with the original example.
You can just do everything in a functional pipeline which is much much easier to reason about
Small RUclipsr 😂😂😂
ZIO!!!
But in JavaScript !
hahaha this is crazy
Almost took you seriously until I saw that dumb font 😭
I've been a software engineer for 8 years and can't remember the last time I had a type error in JS. Beginning to think the cult of typescript is just job security at this point lol.
Average league player lol
This is gross
Great video!!! Could you also make a comparison between Bluebird.settle/Bluebird.reflect vs Effect.all :)
Just took a quick look at bluebird, appears to have zero typesafety. Effect is a lot more than that, but that is one of its biggest selling points.
it’s hard to even compare the two after that distinction.