"Stop Using LINQ in .NET!"

Until the 30th of April, use code BIRTHDAY40 for 40% off any course, BIRTHDAY20 for 20% off any bundle and BIRTHDAY15 for 15% off your first year of Dometrain Pro: bit.ly/4aUVR8l
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video I want to talk about one of the most insane things I've seen on Reddit regarding employers banning the use of LINQ in the entire company.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet

[@sealsharp]

1) ban LINQ 2) write your own methods 3) write the same methods again and again 4) collect common methods 5) make a library of common methods 6) have LINQ without MS doing the unit tests for you

[@TheFantasticMrFish]

Gru looking perplexed: have LINQ without MS doing the unit tests for you

[@jongeduard]

The next step will be that the boss also prohibits `yield return` and Enumerators. 💀

[@ericblankenburg]

I've been in software architecture and development for 30 years. I have found that there are a lot of people in positions of leadership in the industry that shouldn't be there.

[@IndigoDalliance]

Indeed. Some managers have a very poor understanding or too conservative approach of the technology.

[@mattbristo6933]

Many managers know nothing about software engineering and I mean nothing.

[@doughboy_6439]

It's either the Peter Principle -- the most skilled 'producer' becomes the manager, which leads to people in management who are not at all skilled in management... Or it's the Dilbert Principle -- the *worst* guy on the line that makes big mistakes but everyone loves and protects him, he's the guy that gets promoted, in order to get him off the line.

[@krccmsitp2884]

Unfortunately, I have to agree with that (excep for my current job).

[@frankhaugen]

That's why I refuse to listen to management for technical things

[@emmanueleriksson]

Time to quit.

[@jfaquinojr]

The redditor's boss probably will watch this video now.

[@valeriesimpleton2525]

I don't let anyone on my team use classes they're too risky

[@younesskafia4189]

I don't let anyone in my team use static functions, can you imagine how many stack overflow can happen with those?

[@gordug]

I wouldn't let them use Interfaces because it's hard to debug and read😢

[@sanglin9387]

haha struct all da way🎉

[@RubenALopes]

I dont let anyone on my team use computers they're too risky

[@suic86]

What about variables? 😂

[@hodgenick]

I would change employer. What an idiotic mandate.

[@Linkario86]

Wtf? I really didn't expect this to get so much traction. But I'm a Nick Chapsas Video. Cool! :D

[@bikeindustryshill]

I’d fire you man 😂

[@jauffretv]

But are you gonna send this to the engineering manager that made the decision? :)

[@kevinloggenberg6000]

Hopefully, this video and literally every developer in the world saying that what is being proposed is ridiculous saves you a job and you become the LinQ hero at your place of employment.

[@phizc]

I would have loved to listen in on the conversation if Scott Hanselman called up your boss 😂. Linq is good unless you measure "code quality" in lines of code. Or where extreme perf/no alloc is required.

[@ByTheRiverHelge]

@@phizc Hanselman calling your boss would be the real world equivalent of Zeb Macahan entering the scene in How the West Was Won.

[@sasukesarutobi3862]

"LINQ is hard to read/debug"

[@vincent06]

It doesn't matter if it is a skill issue or not, some people won't learn or make the effort to write readable LINQ query and you will be forced to work with them and their code.

[@ErazerPT]

100% behind you. If anything, yes, those intermediate vars are what makes debugging "simpler" not not using LINQ.

[@adambickford8720]

@@vincent06 So just like ALL code? There is no worse offender than mutable, imperative code

[@adambickford8720]

@@ErazerPT Does C# debugger suck? In intellij you just set a breakpoint and look. You can have it tack return values if there are no local variables

[@vincent06]

​@@adambickford8720 Yep but in my experience it is worse with LINQ queries.

[@yupii1997]

At my first internship we werent allowed to use Include, or any type of SQL joins. The reason? The manager said it could mess up the database. So instead if we wanted to get the related data we had to send multiple database calls in order to get the data we needed. Good times

[@deado7282]

Sounds painful. "The manager said it could mess up the database." sounds like a skill issue

[@yupii1997]

@@deado7282 right? There was a api endpoint that needed to retrieve data from like 8-9 tables, maybe more. So you could imagine the performance. Also another thing writing data same thing, no bulk inserts, no transactions, unit of work, anything, one by one table by table. There was an endpoint which inserted in 28 tables with one request. Do you know what he told me when i said to him, well what if something goes wrong and we cant finish inserting into all tables? Wrap every insert in a try catch block, if it fails inside the catch delete all previous data one by one.

[@local9]

WHAT! I'd walk out at the point of starting.

[@deado7282]

@@yupii1997 Like this smart reddit poster said: "RUN"

[@yupii1997]

@@deado7282 did do. Three months later my internship was over, offered me to continue as junior, couldnt say no to the offer faster

[@Krimog]

Here's my take: the only scenario where you should not use LINQ is when you have extreme performance requirements. But you have to be an experienced developer to write faster code than LINQ. And if you are, you don't need someone to tell you that you should not use LINQ. So the "Do not use LINQ" rule is, at best, useless, and most of the time, bad.

[@davidmartensson273]

