"Stop Using Async Await in .NET to Save Threads" | Code Cop  

:)) I will loose also my private jet :)

Avoid bugs - stop writing code

To be fair, my PC is my main space heater as well.. So I kinda am saving electicity while using it? :D :D :D

stop using electricity, use solar energy

Yeah get a Mac 😂

"Don't stay in house, the ceiling might collapse on you"

@@POWEEEEEER "Don't make a comment, you might get a response you don't like."

I also ran into an issue with this when working with sql lite a few years back. Maybe I'll fire up the old project update the packages and see if I still can get the issue.

I thought only sqlite has this problem

That also happened to us with StackExchange Redis due to a bug x)

​@@JacobNax how do u face this issue with StackExchange Redis? I'm curious

And this ppl is why you shouldn't block in async code. If it was implemented that way you would indeed be better off without async await.

Calm the blasphemy down.

​@@jasonenns5076 sorry, let me correct: "David Fowler, who is literally God"

Genuinely used List for a weird edge case of wonky json data being spat at a UI, but never a List... ever... EDIT to add - I removed it pretty fucking fast when I realised that our serialisation method opened up a MASSIVE security hole where any caller could deserialise any object on our server, and execute code in it's constructor...

"The idea behind "using" with disposable objects is to prevent memory leaks in several ways:". It is much better to say "resources", because once you start associating disposing with memory, you are shortcuting its actual purpose.

The biggest flaw is that C# does not indicate disposables in any way. You need to memorize which classes are disposable. Compiler does not produce warnings if 'using' is omitted.

@@mk72v2oq There has to be an analyzer that does that already.

