re "how would it work with const": if it's limited to blocks and goto is limited to going only to one of the parent block labels then it can work function what() { blockx { const x=a ... repeat blockx // or // break blockx ... } }
HashBang is not interpreted by bash, but by OS. This is common misconception. Any script that is executable gets run directly by OS and it is OS that sees #! and knows to use the interpreter that is stated between #! and , like #!/bin/bash . The proposition is that it should be ignored by Javascript runtimes like node or browser. Use-case is if it is a CLI javascript program and you want to run it in a browser and not immediately cause an error (invalid unexpected token error)
@@hentaihero2201 that is true. Non-Linux (or Unix) OS-es need the interpreter to do it. In Linux it's the OS is the one doing that, which to be honest, surprised me when I first heard about it.
WeakMap frees a value when/after key is freed its useful if you wanna attach some data to an object but dont wanna add it to the object itself with a weird prefix like __ one simple example is you know when people add some extra data to HTMLElement(s) or Node(s) and they add a prefix like $ or __ or ___ etc. with WeakMap you dont have to actually modify the object for adding extra data.
Might be outdated but, at some point, the JIT generated compiled code based on the shape of the object being fed to a function. iving new field to an object would change the shape of an object and lead to deoptimisation. That said, JIT are constantly evolving (try catch used to be bad) so always profile I guess.
Yes, in JS, as keys are added to objects, it makes like hidden classes underneath that handle that shape. So more and more of this is more hodden classes and more cost to move through them. Ideally you want the same shaped objects to always be made the same way and in full
idk how v8 really handles them but i image values on WeakMaps similar to symbols but without no way of accessing them nowhere else except through the WeakMap
The most consistent tech youtuber even tho i dont understand 99% of what you guys are talking about (since im a newbie) i still enjoy being here (to some degree)
@@vczoika full-stack web development, many say don't go this way but for me it might be the only way I could get a job. I will Learn html css and js obviously and maybe python and rust and later some C for libraries and framework I'll learn the mern stack and maybe svelte as well since a lot of developers are migrating to it
The reason for the shebang importance is interopability outside. # is not a valid comment in javascript. however #! is needed when executing things in posix to determine what to run it with. by making it accepted by the language, javascript will not throw a syntax error when it encounters it. this would allow you to both execute it directly with a shebang or indirectly by passing it into node.
First thing I thought when he was rambling on about it, the clue was also on the second snippet... `export`.. implying this JS file can be imported & executed. The only thing I can think is that he thought # was a comment..
Regarding the shebang, all your shell does is invoke the rest of the line as a command, passing the current file path. It's not reading the rest of the file and feeding it as stdin, so it can't remove the first line.
@@amrojjeh With usual shells it's not necessary, because # defines comments. In node # is not a comment and it would cause a syntax error. The reason this currently works is that node knows about shebangs and ignores it, the proposal wants to make this official and integrate it into the javascript engine, so no matter whether you're using node, deno or whatever else, they don't need to know about the shebang to ignore it
@@LorenzoLeonardini Ahh gotcha. I forgot that Javascript comments don't start with hashes since my mind partially drifted into Python land. I must admit though that I found that portion of the article funny because they were seriously saying that'll complete JS as a server-side language "because other languages have it."
i maintain the unfounded theory that hidetaka miyazaki got the inspiration for his poison swamps and decaying cathedrals from working at oracle before joining from software.
The shebang proposal is just "ignore the shebang line" because in JS, # is not a comment prefix like // is. Node already does this, now it's standardized across JS.
14:42 no, it's handled by kernel interpreter needs to ignore (hash|she)bang because it's not supposed to be code in languages like python, bash you get ignoring for free because it looks like comment for interpreter example (`./deez`): ``` #!/usr/bin/echo welcome to most useless interpreter (don't even read the script)! ``` you run that as executable (`./deez`) kernel sees that there is (hash|she)bang and runs `/usr/bin/echo ./deez` instead echo echoes `./deez` it's now up to interpreter to do something with `./deez` argument (usually it's opening file with that path and reading it)
If you pass a file with shebang into a js engine the engine will bomb because it isn't a valid js file. Currently node executes and strips the shebang and passes it to js engine. This allows the js engine to accept the file as is with the shebang and ignore it. So that node/etc don't have strip it pass a valid js file to engine.
I am baffled when people say "web assembly is not intended to replace JavaScript". Are you friggen kidding me? From transpiling everything into bizzare mangled JavaScript to being shackled to the TC39 working group - why wouldn't we want an efficient executable binary format that web browsers could run rather than JavaScript? It's not like browsers will stop supporting JS - they will just also be able to run amazing efficient safe multithreaded Rust code compiled to target the browser.
17:32 That's not what it's about. It's so you can run `./filename.js` and the shell will open it using node, even though you didn't put `node` before the command. Same way how you can but #!/bin/bash and running ./scriptname(.)sh will automatically run it in bash... The Node interpreter only strips it out before sending it to the JS engine because it HAS to. It's not doing any of the "deciding what program to use" stuff. It's been picked by the shell to run your code, but it can't yet, because keeping that line would cause a JS syntax error since #! isn't part of JS syntax. It has to detect that line so it can be removed and make sure your code works, NOT because it's actually doing anything with the information. I just don't know why people do that instead of running it via `node filename.js`
Hashbangs are NOT "stripped", all that happens (this is done by the kernel, actually) is that the hashbang contents are prepended to the original command and then that is executed. Node still has to read it, discard the first line if it's a hashbang and then give it to v8 (as v8 does NOT understand hashbangs, they are not valid JavaScript after all). No "valid" JS parser library has to support hashbangs even though any file can contain it. Node has to require/import files with hashbangs, ESLint/Prettier/whatever has to fix/lint/format it, etc. With this change parsers WILL have to support it and we can reduce all the duplicated processing in every "real world" JS tooling that may ever see nodejs code.
27:49 Plot twist: yesterday I listened to a lecture by a biblical scholar (who reads some cuneiform BTW) and it turns out that the biblical Babel Tower is almost literally named Babilon (kind of pars pro toto) and semantically the names are the same. The origin of biblical story is probably the experience of desert dwelling Jews seeing a 300 ft high, almost cube structure which was unimaginable in size but albo "weird because built out of bricks instead of stone" and making an anthropological sense and spiritual meaning out of its city and multi-language and highly urbanized construction site. The historical building was the E-temenanki ('E' being a word for a temple) ziggurat consisting of multiple platforms and temples for different deities to which the biblical authors attached the anti-dated mythical story.
42:04 the lock is for multi process parallelisem, so 2 node process can share a buffer (basically a memory mapped file but without a file) This is already possible. Its not the unix way of doing multi processing. But it is the fastest way
You need to do immutable updates when you're dealing with any library that does identity based updates, most well known being React, but i believe Solid and most other UI based libraries will do that. Searching from the end seems to be obviously for when there may be multiple matches and order matters.
I find decorators in python pretty amazing to apply to my scheduled scripts, i can just put my entire main function for each procedure through an error logging decorator and have any failures logged to a database. I'm not sure what a similar use case would be in Javascript since you're running it locally in much rarer cases, but they have their place
I also think they're sik. They handle tangential stuff to the main function logic. Logging, profiling, setting permissions. It just clutters the function if you have to include all these things inside the function. They're not part of it. I can see that they could be abused if you start wrapping logic in them that could make debugging hard. But I've literally never had a decorator issue when debugging.
immutability is not practical outside of functional contexts and academia. And any time anyone ever says "maybe things should be more efficient" the response from tons of JS devs is always 'nah modern computers can handle it, and memory is infinite' as if we should waste cpu cycles and memory on their inability to manage memory and state. 'if a program runs 2000 times slower it's still comparatively O(n)' type mindset
23:10 To be fair, C# has great iterators too, the problem is that they're not very optimizable in general (you can do some tricks here and there but after you start chaining them it becomes hard).
Every interpreted language have performace problems with iterators, because the JIT does not have enough time to optimize it, it needs to have a fast startup time. Rust and C++ can have zero overhead iterators, because the compiler can optimize those to normal for loops, at the cost of having slow compile times. I have seen a video that showed that a naive iterator in Java and C# is about 8 or 9 times slower than a for loop, wich shows how much work LLVM needs to do in Rust.
It's a shuh-bang not a Hashbang btw. And Ruby has a great convention for sorting and returning a new array or sorting in place .sort and .sort! respectively. ! At the end of the function name indicating that the function modifies the object when called.
Agreed! I just said the same thing! Ruby isn’t super strict like Rust, but they do know the importance of knowing when things mutate. And I love that they did it via naming convention
I believe that the average JS-devs has very little clue what features are really needed. One of the ultimate goals is to improve performance for everyone, and I believe that only the framwork-devs behind frameworks like React/Svelte and the Browser-core-devs behind engines like Chromium really have a plan how to improve performance.
If we're talking about class decorator, then it's not inheritance but composition. It feels like inheritance because the decorator and the class being decorated both implement the same interface.
it's not that the shebang enables any new functionality, it just makes it NOT AN ERROR in an otherwise valid javascript file. before this spec change, having '#!' in your file is an error. (node ignores this, but that makes it a non-compliant javascript parser)
My understanding is that HashBang is for the Linux OS to be able to run nodejs by simply executing the file, like running any other scripting file like .sh scripts. So instead of running the command node with parameters of the file to run, the OS would do that for you so because nodejs will be configured with the OS on install.
I imagine any site encouraging people to use another language and providing training and education, would be requested to be taken down. The Jealous ex cant stand to see those people having fun with someone else.
So far I'm not a fan of the toReversed and toSorted because now instead of remembering that reverse and sort happen in-place you have to remember which way to type the function does which, and that's harder to remember and especially harder to review because there you generally don't have intellisense or whatever giving you useful tooltips.
IIRC, "babble vs bayble" is Bristish vs American (and also regional dialects). But in Hebrew and other languages from the region, it's usually "bah-vel".
The shebang is what is read by your shell, yes, but the entirety of the file content is also passed to your js engine, at which point shebang is not valid js. Node and deno both implement first line shebang technically out of ES spec, except now it's part of the spec officially. That's it, that's the point of that proposal
When you put shebang something, the Unix like os sees the file as executable and if you ./ eaxecute it whatever you have written after shebang will be used to run the code
They did debate decorators for over 5 years. And when the initial proposal was made, there was already existing experience with TS decorators and a couple of babel implementations. Hopefully TC39 cooked with something good for decorators in all that time.
Sort has bitten people who use immutable stores, such as Redux, maybe that's the problem to begin with? But yeah, two readers of the same list, one them sorts it, the other one is indirectly affected, and won't show the bug, until re-rendered. And yeah a simple slice does the trick.
Bro, I just inherited a legacy app with an oracle db and we can't even install a db on our dev machines, because oracle wants us to pay a license for that. I feel like I'm living in the 90s.
6:45 I kinda hate this because now we have to explain to everyone the difference between .sort() and .toSorted(). And 99% of the time no one is gonna use .toSorted(). We have enough bs like this in js already like .substr() vs .substring(). Is it too hard to just write .slice().sort() instead of .toSorted(). Actually just give us .clone() so the chain would read more like normal english. Kinda pointless and confusing. And if you care about the performance implications of not doing it in one go... why are you using immutables again??
12:34 omg somehow I hate this even more. who the hell is thinking about improving performance by starting the search from the end of the array instead of the beginning? that makes no sense. and if it starts making sense in your code I feel like you've done something terribly wrong...
Incidentally (and I'm sorry for spamming), ecmascript standard versions don't really matter, stage 3 is the real "you can start using these as they start getting added to compilers and engines, they won't change" and 4 is the "this is going to be in the next standard when the year comes around", so no reason to bother waiting.
As a TC-39 delegate, I can tell you that this is most definitely NOT true. Stage 3 proposals that are contentious will often see changes (sometimes drastic ones) once the first implementations came into use.
@@AnthonyBullard oh? I'm not aware of anything like that, happening, but I obviously you would know better! I based those statements on the proposal level descriptions and the typescript team's position on waiting for stage 3 before implementing.
Stage 3 is the point where engines should begin implementation. It is likely to be stable, but developers should not depend on that. If I remember correctly, decorators have been stage 3 more than once. Don't have time to pull up the other examples where it has happened(I'm also
I use WeakMap all the time, but I can't imagine what the use case is for symbols as keys. This sounds like "I can, therefore I will," without considering "should I?" Or perhaps I'm being blind and pigheaded, and these are the savior of mankind my job will depend on in the futre. We'll find out. This whole bit of "we're going to improve iterators and resource management but only for synchronous code" is beyond useless to me. I've been working with generic bare iterators rather than specific collection types for some time, but async iterators are the only environment in which this makes sense. With a large synchronous array, there is a real cost savings from working with an element at a time over multiple sterps rather than rolling a complete array to capture the results of each step. But this is laughably pitiful compared to processing indefinitely-sized and sporadically growing async iterators. If this only works for synchronous iterators, you still need the whole dataset available at the start, and while infinite synchronous iterators are theoretically possible, they're simply not feasible. Only your consuming process, and not your delivery process or any intermediate steps, could be async. It's not solving any real problems unless it works off of Symbol.asyncIterator, except perhaps to spur the economy of UA-cam tutorials in building useless JavaScript constructs. (It's embarrassing how many tutorials exist on building queues in JavaScript which are all synchronous and fulfill zero development needs, because if I actually needed a synchronous queue for some godforsaken reason, I'd .push() and .next() my way through an array.)
“New features in JavaScript? I really want pattern-matching in JavaScript. I also want that feature where you hold JavaScript under the water, and it wiggles, and then it stops wiggling. I want that feature in JavaScript” - ThePrimeagen
I love weakmaps. They r the best. p.ex you have some tree-state, w weakmaps u could attach functions to a node, so u can keep the data clean instead of passing in the functions in the data itself. It's almost like a form of encapsulation. You could have multiple weakmaps referring to the same node, with different functions. Like parallel worlds. I use it in a project rn as a caching mechanism as well. And you don't have to think about memory cleanup or anything.
Will WebAssembly basically make programming language selection for speed obsolete? For example if all programming languages compile to web assembly, and then web assembly is what is actually executed client/server side then won't it make which language you use more a personal preference issue "what you know" over the trade offs in speed and performance as all languages will become equally fast as everything will become web assembly in the end? Trying to make sense on what a web assembly future looks like...
Different language semantics will produce webassembly with different performance characteristics. Also language compilers aren't uniform in the sophistication of the optimizations applied.
The problem with the hashbang syntax is that bash/zsh etc. would interpret it, but not strip it from the file. So, without this proposal, it’s not valid JavaScript out of the box.
I don't get the complaint about decorators but the support for function-level rust macros and things of the like - it all feels like voodoo that is not transparent to the developer.
I pronounce it Babble because of the pun. It’s a system that takes meaningless gibberish and converts it to something interpretable (that said, I avoid that tool and webpack like the plague)
javascript doesn't need python-like decorators because javascript has inline functions: ``` var df=decor(function(){ alert(1) }) ``` python-like decorator would be: ``` @decor function df(){ alert(1) } ```
Decorators aren't for functions really, they are for class methods and fields as well as class declarations. That's where its proponents see the real value. They also use classes in JS
I hope chromium and other browsers are gonna use a new browser language where complexity is taken away and where JavaScript or something else wil be faster so the browsers ram can store more.
I like ocaml but I hadn't really had chance to see large applications written in it so I don't know if I still would enjoy it in enterprise environment. I like Java OOP I think it's great I can write decent code. I can write decent oop in JS. But I absolutely cannot make any sense of "functional" JS programming.
@@sk-sm9sh There is the fact than languages in the ML family are way more expressive than their mainstream counterparts and that most JS functional programmers don't understand functional programming and that the O in OCaml stands for Object.
JS kind of sucks for FP. Yeah you can do it, but the language offers you no guarantee to protect immutability like something like Rust would. So pretty much the language won't help you at all with ensuring you're actually writing valid FP style code. Not that JS helps you with much of anything. That being said, as a general paradigm, if you can avoid mutability, generally that's a good thing. So write pure functions whenever you can (within reason of course).
@@taragnor honestly I think whole immutability argument is bit overused. Sure it's easy to construct example that does some stupid things and endup having bug but with little bit of common sense it's quite easy to avoid most of pitfalls related to mutable state. In my 10+ years of coding I hardly remember that many instances where there was difficult to fix problem that happened due to "mutable" state. More often it's architectural problems. Applying blindly "immutable" patterns also don't fix anything as it's totally possible to build immutable framework that enables recreating very similar problems that exists with mutable state and I've seen plenty of ridiculous examples in react-hook or redux applications that are written in immutable way and endup having rather ridiculous state problems mostly related to referencing closure bound out-of-date values.
@@taragnor regarding expresiveness honestly I don't feel like I've lacking too much of it. Java already has pretty much all I need. Sure some things could be done little easier making code some 50-80% shorter. But what gives when in enterprise application 80% of code is plumbing and can't that easily go away and it can't go away because when you have hundreds of engineers building pieces it's impossible to have full alignment thus the way pieces gets built don't interoperate super well and thus plumbing code to connect them is necessary and I don't see this problem going away in OCaml. If someone had chance to work on multi-hundred staffed ocaml project I'd be happy to be englightened about approach that solves problem when independent components aren't perfectly aligned in way that needs no plumbing. Now it's whole different story for some projects I can totally see how expressiveness would be more useful building a compiler. But when you're building your regular enterprise application with endless UI panels, toggles, features, etc, all that expresiveness isn't really necessary in fact I'd argue it's counterproductive because when you have language that allows experssing virtuasity and you have creative inexperienced engineers they endup using too much creativity and making things more complicated than necessary.
I hope they add GOTO in the next feature update. That'll make it blazingly fast heh.
Hell yea, backin the 80s Goto was where it was at.
how would it work with const?
```
function what()
let a=1
label:
const x=a
if(a===1){a=69;goto label}
return x
}
```
re "how would it work with const": if it's limited to blocks and goto is limited to going only to one of the parent block labels then it can work
function what() {
blockx {
const x=a
...
repeat blockx // or // break blockx
...
}
}
static typing would truly make it blazingly fast
isn't there already goto in JavaScript
HashBang is not interpreted by bash, but by OS. This is common misconception. Any script that is executable gets run directly by OS and it is OS that sees #! and knows to use the interpreter that is stated between #! and
, like #!/bin/bash
. The proposition is that it should be ignored by Javascript runtimes like node or browser. Use-case is if it is a CLI javascript program and you want to run it in a browser and not immediately cause an error (invalid unexpected token error)
Not quite right. Bash can be configured to interpret hash-bang, and very often is when the OS doesn't support it (or has limited support)
@@hentaihero2201 that is true. Non-Linux (or Unix) OS-es need the interpreter to do it. In Linux it's the OS is the one doing that, which to be honest, surprised me when I first heard about it.
Instead of "When pigs fly" or "when hell freezes over", we can say "When ThePrimeagen remembers to turn off alerts"
impossibru!
WeakMap frees a value when/after key is freed
its useful if you wanna attach some data to an object but dont wanna add it to the object itself with a weird prefix like __
one simple example is you know when people add some extra data to HTMLElement(s) or Node(s) and they add a prefix like $ or __ or ___ etc.
with WeakMap you dont have to actually modify the object for adding extra data.
Might be outdated but, at some point, the JIT generated compiled code based on the shape of the object being fed to a function.
iving new field to an object would change the shape of an object and lead to deoptimisation.
That said, JIT are constantly evolving (try catch used to be bad) so always profile I guess.
so a lifetime clinger, like a parasite that lives with you and dies shortly after you die.
Yes, in JS, as keys are added to objects, it makes like hidden classes underneath that handle that shape.
So more and more of this is more hodden classes and more cost to move through them.
Ideally you want the same shaped objects to always be made the same way and in full
idk how v8 really handles them but
i image values on WeakMaps similar to symbols but without no way of accessing them nowhere else except through the WeakMap
The most consistent tech youtuber even tho i dont understand 99% of what you guys are talking about (since im a newbie) i still enjoy being here (to some degree)
I'm also a newbie 3 weeks to be exact
Pretty much the same
wow what u guys learning? newbie as well :c
@@vczoika full-stack web development, many say don't go this way but for me it might be the only way I could get a job. I will Learn html css and js obviously and maybe python and rust and later some C for libraries and framework I'll learn the mern stack and maybe svelte as well since a lot of developers are migrating to it
The reason for the shebang importance is interopability outside. # is not a valid comment in javascript. however #! is needed when executing things in posix to determine what to run it with. by making it accepted by the language, javascript will not throw a syntax error when it encounters it. this would allow you to both execute it directly with a shebang or indirectly by passing it into node.
the shebang stuff is probably for imported js files that also include the shebang. so it strips it before evaluating the file
First thing I thought when he was rambling on about it, the clue was also on the second snippet... `export`.. implying this JS file can be imported & executed. The only thing I can think is that he thought # was a comment..
Regarding the shebang, all your shell does is invoke the rest of the line as a command, passing the current file path. It's not reading the rest of the file and feeding it as stdin, so it can't remove the first line.
Why does it need to remove the line though?
@@amrojjeh With usual shells it's not necessary, because # defines comments. In node # is not a comment and it would cause a syntax error. The reason this currently works is that node knows about shebangs and ignores it, the proposal wants to make this official and integrate it into the javascript engine, so no matter whether you're using node, deno or whatever else, they don't need to know about the shebang to ignore it
It's not the shell that reads the shebang, it is libc.
See "man 2 execve"
@@LorenzoLeonardini Ahh gotcha. I forgot that Javascript comments don't start with hashes since my mind partially drifted into Python land. I must admit though that I found that portion of the article funny because they were seriously saying that'll complete JS as a server-side language "because other languages have it."
@@ianliu88 right, otherwise random process calls would have to go through shell (like on Windows, ugh)
i maintain the unfounded theory that hidetaka miyazaki got the inspiration for his poison swamps and decaying cathedrals from working at oracle before joining from software.
The shebang proposal is just "ignore the shebang line" because in JS, # is not a comment prefix like // is. Node already does this, now it's standardized across JS.
14:42 no, it's handled by kernel
interpreter needs to ignore (hash|she)bang because it's not supposed to be code
in languages like python, bash you get ignoring for free because it looks like comment for interpreter
example (`./deez`):
```
#!/usr/bin/echo
welcome to most useless interpreter (don't even read the script)!
```
you run that as executable (`./deez`)
kernel sees that there is (hash|she)bang and runs `/usr/bin/echo ./deez` instead
echo echoes `./deez`
it's now up to interpreter to do something with `./deez` argument (usually it's opening file with that path and reading it)
If you pass a file with shebang into a js engine the engine will bomb because it isn't a valid js file. Currently node executes and strips the shebang and passes it to js engine. This allows the js engine to accept the file as is with the shebang and ignore it. So that node/etc don't have strip it pass a valid js file to engine.
I am baffled when people say "web assembly is not intended to replace JavaScript". Are you friggen kidding me? From transpiling everything into bizzare mangled JavaScript to being shackled to the TC39 working group - why wouldn't we want an efficient executable binary format that web browsers could run rather than JavaScript? It's not like browsers will stop supporting JS - they will just also be able to run amazing efficient safe multithreaded Rust code compiled to target the browser.
17:32 That's not what it's about. It's so you can run `./filename.js` and the shell will open it using node, even though you didn't put `node` before the command. Same way how you can but #!/bin/bash and running ./scriptname(.)sh will automatically run it in bash... The Node interpreter only strips it out before sending it to the JS engine because it HAS to. It's not doing any of the "deciding what program to use" stuff. It's been picked by the shell to run your code, but it can't yet, because keeping that line would cause a JS syntax error since #! isn't part of JS syntax. It has to detect that line so it can be removed and make sure your code works, NOT because it's actually doing anything with the information.
I just don't know why people do that instead of running it via `node filename.js`
Hashbangs are NOT "stripped", all that happens (this is done by the kernel, actually) is that the hashbang contents are prepended to the original command and then that is executed. Node still has to read it, discard the first line if it's a hashbang and then give it to v8 (as v8 does NOT understand hashbangs, they are not valid JavaScript after all).
No "valid" JS parser library has to support hashbangs even though any file can contain it. Node has to require/import files with hashbangs, ESLint/Prettier/whatever has to fix/lint/format it, etc.
With this change parsers WILL have to support it and we can reduce all the duplicated processing in every "real world" JS tooling that may ever see nodejs code.
27:49 Plot twist: yesterday I listened to a lecture by a biblical scholar (who reads some cuneiform BTW) and it turns out that the biblical Babel Tower is almost literally named Babilon (kind of pars pro toto) and semantically the names are the same. The origin of biblical story is probably the experience of desert dwelling Jews seeing a 300 ft high, almost cube structure which was unimaginable in size but albo "weird because built out of bricks instead of stone" and making an anthropological sense and spiritual meaning out of its city and multi-language and highly urbanized construction site. The historical building was the E-temenanki ('E' being a word for a temple) ziggurat consisting of multiple platforms and temples for different deities to which the biblical authors attached the anti-dated mythical story.
Babel is the Hebrew name, Babylon comes from the Greek language.
@@blaser80 True, just the -on toponym suffix.
They are definitely two different names for the same city
42:04 the lock is for multi process parallelisem, so 2 node process can share a buffer (basically a memory mapped file but without a file)
This is already possible. Its not the unix way of doing multi processing.
But it is the fastest way
You need to do immutable updates when you're dealing with any library that does identity based updates, most well known being React, but i believe Solid and most other UI based libraries will do that.
Searching from the end seems to be obviously for when there may be multiple matches and order matters.
Immutable deez nuts
I find decorators in python pretty amazing to apply to my scheduled scripts, i can just put my entire main function for each procedure through an error logging decorator and have any failures logged to a database.
I'm not sure what a similar use case would be in Javascript since you're running it locally in much rarer cases, but they have their place
I also think they're sik. They handle tangential stuff to the main function logic. Logging, profiling, setting permissions. It just clutters the function if you have to include all these things inside the function. They're not part of it. I can see that they could be abused if you start wrapping logic in them that could make debugging hard. But I've literally never had a decorator issue when debugging.
immutability is not practical outside of functional contexts and academia. And any time anyone ever says "maybe things should be more efficient" the response from tons of JS devs is always 'nah modern computers can handle it, and memory is infinite' as if we should waste cpu cycles and memory on their inability to manage memory and state.
'if a program runs 2000 times slower it's still comparatively O(n)' type mindset
the hashbang proposal just said pretty much that the engine will ignore that line lol
06:50 I want more in place functions like sort and reverse, not array copiers!
23:10
To be fair, C# has great iterators too, the problem is that they're not very optimizable in general (you can do some tricks here and there but after you start chaining them it becomes hard).
Every interpreted language have performace problems with iterators, because the JIT does not have enough time to optimize it, it needs to have a fast startup time.
Rust and C++ can have zero overhead iterators, because the compiler can optimize those to normal for loops, at the cost of having slow compile times.
I have seen a video that showed that a naive iterator in Java and C# is about 8 or 9 times slower than a for loop, wich shows how much work LLVM needs to do in Rust.
It's a shuh-bang not a Hashbang btw.
And Ruby has a great convention for sorting and returning a new array or sorting in place .sort and .sort! respectively. ! At the end of the function name indicating that the function modifies the object when called.
Agreed! I just said the same thing!
Ruby isn’t super strict like Rust, but they do know the importance of knowing when things mutate. And I love that they did it via naming convention
I believe that the average JS-devs has very little clue what features are really needed.
One of the ultimate goals is to improve performance for everyone, and I believe that only the framwork-devs behind frameworks like React/Svelte and the Browser-core-devs behind engines like Chromium really have a plan how to improve performance.
That is why the name ECMAScript exists. The real name of JavaScript. Not owned by Oracle.
We just had pattern matching added to Dart, such a nice improvement
If we're talking about class decorator, then it's not inheritance but composition. It feels like inheritance because the decorator and the class being decorated both implement the same interface.
Babel, Hebrew name for Akkadian Bab-ilim, Babylon -> Greek name for the same place.
Does youtube let you stop others from making short clips from your videos? too bad... can you put out a short for this javascript underwater feature?
it's not that the shebang enables any new functionality, it just makes it NOT AN ERROR in an otherwise valid javascript file. before this spec change, having '#!' in your file is an error. (node ignores this, but that makes it a non-compliant javascript parser)
My understanding is that HashBang is for the Linux OS to be able to run nodejs by simply executing the file, like running any other scripting file like .sh scripts. So instead of running the command node with parameters of the file to run, the OS would do that for you so because nodejs will be configured with the OS on install.
C# does explicite resource management with `using` syntax, which is syntactic sugar over try-catch-finally, hope JS would adopt that as well! 😅
Iterator helpers are now at stage 3! LETS GO
I imagine any site encouraging people to use another language and providing training and education, would be requested to be taken down. The Jealous ex cant stand to see those people having fun with someone else.
As a not native english speaker, the Wiggle word is now my favorite word. Let's wiggle some javascript code to death...
40:00
Now this is the Nipah's law, every single language one time or another will turn into C#
I'm happy they added types, a compile step, a borrow checker, powerful generics, and a name change to Rust
So far I'm not a fan of the toReversed and toSorted because now instead of remembering that reverse and sort happen in-place you have to remember which way to type the function does which, and that's harder to remember and especially harder to review because there you generally don't have intellisense or whatever giving you useful tooltips.
IIRC, "babble vs bayble" is Bristish vs American (and also regional dialects). But in Hebrew and other languages from the region, it's usually "bah-vel".
The shebang is what is read by your shell, yes, but the entirety of the file content is also passed to your js engine, at which point shebang is not valid js. Node and deno both implement first line shebang technically out of ES spec, except now it's part of the spec officially. That's it, that's the point of that proposal
When you put shebang something, the Unix like os sees the file as executable and if you ./ eaxecute it whatever you have written after shebang will be used to run the code
Python's decorators are like completely different thing 26:00.
Only js feature everyone need is its deprecation
My favorite feature
this x100
They did debate decorators for over 5 years. And when the initial proposal was made, there was already existing experience with TS decorators and a couple of babel implementations. Hopefully TC39 cooked with something good for decorators in all that time.
Sort has bitten people who use immutable stores, such as Redux, maybe that's the problem to begin with? But yeah, two readers of the same list, one them sorts it, the other one is indirectly affected, and won't show the bug, until re-rendered. And yeah a simple slice does the trick.
Prime actually read the new syntax of the proposal before ranting challenge :D
Also using in C# is really easy. Explicit Resource Management isn't about thread locks and crap, just ensuring cleanup functions get called.
Just realized... is that Comic Sans as the message stream font??
2023: JS invents something which was in C# for more that a decade. P - pathetic.
i really need the documentation window that u have
33:00
it's bordered and full of info i ony get basic thing
waiting for him to find the `using` syntax was so frustrating
Thank you for the streams and the videos appreciate it ❤
Explicit resource management? When is the borrow checker coming?
34:48 who decided it would be a good idea to put a closure in there
Bro, I just inherited a legacy app with an oracle db and we can't even install a db on our dev machines, because oracle wants us to pay a license for that. I feel like I'm living in the 90s.
6:45 I kinda hate this because now we have to explain to everyone the difference between .sort() and .toSorted(). And 99% of the time no one is gonna use .toSorted(). We have enough bs like this in js already like .substr() vs .substring(). Is it too hard to just write .slice().sort() instead of .toSorted(). Actually just give us .clone() so the chain would read more like normal english. Kinda pointless and confusing. And if you care about the performance implications of not doing it in one go... why are you using immutables again??
12:34 omg somehow I hate this even more. who the hell is thinking about improving performance by starting the search from the end of the array instead of the beginning? that makes no sense. and if it starts making sense in your code I feel like you've done something terribly wrong...
17:55 Sorry I am just reacting to these as they come up but HOW DO THEY KEEP GETTING WORSE. I hate being a js dev lmao.
I'm using immutable because I got forced to use react against my will.
The shebangs feature means just it's allowed to ignore that part in the JS engine
11:47 FINALLY cleared your throat 😂
I need some of that watermelon, Prime...
watermelon with bread 🤤🤤🤤
Incidentally (and I'm sorry for spamming), ecmascript standard versions don't really matter, stage 3 is the real "you can start using these as they start getting added to compilers and engines, they won't change" and 4 is the "this is going to be in the next standard when the year comes around", so no reason to bother waiting.
As a TC-39 delegate, I can tell you that this is most definitely NOT true. Stage 3 proposals that are contentious will often see changes (sometimes drastic ones) once the first implementations came into use.
@@AnthonyBullard oh? I'm not aware of anything like that, happening, but I obviously you would know better! I based those statements on the proposal level descriptions and the typescript team's position on waiting for stage 3 before implementing.
Stage 3 is the point where engines should begin implementation. It is likely to be stable, but developers should not depend on that. If I remember correctly, decorators have been stage 3 more than once. Don't have time to pull up the other examples where it has happened(I'm also
I like toReversed and toSorted, I write a shit ton of functional ts so it could help me to have a cleaner code, in terms of FP.
The current shebang handling is nonstandard. Standardizing it just guarantees all runtimes will properly disregard it when parsing the file.
Now I want watermelon. Thank you.
I use WeakMap all the time, but I can't imagine what the use case is for symbols as keys. This sounds like "I can, therefore I will," without considering "should I?" Or perhaps I'm being blind and pigheaded, and these are the savior of mankind my job will depend on in the futre. We'll find out.
This whole bit of "we're going to improve iterators and resource management but only for synchronous code" is beyond useless to me. I've been working with generic bare iterators rather than specific collection types for some time, but async iterators are the only environment in which this makes sense. With a large synchronous array, there is a real cost savings from working with an element at a time over multiple sterps rather than rolling a complete array to capture the results of each step. But this is laughably pitiful compared to processing indefinitely-sized and sporadically growing async iterators. If this only works for synchronous iterators, you still need the whole dataset available at the start, and while infinite synchronous iterators are theoretically possible, they're simply not feasible. Only your consuming process, and not your delivery process or any intermediate steps, could be async. It's not solving any real problems unless it works off of Symbol.asyncIterator, except perhaps to spur the economy of UA-cam tutorials in building useless JavaScript constructs. (It's embarrassing how many tutorials exist on building queues in JavaScript which are all synchronous and fulfill zero development needs, because if I actually needed a synchronous queue for some godforsaken reason, I'd .push() and .next() my way through an array.)
1:27
I'm a javascript developer but damn i've laughed so hard to this 😂
Babel and Babylon are literally the same place and existed continuously for thousands of years 🤓
Pattern matching is stage 1, so good luck
5:55 Sounds like it would be a good use case for a language like Rust!
“New features in JavaScript? I really want pattern-matching in JavaScript. I also want that feature where you hold JavaScript under the water, and it wiggles, and then it stops wiggling. I want that feature in JavaScript” - ThePrimeagen
The twitter page looks like a big warning with all those yellows. Says a lot about the language.
I love weakmaps. They r the best. p.ex you have some tree-state, w weakmaps u could attach functions to a node, so u can keep the data clean instead of passing in the functions in the data itself. It's almost like a form of encapsulation. You could have multiple weakmaps referring to the same node, with different functions. Like parallel worlds. I use it in a project rn as a caching mechanism as well. And you don't have to think about memory cleanup or anything.
Yeah, it's nice being able to toss DOM nodes in a weak map keyed on elements of some list.
Babel is from tower of Babel, not Babylon. Story of the tower is a about the languages being created.
All this thing is like a response to a Primagean tweet
Will WebAssembly basically make programming language selection for speed obsolete? For example if all programming languages compile to web assembly, and then web assembly is what is actually executed client/server side then won't it make which language you use more a personal preference issue "what you know" over the trade offs in speed and performance as all languages will become equally fast as everything will become web assembly in the end? Trying to make sense on what a web assembly future looks like...
Go and rust both compile to assembly rust is faster in general the same will apply to web assembly.
Different language semantics will produce webassembly with different performance characteristics. Also language compilers aren't uniform in the sophistication of the optimizations applied.
The problem with the hashbang syntax is that bash/zsh etc. would interpret it, but not strip it from the file. So, without this proposal, it’s not valid JavaScript out of the box.
16:13 timestamp for reference
But I agree, all the reasons in this article for having this change sound stupid.
Bloatscript just gets more bloated. Looked at that thicc programming language.
I don't get the complaint about decorators but the support for function-level rust macros and things of the like - it all feels like voodoo that is not transparent to the developer.
Forgot alerts, oracle sucks, this one is already a banger 🎉
Wow chat was right about Babylon.
I pronounce it Babble because of the pun. It’s a system that takes meaningless gibberish and converts it to something interpretable (that said, I avoid that tool and webpack like the plague)
Do you want a course ? The hashbang would raise a Error so when you Put a shebang in a .js File ITS Not anymore js now it is.
The most important thing you need to know about JavaScript is that it sucks.
decorators when used right do the same thing as derive macros in rust. when used wrong they do all kinds of horrible stuff.
To this day, when I hear MLP, I think friendship is magic.😂❤
I work at Oracle so I probably shouldn't say this, but yeah Oracle does suck
are you in any way related to gilbert gottfried ?
ecma nuts
at the end of the day
what to say. I hope to level up my knowledge and in the future videos to keep up with you! haha
so basically this is how to let JS look just like Python and what it's has been doing for the past 10+ years ?
We don't need more array methods. We need better iterators.
javascript doesn't need python-like decorators because javascript has inline functions:
```
var df=decor(function(){
alert(1)
})
```
python-like decorator would be:
```
@decor
function df(){
alert(1)
}
```
Decorators aren't for functions really, they are for class methods and fields as well as class declarations. That's where its proponents see the real value. They also use classes in JS
Primagen being confidently incorrect about the etymology of babel.js
Array methods in PHP are fucked, either stick with mutating or not mutating
I call it babel, not baybel. I might have to show myself out.
Get well soon bro.
We love you Prime! God bless you ❤
Tyty
I hope chromium and other browsers are gonna use a new browser language where complexity is taken away and where JavaScript or something else wil be faster so the browsers ram can store more.
People should use OCaml instead of shoehorning functional programming into JavaScript
I like ocaml but I hadn't really had chance to see large applications written in it so I don't know if I still would enjoy it in enterprise environment. I like Java OOP I think it's great I can write decent code. I can write decent oop in JS. But I absolutely cannot make any sense of "functional" JS programming.
@@sk-sm9sh There is the fact than languages in the ML family are way more expressive than their mainstream counterparts and that most JS functional programmers don't understand functional programming and that the O in OCaml stands for Object.
JS kind of sucks for FP. Yeah you can do it, but the language offers you no guarantee to protect immutability like something like Rust would. So pretty much the language won't help you at all with ensuring you're actually writing valid FP style code. Not that JS helps you with much of anything.
That being said, as a general paradigm, if you can avoid mutability, generally that's a good thing. So write pure functions whenever you can (within reason of course).
@@taragnor honestly I think whole immutability argument is bit overused. Sure it's easy to construct example that does some stupid things and endup having bug but with little bit of common sense it's quite easy to avoid most of pitfalls related to mutable state. In my 10+ years of coding I hardly remember that many instances where there was difficult to fix problem that happened due to "mutable" state. More often it's architectural problems. Applying blindly "immutable" patterns also don't fix anything as it's totally possible to build immutable framework that enables recreating very similar problems that exists with mutable state and I've seen plenty of ridiculous examples in react-hook or redux applications that are written in immutable way and endup having rather ridiculous state problems mostly related to referencing closure bound out-of-date values.
@@taragnor regarding expresiveness honestly I don't feel like I've lacking too much of it. Java already has pretty much all I need. Sure some things could be done little easier making code some 50-80% shorter. But what gives when in enterprise application 80% of code is plumbing and can't that easily go away and it can't go away because when you have hundreds of engineers building pieces it's impossible to have full alignment thus the way pieces gets built don't interoperate super well and thus plumbing code to connect them is necessary and I don't see this problem going away in OCaml. If someone had chance to work on multi-hundred staffed ocaml project I'd be happy to be englightened about approach that solves problem when independent components aren't perfectly aligned in way that needs no plumbing. Now it's whole different story for some projects I can totally see how expressiveness would be more useful building a compiler. But when you're building your regular enterprise application with endless UI panels, toggles, features, etc, all that expresiveness isn't really necessary in fact I'd argue it's counterproductive because when you have language that allows experssing virtuasity and you have creative inexperienced engineers they endup using too much creativity and making things more complicated than necessary.
But in total, yeah, The New Stack is crap.