So true, I totally agree. The only case where I skip link is when there is another way that is just as easy and readable and that is faster, meaning I will not loose anything for the performance. But in 99.9 % of all code I write, readability beats nano second optimizations by magnitudes. I do not work on game engines, AI engines or super computer calculations, 99 % of all performance issues are either DB related, or calls to other services. I would have to really aim for it to create a linq statement that would be measurable in comparison :)

[@alexclark6777]

I've worked with people like this in the past. "Any technology I don't know is banned because I might have to support it after you leave."

[@antonybaasan]

That is different. Don't introduce any unnecessary not well supported libs.

[@Tsunami14]

Not often, mind you, but there definitely have been some times where query syntax led to improved readability of existing code. e.g. chaining multiple "from"s automatically does a SelectMany(). And there's no direct function-syntax equivalent to the "let" keyword for introducing an intermediate variable.

[@abj136]

No direct… but just do `var a = firstpart; var b = secondpart using a; ` It’s not hard to read.

[@supreme_dev]

The only situation where we've been avoiding linq is in game development, more precisely in Unity where we are on .NET Framework 4.8 where linq is pretty allocation heavy and slow so we implement most of the stuff carefully, that's the only place I could understand avoiding linq (or any similar scenario), otherwise this is completely sad

[@Un4GivNX]

This! We're using linq during initialization of systems and menus. We avoid using linq on any update loop.

[@galandilvogler8577]

Fellow gamedev lead programmer here using Unity - the amount of allocations we get even on Standard 2.1 is quite big, so I had to ask everyone to not use LINQ except at startup/init. And I'd love to be able to use LINQ, since our game is a tycoon, so lots and lots of collections to manage everywhere. That's why I've promised myself to at least try for fun Stride, which runs on the latest version of .NET.

[@damienfenton3880]

Reminds me of the time my boss was in a panic about a new calculation that wasn't covered by an Excel spreadsheet's existing formulas. I said a simple change to one of the formulas would resolve the issue but she was too scared to change it because "the formulas are too important to mess with". The result was an additional two hours of manual calculations per month which also increased the risk of human error.

[@abj136]

Duplicate the spreadsheet. Run the calculations old and new ways simultaneously. Insert a new calculation that is your manual calculations so you just have to plug in a number manually. Produce a report of the relative quality of each output.

[@emerynoel567]

@@abj136 And then take a bonus 2 hour lunch once a month! :)

[@DevMeloy]

I know I'm in the minority here, but I like LINQ query syntax. It reads more like SQL and in my experience easier to write certain complex queries in.

[@VoroninPavel]

Yep, when you need multiple joins or group joins.

[@marcusmajarra]

Not to mention the fact that it removes the overhead of lambda function parameter declarations and ensures that the same variable always points to the same object within the query. With chained extension methods, nothing prevents you from reusing the same variable across different operations, so you're basically deferring to good programming practices to prevent the introduction of ambiguity. I just wish that the LINQ query syntax went all the way in supporting the various kinds of join operations.

[@enderinglewood]

Yeah, exactly! Besides easy chaining multiple (group) joins, it's also possible to use query variable (let keyword). In my mind, it have some pros and cons (eg. you can't use Aggregate, ToLookup, Min, ...) like basically everything in life. So, I don't really get the hate. The only thing which is imho little weird is synatx. It's like some sort of alien language inside of regular c#.

[@robsosno]

I'm not using it except outer joins. In these cases it is much easier syntax.

[@kostasgkoutis8534]

I like it as well, it reads like a haskell do block or an sql statement.

[@keyser456]

This dogmatic overbearing "you must!" or "you must not!" attitude has been pervasive in software dev for a while now. It's funny some people are just now raising the flag. I don't think most devs even realize they're guilty of it themselves. One size doesn't fit all, so let's all get better about not being _that_ guy.

[@emerynoel567]

It's good to have baselines, but bad to be utterly inflexible. E.g. don't use select * in a SP if the table isn't defined in the SP, because if someone changes that table you're gonna get a bug.

[@1992jamo]

There is only "must not". Must is just what's left.

[@davew2040x]

I honestly think it’s a function of the mindset of many programmers, where everything is either “it sucks!” Or “it rocks!” with essentially nothing in between. For as complex as software development is, I’m shocked at the narrow perspective of a lot of people who do it for a living.

[@1992jamo]

@@davew2040xThere are some absolutely beyond shocking ways to doing things though.

[@FlorianDelorean]

At a job in my junior years (13+ years ago), I was forbidden to use "goto"... But not just the keyword, if a comment or variable had the word "goto" in it, our "quality gate" would find it. The quality gate you ask? Full text search in all solution files... Also, it would NOT prevent the check in into the branch, but send an email to the manager about this "incident". The manager left before I did.

[@csabraxas]

Ok the email to the manager is ridiculous but those checks are fairly common. For example setting up Sonarqube on a build pipeline to do those checks

[@alejandroguardiola9085]

I mean I would forbid the use of goto too, but just the keyword

[@casperhansen826]

Well, the goto comes in quite handy when exiting two loops, but I agree that in most cases it should be avoided

