0.1+0.2!=0.3 is a byproduct of the actual floating point arithmetic spec, not the implementation, it’s not a javascript issue
@DavidMulderOne7 ай бұрын
Theo's lack of knowledge here was... surprising. Not saying base 10 numbers wouldn't be useful to have in JS... but it makes perfect sense that it's not the default.
@fusedqyou7 ай бұрын
@@DavidMulderOne This guy doesn't spend more than an hour on these reaction video's. Lazy content.
@Elesario7 ай бұрын
I wish it was a more well known fact about the nature of floating point representation. I've seen floats used in situations where the dev was clearly just using it for a lazy convenience, but totally ignorant of the loss of precision they'd just created. Especially bad, because many times those numbers represented financial values.
@monishbiswas19667 ай бұрын
Yes - I though this was well known. I imagine the advantage of using binary encoded floating point is that it can use the native CPU support for floating point arithmetic if present.
@Archheret1c7 ай бұрын
I'm sure he knows it follow the ISO-standard, it's just more fun to complain about javascript.
@Cool_Goose7 ай бұрын
The whole 'even Edge' has it is a bit tiring considering it's using effing chromium in the first place.
@ark_knight7 ай бұрын
Not sure if it was meant to be funny? The fact that engineers from both Google and MS are going full time on V8 while Gecko is being starved to death with barely minimum resources. Saying Firefox is holding back web is like saying the resistance is holding back the world domination. smh
@ky3ow7 ай бұрын
comparing multibillion orgs with non profit mozilla and saying that it lags behind sure is strange move
@rand0mtv6607 ай бұрын
Yeah it's a silly comment from him that doesn't seem to understand that Chrome and Edge are basically skins on top of Chromium. There are also instances where Firefox had support for something years before Chromium. For example subgrid is one of them and also animating some flexbox features. To be honest, In the last few years I had way more issues supporting Safari than I've had Firefox on anything I've worked on. Safari and especially Safari on iOS always have the weirdest issues. It's actually admirable that Mozilla is managing to keep up with Chromium at all considering the lack of resources.
@ark_knight7 ай бұрын
@@rand0mtv660 I think Theo is laughing his ass off seeing how a handful of people are triggered for no reason lol. He prolly understands the gravity of his statement, but he just likes to have fun with Firefox people haha.
@neociber247 ай бұрын
@@ky3ow So, let's talk about Safari
@BogdanTestsSoftware7 ай бұрын
14:30 - Of course Edge has most features Chrome has - it's still Chrome. Come one, Firefox is not that old, I'm sure they'll manage to implement it shortly. I'm sure Safari has more outdated features & not implemented features
@hoaxygen7 ай бұрын
Yeah, what are these awful takes. Isn't this common knowledge at this point?
@flufster7777 ай бұрын
The irony of bagging on firefox immediately after praising MDN.
@retakenroots5 ай бұрын
Yeah, like no one ever has done that with Internet Explorer and Microsoft Developer Network.
@epicmetodАй бұрын
whats wrong with McDonald Nuggets
@tiedye0017 ай бұрын
Theos ingorance surrounding browser monopolies is confounding
@1337cookie7 ай бұрын
He still fanboys apple despite their constant anti-consumer attitude.
@pokefreak21127 ай бұрын
Chromium has a near-monopoly because it is better than the other browsers, they're not doing anything wrong. Nerds will complain on the internet but most of you will never even _attempt_ becoming a Firefox contributor, your loss!
@rand0mtv6607 ай бұрын
@@pokefreak2112 Chrome has a monopoly because Google controls Google Search and Android and showed Chrome down our throats for the last 10 years. It's not miles ahead of other browsers in anything really. Not saying it's not good, just saying it's not that better than others. Although there was initial period when Chrome appeared when it really was a breath of fresh air in browser wars.
@tiedye0017 ай бұрын
@@pokefreak2112 🤣 You're trolling
@Zeragamba7 ай бұрын
@@tiedye001 Not really though. Between Chrome 124, Safari 17.4, and Firefox 125 on Can I Use, Chrome has almost all of the features supported or at least partially supported, where as Firefox and Safari have a lot more Red than Chrome
@rand0mtv6607 ай бұрын
14:45 "even Edge has it". Bro, they implemented it only like two months ago. It's not like you can start using the feature and ship it to users since most users probably still haven't updated to latest browser version. Of course you can just use it anyway and bundler will transpile it to some polyfilled code so that browsers you support will be able to run it. In that case Firefox support doesn't really matter. But same can be said other way around for something like CSS Subgrid. We would have been able to use it for years now if Chromium implementation didn't lag behind Firefox for almost 4 years. Yes that's right, 4 years, not 4 months. Unfortunately something like subgrid cannot even be polyfilled.
@Markov397 ай бұрын
Firefox holding back a feature, thats under a year old in other browser doesn't seem to bad to me.
@TurtleKwitty7 ай бұрын
a feature that is polyfilled so holding back slight performance gain not the feature as whole at all XD
@kisaragi-hiu7 ай бұрын
The 0.1 + 0.2 thing is floats acting exactly as defined and not at all JS's fault. 0.1 + 0.2 != 0.3 in Python either, for instance. What JS lacks, however, is a builtin Decimal type and/or Rational type. Imagine if JS actually had Scheme-style exact numbers, rationals, and even complex numbers. It'd be pretty nice.
@tempname82637 ай бұрын
If we go into complex numbers territory, then we should also add GA rotors.
@EdwinMartin7 ай бұрын
It has BigInt, though 🙂
@MelroyvandenBerg7 ай бұрын
@@EdwinMartin BigInt != BigDecimal
@EdwinMartin7 ай бұрын
@@MelroyvandenBerg Klopt
@TehPwnerer7 ай бұрын
I had to implement my own Decimal type for counting money which is perfectly discrete to the cent
@benheidemann38367 ай бұрын
Wow… “Once again Firefox is holding back the internet” is a really bad take. Firstly, they have a much smaller team than any of the other browsers. And secondly, the “once again” part is totally unfair. Safari is just as bad if not worse, and chrome isn’t perfect either. Specifically in this case, the behaviour can be and is polyfilled so they’re not holding back shit.
@Darkstar1597 ай бұрын
What does polyfilled mean?
@ark_knight7 ай бұрын
@@Darkstar159 A third party library/your own custom implementation that fills the missing feature.
@rand0mtv6607 ай бұрын
As I've mentioned in one other comment, I personally had way more issues supporting Safari (especially on iOS) rather than Firefox. But Safari team is definitely stepping things up, I think in the last 1-2 years they invested significantly more effort into Safari and implementing the spec. Only downside is that Safari is still tied to OS updates and not independent so people that don't want to update the OS also don't get latest Safari.
@AvanaVana7 ай бұрын
Agreed, safari can be awful.
@reidond7 ай бұрын
Safari has soo much bugs we have to mitigate on my work...
@Youssef-zy8hk7 ай бұрын
date time functions are what im crazy hyped for
@NithinJune7 ай бұрын
9:50 0.3 isn’t even a valid floating point number. The closest is like 0.300000011920928955078125
@echobucket7 ай бұрын
One of the best things about match is that it will hopefully be an expression. which if statements and switch statements are not.
@ljharb7 ай бұрын
i'm sure you've just overlooked that i'm eminently reachable, if you want to talk about tc39 proposals :-p
@BenjaminSolum7 ай бұрын
I still reach for `reduce` for filter / mapping to skip a loop. Did everyone move over to `flatMap` instead?
@thomassynths7 ай бұрын
No one did. People moved back to loops because they are simple to write, simple to edit, easy to get performance, often easier to debug, and everyone knows what a for-loop is regardless of background and skill.
@McFrax27 күн бұрын
@@thomassynths Not everywhere, though. Reduce is still dominating in my team's codebase, and I hate it 😢 Though given our requirements of empty lines before and after block statements the solution with for loop is arguably worse, because you need at least 6 lines - accumulator declaration, space, 3 lines of for loop, space, 1 line to actually use the result - that's often twice the space needed for reduce.
@Exilum7 ай бұрын
21:20 I mean, it's really not an implementation issue, it's just how iterators as objects work. In our case, it seems like the source iterator mutates when using take. It wouldn't be take if it allowed going beyond the set limit. On the other hand, if the iterator didn't mutate, a new take would start again from 0. So no matter what "version" of take you do, none could support that behavior. I do agree it would be nice to have a method that returns a number of values *and* mutates, but the implementation would need to be a single call returning an array, rather than a method returning a new iterator. In the end, it's a bit too specific to be part of the base language.
@piaIy7 ай бұрын
I've read your comment a few times and I'm still not sure what you mean exactly. Regarding the closing of the underlying iterator when take() is exhausted, it's not an obligatory side effect of the iterator protocol but a deliberate choice by the authors of the proposal to avoid memory leaks. Iterators may have resources that must be freed, but they can't until the iterator completes. Let's say you've got an iterator that reads a file line by line. First, it opens the file, then it yields a new line after each next() call until it finishes, then it closes the file. If the file is 20 lines long but you only take 10, the file would never be closed if take() didn't call return() on the original iterator.
@Exilum7 ай бұрын
@@piaIy If take built an iterator that passed the done flag at index i, yet could continue after said flag, it wouldn't be an iterator. It'd be some sort of zombie hybrid type gluing two iterators together. The best way to insist on having that implementation would be to have an additional exhausted flag or an exhausted method. The done flag does not just indicate the end of the iterator, but also the exhaustion of said iterator. An exhausted iterator should be thrown away, and going against it would mean that every library developer would have to deal with the possibility of a second iterator hiding behind the first, either ignore it (no code change, but an unsupported feature) or handle it (code changes everywhere).
@piaIy7 ай бұрын
@@Exilum these methods create a new proxy iterator that delegates the calls to the inner iterator, but it also has its own state. If you have an infinite iterator named _x_ and you define _y = x.take(1)_, it won't mutate x right away, you can still call x.next() as many times as you want to get the next value. Only when you call y.next() for the 1st time will it mutate x and jump to the next value, and when you call it again, both will be done, including x. But this last behavior is an implementation detail for extra safety, you could still write your own take(innerIterator, limit) generator that would yield the value of innerIterator.next() in a loop up to the limit, then return without closing the inner iterator. Your take generator wouldn't yield any new value, it would be exhausted without affecting the other, but then you would be responsible for cleanup (you could call innerIterator.return() to accomplish this). It's even possible to get around the cleanup behavior of the built-in take(); you can wrap the yield statement in a try-finally block and change the control flow, like using continue in a loop, but this has its own drawbacks, like making it trickier to intentionally close the iterator with return().
@BrankoDimitrijevic0217 ай бұрын
Welcome to 2007, dear JavaScript! 🙂 Best Regards, LINQ
@RealRatchet7 ай бұрын
Majority of games engines don't need precise floating point math and would be negatively impacted by it because fadd is an instruction on the cpu assuming zero overhead from V8. Only games that come to mind could use something like that is KSP and Minecraft but there are cheaper workarounds neither of which are in JS. This would be more useful for currency but who even uses floats for currency. Also simulations but noone is writing simulations in JS either.
@JacobSantosDev7 ай бұрын
All numbers in JS are floats.
@jonaskohl137 ай бұрын
Babe, wake up, LINQ for JS just dropped
@mrkostya0087 ай бұрын
Looks more like Java's stream api
@nepalxplorer7 ай бұрын
it's funny to see js becoming c#
@asdfghyter7 ай бұрын
@@mrkostya008 they’re all just specialized monads in the end, so same thing different name
7 ай бұрын
@@mrkostya008 It's LINQ. Plain as day.
@zumalifeguard34937 ай бұрын
If he this excited to see literally LINQ from C#... it's 2024. LINQ was there in 2007, and it borrowed from Haskell. But never mind. If this guy actually saw what LINQ to SQL does. I don't think he'll understand it at first. And then he'll have a "holy shit!" moment six months later. We won't get into building LINQ expression trees
@awesomekalin557 ай бұрын
More things directly in ECMAScript is so good. Simplifies the ecosystem
@FryGuy10137 ай бұрын
this iterator stuff is all the stuff i miss in ts when coming from c#. although `skip` seems to be called `drop` for some reason. now just to have a built-in `iterator.range` method
@LarsLinde7 ай бұрын
JS turning into C# 😀
@phil-l-tech7 ай бұрын
Tbh I’m just waiting on full type / ts support
@aresstavropoulos9164 ай бұрын
@@phil-l-tech i mean, how would you compile down code that lives on a server at runtime?
@phil-l-tech4 ай бұрын
@@aresstavropoulos916 if JS becomes TypeScript, then JS engines will just parse and execute TS directly
@aresstavropoulos9164 ай бұрын
@@phil-l-tech okay but why? we'll have slower runtimes, and why would you want to test in the browser when you have compilations and LSPs?
@EngineerNick7 ай бұрын
I like Firefox man. How the flipped pancakes did Set get in js without those set functions at the same time. Also where are the iterator functions `pairwise`, `chunks` or `windows` :(
@chiebidoluchinaemerem58607 ай бұрын
I think they should make the interaction with shadow realm use promises. If possible, they could use one free thread to run any potentially lengthy code and post the result back to the main thread.
@babakfp7 ай бұрын
Dude, Firefox also have features implemented a long time ago which you need to wait for other browsers to support it!
@DavidMulderOne7 ай бұрын
What's the advantage of ShadowRealm over Web Workers? Web Workers (when properly configured) allow for fully sandboxed code execution, although I acknowledge that ShadowRealm makes it easier to intentionally write it as single threaded code, but it doesn't sound like it would allow for new applications, just makes it easier to write certain things.
@Exilum7 ай бұрын
It might not be a perfect take, but I have several guesses: 1) AFAIK, workers require an event listener or a broadcast channel, this might make it harder to get a type safe implementation with typescript (without a library to abstract it or some type magic) 2) I'm not certain about the efficiency of instantiating web workers. A quick google search got me 40ms, it's probably inaccurate, but it sounds about right. What we want from web workers isn't fast instantiation. In the case of the shadowrealm, you'd expect a realm to be fast to initialize and throw away. 3) Web workers don't exactly have the same environment as regular js land. You might want your "unknown" isolated code in the shadowrealm to be able to access every single JS API while isolated. Workers are known to be workers at dev time, we don't expect realm code to know it's in a realm and still run just fine. 4) Going back to efficiency, because the shadowrealm does not serialize or deserialize, it's also that much faster. It still uses the heap instead of reserving its own memory. In that sense, it's weaker isolation, but it fulfills its purpose.
@TurtleKwitty7 ай бұрын
The api is very different, workers need explicit communication back to the main thread but the realm stuff is just calling a function so theres no 'contract' the code in isolated realm needs to uphold
@DavidMulderOne7 ай бұрын
@@TurtleKwitty Yeah, it's single threaded and the API is quite different. I was mostly responding to his comment that it would allow for new stuff. As far as I can tell you could polyfill ShadowRealm's API fully with web workers (it just would be multi threaded)
@DarylMetzler7 ай бұрын
One thing with the floating sum logic is that it will _add_ precision, not remove it. So if you have something like `sum([FLOAT_MAX , 1.0, -FLOAT_MAX, 2.0])` youd expect sum to give (not quite) 3.0. But a reduce (in array order) will drop precision a bunch and give you something like 2.0 instead
@Leonhart_937 ай бұрын
The thing with the Signals is that adding them to the spec is largely irrelevant for those that know about them. If you want to use them you can always include right now the current implementation code.
@keithjohnson65107 ай бұрын
The main driving force for adding Signals is so that we get more library integration, eg. You could create a Signal in React and use in Vue. etc. It's a bit like Promise, can you image if every lib implemented it's own variant, they would be way less useful. Now lets assume you wanted to create a Widget that worked on all frameworks, Vue / React etc, if you made the component say using direct DOM methods, your component would now work with any framework with very minimal effort.
@simonhartley91587 ай бұрын
A library could offer a native Signals build where they replace their own implementation with a thin wrapper around native Signals. The resulting library could then be smaller and potentially more performant.
@pairofrooks7 ай бұрын
Ah yes, just like we all write native web components to work with all those other frameworks we don't use
@keithjohnson65107 ай бұрын
@@pairofrooks It's true Web components have not really taken off, I think the main reason is if say your using React, you will create a React component, and because State is pretty unique to React, say compared to SolidJS, your kind of tied in. But lets say you wanted to move to SolidJS, you could transition the State to use Signals, and maybe even convert some bits to WebComponents, moving to SolidJs is now much simpler. Regardless, having extra features baked into the browser like this is surely a good thing, not sure why anyone would grumble about it.
@MarsAnonymous7 ай бұрын
Ah, filter/map/reduce for iterators. JavaScript finally gets Java's Stream methods, with all the performance-enhancing benefits it brings.
@proosee7 ай бұрын
You mean Java *finally* got it in 2014 after C# introduced LINQ in 2007?
@keithjohnson65107 ай бұрын
It was pretty trivial to create map function for iterators already, these extensions just make it a little bit easier and more natural. eg. a map iterator function -> function *map(i, fn) { for (const a of i) yield fn(a); }
@asdfghyter7 ай бұрын
@@proosee oh, you mean the stuff that Haskell has had out the box since at least Haskell98 and most likely even Haskell 1.0 from 1990? (which is before Java and C# existed)
@proosee7 ай бұрын
@@asdfghyter yes, but well, don't judge me if I don't count Haskell as mainstream, widely used, well supported language. Maybe when Haskell earn some decent package manager after existing for over 30 years then I will reconsider.
@asdfghyter7 ай бұрын
@@proosee sure, it isn't mainstream and it certainly wasn't back then, but that's kind of the point. mainstream langagues are very slow to adopt good features from more academic languages like Haskell. And as I said, it existed even before someone had considered making either of the languages, so they don't have the excuse of it being something new
@vainoleppanen89717 ай бұрын
2:50 "Defer" is one of my favorite features of Go so I'd like to see "using" implemented because such block scoped execution of code is really useful. Of course in many languages blocks are defined merely with braces so the closing block isn't necessarily defined by a function or a method but it usually is.
@MrManafon7 ай бұрын
insta-watched, just to see if pattern matching and pattern matching overloads have been mentioned 😢
@Caldaron7 ай бұрын
js slowly morphing into c#^^
@mosescosme86297 ай бұрын
Those were all super cool. I love the iterators, but I'm most excited for Temporal.
@TesterAnimal17 ай бұрын
Me too. In my job we slice and dice and compare and add time, dates and durations. We have a lot of legacy horror that is going to be dumped.
@gabynevada7 ай бұрын
I started using the temporal polyfill for now and it's great. Only downside is converting back to regular dates when interfacing with other libraries
@anon_92217 ай бұрын
0.1 + 0.2 !== 0.3 is not a precision issue in the summation, it is an untrue statement if 0.1, 0.2 and 0.3 are meant to be the closest double precision base 2 approximations of the respective decimal numbers. Also, Math.sumPrecise(...) will never yield a different result than simple addition for just two numbers, since the addition of two numbers is already required to produce the correctly rounded result. A better demonstration would be Math.sumPrecise([1, 1e-20, -1]) === 1e-20 instead of (1+1e-20)-1 === 0. 0.1 in the source code is defined as the closest double precision approximation, which is 1.10011... * 2^-4 (repeating 0011 patterns in the ... for a total of 53 digits). Closest double precision number to 0.2 is the same, except the exponent is -3 instead of -4. Adding those two exactly yields 1.0011...00111*2^-2, the last 1 is one digit too many for double precision and since default rounding is to even, we round up to get 1.0011...0100*2^-2, roughly 0.3000000000000000444 (~4.44e-17 away from 0.3), which is the correct closest double approximation of the exact sum of the closest double approximations of 0.1 and 0.2 but it is not the closest double approximation of 0.3, which is roughly 0.2999999999999999889 (~1.11e-17 away from 0.3). There is no way to make tests like base2ApproximationOf(0.1) + base2ApproximationOf(0.2) === base2ApproximationOf(0.3) reliably true with binary floating point semantics, regardless of the number of digits because it is fundamentally untrue. And changing the implicit meaning of 0.1 away from base 2 float to some decimal type would be a severe performance hit for all numerics in JS and definitely break things that use binary floating-point in an intentional way .
@wafflesredditreader7 ай бұрын
The iterator proposal is years old. Take has been around for a while, same for foreach, map, etc
@TimwiTerby7 ай бұрын
C# has had those iterator functions since 2007, and its implementation of them is a million times better. JS is so far behind it boggles the mind. Even after this proposal you still can’t run .map/.filter on document.querySelectorAll. You still have to jump through a hoop (.values()) to get .map/.filter on arrays to be lazy. Etc.etc.etc.
@alanscodelog7 ай бұрын
I can't wait for realms. Just a small correction. You can isolate and communicate with an but it's very complicated, requires understanding CSP and the worst part is its async comms only. Realms would be like a safe evaluate although you still have to be very careful not to shoot yourself in the foot. Am currently trying to create a safe plugin system for a project and I'm using s + the realms shim. The is for extra security against flaws in the shim + dom access + control over network access using csp rules. Lots of hacks were involved to get things working.
@ray738647 ай бұрын
It's funny, because in some other languages, 'using' is often called 'with', the idea being that once the 'with' block has finished, it auto-cleans up. About time JS gets something like that.
@Pptruenoz7 ай бұрын
Temporal has been stage 3 for so long I can't even remember anymore
@unterdemasphalt7 ай бұрын
When you have to work with money values, you better correctly sum those floats!
@hoaxygen7 ай бұрын
Or just work with integers? 1 int = $0.01
@unterdemasphalt7 ай бұрын
@@hoaxygen The problem in my case back when was vendor data being all floats for whatever reason
@pqnet847 ай бұрын
chaining on iterables will consume completely the previous iterable because that's the only thing that can be relied on, otherwise side effects would be surprising. I wouldn't be surprised if after n.take(5) the state in n is completed already, even without iterating the n.take() result with toArray
@codeChuck7 ай бұрын
I totally ♥the consistency of how `JS is being JS` even after some fancy math optimization propasals :)
@Z4KIUS7 ай бұрын
Gecko may be a bit slower to implement things that Google invented, but it's Chromium that has terrible user experience, missing the most basic features sure, Quantum isn't as good as Firefox was, but it's the pressure to compete in benchmarks and implement all the craziest ideas that forced them to give up most of the power and yet Quantum still offers much more than Chromium, The Unusable
@ark_knight7 ай бұрын
What is Quantum here? The Firefox redesign you mean? And why do you think Chromium has terrible UX? I think Chrome browsers in general have bad devtool experience (atleast the looking part) but from a user perspective, i think its fine.
@Z4KIUS7 ай бұрын
@@ark_knight Quantum is the browser that replaced Firefox, different goals and priorities, but the legacy components can still be used to bring back most of the power Firefox had Chromium has a terrible extensions API (true, WebExtensions are based on that and most of the issues persist, but at least uBO works as expected), you can't configure your toolbar as needed, you can't remove close tab buttons that only bring despair when the browser isn't able to fully restore the state of just closed tab, no way to get mouse gestures to actually work unless implemented natively (WebExtensions force the use of ContentScripts, and these only work within the viewport, need to be injected into AL frames, and can't be injected into some classes of pages leading to inconsistent flow), the long lasting text rendering issue finally got partially patched in upstream, I think over a year after MS prepared the patch, but image scaling issue persists and don't get me started on mobile...
@guillermogutierrez7107 ай бұрын
Wow, JS is starting to look like C#.
@TreeLuvBurdpu7 ай бұрын
I've been away from JS for a year or two, in C-land and Python 3D modeling. Now, converting my Hugo static sites from JS to TS (which is so easy). Good to see so much new goodness coming to JS.
@Zullfix7 ай бұрын
Enforcement of using seems terrible. There have been many times in C# where I have wanted to deliberately not dispose a resource at the end of a statement, and enforcing using would mean needing to spawn a thread that sleeps infinitely just to get around that. Language designers should not encourage harmful patterns just because a small subset of developers make dumb mistakes.
@chrismckelt7 ай бұрын
implement IDisposable interface perhaps?
@kisaragi-hiu7 ай бұрын
The proposal only adds a mechanism of enforcement, and whether a Disposable requires `using` or not is dependent on the library defining the Disposable. Language designers are not enforcing `using` in general; it is opt-in (for libraries). > Were such enforcement to be mandatory, these hosts [Node, DOM, Electron etc. who provide disposables] would need to implement and maintain a completely parallel set of APIs purely to support using. As a result, we are proposing this as a purely opt-in mechanism that could be leveraged by new APIs that need stronger enforcement guarantees. And it's also still stage 1 anyways. If it still doesn't sound like a good idea, now's the time to strike it down.
@neociber247 ай бұрын
Disagree, this is how memory leaks happen. The language should prevent the programmer do be able to do dumb things like never dispose resources, but also provide interfaces when you want more control.
@Zullfix7 ай бұрын
@@kisaragi-hiu I understand that it is an optional and separate from the primary Disposable of the proposal, however the fact that it exists is a problem, as inexperienced or close-minded developers won't see the difference between the APIs or will not be open to changing a forced API to a non-forced API.
@Zullfix7 ай бұрын
@@neociber24 At the moment, it is easier than ever to not dispose resources, and `using` will only make it harder. That doesn't mean you should make it 100% impossible to manage disposables because of a few clueless developers. Having a forced `using` disposable is as dumb as the leniency of ==, and if it gets through there will probably be a feature added in the future that allows you to bypass the forced `using` just like ===. Let's imagine that you have an API that returns a `binaryStream` that can be read from and written to. In this hypothetical, the stream only accepts bytes on its `write` methods and implements forced disposable. Now, you have decided that you need to write some strings to the stream, however manually converting to bytes is a little tedious. The solution is to create a `binaryStreamWriter` object that takes ownership of the stream and exposes both byte and string `write` methods. Now realize that the existence of the `binaryStreamWriter` object is impossible because of forced disposal. Forced disposal does not allow for transferring of ownership because it will always be disposed by the scope it was declared in via the `using` keyword. Even if you were to fetch the `binaryStream` within the writer, you still would not be able to store it as a property of the writer because it would be disposed by the scope of the writer's factory method. The only true way around it is to use a separate thread that never exits the factory method due to a `while (true)`, and that is arguably way more harmful than forgetting to (or not knowing to) dispose resources. So I ask again, why would you hurt experienced developers just because of a small subset of clueless developers who do not know how to use a language.
@marty06787 ай бұрын
You can communicate somewhat with an iFrame using the postMessage method. It's a pain but we've done stuff like drag and drop content between iFrames and the parent and send data back and forth.
@beowulf_of_wall_st7 ай бұрын
Iterator helpers are a tease for algebraic data types, which would be immense for js
@ShaharHarshuv7 ай бұрын
The Iterators methods are amazing! I have a use case in our app which I think would really benefit from this.
@pqnet847 ай бұрын
Another usecase for ShadowRealm is to execute the proxy autoconfiguration file (PAC) when doing an http request without giving the network admins the ability to run arbitrary code in your machine.
@TreeLuvBurdpu7 ай бұрын
I remember dealing with dates difficulties in the 80s and thinking "how is this not already done?". Strings too. And CSVs.
@Darkstar1597 ай бұрын
Answering your question at the end of the video - I would like to see focus on the parts which are not already seen in other common languages. Stuff like iterators, set functions, lazy generators are all common things. I would like to see more about things like those shadow realms
@anon_y_mousse7 ай бұрын
I'm more than a little curious if JavaScript can be used to implement a custom floating point interpretation. I've partially implemented the operations in C, + - * /, and I can't imagine that it would even be possible in JavaScript without the ability to do a reinterpreting cast on the bit patterns. The thing I keep thinking about with all of these additions they keep coming up with is that we're going backwards in terms of functionality. We should be aiming to speed things up and all of these functional design patterns just slow us down and make the code more difficult to read. It feels like every advancement in computing power we've gotten has come with a devolvement in software which erases all of the advancement.
@KevinVinck7 ай бұрын
Would definitely like a video on the history of dates in JS. When I first started writing JS the lack of something built in like Python’s DateTime was something I found kind of baffling.
@von_nobody7 ай бұрын
3:33 Technically C++ is here too, but "cleanup" is integrated into object lifetime itself by destructors
@nage74477 ай бұрын
9:50 not earlier than we will store floats differently in memory
@KangoV7 ай бұрын
I'm not a JS dev, but for some reason, I thought it already had this stuff. Mind blown.
@Dorff_Meister7 ай бұрын
LOL welcome to Groovy 15 years ago. But honestly, many of these features are kind of great. I use to just hate Javascript, but now I'm a Nextjs/Typescript dev and I am enjoying the language.
@ShaharHarshuv7 ай бұрын
20:20 now you just need the "naturals" function built-in
@BroodWar4Ever7 ай бұрын
I don’t use reduce often but I recently found myself using it to traverse a tree like structure. While writing this I realize the final code I ended up with doesn’t need the reduce. Im going to rewrite
@penguindrummaster3 ай бұрын
In your question about using Array.prototype.reduce, I like to use it for converting object A to type B. For example, if I have an array of things (say, Selenium WebElements) and I want to make a dictionary out of them, I would say elements = awai driver.findElements(...); keys = await Promise.all(elements.map(WebElement.prototype.getText)); dict = elements.reduce((map, element, index) => map.set(keys[index], element), new Map());
@eduardozepeda19727 ай бұрын
- So all I had to do was to imitate what Python has been doing so far! - Congratulations Shinj... Javascript you figured it out! 👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏
@jesperstaunhansen71907 ай бұрын
Linq coming to javascript?
@dagadbm7 ай бұрын
you can also use switch true statements instead of match. its a very cool trick
@AvanaVana7 ай бұрын
8:15 “0.5? I cant recall”…I see what you did there…
@MelroyvandenBerg7 ай бұрын
Only we understand.
@PGDJ886 ай бұрын
For personal reasons the set stuff. For current business reasons I would love shadow realm!
@TreeLuvBurdpu7 ай бұрын
I like seeing more and more C#/F# showing up in JS.
@zwanz0r7 ай бұрын
I didn't have time to dive into Temporal yet, because I've not allowed time when creating my schedule and that isn't mutable
@KangoV7 ай бұрын
I'd like you to do a comparison of JS Iterators and Java Streams and Gatherers (JEP-461). As a Java dev it's sometime hard to get my head around JS.
@MikeDSutton7 ай бұрын
It's great that the new Set composition methods also accept Set-like operands, e.g: `new Set([1, 2, 3]).union(new Map([[3,"3"],[4,"4"]]))` => `Set{1,2,3,4}`
@m4rt_7 ай бұрын
I'm used to using being something to include a scope into your scope. For example: Foo :: struct { a : int; } main :: () { foo : Foo; foo.a = 1; using foo; a += 1; } So seeing it more like an abstraction of defer is weird.
@devpitch6 ай бұрын
Awesome analysis! I am not a big fan of JS on the server possibly due to my background being data centric, but on client side these are cool toys. Date handling is a clear win. Any effort to move Typescript into JS is mostly a good idea. Unfortunately, they said type safety and true OOP cannot be possibly added to JS. Not sure why.
@Metruzanca7 ай бұрын
I actually wrote my own decimal implementation so that I could have accurate sums. Then I decided to find a package for it instead. I was building a spreadsheet :)
@victorob7 ай бұрын
This ShadowRealm proposal is the thing that Figma want(ed) to run 3rd party plugins within Figma or am I tripping?
@LittleEragon20037 ай бұрын
Iterators are dope, for me it's the ability of doing .map().filter().map() (or similar) without worrying about the performance
@dazraf7 ай бұрын
Really funny to see features give been using in so many other langs. These new updates will be good though for those langs - effectively compile to the native op. Also, floating point additions will never be resolve the problem of 0.1 + 0.2 because of IEEE754. You have to use high/infinite precision.
@TranCanada7 ай бұрын
Old school game engine I wrote had a custom float adder but everything was custom back then when the first Voodoo cards hit.
@ThugLifeModafocah7 ай бұрын
pattern matching is only good if you can have it in function signatures like in Elixir. If not, it is just another way to do if (like the switch/case too).
@CadisDiEtrama0007 ай бұрын
Did you hear about/try Effect? They plan to add some of these features themselves... But in general, wanna hear you thoughts on it.
@clementj25887 ай бұрын
floats are evil anyway, just use ints by multiplying by how much precision you need, and then format for display
@hacktor_927 ай бұрын
9:45 - that's why in php we have `serialize_precision` defaulting to `-1`, just to have it "working" for JS `JSON.parse`
@brunoais4 ай бұрын
38:00: I just hope this doesn't make things much worse to webextensions or to userscripts to hide and make it impossible for userscripts to modify code, for example.
@J1Jordy7 ай бұрын
Seeing people hyped over lazily evaluated generator mapping/filter/etc that's been out in other languages for so so long honestly feels like a "welcome to 2024" moment
@sofia.eris.bauhaus7 ай бұрын
i want Records and Tuples so bad 😭.
@rafaeldeleon33867 ай бұрын
I've been waiting for Record and Tuple for 5 years. This would help with doing primitive equality on object and array like structures without relying on external isEqual function check.
@Steeeved7 ай бұрын
Good god Temporal looks SO much better than Datetime. I remember years back making an attempt at a silly little webgame and I wanted to make a custom time progression for it, based around a 7 hour day. Dear god that was pain.
@jly_dev6 ай бұрын
I use Set difference & intersection in Python on a daily basis -- this is dope
@daveism17 ай бұрын
What browser do you use, Theo?
@thegrumpydeveloper7 ай бұрын
Nice! 🎉 It’s about time for temporal.
@ray738647 ай бұрын
I use reduce quite a bit, but I don't use JS frameworks, so my JSON returns arrays, and now I need reduce to sum shit up!
@br3nto7 ай бұрын
19:46 I’m half way through. I hope there’s a proposal for extension methods!
@user-hk3ej4hk7m7 ай бұрын
JS is looking more and more like python but with braces
@dhkatz_7 ай бұрын
The "using" feature is nice. It's funny to see garbage collected languages all eventually implement something like this because they realize "oops object lifetimes actually matter!". Python got this through the "with", Java got this through "try", C# got this through "using". EDIT: Ok watching further it's funny the proposal used the same exact examples I did 😅😅 Meanwhile the more "complicated" language C++ has a much simpler memory model of RAII, and has constructors + destructors.
@ShaneGoodson6 ай бұрын
I use reduce a lot for several operations in a single array iteration
@DanielNistrean7 ай бұрын
'using' is straight from C# not Python.
@valseedian7 ай бұрын
using is a c++ thing... not exactly the same thing here, but close.
@DanielNistrean7 ай бұрын
@@valseedian Oh, thanks for educating me!
@grcodemonkey7 ай бұрын
The implementation is definitely mimicking the C# Disposable pattern. The `using` and `await using` keywords along with `dispose` and `disposeAsync` are directly analogous to the C# implementation. The Microsoft funnel of C# to TypeScript to JS continues.
@ciberman6 ай бұрын
JavaScript is turning into C# and I'm all in for it! :D
@tinrab7 ай бұрын
Iterators and pattern matching are clearly inspired by Rust, and that's great.
@elagrion7 ай бұрын
js: yeah, so we invented Sets, data structure known to men since Ancient Greeks, and available in almost every other programming language.
@joter-glem7 ай бұрын
In the future instead of writing code a programmer will investigate a huge amount of api to find an exited implementation for his problem. I found out that for many things is better to think twice and write yourself.
@jly_dev6 ай бұрын
JS lacking a clean distinction between int/float has caused me so many headaches