New Keyword 'using' in JavaScript!

Recorded live on twitch, GET IN

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

[hkupty]

Also, I'd much prefer something like python's `with`, creating a new context where the disposal will happen once the context is exited, rather than changing the current context.

[JLarky]

React on the server is going to look lit

"use using"

using using = use(use)

[MrMelick]

Us C# devs have been using the "using" keyword for a while now

[richardrapstine]

Finally, someone addresses the silliness with using arrow functions to make a named function!

[anlumo]

Fully with you on this one. The feature itself is great, but the syntax is weird. I wonder if they just didn't want to introduce yet another keyword along with "using", and thus reused "await".
I can already see beginners getting utterly confused by this.

[basione]

Arrow functions are great for callbacks. But for other functions, I prefer the 'function' way.

I even have a vim macro defined for js/ts files. It expands 'ff' to 'function' :)

[grumpylibrarian]

Regarding performance of ad-hoc objects versus class instances. There is a real and surprisingly high cost of long prototype chains, and ad-hoc objects tend to be 2-layer (instance + Object.prototype) while class instances are at least 3 layers (instance + class.prototype + object.prototype). You probably aren't going to get a concerning performance hit at 3 levels, but frankly you aren't going to get a concerning performance hit with a new closure for existing function code. And the prototype chain hit comes from referencing properties throughout the object's lifetime, where the closure hit happens only when the object is created.

Arrow functions are good to prevent use of 'new' with the function. An interface should only be able to be used in one fashion, and it should immediately fail if used in any other way. Using 'class' for constructors requires 'new' and using arrow or class/object methods will throw an error with 'new'. The arrow syntax might be ugly, but there's a reason to never ever ever use a 'function' keyword as they can be invoked either way, and unless you boilerplate your functions with a crapton of guards you might end up with strange results if you used the incorrect invocation.

I agree that the syntax for this proposal is godawful. It's getting awfully close to magic, which is the worst feature of any language. Take it from a guy who still has to maintain ancient Perl scripts. Programming magic is designed to make it easier for the first programmer to write, but it makes it much much harder for the second programmer to trace and maintain.

[capsey_]

I think what would make it less confusing for Prime is to make it "async using resource = getResource()" instead of "await using resource = getResource()", because "await" usually means right now and "async" mean that this has something to do with "await"

[alexley]

C# makes more sense:
await using (var resource = useSomething())
{
// block to do something with resource
} // gets cleaned up

Can have nested using blocks easily and can read left to right top to bottom.

Similar to python’s with statement/block

[danielvaughn]

After writing Javascript for 11 years, I'm finally ready to be off this ride. There's only so much wonky syntax I can learn year after year. I'm gonna go learn Rust.

[evergreen-]

3:08 the reason, I think, why arrow function are preferred over function declaration is that the arrow functions in JS don’t redefine the value of “this” in their function body which makes them more “stateless”

[isodoubIet]

The trend of languages without RAII coming up with kludges to imitate RAII remains undefeated

[garretmh]

There was a lot of pressure in the committee to use “using async” instead of “await using” but there were issues with the language parser complexity or backwards compatibility or something.

[NycoD]

The main diference between ()=>{} and function(){} is that the first can excute in the global scope and access it's variables, when inside a class or an object. The function declaration, runs inside the local scope of the object and canot access the values from where it was called, this comes from vanila JS, in frameworks this does not make a diference, it's only visual.

[bloody_albatross]

Naively I would assume that calling a method on a class instance that uses a field would be slower than calling a method on such an object using a variable in the closure. To call the method you need two hashtable lookups, one directly on the object, which fails, then going one up the prototype chain. Then you need another hashtable lookup for the involved field. For the object+closure case you need only one lookup for the method and the variable is bound via closure. That should be accessible via a pointer deref and array element access, basically. However, any of that could be optimized in any way and it ignores the added GC pressure for creating a closure for each method.

[gracjanchudziak]

Totally unreadable... Congrats JS devs, you have created a new crap

[heater]

I see the future of all programming languages...

Over time every enthusiast of every programming language will get their favourite features of whatever language they love into JavaScript. Why? Because eventually they have to do some web development, they find they have to use JS instead of their favourite language, but Javascript is shit for them, so they push to make it look more like what they know and love.

I first had this thought when JS sprouted the unnecessary "class" feature. Ah, I thought, a lot of refugee Java programmers have been forced to use JS, they want to make JS look like Java. All of a sudden the innocent simplicity of JS was defiled, sullied.

Of course bolting syntax and semantics of one language into another results in a chaotic, unfathomable mess. We see this with natural languages like English. Concocted as it was from old Viking, old French, old German, Latin, and other influences as it is, and then bent out of shape by Americans. I'm sure there is an "original English" still in there somewhere.

Of course this processes of language rotting is not confined to just JS. Look at what has happened to C++ as every idea from every other languages is injected into it, as it flails around pretending to be a functional language rather than an OOP language, etc. 

No, every language we have will get stirred up by every possible feature from every other language. 

Entropy always increases as the Physicists tell us. The heat death of programming as we descend into chaos, unable to do anything.

[GingerGames]

Why are they going the pseudo-destructor route rather than just having an explicit `defer`? The Drop trait makes sense in Rust due to its ownership+lifetime semantics, but does this `using` idea actually make any sense in JS? Why would `defer` be a bad idea? (I know `defer` is kind of already a thing for `<script defer ...>` but that's not technically JS at that point).

let resource = getResource();
defer resource.dispose();
// or
defer await resource.dispose();

This is just objectively clearer, even if you have to type an extra-line (oh no, not another line(!) /s). It would work with everything else already too that doesn't have the Symbol.dispose/asyncDispose nonsense too.

[vnshngpnt]

The arrow function thing is basically because the standard is to treat function as values (assigning them to variables, passing them to other functions, etc) instead declarations. It's just a matter of perspective and getting used to it. I personally prefer that style, but yeah a lot of people prefer declarations.

As for the `using` feature... I guess it's fine for some use cases, but I feel like it just doesn't belong to JS.

[jfftck]

I love that JavaScript is being written as functional with scopes, if you look at all of the examples, you need scope to use using. JavaScript has always allowed wrapping everything in curly brackets to give scope without needing classes or namespaces, and these examples show that in action. I would prefer if using was a class or even a keyword of “resource” to denote the intention of the code without having to look at the object members to see if dispose is being used. So, take the current class format and replace the “class” keyword with “resource” and this specification would be much clearer and easier to understand.

Also, I am not a fan of using “Symbol” to add functionality to the language instead of keywords. The Symbol documentation will have a lot of links or end up being the longest page with unrelated content.