[@neverknowsbest2879]

​@@alejandroguardiola9085 I wouldn't. Use of goto in some very rare cases is justifiable. It is the same case as with inheritance (from concrete classes). In 99,9% of cases inheritance should not be used and instead one should use composition. But in some very rare cases inheritance is justifiable. The fact that people misuse some tools doesn't mean that the tools should be banned. If some person wants to use goto or inheritance he MUST prove that it is justified and that other methods are too hard or make code unreadable.

[@T___Brown]

Last checkin before i left would be a bunch of comments // goto hell

[@rumplin]

I would stay at that company, but I would demand 30x raise, because I would be the only dev left there.

[@andywest5773]

Unfortunately what really happens is that the only people who stay are those who can't get jobs elsewhere. So it would be you, a bunch of underskilled developers who are afraid to leave, and an employer who knows they have the upper hand. Better to just quit.

[@Matt23488]

I actually do use the LINQ query syntax, albeit very rarely. Basically if I need to do something like joining two collections together on some common key, I find the extension method syntax harder to read once you start having to pass multiple lambdas. Aside from those types of uses, neither syntax is harder to read than the other so I default to extension method syntax.

[@1992jamo]

Completely agree. I use the method chaining syntax predominately, but there are very good use cases for the query syntax.

[@ugo4brain]

I don't believe that the LINQ query syntax is inherently bad. It excels in scenarios involving complex queries with multiple joins, making them more readable (at least for me) compared to the method syntax. However, for simpler queries, I tend to prefer the method syntax. It ultimately depends on the specific use case where each syntax is applied.

[@alejandrocoto7367]

@Nick Your example doesn't help case for LINQ, mainly because non-LINQ code (if you take a step further and remove the List) runs 8 times faster than the LINQ code without any memory allocation (the LINQ code still have some bytes allocated) and the readability is not that worse. Maybe if the example is not trivial, with a GroupBy or OrderBy maybe, where the non-LINQ code would explode in complexity and have significant worse readability can better support the case for LINQ. Another example that would help, will be an optimized LINQ method, that may use SIMD behind the scenes, which is not easy to write or read without LINQ. For the record, I think that decision is nuts and LINQ have it's place, maybe not that much in hot-paths, but you don't want to throw it away like that.

[@nocturne6320]

I think a next logical step is to use Interceptors and source generators to upwrap LinQ into inlined generated code, that way we get 0 allocations for enumerators and maximize performance to a point where most people won't be able to write faster code unless some very low level techniques are used

[@ByTheRiverHelge]

As an F# fan, I love LINQ in C# because it makes C# look like F#.

[@asedtf]

I'm so excited I got to see one of the five F# developers here

[@fsharpfan]

Here is one. Only three left. Where are they?

[@leandrostoneshop]

@@asedtf 🤣🤣🤣🤣🤣🤣

[@Ragastr]

I wrote some pet projects in f#

[@ByTheRiverHelge]

​@@fsharpfan Elixir seems to be on the rise, so maybe there's where they went. I'm considering it myself but I really dislike dynamic typing. As Dirty Harry puts it in Sudden Impact: "If you use weak typing, you got to ask yourself one question: Do I feel lucky?"

[@vyteniskajackas7579]

Omg, I read this reddit post and thought "Nick has to make a video" and here we are :Ddd

[@asedtf]

Nick-driven-development

[@cubbucca]

FirstOrDefault is LINQ, I couldn't use C# without it. Also GroupBy, OrderBy and Select

[@MarkCastle]

Same

[@7th_CAV_Trooper]

And Where

[@PhantomPhobos]

LINQ is basically enumerator syntax sugar, in other words it's not taking away from anything that you should be able to do without it, funny that someone would even consider it being a problem. If they don't like syntax sugar or language complexities they should just write the code in C.

[@deondupreez4713]

Worked at a place where a manager banned LINQ for his team because "it works until it doesn't" and he couldn't give examples or elaborate on this. Luckily, I never worked under him and I continued using LINQ with 0 issues

[@LintAndButtons]

I work in games and many of the most common performance spikes and garbage allocations come from use of LINQ. This is absolutely a case when LINQ should be avoided.

[@davidmartensson273]

Tight loops and code that is called very very frequently is the place to look for micro optimizations so yes, in the few occasions I have had similar code I sometimes replaced linq with something else. But in many cases, after testing, the actual gain was not really that much. For a game sure, any performance gain is most likely worth it,

[@bernierm]

Some of the performance issues with LINQ are developer issues - I've seen a lot of code where a dev will .ToList() the results of a query and then a few lines later do another query on that resultant list and .ToList() that result.

[@davidmartensson273]

@@bernierm Or before the VS warning, enumerate the same query without a ToList before, rerunning the root query.

[@BrutusDunKutus]

Indeed, I've encountered this sentiment within my company too. Some colleagues lean towards exclusively using stored procedures rather than LINQ (Use stored procs for crud operations, but really they want to even implement loads of logic in there. so basically use sp's for everything...). I think you should both depended on the situation.

[@davidskidmore3442]