It's less about leaks (the GC will get around to it eventually). it's more with dealing with unmanaged resources (i.e. things the GC isn't aware of, such as Drawing.Bitmap), and depending on what you're doing, returning resources when you're done (e.g. SqlConnection, Mutexes, File Locks, etc), or finalising things where appropriate (e.g. MVC uses it to write the closing tags for HTML renders, Streams to Flush). The latter 2 are critical; for the former, improper disposal can and **will** make your app stall indefinitely if there is insufficient GC pressure, and not doing the latter will make you output garbage. Also if you want some inspections, I believe Roslynator has several around IDisposables to augment the ones in VS itself.

@@mk72v2oq this is absolutely right. There ought to be an indication at least at compile time if the object calls dispose somewhere in the code. And to be honest, if a class uses un managed memory, it is not my responsibility to clean it! The destructor of the class implementing the IDispose should free the memory it used. The IDispose should force the use of dispose method in the class. Using the class, I should not need to use using. I do not care what and how things are made inside that class really.

You don’t use ArrayList because it is not generic, plain and simple.

That's actually welcome since it's getting really warm in here

Watching the video from Australia, I appreciate his t-shirt being transformed back into the pullover.

Yeah seems one of the corner cases where it's valid. But generally, within a C# closed system that isn't shitting bad data across the wire, I really can't think of a good reason for it!

Spot on, shows the poster doesn't code, so it's junk, there's gonna be more of these junky articles.

I am so tired of the AI trend. Everything in my office now people say: oh chatGPT can do that. Geeeez can people be MORE lazy? ffs no one wants to do stuff anymore. :(

Hot take: If you're using List, it's because you lack the technical expertise required to build a solution in a maintainable, type-safe way. Honestly just a skill issue on your part.

@manilladrift Real Hot Take on your so-called hot take: BWAHAHAH. Absolutely wrong @manilladrift . If you make comment that implies "there is *never* a reason to code in such a way" then it's you, *honestly it's you*, who not only lacks technical expertise, but you also lack coding experience. While object[] can often be used instead of List there are scenarios that *a developer with actual technical expertise* will recognize the latter is better. There's a reason reflection invocation calls to methods use an object[] parameter. It's because methods have parameters of any number of types. Now, follow what I'm about to say so you can gain some knowledge. If you have an object[] in .NET's method invocation reflection call because the parameters can be of mixed types when invoking a method, SCENARIO 1: if you at *run-time* need to collect data of varying types for a method invocation that itself is also determined at run-time, which has an object[] parameter in addition to other parameter types, then *List* is perfect for that scenario. There's other details about the invocation that solidifies that as being perfect too, but what I mentioned sufficiently demonstrates it as preferable if you understand. That scenario is for a system that collects live data as a conversation is being monitored for specific words. Various word are connected to various types, and those types are collected in real-time. Various word combinations then trigger the need to invoke various methods determined at runtime that have varying parameters counts & types, passing in various metadata types as individual parameters. Those methods then do their work providing valuable info for speakers in the conversation. A complete success. If you have in your mind "*nEVeR* uSe *List* because sOMebOdY said 'aLWayS bAd'" then you'll probably try allocating an object[] with a probable size and resizing object[] as needed like the code behind List would similarly do, instead of simply using List, which is optimized already, to collect the data as it came in. Using *List* to collect that data of varying types as it came in would be the proper approach for that scenario. Your assertion @manilladrift, with just one scenario of many, is wrong. Whether you think a particular design is good or bad, extreme or otherwise, there are proper scenarios in good designs and bad designs where using List is proper for the particular design in use. *Understanding that comes with maturity @manilladrift.* Your reasoning is why people say silly things in YT videos like "there's *NEVER* a good reason to use async void or Task.Wait." While the use cases may be extremely limited, saying "never" simply demonstrates one's lack of expertise & experience. Your comment has exposed yours. Good day.

@@ThomasJones77 I'm sorry, I disagree completely. I believe there is always a smarter, more type-safe way to represent diverging types by aggregating common or expected traits into separate type definitions. Using a List is simply a bad design decision that shows the developer is simply unable to come up with a smarter solution. Again, it's a skill issue.

@@ThomasJones77 you have varying types and you dont know when and it what order they occur, but as a programmer you still know what kind or pool of types you could expect, right? so cant you just create an interface like ICollectedData or something that all known types implement? even if the types dont share a common functionality defined in the interface, wouldnt an empty interface still vastly improve the code readability?

@@manilladrift As an exercise, rewrite the .NET method invocation code (*MethodInfo.Invoke(...)*) to be strongly typed only, eliminating object and object[]. Just something as basic as that demonstrates that it is you who lack the skill and experience. There are simply instances where things do not need to be strongly typed as you insist. You say it's bad design and the developers of .NET should have come up with something better, but you can only make such an assertion if your skill and experience level with various coding scenarios are limited. The use of List for collection to populate various parameter types of various methods that are determined at runtime is just ONE example of many.

Sounds like a JavaScript developer.

" deserializing unknown list data" - from experience, this is a massive security hole that I'm glad you resolved :)

@@mattyward1979 In this case its not data from external sources but rather for some generic debugging or as I mentioned, adhoc parsing to easier identify what types I do need to map out the correct type of objects. In production code I would not trust that kind of code, even without the security problems :)

Depends what the lifecycle of your dependencies are. If you have a singleton that hosts your DBContext, you may have introduced a memory leak unless you manage it internally If you're using something like Castle or .NET DI containers, PerWebRequest/Transient will tidy up anything that no longer has a dependency (typical garbage collection) If you have a dependency in that chain that is a singleton, it will remain in memory and always be injected into those new instances

I think it is usually better to use "JsonElement" instead of Object, because that is what is really there (if using System.Text.Json), and it will gain more power to you. As for XML, it might be XmlNode, and so on.

@@realsk1992 Actually it is the issue as I code an agnostic format's serializer so I cannot know in advance if it will be Json, XML, ... used by user.

Ints won't be boxed in List, but in List they will.

@@QwDragon correct, I was just replying to the statement about value types usually being stored on the stack. That is not the case when the value type is a member of a reference type

Further to above, the defining characteristic of value types is not where they are stored, it's that their type and value are stored together.

The system I primarily interact with is all over the place with exception handling.. Loads of calls throw unhandled exceptions, sometimes return a packaged response with exceptions on an aggregated basis or a row by row basis. To have a catch all we also use an ExceptionFilter that has broad (but not exhaustive) knowledge of system expected exceptions with a fallback error extraction to a known exception type understood by the calling agent (UI) We can then just allow our server to throw shit willy nilly and it will always be processed correctly Probably an anti pattern in there somewhere, but saves me a lot of time :)

I think it depends on the purpose of the class. If the class is really an abstract data type that has to preserve the consistency and integrity of the data within it, it should really throw in the constructor. e.g. it shouldn't be possible to construct an array type of length -1. This significantly helps reasoning about code using it not having to worry about if the state is valid. There can be good cases for a factory method, but generally when you might have different kinds of factories or different creation logic. I hate having a Create function just in place of a constructor, it is unexpected compared to everything else.

