@@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...
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
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 :))
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
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.
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.
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 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.
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 😂 👏 🙌
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
Really nicely narrated. The Effect library syntax is overly complex, if I came across that in somebody else's codebase I wouldn't have a clue what it did without looking it up
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'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.
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.
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 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 :)
One major Issue I see with Effect lib is the difficulty it has for new devs, I cannot have this code in a small scale company like mine and expect the people working with me to be able to maintain it.
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.
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..?
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
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..
I'm an adept of the KISS principle (Keep It Simple Stupid). Effect is one of these approaches that are the complete opposite of that. Overkill in 99% of cases. Yes, it's nice. That's just not my cup of tea and really think that trying to make code simpler is an art in itself, as interesting and powerful than a library like Effect. The code will be more robust and enjoyable to work with, for you and your team. For the 1% problem that's left, sure, use the nuclear option.
Just to make it clear- I think this is a very reasonable take However, I would really challenge you on that 99% figure. 99% of random projects? Maybe. But 99% of large scale production typescript apps- I would strongly disagree. If you are writing a large scale production typescript app, the things effect solves are problems you have to solve in some way- structured error handling, interruption, retries, bounded concurrency, telemetry, etc. I worked at a startup this summer used effect extensively and we had all of these issues come up- and effect handled them gracefully. Can you replicate the stuff effect does yourself- totally, but why spend the engineering time on something that will probably be less robust and not community supported? You could make the same argument on something like react- "99% of apps could just be jquery". But clearly react has value, mainly from its composability (effect does the same thing!), that makes it worth adopting for non trivial applications. Could you write your own framework- sure, and people do, but I don't think anyone is calling react "the nuclear option" despite how it also asks quite a lot in terms of fundamentally shaping how most of your code is written.
@@ethanniser 99% wasn't to take literally :) I meant that there are far far more not so complex projects out there and they don't require this. If you are going to argue by first splitting between simple app and "large scale production typescript app", then of course this "big apps" category has a higher probability to require something like Effect. To me, it feels like typescript / javascript isn't good enough in some cases, which could be true, but people use it anyway. They then make libraries that encapsulate solutions that exist in other languages and so, it's not really typescript anymore. Look at your video code examples, practically all lines in your code have "Effect" in them (or Effect related like "Either"). It's not Typescript anymore, it's "Effect language". Which again, is ok I guess. But probably most new typescript dev you hire won't know it and need extra time at the beginning. I only want to point out that using Effect has its drawbacks which involves every dev in a company. If there is another language that has what you want, why not use it and hire people who know it instead?
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
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.
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 🤪
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
This videos has the effect of making me feel like I have no idea how to JavaScript anymore
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...
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
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 :))
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.
Controlled concurrency is huge. Solves a lot of problems I was using queues for
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.
Love your style and ability educate me just enough on effect to make the rest of the content make sense. Subscribed.
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.
Now we need Primeagen reaction to this video to complete excellence
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.
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 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.
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 don't know you and I had you on my home page, good job with destroying the algorithm 📈
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
Really nicely narrated. The Effect library syntax is overly complex, if I came across that in somebody else's codebase I wouldn't have a clue what it did without looking it up
I think you did great introducing us to Effect, but still the syntax is the only problem I have!
It feels kinda different.
3:50 You can't call that code ugly and proceed argue that the generator code looks any better 😂
Great video Ethan. I'll definitely use Effect from now on
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'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, kinda a part 2 of Theos video amazing work both of you!!!!!
Btw Effect looks really cool, I’ll try to read more later
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.
It may be powerful but man is it tough on the eyes imo lol
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
knew my tinkering with haskell would pay off one day
Now this is a great video, super excited to try Effect out :))
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.
Great video! What do you think about RxJs? Don't you think it is a valid more established alternative?
I love your videos about effect. Do you plan to do more?
Yes, soon *tm*
anti-theo youtube is now a legit niche
Your awesome, keep up the content.
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 :)
Really awesome 😎 video! I happened to be working on the same topic. I'll definitely check out Effect 👌.
It looks way more complicated/overkill than the Promise API
I think this is about the library than the promise js at all. Totally different. It’s like comparing lodash with js.
One major Issue I see with Effect lib is the difficulty it has for new devs, I cannot have this code in a small scale company like mine and expect the people working with me to be able to maintain it.
4:11 "Effect is also really big" → Clarification: Big as in ecosystem, not in bundle size (very tree shakeable).
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.
this was a banger sheesh
Great video! The algo brought me here FYI...looking forward to more videos
Is there a market for a video called “Why Ethan Should Use RxJs”
To be honest, it's just another abstraction, adding more complexity.
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!
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..?
MONADS
blessed video
what a great vid! congrats
yes!
good work!!👍
I am here for the algorithm destruction!
Wow man, just wow.
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
This was amazing, never really heard of effect before this but I already have so much regrets for not using effect in my work.
I‘d rather cast the error type than use those yields all over the place. How is that less ugly? yield* _()
First 2 seconds I already love the video
Huh. Algorithm worked on me
Hi I saw your RUclips channel How do you have less time you grow a fast RUclips channel ?? please explain me???? 🥺🥺
Title of the video got me thinking it's useEffect for some reason 😭
2:39 console is hard to read on mobile
yea probably shouldve had my browser zoomed in
for next time
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..
Can rxjs forkJoin be used as an alternative?
if you dont want any of the typesafety, sure
I'm an adept of the KISS principle (Keep It Simple Stupid). Effect is one of these approaches that are the complete opposite of that. Overkill in 99% of cases. Yes, it's nice. That's just not my cup of tea and really think that trying to make code simpler is an art in itself, as interesting and powerful than a library like Effect. The code will be more robust and enjoyable to work with, for you and your team. For the 1% problem that's left, sure, use the nuclear option.
Just to make it clear- I think this is a very reasonable take
However, I would really challenge you on that 99% figure. 99% of random projects? Maybe. But 99% of large scale production typescript apps- I would strongly disagree.
If you are writing a large scale production typescript app, the things effect solves are problems you have to solve in some way- structured error handling, interruption, retries, bounded concurrency, telemetry, etc.
I worked at a startup this summer used effect extensively and we had all of these issues come up- and effect handled them gracefully.
Can you replicate the stuff effect does yourself- totally, but why spend the engineering time on something that will probably be less robust and not community supported?
You could make the same argument on something like react- "99% of apps could just be jquery". But clearly react has value, mainly from its composability (effect does the same thing!), that makes it worth adopting for non trivial applications. Could you write your own framework- sure, and people do, but I don't think anyone is calling react "the nuclear option" despite how it also asks quite a lot in terms of fundamentally shaping how most of your code is written.
@@ethanniser 99% wasn't to take literally :) I meant that there are far far more not so complex projects out there and they don't require this. If you are going to argue by first splitting between simple app and "large scale production typescript app", then of course this "big apps" category has a higher probability to require something like Effect.
To me, it feels like typescript / javascript isn't good enough in some cases, which could be true, but people use it anyway.
They then make libraries that encapsulate solutions that exist in other languages and so, it's not really typescript anymore.
Look at your video code examples, practically all lines in your code have "Effect" in them (or Effect related like "Either"). It's not Typescript anymore, it's "Effect language". Which again, is ok I guess. But probably most new typescript dev you hire won't know it and need extra time at the beginning.
I only want to point out that using Effect has its drawbacks which involves every dev in a company. If there is another language that has what you want, why not use it and hire people who know it instead?
Your kind of human robot hahhaha, well explained though!
Just map the promises instead of using leftpad
At this point you should just use Haskell lol
Effects can run on server side ?
Yep! It can run anywhere that JavaScript can.
amazing, ideal combo with tRPC ;)@@jessekelly8625
How come that guy's hair is blond and moustache is black?
i think now readability kinda sucks here. 😢
So pretty much an Either monad
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
Please update Chrome.
Sorry will do lol
ZIO!!!
But in JavaScript !
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.
Small RUclipsr 😂😂😂
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)
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)
Almost took you seriously until I saw that dumb font 😭
hahaha this is crazy
Theo should learn to code before opening his mouth
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.
This is gross
Average league player lol
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.