Back when I studied database applications formally, about 25 years ago, this was a big thing; put business rules into the schema and functions and SPs, and then the client/middleware applications literally can't do database things wrong. That said, we've come a long way in terms of application design, developer education, and database usage from where we were in 1999.

[@Codestud]

A few years ago I was interviewed for a development job. I liked the development manager, but during the interview he said that he had been considering banning LINQ so that everyone had to use stored procedures. I accepted a different job. Yes, I know that LINQ can be tricky sometimes, but I felt that I just couldn't live under that restriction.

[@bikeindustryshill]

Good move. Software that heavily relies on SQL and database level processes really is the worst to work on now. Code first + good ORM leads to a much nicer dev and user experience

[@andywest5773]

Considering that LINQ on its own has nothing to do with relational databases, I think you made the right choice.

[@adan5368]

This is also happening on my company, I've been working for so long here that I already forgot about several LINQ things I used to apply on my day to day basis. My only question about the LINQ usage is if it is "Exception friendly".. Could any of those extension methods throw an exception or will they return an empty collection of elements? If they throw an exception and you need to add an if in the middle of the process, do you split the "query" of methods or you just add it inside them?

[@colindawson4818]

Many years ago, I'm talking back when .net 2 was new, Linq to SQL was new. We had to ban the use if it for accessing the database, and limit all access to the DB to stored procedure calls only. This was not because Linq to SQL was the problem, it was because the developers didn't know how to write SQL and was using Linq as a crutch, in turn that was create really bad SQL queries, and killing the performance of the database. In the many years since then, and I'm talking decades at this point. Linq has become much better, entity framework has been made alot better and with the right oversight, it can actually be easier to not use stored procedures as all and run everything via Linq instead. The main advantage being that it's possible to make the data accessing language database agnostic, so that it's not tied to a specific database.

[@aliaksandrkhlebus1566]

I wouldn't wonder about database agnostics as it is not often that database changes but ability to test linq queries and compile time checks against schema overweight transparency of stored procedures.

[@britishjames9415]

Linq was added in .NET framework 3.5

[@colindawson4818]

@@britishjames9415 later than I thought, still a long time ago. It’s come along way since those early days.

[@davidmartensson273]

I almost never actually use Linq for DB access :) Sure if you have entity framework its slightly easier to use, but I wrote SQL queries for some 15 years before Linq came around and even now I find I default to SQL because I just know it better. And I also worked on some massive databases where when we tried to use EF and Linq, we found that it really could not optimize the queries good enough. The problem was that the same query could behave very differently depending on the parameters meaning we often had to tweak the query to enforce certain optimization and that was not really possible with Linq and EF.

[@deado7282]

Removing the best parts of .NET

[@haroldcruz8550]

That's Microsoft for you

[@CanonOverseer]

@@haroldcruz8550 What

[@jannowak2413]

Do you really think that query like syntax should we removed? Thats odd, I think with slightly more complex queries (e.g. using left join) query like syntax is much more readable. But that may just be me being accustomed to SQL

[@rreiter]

I agree + I use what's suitable. I've had to translate SQL into LINQ as much as possible during a code modernization project, in part so others on the team could work with the code going forward without being SQL experts. Some very complex but easily readable SQL queries and stored procedures became outright abominations in LINQ no matter the flavor., so those were left SQL.

[@igorsolomatov4743]

I find the only issue is that it silently falls into memory execution, because somebody used something like a custom function. But the “where” was applied down the line. So it has to load almost everything.

[@TheOnlyDominik]

I ❤ Linq. I would quit!

[@malignate4sd]

In my first job (around .NET 2.0 or .NET 3.0) we were not allowed to use Interfaces. There was a core team which has built all the complicated stuff and like 80 other developers for the boring code and the core team thought that the other developers are not capable to use interfaces. I was only working part time because I studied CS and I was responsible for tools and infrastructure code, which was not part of the core product. So I just ignored them and after a few months of fighting with the core team they gave up and just accepted it.

[@alissoncandatem1896]

Bruh for what REASON it was not allowed to use interfaces? how can someone write software nowadays without that? i mean yeah there's language out there that does not have but when talking about OOP there's no way avoiding that(not that you want to avoid something so valuable as interfaces)

[@NikorouKitsunerou]

C# without interfaces it like an omelet without eggs.

[@nanvlad]

@@alissoncandatem1896 maybe they wanted to avoid boxing if structs inherited interfaces...

[@hasmich]

In the end what matters most is the reasons behind a decision. People tend to focus on decisions outcome, but if you think about it the process of making decision is much more influential for long-term outcome. If one uses "because something is bad" explanation then there's no reason to treat that seriously, but there are scenarios where decision you described would make perfect sense - it just depends on use case, what they were trying to achieve and did the decision bring them closer to the goal they had in mind.

[@BTimelessC]

My ex boss banned me from using unit tests. Because they waste time. That was after I had implemented unit tests and we were catching bugs way faster and more efficient and we could prove that. Now, I'm enjoying my unemployment.

[@sanglin9387]

i dislike unit test . autocommit 0 and log much faster catch bugs

[@user-jc6pe2bp1y]

