There are libraries, there are frameworks and then there are language rewrites inside the language. I say: use libraries, be wary of frameworks, run from nested language rewrites.
@@calder-tyfunctional only really works well with compilers, with the ability to aggressively optimize memory usage, e.g. overwriting a buffer instead of allocating a new buffer. It’s hard to get right in interpreted languages that weren’t built with functional programming in mind, *cough Python *cough, but with a JIT that’s optimized for it you can probably get 70% of the way there anyways.
@@anonymousalexander6005 Interpreted languages claim that they are imperative and functional because they have lambda functions and a few higher order functions. Where are the monads? The monoids, functors and applicatives? Also python's lambda syntax is very ugly.
I think if JavaScript and Typescript devs would start to embrace the idea of errors as values and start writing libraries and packages using this model, we could probably inspire change among the community
@@ilearncode7365 it means returning a composite data type with either the result or the error instead of using the try catch and unwinding the call stack. Structured error handling was a mistake.
@@monad_tcp I'm not sure I really get this, what bothers people is that errors aren't being handled ? I feel like it would bother me more if they all were in a generic unhelpful way, I mean this is literally what catches do without having to write the generic handling at every level. Let's say you have a stack that is router -> controller -> service -> model, do I really want to check the output for each function in the stack ? Isn't it just easier to throw a custom 404 from the model if what you're looking for doesn't exist ? If you are calling that from the API the router will handle the 404 and return the error code to HTTP. If you are using the model from a script or something you could handle the 404 error and output it to stderr or something. I really don't see the added value of the extreme verbosity of specific error returns at each level.
I mean there are a bunch of libraries for handling errors in this way and actually I even worked in a project which used one of these. It was mostly okayish for our own code, but caused some really frustrating debugging sessions when someone made a mistake wrapping some other dependency.
@@andrewpatterson3139 Sure, but javascript developers can see how effective effects are (no pun intended). Also, IIRC Scala has a lot of software written this way (but I don't know that much scala). Of course, you should consider other aspects aside from developer experience such as performance, integration with the ecosystem, etc...
@@andrewpatterson3139it's hilarious how the people who leave your types of comments assume that performance matters to more than 2% of typescript developers who would be interested in this. Most of them don't even require the type of optimization you're talking about. It's about dev experience. Does Effect help the average typescript dev write more robust code, faster is the question. If they wanted to learn Haskell, they would.
Frameworks like this tend to result in write-only code and become legacy once the next fad shows up. Not saying it's not good, just saying 999 out of 1000 of these fail and fade with time, the other 1 will be deprecated because at some point useful features get first class support in the browser/base lib
these are something should be pick-up by the core teams at JS or Node and built a standard pattern across but we all know how incompetent JS is at standardising things
First-class support is the perfect outcome. This is the issue with Js/Ts in general. Devs want some problems solved, but language designers seem to make poor decisions, leading to a poor code, leading to devs solving problems in a poor way, leading to devs wanting to solve some language problems, and the cycle repeats.
@@thekwoka4707it's not bespoke, it's basic computer science. These concepts aren't going anywhere. It's not some meme js framework. With that being said ya it's ugly in ts
It's not a framework at all, just a library that focuses around the IO monad in a convenient way. The library might go away, these concepts never will and the will always be something like this. Hopefully built into the language
I agree, unless there is language syntax support its unusable. Look up "Algebraic Effects for the Rest of Us", the author introduces made up syntax which makes it way more simple to read and understand
It's a good reminder for new programmers to do your best to induce randomness to scheduled client request and all back offs. This some how escapes people's thinking. If all the client programs request an update on the hour. You're essentially building your own DDOS client. Will you be able to handle 100k clients all asking for the same resource at 1 am? what about million? and if so much more computer power are you paying for to do what could be spread out over 1 min? 5 min? an hour? etc. Instead, you can quiclky generate a random or pseudo-random offset*. Now, on the back-off and retry, you need to the same thing. Why? because if the server fails it will likely fail on the clients at near the same time meaning they'll retry at near the same time. Also, it needs to be more aggressive in fall-off and failure then you'd think when start getting into "scale." *Try to use something unique like user_id plus time, mac address plus time if you have to set your seed value. In environments where all clients have the same hardware. You might set your random seed to time since boot. That will be same or at least cluster for the devices with the same hardware and software. And setting to the current time at startup can also cause problems if your hardware boots up on it's own after a power outage since all the hardware will boot up at the same time. Nothing like suddenly having 10k clients in sync.
@@tensor5113 Okay, you're holding a million messages in your queue. 1. You have to have the infrastructure to accept and queue them. 2. You have to process them before you time out. Remember thanks to NTP all your clients are in near perfect sync.
@allalphazerobeta8643 you're thinking too much about the time. Understand why 100k clients need a message at 1pm, and now try to see if they need it at their time locally or your time. Also, you can fanout the message, or do caching. 100k clients for 1 message isn't a small task, but its not a difficult one either either, unless you're doing many writes
I was using fp-ts, and I loved it, and Effect is even better. People writing comments here are like horse riders criticizing cars or people using zip files instead of git. The Effect is a great tool. I would ask them how you handle errors in your apps or libs? Try catch? Oh noooo, poor boy/girl. How do you pass dependencies? Manually or globals? How do you know this function can fail? Reading the source code? Really? And how do you structure code? Mutable classes? OMG. ThePrimeagen just reacts; he explained nothing... it's just a show-a waste of time.
What was the number of code lines in your project with Effect-TS? Zod tends to ruin compiler performance way before 1M, even before 500K lines of code. And this stuff is a Zod++.
I kind of hate opinionated frameworks with passion, thanks Qt. When someone tries to modify the workflow of a language - adds language extensions/preprocessors (Qt, React), forces a code structure (often with a custom build system that stops working after a while, hey Meteor), adds programming primitives that are incompatible with the baseline of the language (Effect is a great example of this) - the project becomes unmaintainable trash in a 2-3 years. Frameworks like React - that are, arguably, a net positive between a forced structure+primitives vs simplicity+standardization - are exceedingly rare.
I love Ethan, can't wait for him to see this and address the performance aspects :) I'd throw in some more syntax sugar for some of these, and hope to see them benchmarked against "vanilla typescript" haha
I am doing my degree in computer science currently and I have to say that I have learned more about programming from you than I ever have from school. You not only teach stuff but also show us how to fend for ourselves. Im looking forward to being as good as you are.
That degree is a nice ticket to the big merry-go-round. Don't depend on it though to actually become good at your craft. You're on the right path following people like Prime. Keep yourself informed, and learn software development by diving into projects, learn new languages and frameworks, and just keep buiding stuff. You'll quickstart your career for sure.
@@Notoriousjunior374 thats like 5% of jobs. As a self taught engineer, never had trouble, not even at faang companies. IMO getting a degree is only a good investment if you have 0 clue. I was already coding when I was 10. got my first real software engineering job at 18, now I have +10years in the industry, without counting my self taught path (another 10 yrs)
@@jordixboy You may also consider that you have survivorship bias before giving life advice to students. Your path does not seem to be the most common, as not every person can get successfully hired at 18 and build their career from there. Not saying it's not _a_ path, but it's not the most common one.
Looks like someone finally turned Tom loose on TypeScript. Someone needs to build fundamental tools that assume asynchronous operations by default and byzantine or distributed problems where concurrency primitives are EFFICIENTLY WRITTEN (memory efficient) first-class citizens allowing you to set sync points that run when dependencies resolve or are available. Unfortunately, this does not do that. Ultimately something capable of doing things like this is probably an interpreter mixed with a scheduler pretending to be a language... Good video and meta video!
Just write a new language instead. If you want to fix language issues, don't do it inside the same language. Make a language that compiles down to wasm, and by the time you're getting it put together, wasm will have direct access to a bunch of useful browser APIs, and you won't even need to get messy with JS layers of the language.
14:40 This happened to us for a websocket reconnect backoff algorithm, except the connections were successful, but there was an error that happened *every time* for all clients after that request, so the "request success" was never successfully processed, but the backoff algorithm thought it succeeded. So the backoff not only "didn't work", but it also compounded onto itself due to the exception bubbling and incomplete processing. So after a bit of time, all clients were sending 10+ expensive requests every second. It was like the Loch Ness monster hiding in the code trying to figure out the exact cause of the chaos.
We're reaching a point where the bicycle has already been reinvented because round wheels were deemed inefficient, except the new wheels are now dorito shaped, and somehow it's better. Maybe things like wasm really will be the future, because this really isn't it, chief
Wasm with access to web api should have been the thing all along. I’m also sad that Js as a compile target is not more prevalent. Though it’s a shitty compile target at least you don’t get to touch it directly.
Couldn't disagree more lol, I like the idea of wasm but it's evident that it just causes people to create docker-esque complex monstrosities. Js as compile target is a blue pill. you may not like js but it's the unfortunate reality we live with, unless the new lang is a strict superset of javascript's feature set you're literally preventing yourself from writing optimal web code
@@pokefreak2112 we can just agree to disagree. The benefit to WASM, at least in this case, is that there's a strong variety of things you can write that'd ultimately compile into the same thing. JS will aways be JS no matter what library you slap on top. Sure, it has a dominating presence over the current standards, but it doesn't mean it's flawless, or that it'll stay forever. Nothing stays forever, and it will be phased out by something better eventually
@@pokefreak2112 you're issue with WASM isn't the issue, the problem with WASM is mostly that it is still not first class and you have to bloody write JS interrop anyway.
@@cat-.- Kotlin has JS, Wasm, Native and JVM targets, which looks like a big win. However, its JS target is ridden with OOP nonsense. I really wish they pushed for a minimal runtime overhead.
yeah I guess you could do this. But tbh it's a lot simpler to just have tagged unions representing an Ok or an Error (pretty much a sum type, enum, or whatever you want to call it, but a "union" of structs in TS). then in the happy path you return an Ok with the data and with the discriminator set to "ok", and in the error path you return an Error with the discriminator set to "error". The type declaration looks like this: type Result = { status: "ok"; data: T} | {status: "error"; err: Err} and you check the discriminator (`status`) to determine what to do. this encodes errors in the type system and effectively solves the problem, you just have to remember to put a .catch on every promise and return errs from catch blocks
Well, it's nicer if you also provide the methods like Rust Results have, so you can work with them without needed to check each and every one individually.
I like how typescript devs had to make up a bunch of random words to sound smart because learning the actual words from type theory and category theory was too scary
@@AndreiGeorgescu-j9p typescript devs didn't invent those words; they've been in use since unions were a part of C, and maybe even before then. and i hope you would give some examples of "the actual words" from type theory and category theory, that typescript devs are apparently too stupid to use. maybe the words you're thinking of don't map as cleanly onto typescript as you think they should.
@@harleyspeedthrust4013 ya well typescript is carrying on the tradition of C and every other imperative language of just building on top of adhoc nonsense. Instead of just learning computer science, they're at best learning the von neuman architecture system, at worst whatever adhoc nonsense some guy decided to make at any given time. John Backus used up his nobel prize speech in the 70s to criticize this and it's only gotten worse. Typescript doesn't have a real type system. It's not nominative like haskell or even Java, it's structure based which is why so many things are so verbose. It's the reason why a library like effect looks so bloated in JavaScript, because these are things that should just be in the language but hand to be tacked on. JavaScript was actually supposed to be a functional language but that got changed and it was a prototype of a language. Looking over what you said again you did actually mention sum types and tagged unions but discriminated unions aren't a thing and neither are discriminators. These are things typescript made up. What you're looking for here is to create a sum type to handle the different states your response can be in. That's really it. You'll often see Either be brought up to do this which is an abuse of the functor Speaking of functor, typescript people seem to have no idea it exists and use the map function like it's some kind of adhoc function for lists (sorry they call them arrays, you can't upset von neuman). Same for catamorphisms, applicative, alternatives, traversables, and even monads. I also notice typescript people talk about things like effect, which is really just a library based around the IO monad, like it's some fad style somebody came up last year and isn't just a wrapper around a fundamental concept in math. Most software "engineers" are just mechanics and sure think like them. And most importantly, it's a programming language's job to implement computer science/programming language theory concepts, not the other way around. If there is something in typescript that cannot be explained in category theory then it almost certainly shouldn't exist. Dependent types are the closest things to an important concept I can think of that isn't easy to figure out in category theory but that's like 5 type systems above the level of where typescript is at which is embarrassing in 2024.
@@harleyspeedthrust4013 ya well typescript is carrying on the tradition of C and every other imperative language of just building on top of adhoc nonsense. Instead of just learning computer science, they're at best learning the von neuman architecture system, at worst whatever adhoc nonsense some guy decided to make at any given time. John Backus used up his nobel prize speech in the 70s to criticize this and it's only gotten worse. Typescript doesn't have a real type system. It's not nominative like haskell or even Java, it's structure based which is why so many things are so verbose. It's the reason why a library like effect looks so bloated in JavaScript, because these are things that should just be in the language but hand to be tacked on. JavaScript was actually supposed to be a functional language but that got changed and it was a prototype of a language. Looking over what you said again you did actually mention sum types and tagged unions but discriminated unions aren't a thing and neither are discriminators. These are things typescript made up. What you're looking for here is to create a sum type to handle the different states your response can be in. That's really it. You'll often see Either be brought up to do this which is an abuse of the functor Speaking of functor, typescript people seem to have no idea it exists and use the map function like it's some kind of adhoc function for lists (sorry they call them arrays, you can't upset von neuman). Same for catamorphisms, applicative, alternatives, traversables, and even monads. I also notice typescript people talk about things like effect, which is really just a library based around the IO monad, like it's some fad style somebody came up last year and isn't just a wrapper around a fundamental concept in math. Most software "engineers" are just mechanics and sure think like them. And most importantly, it's a programming language's job to implement computer science/programming language theory concepts, not the other way around. If there is something in typescript that cannot be explained in category theory then it almost certainly shouldn't exist. Dependent types are the closest things to an important concept I can think of that isn't easy to figure out in category theory but that's like 5 type systems above the level of where typescript is at which is embarrassing in 2024.
It’s pretty well known (and powerful) writing style in FP, it’s expected that mainstream languages catch up only a few years later. Although there is an old but vibrant libs and community around it in JS (see Fantasy Land).
Sometimes I have trouble understanding some specific things that are discussed but it's ok since I'm not the most knowledgeable about more low-level and memory concepts. I am however fairly experienced in JS and TS, so when I see these videos and don't understand half of what's being said, my impostor syndrome level goes through the roof.
I started out with JS, jQ and PHP due to WP. While I took notice of all the other languages and tech, only when I found Fireship the syndrom actually swept me away. I have been getting more and more into contact with the rest of the world since, and it's been quite the journey....
New Dev Question: I started noticing that TRY CATCH issue a while ago so I’ve been dealing with it by giving each Action item its own function with its own TRY CATCH. Then using a Controller function that Await Calls each function. The Function would catch the Error and move it up. Wouldn’t that be the solution to all this? If theres one thing I’ve learned in my short time, it’s never that simple Lol
I remember Redux Saga was hot back in the days. Quite a lot of companies used it, or at least attempted to use... Now does anyone have the courage to admit that all that experiments were a mistake? And Saga's ambitions pale in comparison to this library. Effect-TS wants to rewrite everything: validation, Math.random, datetime helpers, fetch... everything. Will it succeed or fail miserably? Well, I'm not aware of ANY precedent of a language + full ecosystem (!) rewrite "from the inside". So I'd better ignore it. You know, it's almost never too late to switch to a shiny new tech, but God forbid to do that too early.
I highly expect the type name arguments in functions like catchError to be safe. I’ve accomplished similar things in my library functions and it provides intellisense too
All monads where `flat_map`/`and_then` takes an `FnOnce` are effects. (Also, few things are easier to reason about than RxJS. The only time I had an "if the types check out I can reasonably expect it's doing what I want" experience in something JS-based.)
completely agree with the conclusion and drawing parallel with rxjs. More people should start thinking about that before they quit the project they started bacause they cannot debug anything anymore... Also profiling in the browser is a nightmare as everything is fragmented and scattered all over the graphs...
ZIO is my favorite ecosystem by far - and as much as I personally enjoy learning category-theory, "classical" FP has a quite high barrier to entry. Requiring half a math degree is a serious disadvantage in recruiting. Plus - cognitive load is a source of errors, so effect-systems which eschew category-theoretical jargon in favor of process-oriented concepts and terminology are IMO a very good way to make type-safe, composable, functional programming more accessible.
I honestly had to vomit on the first Effect code and it didn't stop afterwards either. Glad I'm not a Web developer that has to deal with sh*t like that.
12:12 why? How does it help? Too much code based on (was it ever proven?) assumption that it’s unrealistic to make dependency injection at 11:15? I’d really like to see the code for which they implemented this wrapper.
I like it as an experiment. But I am really tired of the years we have on trying to "improve" javascript adding a whole layer of concrete on top. Not really solving it, just covering the ugly.
Yes please give us a programming language with effects! If you want to see the theory look up "algebraic effects and handlers", it's s concept that's been studied for some decades now. Algebraic effects capture a class of effectful computations that can be reasoned about, well, algebraically. Monads can implement all algebraic effects, but their logic sometimes is too abstract and fails to capture some properties of specific effect systems.
As a web dev that exclusively uses typescript in React apps, I have no idea what current 'real world' issues this would solve for me. What am I missing? Also really confused every time I hear him say "useEffect", but then try and go back and remember he is probably saying "use Effect"
As the video shows, it is to make error handling more concrete and able to be reasoned about. Instead of just throwing code around and pretending like errors don't exist because they aren't documented properly, it is about making them more obvious and making the handling of them easier.
@@mattymerr701 had to go back and rewatch as it had been 2 months, but my question still stands. This looks like a needless abstraction over existing error handling strategies we already use in web dev world. I can see it might help those coming from a place that is more familiar with these patterns, but I just see a nightmare of training sessions for jr web devs (if not mids, sr, too).
I don’t understand the problem with promises already running in the background and the value being memoized. Just pass around a function instead. You can then call the function as many times as you like and get new values each time.
type and variable with the same name belong to different namespace and the compiler does its work.. has no limitations except naming conventions working with multiple devs
This isn't for people who know enough FP to write their own endofunctors and monads. Nor for people who know enough about TypeScript to write generic monads with bimap implementations, like Either, which allow the type of Left to change at every turn, while maintaining perfect type correctness, through the chain. Give it a try in TS3 or TS4. It is an absolute nightmare. This is lazy-execution monads, without using the word "monad", for people who don't know what a monad is, with an async generator coroutine runtime.
@@SeanJMay unfortunately for myself I tried way too hard to make FP work in JS, so I tried many things throughout the years. There was an abundance of libraries that were JS first and had no type inference, so if this one is actually good at that this is QoL improvement. The only libraries that were not absolute nightmare was purify-ts, and fp-ts. First one didn’t have many niceties of his library, and was more about the most popular ADTs so little bit unfair. Syntactically it was much better than Effect, imo. Second one can do almost anything, but it’s definitely inaccessible for public use, because to even read the docs you have to know a LOT of FP theory. I never had a chance to use it on “real” project because nobody around me would be able to read it. So I can concede that if he addressed all of these points, it’s an achievement. I just don’t know why you would throw prior art under the bus? Especially since some of his promise wrappers is basically 1 to 1 syntactically to bluebird, but with extra features under the hood. The fact that he build fibers runtime for all of that is impressive, sure. And the main reason I stopped doing all of that and kinda skeptical about all of it - it’s still going to be horrible at runtime, compared to writing it “normal way”. Most of the UI frameworks will not be playing nicely with this paradigm either in code or in runtime. So your only real choice of using it is creating your own frontend framework with these primitives in mind or doing so on the backend, which I will never do on my own volition. I know there are like 10 people in the world who write JS/TS that actually care about performance a little, but if I have to write it I can actually bring myself to normalize error handling in the app and just wrap the top function in the tryCatch.
Well, gcanti (the guy behind fp-ts) is one of the main contributors of effect, so there’s that… You can basically use effect as a more accessible fp-ts, without having to opt in all of their runtime system.
Who is this guy talking? He looks like the prime-guy, but we all know that the prime-guy has the hood as an essential part of his brain. It's like a turtle and his shell, they could not be apart.
8:49 I agree. Just benchmarked Rust style custom Option and Result types in C# (I know...) to see how it's causing more allocation and GC for basic syntax sugar. But for some reason, people pushing this ideas because it's 'clean code' without realizing language itself doesn't play well with these concepts.
@@MrFoxPro If your method throws exception too often yes, result type might be a good way to optimize but if it is a rare occasion, result type just causes extra gen 0 and gen 1 allocation for no reason unless it's a ref struct. Also there is a GC part, we might gain execution speed over throwing but in return we get extra GC spike so benefits are application specific and requires benchmarking.
Modern Java now espouses return types modelled by an interface with multiple records (structs) implementing it. You then use switch with pattern matching on the result. You create an exception and wrap it in the result (the Error record type), but not throw it. So much better developer experience. Is this better?
Memory concerns with JavaScript 🤔 Okay, yeah that makes sense. I haven’t encountered those issues yet but I get it. But are you really programming with JavaScript for televisions? Wouldn’t you do it in C or Java? Are televisions closer to imbedded systems, browsers, or operating systems?
Yeah, this might just be trying to do too much ; the error handling is OK-ish although as you mentioned it could really benefit from language level support (prettier syntax), but the concurrency thing sounds like it belongs in a completely separate language. It could work the other way around too, perhaps ; it could be an alternative async library, the way we have some in Python, while trying to instead make the error handling part of the language?
the generator function thing is a pretty neat idea, but I agree that it just doesn't really seem like it fits into the language, and would be prone to spreading to places where it only complicates the problem for no real reason.
It’s funny how prime spouts all these pieces of true wisdom but then completely collapses onto his own opinions and perceived used cases to bash something he clearly doesn’t really understand. Like the fuck you talking about device programming and hyper memory optimization when that’s obviously not the use case and isn’t relevant for 99% of apps or programs. Effect allows you to rapidly prototype, map your domain explore useful constructs and you can literally drop in a completely different implementation of a core service trivially if you need to test performance or interop with something else. The fact that he completely dismisses it based on his own assumptions of how it works without even glancing at the source code is disappointing. This project has been in the works for years and is the product of deep thought and care from people who have been using code like this in production. Reading the comments and watching the twitch chat just proves how ignorant people are. Anyone who knows anything would be extremely impressed by what they’ve created here.
Its not like RxJS, its more like promise with typed errors and "environment" (context object). Which is what most JS backends end up implementing, over and over, manually. Why not benchmark the performance? :)
Anyway I wrote a little something about this 8y ago and I wasn't very optimistic because we standardised something else (search for: ES7 async functions, a step in the wrong direction)
Question for Prime and the web devs here: what's wrong with non-typescript languages that compile to readable Javascript? (I'm thinking Purescript or ReScript, but there are probably others.) I can understand why you wouldn't want something that emits something you can't read and I understand that using web assembly has costs and overhead. But is there some reason beyond popularity / familiarity to use Typescript over Purescript et al.?
It's not (only just) about familiarity, but also it builds on what you already know instead of having to "reinvent the wheel": Because syntax-wise, ALL JavaScript codes IS automatically Typescript code. Why bother with languages that have different syntaxes altogether if you're only going to compile them into OTHER language with a totally different syntax too just for the "extra" features, when there's this language (TS) that can accomplish them WHILE letting you keep those familiarity? Seems like a waste of resource to the point that just use a language like Rust or Go that have their own unique benefits.
11:15 > uses `db` from outter scope > but how we would change it for testing > muyby use full DI? Or maybe show us how you put it there in the first place, clown?
I think these guys need to create a new syntax for that, aka .ets, .etsx , that will support describing all this concisely, while having all the benefits (concurency, traceability etc)
At the time you get to this level of complexity and ugly syntax and perf impacts… Just use a language that supports the things you want, instead of trying to put lipstick on a pig. Libraries that are trying to fundamentally transform a language always end up in regret
14:25 You google it. No need to write it every single day, couple rewrites a day. I hate when people use such examples to prove something. When in reality we just sending json back and forth...
![เป็นไปได้ไหม - WanMai [Official MV]](http://i.ytimg.com/vi/_6lZ6b3_7Vo/mqdefault.jpg)
"Vanila" typescript got me
Everyday mankind strays further and further...
"Vanila" Effect next
@TayambaMwanza my brother just confessed to me that he used to shoot ropes to photos of latrell spreewell
@@laloqf i said son get on your knees!
true even I was scared if we have reached that point
There are libraries, there are frameworks and then there are language rewrites inside the language.
I say: use libraries, be wary of frameworks, run from nested language rewrites.
Looking at you Ramda
@@DubiousNachos the name alone sounds like it is a functional language designed to take all your memory
@@calder-tyfunctional only really works well with compilers, with the ability to aggressively optimize memory usage, e.g. overwriting a buffer instead of allocating a new buffer. It’s hard to get right in interpreted languages that weren’t built with functional programming in mind, *cough Python *cough, but with a JIT that’s optimized for it you can probably get 70% of the way there anyways.
@@anonymousalexander6005 Interpreted languages claim that they are imperative and functional because they have lambda functions and a few higher order functions.
Where are the monads? The monoids, functors and applicatives?
Also python's lambda syntax is very ugly.
What would you say about svelte. Where do you put it?
He made a mistake at Effect.Effect return Effect.flatmap(effect: effect)) : Effect
I think if JavaScript and Typescript devs would start to embrace the idea of errors as values and start writing libraries and packages using this model, we could probably inspire change among the community
not going to happen, it will be forever fragmented
we should kill JS with fire.
what does "error as value" mean? Arent errors objects that have values? Or do you mean returning the error inside the try?
@@ilearncode7365 it means returning a composite data type with either the result or the error instead of using the try catch and unwinding the call stack.
Structured error handling was a mistake.
@@monad_tcp I'm not sure I really get this, what bothers people is that errors aren't being handled ? I feel like it would bother me more if they all were in a generic unhelpful way, I mean this is literally what catches do without having to write the generic handling at every level. Let's say you have a stack that is
router -> controller -> service -> model, do I really want to check the output for each function in the stack ? Isn't it just easier to throw a custom 404 from the model if what you're looking for doesn't exist ? If you are calling that from the API the router will handle the 404 and return the error code to HTTP. If you are using the model from a script or something you could handle the 404 error and output it to stderr or something. I really don't see the added value of the extreme verbosity of specific error returns at each level.
I mean there are a bunch of libraries for handling errors in this way and actually I even worked in a project which used one of these. It was mostly okayish for our own code, but caused some really frustrating debugging sessions when someone made a mistake wrapping some other dependency.
This architecture is very common in Haskell. There are a few effects libraries and talks about them, if you want a taste of it
Haskell has the GHC which optimizes functional code, FP is not a first class citizen in javascript
@@andrewpatterson3139 Sure, but javascript developers can see how effective effects are (no pun intended). Also, IIRC Scala has a lot of software written this way (but I don't know that much scala). Of course, you should consider other aspects aside from developer experience such as performance, integration with the ecosystem, etc...
@@griof Scala performance is horrible, wouldn't really use it as an example. The syntax is pretty nice though.
@@andrewpatterson3139it's hilarious how the people who leave your types of comments assume that performance matters to more than 2% of typescript developers who would be interested in this. Most of them don't even require the type of optimization you're talking about. It's about dev experience. Does Effect help the average typescript dev write more robust code, faster is the question. If they wanted to learn Haskell, they would.
Haskellers: Look what they have to do to mimic a fraction of our power!
Frameworks like this tend to result in write-only code and become legacy once the next fad shows up. Not saying it's not good, just saying 999 out of 1000 of these fail and fade with time, the other 1 will be deprecated because at some point useful features get first class support in the browser/base lib
these are something should be pick-up by the core teams at JS or Node and built a standard pattern across but we all know how incompetent JS is at standardising things
Especially with just how ridiculously bespoke and boilerplatey this is.
First-class support is the perfect outcome.
This is the issue with Js/Ts in general. Devs want some problems solved, but language designers seem to make poor decisions, leading to a poor code, leading to devs solving problems in a poor way, leading to devs wanting to solve some language problems, and the cycle repeats.
@@thekwoka4707it's not bespoke, it's basic computer science. These concepts aren't going anywhere. It's not some meme js framework. With that being said ya it's ugly in ts
It's not a framework at all, just a library that focuses around the IO monad in a convenient way. The library might go away, these concepts never will and the will always be something like this. Hopefully built into the language
I agree, unless there is language syntax support its unusable.
Look up "Algebraic Effects for the Rest of Us", the author introduces made up syntax which makes it way more simple to read and understand
It's a good reminder for new programmers to do your best to induce randomness to scheduled client request and all back offs. This some how escapes people's thinking. If all the client programs request an update on the hour. You're essentially building your own DDOS client. Will you be able to handle 100k clients all asking for the same resource at 1 am? what about million? and if so much more computer power are you paying for to do what could be spread out over 1 min? 5 min? an hour? etc. Instead, you can quiclky generate a random or pseudo-random offset*. Now, on the back-off and retry, you need to the same thing. Why? because if the server fails it will likely fail on the clients at near the same time meaning they'll retry at near the same time. Also, it needs to be more aggressive in fall-off and failure then you'd think when start getting into "scale."
*Try to use something unique like user_id plus time, mac address plus time if you have to set your seed value. In environments where all clients have the same hardware. You might set your random seed to time since boot. That will be same or at least cluster for the devices with the same hardware and software. And setting to the current time at startup can also cause problems if your hardware boots up on it's own after a power outage since all the hardware will boot up at the same time. Nothing like suddenly having 10k clients in sync.
You're just gonna casually forget that messaging queues exist?
@@tensor5113 Okay, you're holding a million messages in your queue. 1. You have to have the infrastructure to accept and queue them. 2. You have to process them before you time out. Remember thanks to NTP all your clients are in near perfect sync.
and for a great deep dive on this look in to why ethernet replaced ring token
@allalphazerobeta8643 you're thinking too much about the time. Understand why 100k clients need a message at 1pm, and now try to see if they need it at their time locally or your time. Also, you can fanout the message, or do caching. 100k clients for 1 message isn't a small task, but its not a difficult one either either, unless you're doing many writes
@pcap8810 in this scenario the fill up is temporary, so you can just buffer the excess messages and the load will soon go back to normal
Writing in this style in Scala with Cats Effect. It's quite nice actually.
I was using fp-ts, and I loved it, and Effect is even better. People writing comments here are like horse riders criticizing cars or people using zip files instead of git. The Effect is a great tool. I would ask them how you handle errors in your apps or libs? Try catch? Oh noooo, poor boy/girl. How do you pass dependencies? Manually or globals? How do you know this function can fail? Reading the source code? Really? And how do you structure code? Mutable classes? OMG. ThePrimeagen just reacts; he explained nothing... it's just a show-a waste of time.
True, true - perfect "upwrite"! #OhHellboyYeah! ✊🏻 😻 🥳🎉
What was the number of code lines in your project with Effect-TS? Zod tends to ruin compiler performance way before 1M, even before 500K lines of code.
And this stuff is a Zod++.
@@IvanKleshninhow deep on the spectrum do you have to be to care about lines of code
I kind of hate opinionated frameworks with passion, thanks Qt. When someone tries to modify the workflow of a language - adds language extensions/preprocessors (Qt, React), forces a code structure (often with a custom build system that stops working after a while, hey Meteor), adds programming primitives that are incompatible with the baseline of the language (Effect is a great example of this) - the project becomes unmaintainable trash in a 2-3 years. Frameworks like React - that are, arguably, a net positive between a forced structure+primitives vs simplicity+standardization - are exceedingly rare.
You have no clue what you’re talking about. You havent read a single line of the source. This dudes channel attracts so many blow hard
Haha. Love it.
Disney+ was made with effect systems in Scala (Cats/ZIO), so they can be fairly efficient resource-wise.
Scala isn't resource efficient.
@@krux02 If Scala isn't then what is???
@@thavrisco1632rust
@@spl420 *mem::forgets half your memory*
Nothing personnel kid.
Explains why D+ is so shit then :^P
I love Ethan, can't wait for him to see this and address the performance aspects :) I'd throw in some more syntax sugar for some of these, and hope to see them benchmarked against "vanilla typescript" haha
I am doing my degree in computer science currently and I have to say that I have learned more about programming from you than I ever have from school. You not only teach stuff but also show us how to fend for ourselves. Im looking forward to being as good as you are.
Your Degree will definitely come in handy though. Employers will generally filter out those who have Degrees > without Degrees. Enjoy.
That degree is a nice ticket to the big merry-go-round. Don't depend on it though to actually become good at your craft. You're on the right path following people like Prime. Keep yourself informed, and learn software development by diving into projects, learn new languages and frameworks, and just keep buiding stuff. You'll quickstart your career for sure.
Prime is like the daddy mentor I never had. I've always been shit at picking good places to work, so a good mentor never materialized.
@@Notoriousjunior374 thats like 5% of jobs. As a self taught engineer, never had trouble, not even at faang companies. IMO getting a degree is only a good investment if you have 0 clue. I was already coding when I was 10. got my first real software engineering job at 18, now I have +10years in the industry, without counting my self taught path (another 10 yrs)
@@jordixboy You may also consider that you have survivorship bias before giving life advice to students. Your path does not seem to be the most common, as not every person can get successfully hired at 18 and build their career from there. Not saying it's not _a_ path, but it's not the most common one.
Vanilla typescript - Vanilla typescript - Vanilla typescript - bossing the windup today.
I am waiting for libraries for this Typescript library...
Looks like someone finally turned Tom loose on TypeScript. Someone needs to build fundamental tools that assume asynchronous operations by default and byzantine or distributed problems where concurrency primitives are EFFICIENTLY WRITTEN (memory efficient) first-class citizens allowing you to set sync points that run when dependencies resolve or are available. Unfortunately, this does not do that. Ultimately something capable of doing things like this is probably an interpreter mixed with a scheduler pretending to be a language...
Good video and meta video!
I love all the neckbeard knownit alls making shut up when they haven’t read a single line of code. Prime really encourages the bloviator crowd
Just write a new language instead. If you want to fix language issues, don't do it inside the same language. Make a language that compiles down to wasm, and by the time you're getting it put together, wasm will have direct access to a bunch of useful browser APIs, and you won't even need to get messy with JS layers of the language.
couldnt agree more. im sick of all this libraries/frameworks trying to fix javascripts problems and making the developer experience worse.
Ah yes, spend probably 10x more time, reinvent so much stuff, and then eventually just have it die in obscurity.
"a typescript library" i'd instantly click away
People layering 30 layers of abstraction just to escape JavaScript be like:
“It’s transpilers all the way downnnnnnn”
Layer on layer on layer on layer on layer on layer
“one more layer bro, I promise it’ll be finally good after I add just one more layer, I promise”
@@jacquesfaba55 That's literally every language ever made 😄
Is Effect a Library or a Framework?
Do you become a Effect programmer?
yes
No?
14:40 This happened to us for a websocket reconnect backoff algorithm, except the connections were successful, but there was an error that happened *every time* for all clients after that request, so the "request success" was never successfully processed, but the backoff algorithm thought it succeeded. So the backoff not only "didn't work", but it also compounded onto itself due to the exception bubbling and incomplete processing. So after a bit of time, all clients were sending 10+ expensive requests every second. It was like the Loch Ness monster hiding in the code trying to figure out the exact cause of the chaos.
We're reaching a point where the bicycle has already been reinvented because round wheels were deemed inefficient, except the new wheels are now dorito shaped, and somehow it's better. Maybe things like wasm really will be the future, because this really isn't it, chief
Wasm with access to web api should have been the thing all along. I’m also sad that Js as a compile target is not more prevalent. Though it’s a shitty compile target at least you don’t get to touch it directly.
Couldn't disagree more lol, I like the idea of wasm but it's evident that it just causes people to create docker-esque complex monstrosities. Js as compile target is a blue pill. you may not like js but it's the unfortunate reality we live with, unless the new lang is a strict superset of javascript's feature set you're literally preventing yourself from writing optimal web code
@@pokefreak2112 we can just agree to disagree. The benefit to WASM, at least in this case, is that there's a strong variety of things you can write that'd ultimately compile into the same thing. JS will aways be JS no matter what library you slap on top. Sure, it has a dominating presence over the current standards, but it doesn't mean it's flawless, or that it'll stay forever. Nothing stays forever, and it will be phased out by something better eventually
@@pokefreak2112 you're issue with WASM isn't the issue, the problem with WASM is mostly that it is still not first class and you have to bloody write JS interrop anyway.
@@cat-.- Kotlin has JS, Wasm, Native and JVM targets, which looks like a big win.
However, its JS target is ridden with OOP nonsense. I really wish they pushed for a minimal runtime overhead.
When the hoodie comes off we get a buff overflow
yeah I guess you could do this. But tbh it's a lot simpler to just have tagged unions representing an Ok or an Error (pretty much a sum type, enum, or whatever you want to call it, but a "union" of structs in TS). then in the happy path you return an Ok with the data and with the discriminator set to "ok", and in the error path you return an Error with the discriminator set to "error". The type declaration looks like this:
type Result = { status: "ok"; data: T} | {status: "error"; err: Err}
and you check the discriminator (`status`) to determine what to do. this encodes errors in the type system and effectively solves the problem, you just have to remember to put a .catch on every promise and return errs from catch blocks
Well, it's nicer if you also provide the methods like Rust Results have, so you can work with them without needed to check each and every one individually.
I like how typescript devs had to make up a bunch of random words to sound smart because learning the actual words from type theory and category theory was too scary
@@AndreiGeorgescu-j9p typescript devs didn't invent those words; they've been in use since unions were a part of C, and maybe even before then. and i hope you would give some examples of "the actual words" from type theory and category theory, that typescript devs are apparently too stupid to use. maybe the words you're thinking of don't map as cleanly onto typescript as you think they should.
@@harleyspeedthrust4013 ya well typescript is carrying on the tradition of C and every other imperative language of just building on top of adhoc nonsense. Instead of just learning computer science, they're at best learning the von neuman architecture system, at worst whatever adhoc nonsense some guy decided to make at any given time. John Backus used up his nobel prize speech in the 70s to criticize this and it's only gotten worse.
Typescript doesn't have a real type system. It's not nominative like haskell or even Java, it's structure based which is why so many things are so verbose. It's the reason why a library like effect looks so bloated in JavaScript, because these are things that should just be in the language but hand to be tacked on. JavaScript was actually supposed to be a functional language but that got changed and it was a prototype of a language.
Looking over what you said again you did actually mention sum types and tagged unions but discriminated unions aren't a thing and neither are discriminators. These are things typescript made up.
What you're looking for here is to create a sum type to handle the different states your response can be in. That's really it. You'll often see Either be brought up to do this which is an abuse of the functor
Speaking of functor, typescript people seem to have no idea it exists and use the map function like it's some kind of adhoc function for lists (sorry they call them arrays, you can't upset von neuman). Same for catamorphisms, applicative, alternatives, traversables, and even monads.
I also notice typescript people talk about things like effect, which is really just a library based around the IO monad, like it's some fad style somebody came up last year and isn't just a wrapper around a fundamental concept in math. Most software "engineers" are just mechanics and sure think like them.
And most importantly, it's a programming language's job to implement computer science/programming language theory concepts, not the other way around. If there is something in typescript that cannot be explained in category theory then it almost certainly shouldn't exist. Dependent types are the closest things to an important concept I can think of that isn't easy to figure out in category theory but that's like 5 type systems above the level of where typescript is at which is embarrassing in 2024.
@@harleyspeedthrust4013 ya well typescript is carrying on the tradition of C and every other imperative language of just building on top of adhoc nonsense. Instead of just learning computer science, they're at best learning the von neuman architecture system, at worst whatever adhoc nonsense some guy decided to make at any given time. John Backus used up his nobel prize speech in the 70s to criticize this and it's only gotten worse.
Typescript doesn't have a real type system. It's not nominative like haskell or even Java, it's structure based which is why so many things are so verbose. It's the reason why a library like effect looks so bloated in JavaScript, because these are things that should just be in the language but hand to be tacked on. JavaScript was actually supposed to be a functional language but that got changed and it was a prototype of a language.
Looking over what you said again you did actually mention sum types and tagged unions but discriminated unions aren't a thing and neither are discriminators. These are things typescript made up.
What you're looking for here is to create a sum type to handle the different states your response can be in. That's really it. You'll often see Either be brought up to do this which is an abuse of the functor
Speaking of functor, typescript people seem to have no idea it exists and use the map function like it's some kind of adhoc function for lists (sorry they call them arrays, you can't upset von neuman). Same for catamorphisms, applicative, alternatives, traversables, and even monads.
I also notice typescript people talk about things like effect, which is really just a library based around the IO monad, like it's some fad style somebody came up last year and isn't just a wrapper around a fundamental concept in math. Most software "engineers" are just mechanics and sure think like them.
And most importantly, it's a programming language's job to implement computer science/programming language theory concepts, not the other way around. If there is something in typescript that cannot be explained in category theory then it almost certainly shouldn't exist. Dependent types are the closest things to an important concept I can think of that isn't easy to figure out in category theory but that's like 5 type systems above the level of where typescript is at which is embarrassing in 2024.
The word "Effect" itself is already very traumatizing
how? it's just a side effect piped from one to the other, it stops running once one of the effects fails. what's traumatizing about it?
@@FlanPoirot useEffect
@@FlanPoirot if everything is a side effect, is there any intended effect?
@@brunokotesky5965 well react is kind trash (imo), and useEffect is only very very distantly related to the effects being used here
It’s pretty well known (and powerful) writing style in FP, it’s expected that mainstream languages catch up only a few years later. Although there is an old but vibrant libs and community around it in JS (see Fantasy Land).
Sometimes I have trouble understanding some specific things that are discussed but it's ok since I'm not the most knowledgeable about more low-level and memory concepts.
I am however fairly experienced in JS and TS, so when I see these videos and don't understand half of what's being said, my impostor syndrome level goes through the roof.
I started out with JS, jQ and PHP due to WP. While I took notice of all the other languages and tech, only when I found Fireship the syndrom actually swept me away. I have been getting more and more into contact with the rest of the world since, and it's been quite the journey....
Well, the presented code there was shit...
OK I just watched the video. I'm very excited about my next typescript project:
Effect
Effect
Effect
Effect
Effect
Effect
Erect
Effect
Effect
New Dev Question: I started noticing that TRY CATCH issue a while ago so I’ve been dealing with it by giving each Action item its own function with its own TRY CATCH. Then using a Controller function that Await Calls each function. The Function would catch the Error and move it up. Wouldn’t that be the solution to all this?
If theres one thing I’ve learned in my short time, it’s never that simple Lol
I remember Redux Saga was hot back in the days. Quite a lot of companies used it, or at least attempted to use...
Now does anyone have the courage to admit that all that experiments were a mistake? And Saga's ambitions pale in comparison to this library. Effect-TS wants to rewrite everything: validation, Math.random, datetime helpers, fetch... everything. Will it succeed or fail miserably? Well, I'm not aware of ANY precedent of a language + full ecosystem (!) rewrite "from the inside". So I'd better ignore it. You know, it's almost never too late to switch to a shiny new tech, but God forbid to do that too early.
Literally just ZIO for TS
And people say Go has bad error handling. if err is 1000 times better than try - catch
agreed
..and then Go inexplicably skipped past pattern matching because they are masochists.
I highly expect the type name arguments in functions like catchError to be safe. I’ve accomplished similar things in my library functions and it provides intellisense too
All monads where `flat_map`/`and_then` takes an `FnOnce` are effects.
(Also, few things are easier to reason about than RxJS. The only time I had an "if the types check out I can reasonably expect it's doing what I want" experience in something JS-based.)
"Effect provides a better way" and then vomits all over the code.
jezus TS got vanilla'd?
completely agree with the conclusion and drawing parallel with rxjs. More people should start thinking about that before they quit the project they started bacause they cannot debug anything anymore... Also profiling in the browser is a nightmare as everything is fragmented and scattered all over the graphs...
ZIO is my favorite ecosystem by far - and as much as I personally enjoy learning category-theory, "classical" FP has a quite high barrier to entry. Requiring half a math degree is a serious disadvantage in recruiting. Plus - cognitive load is a source of errors, so effect-systems which eschew category-theoretical jargon in favor of process-oriented concepts and terminology are IMO a very good way to make type-safe, composable, functional programming more accessible.
The DBClient example reminds me of ObjectiveC protocols, though protocols are much clearer and explicit.
Wait, isn't this ZIO? I mean, it looks like TypeScript implementation...
Yeah it's just ZIO but in Typescript, John De Goes gave a good speech about Effect this year
my boy ZIO is getting into JavaScript ecosystem lol
"Library", "next generation" ... These are the spam words for me nowadays. Let's fix the fix with the fix that fixed that previous fix
Prime says he is pushing 40, but his torso can’t be more than a day past 25.
Sus 🤨📸
I honestly had to vomit on the first Effect code and it didn't stop afterwards either. Glad I'm not a Web developer that has to deal with sh*t like that.
12:12 why? How does it help? Too much code based on (was it ever proven?) assumption that it’s unrealistic to make dependency injection at 11:15? I’d really like to see the code for which they implemented this wrapper.
Effect triggered my Coffeescript PTSD
I like it as an experiment. But I am really tired of the years we have on trying to "improve" javascript adding a whole layer of concrete on top. Not really solving it, just covering the ugly.
Or just pretend you are writing Go and always return [T, error] .
Very simple and works.
Or you can just return a union type and not allocate unnecessary memory.
@@ybabtsbut Go has no union types 😢
@@IvanKleshnin yeah but Typescript does. We're talking about Error handling in Typescript.
Error, Value instead of Value, Error saves you the hassle of explicitely returning undefined
If TS is JS with types then what is TS with `Any` types and try/catch blocks? Hey Tom do you know?
The depency injection part looks like ServiceLocator pattern
Yes please give us a programming language with effects! If you want to see the theory look up "algebraic effects and handlers", it's s concept that's been studied for some decades now. Algebraic effects capture a class of effectful computations that can be reasoned about, well, algebraically. Monads can implement all algebraic effects, but their logic sometimes is too abstract and fails to capture some properties of specific effect systems.
As a web dev that exclusively uses typescript in React apps, I have no idea what current 'real world' issues this would solve for me. What am I missing? Also really confused every time I hear him say "useEffect", but then try and go back and remember he is probably saying "use Effect"
As the video shows, it is to make error handling more concrete and able to be reasoned about.
Instead of just throwing code around and pretending like errors don't exist because they aren't documented properly, it is about making them more obvious and making the handling of them easier.
Whether or not it achieves that is another thing
@@mattymerr701 had to go back and rewatch as it had been 2 months, but my question still stands. This looks like a needless abstraction over existing error handling strategies we already use in web dev world. I can see it might help those coming from a place that is more familiar with these patterns, but I just see a nightmare of training sessions for jr web devs (if not mids, sr, too).
I don’t understand the problem with promises already running in the background and the value being memoized. Just pass around a function instead. You can then call the function as many times as you like and get new values each time.
I wrote something like this, but only the error handling. Just capture the errors as values and use type guarding to "handle" the errors.
Man the hard clipping on the audio is a bit painful. Interesting video though
Functional programming has arrived for typescript.
Agree with “typing strings is always a worry and should use something else”
type and variable with the same name belong to different namespace and the compiler does its work.. has no limitations except naming conventions working with multiple devs
My man pretends there was no Effect libraries before him? There’s entire FantasyLand spec, brother.
Yes, exactly I can name at least 6 major previous attempts. FP-TS is the latest. This guy has no moral right to hush them up.
This isn't for people who know enough FP to write their own endofunctors and monads.
Nor for people who know enough about TypeScript to write generic monads with bimap implementations, like Either, which allow the type of Left to change at every turn, while maintaining perfect type correctness, through the chain. Give it a try in TS3 or TS4. It is an absolute nightmare.
This is lazy-execution monads, without using the word "monad", for people who don't know what a monad is, with an async generator coroutine runtime.
@@SeanJMay unfortunately for myself I tried way too hard to make FP work in JS, so I tried many things throughout the years. There was an abundance of libraries that were JS first and had no type inference, so if this one is actually good at that this is QoL improvement. The only libraries that were not absolute nightmare was purify-ts, and fp-ts. First one didn’t have many niceties of his library, and was more about the most popular ADTs so little bit unfair. Syntactically it was much better than Effect, imo. Second one can do almost anything, but it’s definitely inaccessible for public use, because to even read the docs you have to know a LOT of FP theory. I never had a chance to use it on “real” project because nobody around me would be able to read it. So I can concede that if he addressed all of these points, it’s an achievement. I just don’t know why you would throw prior art under the bus? Especially since some of his promise wrappers is basically 1 to 1 syntactically to bluebird, but with extra features under the hood. The fact that he build fibers runtime for all of that is impressive, sure.
And the main reason I stopped doing all of that and kinda skeptical about all of it - it’s still going to be horrible at runtime, compared to writing it “normal way”. Most of the UI frameworks will not be playing nicely with this paradigm either in code or in runtime. So your only real choice of using it is creating your own frontend framework with these primitives in mind or doing so on the backend, which I will never do on my own volition.
I know there are like 10 people in the world who write JS/TS that actually care about performance a little, but if I have to write it I can actually bring myself to normalize error handling in the app and just wrap the top function in the tryCatch.
Well, gcanti (the guy behind fp-ts) is one of the main contributors of effect, so there’s that…
You can basically use effect as a more accessible fp-ts, without having to opt in all of their runtime system.
Alternate title: Prime tries so hard to like software he hates and not be a bully for 24 minutes and 44 seconds. (He succeeds)
hah, I WAS KIND OK
Prime try not to be an asshole challenge (IMPOSSIBLE)
Who is this guy talking? He looks like the prime-guy, but we all know that the prime-guy has the hood as an essential part of his brain. It's like a turtle and his shell, they could not be apart.
3:50 in which way is this better than just a promise chain?
Oh boy, it's always exciting to see the code that is so fresh but is already a horrible, hated legacy in the making.
aka “greenfield techdebt” 😂🥲
4:50 how can I start writing code for TVs?
How is this different from rxjs ? All problems stated can be fixed using rxjs 18:40
Prime hiding all the muscles under that hoodie
Is that hoodie some kind of power limiter or
Vanilla JavaScript has been a thing for14/15 years now, FYI to anyone who don't remember the first 15/20 years of JS.
vanilla typescript not javascript
@@bigmistqke what typescript is only 10 years old, there was a lot of complier to JavaScript languages, some added types some was "prettier" etc
@@zeocamo the guy in the video mentioned 'vanilla typescript' not 'vanilla javascript'.
in node error is first as there is only 1 error, but more paramers
Where the hell is the black hoodie, prime?
Fun fact an object having a then method can be used like a promise in js.
8:49 I agree. Just benchmarked Rust style custom Option and Result types in C# (I know...) to see how it's causing more allocation and GC for basic syntax sugar. But for some reason, people pushing this ideas because it's 'clean code' without realizing language itself doesn't play well with these concepts.
You mean things like .map that take closures cause GC issues?
@@vanjazed7021 No, I'm talking about custom types for example; Result MyMethod(Option option) instead of T MyMethod(T? option)
@@MrFoxPro If your method throws exception too often yes, result type might be a good way to optimize but if it is a rare occasion, result type just causes extra gen 0 and gen 1 allocation for no reason unless it's a ref struct. Also there is a GC part, we might gain execution speed over throwing but in return we get extra GC spike so benefits are application specific and requires benchmarking.
Modern Java now espouses return types modelled by an interface with multiple records (structs) implementing it. You then use switch with pattern matching on the result. You create an exception and wrap it in the result (the Error record type), but not throw it. So much better developer experience. Is this better?
"all languages are flawed, so.." is such a low bar to clear
7:40 - generators?
haskel is so glorious, you can only write whitepapers. gottem!
RxJs feels like a better way to handle asynchronicity
Memory concerns with JavaScript 🤔
Okay, yeah that makes sense. I haven’t encountered those issues yet but I get it.
But are you really programming with JavaScript for televisions? Wouldn’t you do it in C or Java? Are televisions closer to imbedded systems, browsers, or operating systems?
most smart tvs are just running android so you're just doing mobile dev
Java tv wtf man where did you buy that tv from hell 🥶
@@PanosPitsiandroid
@@PanosPitsistill better than your shitty JavaScript
How many Effect you need to write....
all
Effect.all precisely
Prime without hoodie is something I never thought I will see in my life.
Are we going from wrapping every html tag in a react component to wrap every js line in an "Effect" call? 🤨
If this is a clickbait title god damn it.
Edit: Nvm it looks pretty promising
Yeah, this might just be trying to do too much ; the error handling is OK-ish although as you mentioned it could really benefit from language level support (prettier syntax), but the concurrency thing sounds like it belongs in a completely separate language. It could work the other way around too, perhaps ; it could be an alternative async library, the way we have some in Python, while trying to instead make the error handling part of the language?
the generator function thing is a pretty neat idea, but I agree that it just doesn't really seem like it fits into the language, and would be prone to spreading to places where it only complicates the problem for no real reason.
If they had debugging functionalities as well, would that fix your issues?
It’s funny how prime spouts all these pieces of true wisdom but then completely collapses onto his own opinions and perceived used cases to bash something he clearly doesn’t really understand. Like the fuck you talking about device programming and hyper memory optimization when that’s obviously not the use case and isn’t relevant for 99% of apps or programs. Effect allows you to rapidly prototype, map your domain explore useful constructs and you can literally drop in a completely different implementation of a core service trivially if you need to test performance or interop with something else. The fact that he completely dismisses it based on his own assumptions of how it works without even glancing at the source code is disappointing. This project has been in the works for years and is the product of deep thought and care from people who have been using code like this in production. Reading the comments and watching the twitch chat just proves how ignorant people are. Anyone who knows anything would be extremely impressed by what they’ve created here.
If JS is a such a crappy language why it is used in so many places not related to the web? Latest example, Obsidian note taking desktop app.
Regression to the mean
People only knowing JS, people wanting one language for their whole codebase, people wanting their project to be accessible to contribute
Obsidian is literally a fake web app (electron)
hammer syndrome
@@Dennis-gg9yv OK, what about Grafana K6?
Its not like RxJS, its more like promise with typed errors and "environment" (context object). Which is what most JS backends end up implementing, over and over, manually.
Why not benchmark the performance? :)
Anyway I wrote a little something about this 8y ago and I wasn't very optimistic because we standardised something else (search for: ES7 async functions, a step in the wrong direction)
Question for Prime and the web devs here: what's wrong with non-typescript languages that compile to readable Javascript? (I'm thinking Purescript or ReScript, but there are probably others.) I can understand why you wouldn't want something that emits something you can't read and I understand that using web assembly has costs and overhead. But is there some reason beyond popularity / familiarity to use Typescript over Purescript et al.?
It's not (only just) about familiarity, but also it builds on what you already know instead of having to "reinvent the wheel": Because syntax-wise, ALL JavaScript codes IS automatically Typescript code.
Why bother with languages that have different syntaxes altogether if you're only going to compile them into OTHER language with a totally different syntax too just for the "extra" features, when there's this language (TS) that can accomplish them WHILE letting you keep those familiarity?
Seems like a waste of resource to the point that just use a language like Rust or Go that have their own unique benefits.
11:15 > uses `db` from outter scope
> but how we would change it for testing
> muyby use full DI?
Or maybe show us how you put it there in the first place, clown?
Devs at 90' - we need to create lookup table of sin/cos. Devs today map map pipe recurse
I think these guys need to create a new syntax for that, aka .ets, .etsx , that will support describing all this concisely, while having all the benefits (concurency, traceability etc)
How is this any different from what things like rxjs offer?
At the time you get to this level of complexity and ugly syntax and perf impacts…
Just use a language that supports the things you want, instead of trying to put lipstick on a pig.
Libraries that are trying to fundamentally transform a language always end up in regret
Are we bringing back "OrDie" like PHP ? That Effect syntax needs to be cleaned up or we might as well go back to callback hell
Gosh the more I watch these videos the more I love Go
When are we getting Primeagen courses
Can’t this be implemented using webstreams with transforms?
What does he mean by "V8 is not single threaded?" It's not??
14:25 You google it. No need to write it every single day, couple rewrites a day. I hate when people use such examples to prove something. When in reality we just sending json back and forth...