@@username7763 Oh, certainly. And at the most fundamental levels those kinds of protections are necessary. I think it's a matter of "validation" vs "not even representable". A null value for an array, or a length of 0, may not pass validation, but it's representable. An array with a length of -1 isn't even representable. I'm trying to adapt to a more "functional" style (basically, seeing how well a certain set of recommendations works vs how I normally write code), and the assertion is that the type is just a type, and shouldn't validate itself. The validation is moved to a separate class's factory methods. Though I think it works better from the grounds of using records as data types, rather than full classes. Behavior is lifted out of the type, rather than encapsulated by it as in standard OO. In that manner, you have the 'factory' class and say, "I'm going to use this type in this manner. Please make one for me." And if it's not able to (it fails validation), it returns null, and you don't have to deal with exceptions, just 'if' checks. And nullability warnings in the tooling make it easier to spot where you failed to make sure you got a valid object. If you didn't catch an exception, that could end up being handled anywhere. It's not an error to not catch the exception (at least until the program crashes). That also allows you to create a second factory class that generates the type using different validation considerations, and you don't have to figure out how to make both configurations work within the constructor of the type itself. (Just like an int is just an int, and doesn't care if you're using it to represent an Age value that can't be negative.) I've also found that it's much easier to reason about object creation when the Create() function can be named in a way that explains why it's being used. Compare with having multiple constructors with varying parameters, expectations, and validations; a "new MyObject(~params)" doesn't give you a clue about any such differences, but a Create() vs CreateWithNameOnly() can be a useful distinction.

@@David-id6jw Wow that was a lot to write in the comments section! I think I followed it though. Yeah what you describe makes sense from a function programming style.

A good example for why critical thinking is a must-have skill. Nick usually resonates with me but this one seems not thoughtful. IDisposable is about releasing unmanaged resources and in that one you must trust the component and call Dispose - preferably using using :) - asap.

I don't think it was the using statment he thought was wrong, but how the "mistake" called the Close-method, which is not the same as calling the Dispose-method.

because the using statement is not part of the dotnet runtime, it is just syntactic sugar It is translated to a try/finally so the runtime can execute it

Look into the concept of Lowering in C#, Nick has a great video on this. In a nutshell the C# code you write (the using statement and many other things) gets "compiled" into low level and usually optimised C# code that gets run by the runtime.

@@arjix8738 Yes but not just. Same as lock() and (somevar as sometype), using is syntactic sugar. Just a sign that WAY too many people didn't do things properly so they shortcut'ed it and now people don't know the difference between .Close and .Dispose. And most don't even know what a destructor is, god bless them for working in 100% managed land... The "not just" part is "whatever happens inside using .Dispose MUST be invoked, as that is the sole purpose of using. And that's what finally{} does, call .Dispose whatever happens.

Not sure about the question, if it's about the code lowering or the functional part, but assuming the second, when you use using, the one guarantee you have is that WHATEVER happens, .Dispose is called. So logically try{something}finally{whatever happened call .Dispose}.

According to the ArrayList documentation it was introduced with .NET Framework 1.1.

@@maschyt first comment was based on my memory, you are right, but at this time, i was just starting with C# in selflearning, so it still was an improvment for me :-)

HttpClient is a good example why you might avoid to do so. If you just run overloaded method from inside, you don't care about awiting it, because the overloaded method itself has logic in it which you are interested in

@@isnotnull ... but if you want a rule of thumb putting async/await always without thinking about it is a good one

Is there even a downside to this?

@@discbrakefan If you return the Task, that method doesn't get added to the Task's stack. So it's marginally cheaper to execute, but it also makes it marginally harder to debug because the stack trace won't show how the Call Site got to the Executing Method. As such I would generally recommend only using this in one very specific niche scenario: Forwarding a method without a CancellationToken to one that does, and only when the `default` keyword isn't applicable. e.g. Task MyMethod(params int array[]) => MyMethod(CancellationToken.None, array) async Task MyMethod(CancellationToken token, params int array[]) {...}

@@rafazieba9982 As a rule I assign a result of await to a variable and return the variable instead of expression. Helps in debugging at no performance cost

Can you not use generics for that, ie. List ? I do something similar for caching. But using generics , then you can also restrict the list to be classes inherited from your Entity base object.

@@Biker322 there is no entity base model. Just 10 different classes which are all stored in one list.

same but for 10

I'll do it once, to see how my colleagues will react! :)))

XD))

@@johnnyblue4799 might die, just saying

@@milendenev4935

Thats typical with his video thumbnails and contents. Classic click bait he keeps doing. This guy becoming annoying to me recently

I think his point was more that using calls Dispose(), instead of Close().

​​​@@billy65bobyeah, but he gets very aggressive because he (intentionally?) misunderstood the advice. Imho the original point was to use using() instead of calling Dispose()... But yeah, if you want to see dirt there ..you definitely can ;) The stretch is that in order to blame the advice, he mentions that "yeah using is there, but who cares...you can call try finally and Dispose yourself" and this is a bad advice imho)

I would've made a class with a property inside and instead of list.Add(value) it would be list.Add(new() { Prop = value }), which is mildly less headache-inducing and easier to modify/expand in the future.

@@lordmetzgermeister oh and what would be the type of that Prop? Might it be object?

@@asedtf Yes, but the benefit is you can add other properties to that class that contain other information.

@@okmarshall okay, sure, but that's beyond the scope of the original suggestion. The problem didn't need it