@@sanglin9387 everyone dislikes unit tests but the purpose of unit tests is to catch the same issues over and over again so a change doesn’t reintroduce a bug. The purpose of logs is to identify what caused the bug and potentially where to fix it. Should have both for major projects

[@sanglin9387]

@@user-jc6pe2bp1y when business flow change way fast , the client expects ready next day user acceptance test . What common maybe unit test in first time project too see the flow , afterward no time at all . Boss just want money

[@chewbaccarampage]

We use unit tests as a design tool. Basically the team tests out APIs of classes with unit tests and it allows us to build the same implementation multiple times to compare performance without launching the app. We use property based tests to catch bugs... But if one dislikes unit tests, property tests aren't gonna fly. They are expensive to write and maintain.

[@czcibor6436]

If my manager would said something like that he would receive my resignation letter before he would be able to elaborate why

[@haxi52]

This is just insane. I agree with everything you said. Where I work, it's not "Banned" but highly discouraged developers from using the primary constructor syntax. There are some features/patterns that we stay away from just for consistency across the code base.

[@spikedgav]

I worked in a place years ago where the boss banned the use of objects in javascript because "objects are slow". His alternative to using an object as a hash was to use a string and encode / decode it. He reasoned that "CPUs have instructions for handling strings" He had never actually tried to benchmark what he had done. My solution to dealing with the dumb boss in the story would be to start writing the new code; but at the same time, create benchmarks for whatever the new replacement for Linq was. Turn it into a science lesson. Its possible some of the new methods would be faster

[@1992jamo]

The query syntax can be a lot nicer to read in some specific scenarios.

[@Terry151151]

And it has the very useful "let" keyword.

[@AndersReinhardtHansen]

@@Terry151151 you can just use a statement block in your code, but the point of linq is also the lambda syntax, which forces you to write code without side effects

[@brentsteyn6671]

I agree

[@VoroninPavel]

@@Terry151151 Unfortunately, the implementation of let is not nice. They could do better.

[@Thorarin]

Your non-LINQ code doesn't need a list though, so not really a fair comparison 😉

[@_iPilot]

And it is not necessary to split calculation to two loops imitating the structure of the original LINQ query

[@kingoflol9352]

So should you avoid using the query syntax even when you are using something like entity framework core to create some very komplex database queries? I tend to use it when I need joins and group by since it's a lot less code than the method syntax

[@F1nalspace]

I use linq all time time: FirstOrDefault(), Any(), Where(), Count(), Sum(), etc. But i rarely do more than 3 conditions/conversions in one chain. Also i very often use ToArray(), because i require the full results very often and pass them around. If i really have performance problems, then its most likely because i process single data instead of multiple data. In that case, restructuring the data is the way to go and sometimes i even create data structures, just to process the performance critcal stuff and push the results back into its original data. This is much more efficient, than processing large objects directly - wasting insame amount of CPU cycles, due to cache misses.

[@funkykoval78]

Nick I use Linq to compare +100K List loaded from file with empty dataverse Linq.IQueryable entityset to check the changes, the compare query takes 2.5h am I doing something wrong or is it how long it should take?

[@tallnavyguy5382]

For the first LINQ example, I can think of a much less expensive way to "write it out by hand:" var oldSum = Enumerable.Range(0, 1000) .Select(x => x * 2) .Where(x => x > 20) .Sum(); Console.WriteLine(oldSum); var sum = 0; for(var i = 0; i < 1000; i++) { if (i < 11) continue; sum += i*2; } Console.WriteLine(sum); If you run the code, both Console.WriteLine() statements should give the same result. But, notice where Nick did two loops -- one loop to make a list of the doubles of the numbers from 0 - 999, and then a second loop to compose the sum, I can do it with just one for loop. I know that 10 * 2 = 20, and I only want to take the sum of those values in my doubled sequence that are strictly greater than 20. Okay, that is easy. If i < 11, then simply skip to the next loop iteration. Otherwise, add 2 times i to the sum. You can benefit to do a little math first.

[@stefano_schmidt]

Honestly, have no idea what he was thinking about writing that "equivalent" example

[@arturwolf8689]

If you would like to do the math first, consider this: var oldSum = Enumerable.Range(11, 1000) .Select(x => x * 2) .Sum(); Console.WriteLine(oldSum); var sum = 0; for (var i = 11; i < 1000; i++) { sum += i * 2; } Console.WriteLine(sum); But even if you don't want (or can't) do it, I still would write the example a little bit different: var sum = 0; for (var i = 0; i < 1000; i++) { var product = i * 2; if (product > 20) { sum += product; } } Console.WriteLine(sum); Edit: @iifnox already posted the exact same algorithm.

[@TheSilent333]

I can't imagine doing my job without LINQ. I don't think I've developed anything in the last 10 years that didn't use it in some way. I love LINQ - but query syntax gives me Forest Whitaker eye hahaha

[@user-jc6pe2bp1y]

🤣😂

[@iifnox]

