"Stop Using LINQ in .NET!"
Vložit
- čas přidán 17. 04. 2024
- 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
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
Gru looking perplexed: have LINQ without MS doing the unit tests for you
The next step will be that the boss also prohibits `yield return` and Enumerators. 💀
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.
Indeed. Some managers have a very poor understanding or too conservative approach of the technology.
Many managers know nothing about software engineering and I mean nothing.
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.
Unfortunately, I have to agree with that (excep for my current job).
That's why I refuse to listen to management for technical things
Time to quit.
The redditor's boss probably will watch this video now.
I don't let anyone on my team use classes they're too risky
I don't let anyone in my team use static functions, can you imagine how many stack overflow can happen with those?
I wouldn't let them use Interfaces because it's hard to debug and read😢
haha struct all da way🎉
I dont let anyone on my team use computers they're too risky
What about variables? 😂
"LINQ is hard to read/debug"
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.
100% behind you. If anything, yes, those intermediate vars are what makes debugging "simpler" not not using LINQ.
@@vincent06 So just like ALL code?
There is no worse offender than mutable, imperative code
@@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
@@adambickford8720 Yep but in my experience it is worse with LINQ queries.
I would change employer. What an idiotic mandate.
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
Sounds painful.
"The manager said it could mess up the database." sounds like a skill issue
@@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.
WHAT! I'd walk out at the point of starting.
@@yupii1997 Like this smart reddit poster said: "RUN"
@@deado7282 did do. Three months later my internship was over, offered me to continue as junior, couldnt say no to the offer faster
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.
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 :)
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."
That is different. Don't introduce any unnecessary not well supported libs.
Wtf? I really didn't expect this to get so much traction.
But I'm a Nick Chapsas Video. Cool! :D
I’d fire you man 😂
But are you gonna send this to the engineering manager that made the decision? :)
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.
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.
@@phizc Hanselman calling your boss would be the real world equivalent of Zeb Macahan entering the scene in How the West Was Won.
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
This! We're using linq during initialization of systems and menus. We avoid using linq on any update loop.
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.
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.
Yep, when you need multiple joins or group joins.
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.
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#.
I'm not using it except outer joins. In these cases it is much easier syntax.
I like it as well, it reads like a haskell do block or an sql statement.
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.
No direct… but just do `var a = firstpart; var b = secondpart using a; ` It’s not hard to read.
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.
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.
@@abj136 And then take a bonus 2 hour lunch once a month! :)
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.
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
I mean I would forbid the use of goto too, but just the keyword
Well, the goto comes in quite handy when exiting two loops, but I agree that in most cases it should be avoided
@@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.
Last checkin before i left would be a bunch of comments
// goto hell
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.
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.
There is only "must not". Must is just what's left.
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.
@@davew2040xThere are some absolutely beyond shocking ways to doing things though.
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.
Completely agree. I use the method chaining syntax predominately, but there are very good use cases for the query syntax.
I would stay at that company, but I would demand 30x raise, because I would be the only dev left there.
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.
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.
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
Considering that LINQ on its own has nothing to do with relational databases, I think you made the right choice.
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.
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.
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.
Linq was added in .NET framework 3.5
@@britishjames9415 later than I thought, still a long time ago. It’s come along way since those early days.
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.
@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.
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.
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)
C# without interfaces it like an omelet without eggs.
@@alissoncandatem1896 maybe they wanted to avoid boxing if structs inherited interfaces...
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.
FirstOrDefault is LINQ, I couldn't use C# without it.
Also GroupBy, OrderBy and Select
Same
And Where
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.
i dislike unit test . autocommit 0 and log much faster catch bugs
@@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
@@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
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.
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
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
As an F# fan, I love LINQ in C# because it makes C# look like F#.
I'm so excited I got to see one of the five F# developers here
Here is one. Only three left. Where are they?
@@asedtf 🤣🤣🤣🤣🤣🤣
I wrote some pet projects in f#
@@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?"
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.
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.
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,
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.
@@bernierm Or before the VS warning, enumerate the same query without a ToList before, rerunning the root query.
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.
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.
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.
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
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.
Honestly, have no idea what he was thinking about writing that "equivalent" example
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.
The query syntax can be a lot nicer to read in some specific scenarios.
And it has the very useful "let" keyword.
@@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
I agree
@@Terry151151 Unfortunately, the implementation of let is not nice. They could do better.
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
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
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.
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.
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?
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
"wrote XML from scratch" *shudders* I've seen so much bad XML reading and writing code. So much.
Removing the best parts of .NET
That's Microsoft for you
@@haroldcruz8550 What
Omg, I read this reddit post and thought "Nick has to make a video" and here we are :Ddd
Nick-driven-development
Not ban but discouraged the use of static classes because of that one programmer that didn't line DI
If my manager would said something like that he would receive my resignation letter before he would be able to elaborate why
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...
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.
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)
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
@@asedtf A different opinion is not necessarily a 'skill issues'. I think this expression is really overused and makes developpers look arrogant.
@@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.
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.
@@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.
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.
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.
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.
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.
There's even a warning for this nowadays, so it's easy to catch.
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.
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.
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 :)
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.
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.
Came here to say the same. This example seems a bit disingenuous.
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
🤣😂
I ❤ Linq. I would quit!
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.
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).
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.
Your non-LINQ code doesn't need a list though, so not really a fair comparison 😉
And it is not necessary to split calculation to two loops imitating the structure of the original LINQ query
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.
Yes, you can do the sum in the first loop. I also don't understand why he created two loops
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.
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.
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...
when using LanguageExt, the query syntax makes concatenating bind operations on multiple Eithers or Options very nicely readable.
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
In visual studio you can still do it by putting the cursor on the code in the lambda and pressing F9 (toggle breakpoint)
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
I work in C# within the Unity game engine, and the company I'm currently working for hasn't banned Linq, but it's well known it's preferred you don't use it. I feel at least it's justified in that scenario, as it's incredibly easy for developers to write code that will be executed per frame, and it takes a while for juniors/mid to understand the patterns that don't relly on the update loops. Unity for the longest time now also uses an older version of C# and Linq and just seems to cause a lot more garbage to be collected, causing the garbage collector to run, causing dropped frames and non-consistant performance.
That being said, I've written a lot of Linq, especially for loading and setting up UI elements, and they've been perfectly fine with that. I do come from a C# API background though so I've had a lot more experience with it than my peers.
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.
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.😅
LINQ is so great to use, debug, and support, I keep porting its methods to PHP and other languages. That manager is probably an old-school programmer who keeps writing imperative code and expects everyone in the team to do so too. Probably doesn't even know what's the difference between imperative and declarative, and thinks its a language design. Nah, OP should either escalate to a company wide discussion and fight back or just leave. Or straight up tell that person is incompetent
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.
Agree, quite often deferred enumeration leads to O(n^2+) performance because of multiple enumerations. But there are analyzer warnings for this.
@@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.
Linq was banned in my first job. So as a junior, I was forced, to write many nested foreaches, if statements etc... Horrible. It was also forbidden to use EF 😂
Now, I'm forced to use both - LINQ and EF. Guess where it was easier to develop my skills and to deliver the code (with tests of course 😊)
People, who make such decisions, don't understand LINQ and EF and they are afraid to use it.
I use LINQ everywhere where I can. When working with objects I use method syntax, when working with db I use query syntax, because query syntax better translates to the SQL being generated under the hood. And if my boss would tell me to stop using LINQ everywhere, then I would quit the project or the entire company.
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.
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.
Had the entirety of .NET Core banned at my previous company because one project (using a beta version of Core 1.0) went poorly.
Managed to convince them to change their minds thankfully, still crazy.
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.
I prefer the extension methods when working with LINQ. However, I don't mind query syntax if there is a join involved. I may use query syntax to define the join but then back to the extension methods for the other parts of the query.
Maybe LINQ should be mainly part of the optimizing compiler instead of the extension library
I'm requiring of new video of how to rewrite linq query syntax into linq with joins, properties, etc.
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...
Where I work, banning linq resulted in massive performance gains (memory and CPU) across the board. However, we are still running our C# stack on a modified version of Mono; it might not have been so dramatic in dotNet.
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
Originally i used to despise linq like no tomorrow. Once i started working with people and projects that used it heavily and everywhere - it was very hard to read and understand (first time seeing it). Over time i learned how to use it and realized how easy it is to read, write and understand. Once discussing it with some other people they mentioned its performance for mobile games was bad due to how it can be abused and how slow some phones can be. (Unity uses a very old version of LinQ). Now i love using it in sparce places and love heard how over time it will get faster without any work from me.
Still prefer writing my own loops but for places that may need the performance (1/1000) but i'll leap at LinQ just to speed up what i'm working on and if its a problem i'll solve it later (which it never is)
For games on hot code paths, using linq unless done very carefully results in a lot of small memory allocations. We recently went through and removed a ton of linq and replaced it with traditional for loops, is the code longer and uglier... yeah, is it faster and produces less memory allocations... yeah
"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.
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.
yooo cool to see a redit post I was reading is shown on here hahaha
Love LINQ/functional patterns but we don't use it because it heap allocates delegates and doesn't overwrite collections in-place (ToList etc). We don't want GC stalls in our games. Hand-writing loops can be annoying, but with the right helper methods you can eliminate a lot of duplication.
We do use LINQ in our internal tooling because there's no reason not to. In a language like Rust you can use all these features without concern, but that's not a real world option for us.
Banning LINQ across the board is a ridiculous decision. But if it's in the context of using it to generate queries from a DB via EF then I'm all for that. Avoid EF like the plague, write your own SQL queries and then use a lightweight ORM like Dapper. Any good developer should be an expert in writing SQL.
Honestly, writing your own expression tree parser to generate SQL or other query languages from LINQ methods is not awful. Devs in my group have done it several times so we can use LINQ to query different non-SQL systems.
we got function pointers banned in C cause of safety reasons (related crashes)
your first example is not written well, you could argue that the loops can be combined and the intermediate list removed since its not used anywhere
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?
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.
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
I've never liked the Linq query syntax, but I love the Linq extension method syntax.
But definitely don't be using Linq on a hot path or in a situation where too many allocations could end up actually causing performance problems. Most of the time Linq is going to be less CPU and memory efficient than using foreach/for loops, but it is absolutely worth the performance cost because 99% of the time that performance cost is not going to negatively affect you.
There's also LinqAF so you can still have Linq if you are in an environment where too many allocations will cause problems. LinqAF has way fewer allocations, but is a little slower than normal Linq.
Seems like a misunderstanding. The most important is "The SQL queries are hardcoded using their ugly old ORM". This says everything. If they have large legacy monolith with own ORM, and they have new developers coming and using LINQ queries without thinking about performance, what happens in production? Sometimes reading millions of rows of data from db just to filter them in memory. In such case performance impact is HUGE. So what do you do? Create a rule: DO NOT USE LINQ. USE OUR UGLY ORM INSTEAD. I would do the same.
Not all projects are new, small, and in latest C#. For some projects is almost impossible to rewrite data layer. If you don't like it, you should leave, sure.
This! 👍
My only problem with LINQ is when someone write 25 unformatted lines of chained Select and SelectMany and OfType etc... starting with some overcomplicated dictionary with classes full of properies containg list or sets of complicated classes. But it is not LINQ propblem but wrong desing.
The nicest part of the linq query syntax is the ability to do let and easier table like joins