PokeVideoPlayer v0.9-rev1 - licensed under gpl3-or-later
ImmersiveAmbientModecolor: #be5e55 (color 2)
Video Format : (720p) openh264 ( https://github.com/cisco/openh264) mp4a.40.2 | 44100Hz
Audio Format: 140 ( High )
PokeTubeEncryptID: 49bfe7c226762c903010827a40b197376e436fc2d64a9f731cd6798990a0e6995e0d5c0c7c8ec2128075b5ee87e1c11d
Proxy : eu-proxy.poketube.fun - refresh the page to change the proxy location
Date : 1728539482343 - unknown on CCBot
Mystery text : bG5nNmRtcldnOEEgaSAgbG92ICB1IGV1LXByb3h5LnBva2V0dWJlLmZ1bg==
143 : true
59,238 Views • Sep 8, 2024 • Click to toggle off description
SOURCES
github.com/arthurfiorette/proposal-safe-assignment…
twitter.com/mattpocockuk/status/1825552688660230565
twitter.com/ssalbdivad/status/1824203257402556663
github.com/microsoft/TypeScript/issues/13219#issue…
Check out my Twitch, Twitter, Discord more at t3.gg/
S/O Ph4seon3 for the awesome edit 🙏
Views : 59,238
Genre: Science & Technology
Uploaded At Sep 8, 2024 ^^
warning: returnyoutubedislikes may not be accurate, this is just an estiment ehe :3
Rating : 4.937 (25/1,558 LTDR)
98.42% of the users lieked the video!!
1.58% of the users dislieked the video!!
User score: 97.63- Overwhelmingly Positive
RYD date created : 2024-10-09T22:12:17.415841Z
See in json
YouTube Comments - 224 Comments
Top Comments of this video!! :3
this will give people from the callback era PTSD
80 |
Blindly casting the type to E is not "type safe" because of the potential for anything to be thrown in JS and for any downstream library to throw an error. Errors being `unknown` is the only type safe option. It is completely misleading and therefore the opposite of "type safe" to let the error be whatever is passed in via generic. More realistically if your safeAwait checked for certain likely/expected errors and would only return those in the tuple, else throw on unexpected errors, then you could say it was type safe, because you would be avoiding type not-safety lies to yourself/colleagues/codebase. Another approach could be wrapping the error in a custom type (there are more options now thanks to `Error.cause`) and that could have some logic to help with keeping safeAwait() actually type safe. Otherwise this is a dangerous lesson!
41 |
There is no way I'm ever gonna be able to use something like Effect at work, anywhere. You pretty much never start a project from 0 and when you do reviewers want you to reduce complexity for the uninitiated. Standard library is the only way I'm ever gonna be able to use this
72 |
There's another reason this won't be accepted by TC39 that's a lot more fundamental than bikeshedding the syntax: the "error" value in the tuple could be falsy or even null or undefined, which means it cannot be safely used to determine whether the expression threw or not. This is a potentially huge (if rare) footgun.
22 |
@32:31 You don't need the explicit return type annotation (in the function signature) if you use "return [null, result] as [null, T];" and "return [error, null] as [E, null]" -- works like doing "as const" without also coercing the tuple into a Readonly. I also dabbled with a few TS-based guard and assertion functions to help with the "unboxing" aspect of telling TS what you're working with
I'd share the code in a TS playground link but since YouTube doesn't like that...
6 |
I really which that a throws clause would be included in typescript, even if it only told me that the function throws at all.
But given that it would be extremely confusing and kind of useless as long as there are libraries with type definitions without it I unfortunately dont believe it'll happen or get picked up by the community
7 |
I see the same arguments against Effect as I did for TypeScript (complexity, learning curve, etc). At work, we got on the Angular 2 bandwagon quite early, so was forced into TS. Absolutely no one would have predicted the wide adoption TS got when Angular started using it.
I'm posting this for posterity.
3 |
Stuff like this makes me absolutely loathe working with js/ts. I am professionally using Rust for the last few years, and while the error system isn't perfect, it's SUCH a great step up from throw/catch and gives soo much of the benefits you mention, including self-writing documentation and perfectly resolved and specified matching on error types.
14 |
Hi Theo, there is a good explanation from the TS team as to why errors will not be typed. It basically says it wouldn’t help most of the time, given how errors are handled by the Js community.
4 |
Discriminated unions are just the best datastructure that just became popular in the last few years. There are so many things you can express with a discriminated union. Error handling, implementation variation, optional data, a result that is one of a fixed list of types... The possibilities are endless
3 |
await stuff().then(r=>[r, null]).catch(e=>[null, e]) This pattern is useful sometimes, but not always the most readable, try/catch is useful when you want to handle things at a higher layer. I think all this fuzz would be better focused in more important things like passing named arguments, or improving destructive assignment by letting you extract specific items from an array without having to extract all others like const [ , ,a] = [1,2, 3]; currently you have to specify horrible placeholder variables that you cannot even repeat like: const [_, _z, a ] = [1,2,3]; horrible...
1 |
That along with pattern matching would be wild
5 |
How about this:
const [error, result] c= await fetch(...)
with c standing for catch.
And then you could optionally extend it to this:
const [error, result, pending] c=3 await fetch(...)
where 3 stands for "additionally, give the pending boolean as well".
I would really love to have c=3 or even c==3 or c===3 if I feel like my code is really good, as valid syntax in my production JavaScript code.
2 |
You know what else would fix error handling? Just getting the information that a function might throw. There are so many functions with unknown errors that can be thrown. Not documented anywhere and the only way to know is to encounter them.
13 |
Effect seems very similar to neverthrow after you showed it - but it's less demanding in terms of how much you need to write with it to get benefits
2 |
language level exceptions are a mistake. Result<T, E> is the only good way to handle errors
|
try() as a builtin function-like syntax would also work, and it would feel less weird for it to return a tuple, like
const [err, value] = try(await fetch(...))
. I don't know if keywords that look like a function call is a thing in JS though.
3 |
when you started to write your version of ?= i was like “HOLD THE FU** UP… YOU CAN OVERLOAD OPERATORS???!?!??!???!!111?!!!”
a boy* can dream
*(old af)
4 |
common W for rust. functions like std::fs::read_file() don't throw, they return Result<T, E>, where the error represents any kind of IO error the file might throw
|
@metsatroll
1 month ago
I think the worst part about modern youtube is that 5 minute videos are made into 30 minute videos just because of the ads.
264 |