3:20 you unnecessarily exaggerated non linq approach - new list creation? cmon. No one - ever - write solution for "summation of doubled integer that are > 20" like you did. Non linq version could be just: var sum = 0; for (var i = 0; i < 1000; i++) { var doubled = i * 2; if (doubled > 20) sum += doubled; } Console.WriteLine(sum); Also I'm interested how upper code would behave in benchmarks compared to linq :)

[@stevemerckel9061]

I really enjoy LINQ, especially the extension method syntax. I am less of a fan of the query syntax, but often use it when doing SQL-ish queries makes more sense. Occasionally I use ReSharper's ability to disable and re-enable suggestions for optimizing certain for(each) loops to query syntax. If the ReSharper suggestion looks unwieldly, then I'll revert it back and use the feature to remove noise. I like seeing the green checkmark on files checked by ReSharper.

[@dawizze1]

yooo cool to see a redit post I was reading is shown on here hahaha

[@davidmartensson273]

About the Query vs extension syntax, I agree that I very much prefer the extension syntax in almost any case, except if you do some complex left join like processing. Doing that with extension syntax is also very complex and int that specific case the query syntax I feel is slightly better, mostly because it in some way is comparable to SQL syntax (still quite different).

[@Albi91vl]

Not ban but discouraged the use of static classes because of that one programmer that didn't line DI

[@yoanashih761]

At my previous company, I wasn't permitted to utilize any syntax introduced after .NET Framework 3.5. Yes, you heard that right, .NET Framework 3.5. It seems they insisted on adhering strictly to their 'coding style,' which, to put it mildly, seemed to have been established back in the Stone Age...

[@stoino1848]

Once had collegue who just pressed "to linq" in resharper everywhere. Made a 4 layer nested for loop into a mega linq expressing. I asked if he still can explain the code, he said "no". We had a training for the whole team on linq. Extension method style. I would quit if linq is removed from my toolset for no good reason. One of the best features every c# dev should know

[@adambickford8720]

Same luddites in java where they think anything that uses a higher order function is 'unreadable'. Is it 5x less readable? Cuz at 1/5 the code to do the same thing, we're still even.

[@vincent06]

One problem with debugging LINQ is when you analyze a memory dump because the stack is harder to read (lot of anonymous functions with generics)

[@asedtf]

Literally a skill issue, the stack makes perfect sense once you know what enumerators are. And it's a better stack than whatever handrolled loop bonanza you'd have instead

[@vincent06]

​@@asedtf A different opinion is not necessarily a 'skill issues'. I think this expression is really overused and makes developpers look arrogant.

[@meltygear5955]

@@vincent06 "Harder" implies an objective metric of difficulty. If it's a matter of opinion that means that someone has it easier, and therefore it is only harder for you, which can be alleviated with effortful practice. "Skill issue" is just a short way to avoid all the pedantry I just wrote which you know but chose to ignore out of some perceived objective(?) arrogance.

[@joshuawillis7874]

I think the argument that debugging LINQ is difficult is hugely misleading. What are you actually debugging? The only time LINQ statements should introduce complexity to the point where debugging becomes a valid piece in your toolset is when you're introducing closures - and that's debuggable in LINQ: the F9 key will set a breakpoint inside the closure. If you're working with IQueryable, then inspect the SQL statement generated using logging. I have never experienced an issue debugging LINQ code and I think when people say they have, it's because people aren't familiar with best-practice or their toolset.

[@vincent06]

​@@meltygear5955 LINQ adds a layer of abstraction with not named functions so the stack is objectively less readable. It is of course manageable but I can't say it doesn't make my job (which include debugging mixed native/managed memory dumps from the production) harder.

[@srkidd12]

I had a friend who worked at a place that banned, yes BANNED, the use of indexes in their database tables. Needless to say, he didn't stay there long. They just couldn't understand why he wanted to leave.

[@LoKSET]

If the story is true, it's highly likely the boss/manager will see this video and start wondering who snitched lol

[@DEZK90]

That was also the rule in a company I was in. The reason was: "What if we move away from VB then we would need to translate everything"... They were also against Serializers and wrote XML from scratch. Had methods that took 16 different values and didn't use objects because they thought those were bad. In VB... I left after a year of trying to push for change. Sometimes be the change you want to see is leaving the company and finding one that wants to change

[@davidskidmore3442]

"wrote XML from scratch" *shudders* I've seen so much bad XML reading and writing code. So much.

[@mr.nobody4494]

There are a monthly suscription?

[@joost00719]

The only thing I can think of is that linq queries are executed multiple times, but that's not a mistake of linq, but just not knowing how IEnumerable works.

[@VoroninPavel]

There's even a warning for this nowadays, so it's easy to catch.

[@jongeduard]

This is why ToArray and ToList where invented, to buffer the data. 😉 As soon as you need to iterate same data more than once (for example first do Count and then foreach, which is a common usage), then you want to buffer. Same thing with Streams in Java, where you have toArray, or iterators in Rust, where you have the collect method.

[@jongeduard]

Definitely it's the counter based loops which are the most error prone. Inherently. The reason is that counting can have bugs. Off-by-one errors, index out of range. The familiar problems. Both functional programming style (LINQ) and foreach are much safer, because these do not depend this manual aspect. The counting is done automatically under the hood. So that should already define your first choice by definition. Just limit classic for loops to performance critical code in most cases. In the cases that you also work with Spans and things. Otherwise there is rarely a reason these days.

[@petedavis7970]

"I don't understand how it works, so YOU can't use it!" Sounds to me like this employer ought not be micro-managing a development team.

[@krislogy]

One thing I banned for a few years: Optional function arguments, especially for VB. The motivation was driven more out of stopping people from making the legacy code messier. For e.g., for any new functionality, add a new optional argument so that you don't have to handle all the other places that function is called. That's just being lazy.

[@99aabbccddeeff]

LINQ is about how I met the good friend of mine some years ago. He just said "we don't use LINQ in the project" (in most cases) . It was so interesting for me that I couldn't stop asking him WHY? In general, they had a project with many critical for performance places and it was the real reason why they avoided LINQ in many places. It was not just "we don't use it" without any reason. They made benchmarks for that.

[@MrSmertnick]

As a gamedev using Unity, I want to say that LINQ is great. That said, the general rule of thumb is: avoid LINQ in Update (method that runs every frame). However it is one of those "common knowledge" things, that might be out of date

[@BrunoJuchli]

when using LanguageExt, the query syntax makes concatenating bind operations on multiple Eithers or Options very nicely readable.

[@KodingKuma]

I went through many jobs and I can name 2 organizations those don't like LINQ, 1 of them was just a story from a Co-worker, the other one was witnessing my own. Here's the story, I was under a boss that came from the company that hates LINQ and that explains the 2 places. It all boils down to incompetence. Had a software development boss that knows nothing about object oriented programming basics.

[@michelnunes4421]

I'm kinda new to C#, but can you even write EF Core queries w/o LINQ? Btw, this breakpoint in the middle of the LINQ is a Rider feature? I can't manage to do that in VS

[@SG_01]

In visual studio you can still do it by putting the cursor on the code in the lambda and pressing F9 (toggle breakpoint)

[@kevifarr]

I had my manager to tell me that I shouldnt do early returns in my code. and these were highlighted one by one in all code reviews, should I run too?

[@TheRicherthanyouguy]

I’ll play a little devil’s advocate only because at my work I have seen some awful linq statements basically 100 lines of linq. That said the solution is education not banning as Scott eluded to.

[@VoroninPavel]

Agree, quite often deferred enumeration leads to O(n^2+) performance because of multiple enumerations. But there are analyzer warnings for this.

[@TheRicherthanyouguy]

@@VoroninPavel exactly!. We shouldn't call Any if our collection is concrete and has a count or length property but again there are warnings for this and even then those issues are performance problems but they don't make the code any harder or easier to read.

[@WileeRunner42]

I like the LINQ query syntax especially for the select many scenario and other complex queries. Just do a .AsParallel to make its execution parallel using all available logical processors. It is lazily evaluated so some thought has to be given to its performance in each usage. The simple ones I try to use the extension methods.

[@martinmilbret8952]

Good Luck with working with Entity Framework or any other Lib/Tool with Collections xD

[@BryanKelly]

I saw that on Reddit too the other day. And I got angry for the poster. I'm glad you did this video to answer the comments. I totally agree, LINQ in itself is not bad. You can certainly do bad things with it, but that is not LINQ's fault.

[@parlor3115]

I'm on board when it comes to the query syntax.

[@madks13]

Hello Nick. Although i agree with what you said in the video, i must admit i do not agree with the manual loops you wrote. They do not do the same work the LINQ part does. The LINQ part only returns the sum and doesn't care about anything else, but your manual loops create an additional list. I think the LINQ equivalent could be done in a single loop without a list. I am not sure why you wrote it that way.

[@cosmin1584]

Yes, you can do the sum in the first loop. I also don't understand why he created two loops

[@AndyZakk]

I totally agree. However, in the specific example you showed, it looks like the manual version was purposely written with 2 for loops and an you made use of an unnecessary list. It can all be done within the first loop without the extra list declaration.

[@zorglug]

Came here to say the same. This example seems a bit disingenuous.

[@veritron]

I like linq, but there are cases when it can make the code harder to debug. Sometimes I get asked to analyze a log file where the stack trace fingers a LINQ method such as Enumerable.Single, but then when I look at the original method, there will be multiple invocations of the same LINQ method, and I can't tell which one threw from the stack trace, and so I don't actually know why the code failed without going through the slow process of replicating the bug and manually debugging. It would be nice if resharper or some other tool could suggest breaking up the method to avoid this situation.

[@CraigLuna]

The nicest part of the linq query syntax is the ability to do let and easier table like joins

[@mekowgli]

Personally, I use the query syntax whenever I have to do joins.

[@danbance5799]

I get this. Even after 15 years, my brain really really does not like lambda expressions. The syntax just doesn't fit with 40 years of coding experience. But... I would never tell my staff not to use them. If you aren't developing on current standard practices, you're going to be obsolete and unable to find a job after a few years. That's just the reality of it all.

[@Hyp3rSon1X]

In our team there was a huge discussion of whether the usage of 'var' should be banned or not (We're using Java 17 btw). Restricting the usage for certain cases I would understand, but I don't get why people are going for a global ban the second they see a few examples of when a certain function or feature should not be used...

[@anonimxwz]

i think that can be valid if someone use linq wrongly and a do a trash code, for example there is people who put a ton of stuff inside a where or a select that would be a lot more readable on a regular loop. But if you use linq in a proper way, that is a very usefull tool that helps to read and write better.

[@andreyz3133]

I'm requiring of new video of how to rewrite linq query syntax into linq with joins, properties, etc.

[@brettr8263]

I love linq, and I agree with Nick, practically completely. But the one point I disagree on....BTW, I have changed my mind over the years...I think that the "query comprehension"(sql like) syntax *is less* preferred *if and only if* the linq is linq to sql (or linq to entities)...and the reason is because the more sql-like linq syntax in that context only there, makes it easier to see and debug what sql does (or at least close to perhaps) get generated via the linq...note that I didn't really have to use linq to Entities in previous jobs I've had, but my current job requires it extensively, and it's a pain, when debugging, translating the lamda syntax linq to sql when debugging any possible data problems via sql server management studio.😅

[@ja_mcito]

Maybe LINQ should be mainly part of the optimizing compiler instead of the extension library

[@guenolelacroix6434]

In France, many developers having responsibilities have no training in IT or their knowledge dates from the 2000s. So, they block all innovations, because they are not able to understanding them. And above all, they don't want to make any effort.

[@MrRenneck]

There are some situations, especially with EF queries, where linq query syntax really does have to be used. At least I don't know of a way to get the same kind of control/power out of linq method extensions to join between datasets via a many to many table. I can't remember the specific query I was trying to write where I ran into this issue, but it's definitely come up. That being said, 99% agree. Linq Query syntax is garbage and should be a last resort option.

[@nickbarton3191]

Thank God my management have never heard of it.

[@sunefred]

The only problem with LINQ is that `Select` should have been named `Map` instead. Select makes no sense outside of the context of the relationship with the SQL-inspired query-syntax.

[@CanonOverseer]

You know, I never actually considered that Select doesn't actually make any sense as a name after I learned to use it, Map is much more fitting yeah

[@asagiai4965]

I think this is correct, the term select can sometimes be misleading

[@obinnaokafor6252]

The naming by Linq is more better and natural than the map and filter naming

[@adambickford8720]

@@obinnaokafor6252 Other than EVERY OTHER LANGUAGE using those, sure

[@sunefred]

@@obinnaokafor6252 Select sounds like a filter function to me, i.e. select items out of a set. Am I wrong?

[@user-tk2jy8xr8b]

We had LINQ mostly banned in a highly-performant service to avoid excessive memory allocs and CPU consumption on the previous project. That was ugly. Please don't reject LINQ syntax, Nick, it fits nicely for other monadic types like optionals. I will agree that for IEnumerable it's almost useless, maybe except when you need to cross multiply several collections.

[@ChrisBrandsma]

I’ve seen this in real life. Usually the person doing the banning is convinced that LINQ is only for talking to databases (LinqToSql, or Entity), and will not be convinced otherwise. They also believe ORMs are bad and SProcs are good.

[@pinguincoder]

XD saw that on reddit and was also shocked

[@klocugh12]

When you use List/Array, make sure you actually benefit from what it offers over IEnumerable, e.g., O(1) random access/count done multiple times.

[@Kabbinj]

We have the same rule, with us performance is the reason. The rule is specifically targeting runtime code for unity mobile app builds. Any thoughts on this? Yes, anything running in the physics loop of render loop is highly performance critical, but the typical use cases for linq does not feel like they would be this show. They reference an ancient post on the unity forums by an unity employee BTW. Please form some good arguments for me to help abolish this rule...

[@mattbristo6933]

My team are still struggling with the basic SOLID principles.

[@doughboy_6439]

My workplace banned SOLID because it makes really inefficient code.

[@mattbristo6933]

​@@doughboy_6439and what are they doing instead?

[@arjenmiedema8991]

Hey Nick, Im not against LINQ, but the example code you made is somewhat misleading. You can very easily skip the collection allocation: var nums = Enumerable.Range(0, 1000); var sum = 0; for(int i =0; i < 1000; i++){ int mult = i * 2; if(mult > 20){ sum += mult; } } this should do the same thing without needing any collection allocations. Also you only iterate your enumerable once in this case so it might actually be considerably faster with larger datasets ( in that case you should SIMD this stuff as well but I couldn't be arsed for this example). Anyway it is a good discussion point but I felt the argumentation quickly became quite subjective. Thanks for making me thing about this stuff. Cheers

[@chewbaccarampage]

Lol! I had a similar experience where the tech lead would rewrite Java streams (similar to Linq) into loops. His first rewrite commit created an off by one error - didn't even bother to run the tests. 😂

[@Xaranthos]

I see your point, but as someone that's just started to program properly a year ago or so, I actually still haven't got my head properly around LINQ.

[@JoseFuentesLopez]

Once, in a project, the team refused to build apis due a recomendation from an "experienced programmer who had been worked for the company for years", the real reason was that the programmer didn't know anything about apis.