The Awesome New LINQ Methods Coming in .NET 9!
2024 ж. 11 Ақп.
53 594 Рет қаралды
Use code MODULAR and get 20% off the brand new "Getting Started with Modular Monoliths" course on Dometrain: dometrain.com/course/getting-...
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will introduce you to 3 new LINQ methods coming in .NET 9. Those methods are CountBy, AggregateBy and Index. They were all technically possible before but now it is way easier to implement them.
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
Linq is definitely one of the greatest features of .NET, and I have no idea how I could live without this system.
I'm amazed other langages haven't adopted some sort of similar thing. I honestly think it's one of the greatest programming-related inventions.
Linq was my gateway to F#. It won't ever happen but kinda wished MS finally acknowledge it IS the better language from the ground up rather than keep patching C#.
@@robhunt8378Thank you. I wanted to write the same comment. People who transitioned to F# are not impressed anymore by LINQ. By the way, F# SQLProvider is awesome (but I didn't succeeded to make it work easily with SQLite and cross platform while it works very well with SQLServer)
@@robhunt8378 For your specific use cases F# might be better, but in no way it is or would be remembered as a better language overall. Either you don't have a clue about how the real world of programming is, or you are a troll.
@@poulet_malassis7607 Proof is in the pudding as they say. Functional-first, immutability by default, expressive, concise. MS has been trying to take C# into the F# direction for many years. The cruft is still there. Can't fix bad foundations. Didn't mean to offend anyone though. I forgot people get butthurt even when discussing freakin' programming languages nowadays ROFL.
"amet", third-person singular present active subjunctive of "amo", which means "to love". It basically means [someone] who loves.
Lover?
@@elfanarionit's more "who loves". That is extracted from a text that translates something like: "Nor again is there anyone WHO LOVES or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure."
"Yo amo" in Spanish literally means "I love"
@@unexpectedkAs *yo mama
@@unexpectedkAs Yo no amo. Amar es el comienzo de la palabra Amargura.
Finally an Index method, I always created an extension for that
Me too :)
It's such a "duh" moment for me. I've used the .Select() approach many times before and always thought there had to be a better way, but could never think of what that "better" method would be. But now seeing the .Index() method, it seems so obvious.
Yep it's really convenient. For example Rust has a method like that called enumerate. Same idea.
Ditto here. my function was called WithIndex() so close to this one
Thanks for shaing Nick. Please remember to add it to C# 13 & .NET 9 playlist. Keep coding!
Good stuff as always! It would have been nice to see how the first 2 examples would be implemented before using the new methods, similar to how you did the Index() one :)
Just navigate to the method's source code, and voilà!
CountBy could just be .GroupBy(word => word).Select(g => new { Word = g.Key, Count = g.Count() }) AggregateBy could be .GroupBy(x => x.id).Select(g => new { g.Key, Value = g.Aggregate(seed: 0, func: (totalScore, curr) => totalScore + curr.score) }) I would guess that the new CountBy and AggregateBy would be more optimized than this though. Definitely easier to read and write.
I would like bool In(this T value, params T[] source) to be included. It checks whether value is in source, but source vary. Ex.: person.Name.In("Nick", "John", "Bob")
Essentially the reverse of Contains.
Yeah, it's the Contains method. Easy enough to write as an extension method.
That and many others in "Extenso" Code Library
Dammit, we're not even done migrating to .Net 6.0 LOL
at least you removed the word "Framework" from it
@@yegorandrosov6334 I feel that fr
Couldn't you replace the addition assignment operator += in your AggregateBy func lambda with the addition operator +? Sorry if the reviewer in me prevailed your videos are always awesome :)
for the last one you could do *foreach((int index, string line) in lines.Select((line, index) => (index, line))* if you wanted the order to be the same in both.
I wouldn't mind seeing some LINQ extensions for outer joins. I've been writing my own for a while now.
I would definitely like a video on more unused or hidden gems of Linq (Maybe some under used but powerful Linq methods) Whats your thoughts on using the sql-linq style keywords instead of Linq methods? I am still waiting for the .NET extension update where it expands on extension methods ;)
Index is going to be very useful. I often have to use a for loop and get the value, or even manually i++ in foreach. Nice.
Woohoo more LINQ features for Resharper to recommend and then not work in Entity Framework queries.
In your string split method you should have also used the TrimEntries option or at least also added the remaining whitespace characters to your split function.
Amazing new features. This is why C# is the best. :)
F# had those for ages. IMO a much betyer language than c#, even for OOP code.
Such a nice system!
When I see MaxBy, i expect two exp. 1. Kind of grouping setting. 2 the value for each i want to see max value in each group. Looks strange. It conflict with count by.
Nick, could you please make a video with a library named Morelinq. I used it far long to make things like this, but I'm honestly not truly sure about the performance.
A better way to do joins/merges in linq would always be helpful.
I wonder, do these new features also work with a system such as EntityFramework IQueryables? I wonder how translation would be done for this.
they can always refuse to translate it and throw an exception. even as of now not all LINQ queries are translatable
@@Sander-Brilman No I know, I just wonder if there is going to be translation for these things at all
Link to the post is missing in the description
Kinda confusing that the new methods use 'By' to mean 'GroupBy then apply operation to groups', whereas the old ones are reducers and produce a single result. Honestly I think the old semantics make more sense
A new feature I'd like to see in LINQ is an unstable sort option for Order() / OrderBy(). From my understanding, List.Sort() is faster than List.Order() because Sort() uses an unstable whereas Order() uses a stable sort. Most of the time, I don't need a stable sort.
I'm not even done with Amichai's new vid and my backlog just keeps growing aaaaaaah. Love it :D
Lol same😂😂
Just got through and I think the Unzip() usecase I'm wondering about can maybe be neatly accomplished with AggregateBy() in the future. No particular usecase I'm just a playchild lol
Where can I download this preview sdk? Searching o Google directs me nowhere.
You could just zip you lines with a Enumerable of lineNumbers like this: var lines = File.ReadAllLines("input.txt"); var length = lines.Length; var lineNumbers = Enumerable.Range(1, length + 1); foreach (var line in lines.Zip(lineNumbers)) { Console.WriteLine($"{line.Second}: {line.First}"); }
The aggregate is similar to JS reduce
LINQ, we need more LIIINQ !
Will the new methods be implemented in ef core?
Doubtful! I think we're still waiting for EF Core to support .MaxBy() which has existed since .NET 6, I think. It's annoying how EF Core takes a few major versions to catch up.
I hope they do something to make convertion of dictionary into enumerable any bay more performant. Lot of time sI have a dictionary and Filter with where resulting in an enumerable instead of a new dictionary.
That's an easy extension method to write.
@@gunnarliljas8459I know. Those MayBy, MinBy as well. I just wonder if they can make it performant since it feels very unperformant when doing it myself.
The lyrics of Whenever, Wherever are weird
So they finally have MoreLinq package built-in. Great. Less nugets to install.
Did Microsoft fix edit and continue yet ?
The naming is confusing (but did anyone expected else from Microsoft???) The "By" means something different in "MaxBy" etc where it is reduced and accumulated into single result, vs. these new CountBy means groupBy+apply on the group... This makes it confusing. And the "Index" method.. yeah, but would be probably better something like "WithIndex"
omg dotnet 9
Hmm. Weird seeing the last example. I never would've thought of using linq and would've gone with a for loop instead. Wondering what that might mean from a perf perspective
When he says "We just launched a brand new course" I hear "We just lost..." and I feel bad for a split second.
I think it's very hard to discover the lesser used linq methods.
"Every Single LINQ Extension Method With Examples" - kzhead.info/sun/apGJZrGwo2ebn58/bejne.html. I wish I had this video a decade+ ago.
any hint at a .ForEach() ?
it's slow?
Probably not. This choice is by design. They only wanted to add pure functions to System.Linq.Enumerable, nothing with side effects. And foreach is by definition imperative. It performs work, it does not produce output values. Apart from that it's extremely simple to write one yourself.
@@jongeduard Many of the linq functions are very easy to write. If that is any metric, the api wouldnt be very useful. On the other hand, everyone having their own implementation of this very easy to add functionality, should be reason enough to add this. So everyone can finally use THE ONE ForEach, and not having to repeatedly writing new versions that are all the same.
@@yetanotherdex The idea is that you should not use a function at all, but the foreach statement, which is also very simple to write. That's the point. And just like LINQ, the foreach is based on IEnumerable as well. However, it is an opinion an a design choice, not a rule. It is idomatic in C# in this way. However in Rust, most things produce a value, there are no real statements. And in Rust they also have a foreach function indeed. Although even there the statement version is more popular. It would not surprise me if they actually added the function in C# that not many people will end up using it.
@@jongeduard ill be the one replacing thousands of lines of foreach statements with a single line of foreach function at the end of the linq statement. And I'll be happy because it just looks so much cleaner and thus easier to read. Maybe it's just me 😅
What improvements around LINQ do I want to see? Definitely unfreeze development of Linq Query syntax (from _ in _ select) and extend it for features like aggregation functions, ranges etc. A lot people say, that syntax is not their taste, but quite frequently their argument is, that it lacks those features and combination hybrid of method and query syntax is weird (it actually is), but I personally love that syntax and seeing it being "forgotten" sucks.
I often prefer query syntax for longer LINQ statements. It would be fantastic if Microsoft could integrate full SQL capabilities into LINQ's query syntax. 😎
Why wouldn't they add SQL syntax; then it'll GroupBy(word =>word).Count().Max() It kinda feels better
What would that be in SQL? Count what?
What I really would like to have an Linq is an Or(params..), compatible with entity framework...
How would that syntax be?
can c# be used for data science with such innovative data processing inbuild features? or should i use python ?
Is there any method that let us write a join link query based on a like condition?
I have only just started with .NET 8 and there is already a .NET 9 preview version. Jeez.
Big fan of LINQ overall but honestly I find the aggregate and index ones kinda pointless. Aggregate is one that I honestly feel should be avoided in general due to its habit of obfuscating the code. More lines of code isn't always a bad thing if it better communicates intent. As for Index, the example its trying to fix is weird. Why would you use a foreach and a select for that? A standard for loop/For method will do that just fine as it is
Using a standard loop requires you to predeclare a variable `var i = 0` beforehand and remember to increment in the loop (which you can easily get wrong if you e.g. have a continue in your loop or something). Therefore .Index() or .Select((x, i) => (x, i)) avoids these gotchas.
@@andrewmcclement4464 for loops really don't have this problem. They are specifically structured to provide your initialization; conditional expression; increment.
Min() returns int, MinBy() returns element; Max() returns int, MaxBy() returns element; Count() returns int, CountBy() returns IEnumerable. Looks inconsistent
On the other hand it kinda makes sense. Min, MinBy, Max and MaxBy all return the T of IEnumerable. As for CountBy(), personally I'd call it CountPer(), but I guess it matches GroupBy() as it is.
@@chris-pee Yeah. CountBy IS GroupBy followed by a Select. Almost a bit redundant.
Not to nit pick, should have ' ' and ' ' in the spit chars for the split example 🙄
And he should have used File.ReadLines, not ReadAllLines 🙄
@@NadjibBait Great point. Especially on a system where one of their founders said "Who would ever need more than 640Kb" ☺
I wish we had the option to use a shorter lambda syntax. For example LINQ would be simpler if instead of: items.Where(i => i.Id == 1) you could just write: items.Where(Id == 1) I suppose there's the possibility of a conflict with a local variable, member field, method overload, parameter, etc. but if there's ambiguity, and you want the lambda to take precedence, couldn't that simply be resolved by using the full lambda syntax in those cases?
I don't like this idea. If lambda is not readable, you can extract method and reference it kind of this way - as for example items.Where(ItemIdEqualsOne).
I believe in Kotlin and, as of last year in F# as well, that's Where(_.Id == 1). Personally I like it.
@@chris-pee In Kotlin it would be items.filter { it.id == 1 }
@@vasiliychernov2123 yep, my mistake
That's why they invented the query syntax: from p in people where p.Id == 1 select p That syntax also has some advantages over the lambda syntax, like easier joins, the "let" keyword, more natural grouping. But it's also not complete, so you may have to mix and match it with lambdas, or wrap it so you can do a ToList().
Hi Nick, I see that you are using Rider, for me Rider is very slow, specially when trying to debug, probably you can make a video about how to optimize Rider, tipis or share your settings? Thanks for all your videos
Ryder is slow, even on fast machines. Nick plays screencast videos at double speed 😉😁
But why, why no SortBy() ? Similar to OrderBy, but in place sorting.
SortBy implies modification of the original collection, which isn't the Linq way of doing things. Linq is based on functional concepts, and one of the core aspects of that is immutability. Linq methods should never directly modify the collections they're working with -- or any external state, really -- as a matter of convention. This is also part of why there's no .ForEach() method, I believe. Likewise, Linq chains produce IEnumerables and other generic interfaced collection abstractions, and you can't really do an in-place sort on the IEnumerable result of a Linq chain. Imaging doing .Select(...).SortBy(...) -- it just wouldn't make sense, because at that point in the chain, the connection with the original collection is already lost. In-place sort really only makes sense when performed directly upon the original collection, and generally speaking, collection types already have their own Sort methods that can perform sorting more intelligently as they have awareness of the underlying collection structure.
@@ChamiCh Yeah, yeah. I don't say, I need a LINQ method operating with IEnumerable, it's obviously not possible.
@@siposz if what you want is a method that sorts a list by a simple OrderBy-style selector rather than having to use .Compare() yourself, that's simple enough; here you go: public static void SortBy(this List list, Func keySelector) where TKey : IComparable => list.Sort((s1, s2) => keySelector(s1).CompareTo(keySelector(s2))); You could construct similar extensions for different collection types; I don't believe there's a common interface for .Sort() across different types.
For last one, wouldn't it just be easier to ensure IEnumerable is actually a list, so you can index directly?
And if it isn't? Enumerables and enumerators do not imply that the items do exist beforehand. But they come in a certain order, hence they can have an index. This does not imply at all that you would be able to index the original source. But now you don't have to use a variable of your own if you want a numbered enumeration.
Isn't a list in memory w/a definite size?
If you converted it to a List, all the lines (file) would be loaded in memory. Although in Nick's example it wouldn't matter since he's using File.ReadAllLines, which returns an array, not an IEnumerable (File.ReadLines would be the method to use).
So, they have taken a few, but not all, of the MoreLINQ extensions. Why not just take the whole thing instead of creating future build conflicts.
They are trying to take the most useful ones and leave out those which are less useful - there is a very high bar to getting into the standard library.
But one thing is bugging me. All Linq methods are extensions. Why Microsoft have to make us wait until .Net 9 to make it available. Just publish a nugget package. All of the samples you've shown are methods that could be easily done now with the code that is already available (and I am sure most of us already have something similar created). Microsoft has a System.Linq Nuget package that haven't been updated since 2016 (it is in version 4.3.0 now). Maybe just release a version 8 with the new stuff and make it not compatible with the Net 9 framework so it has to be removed or upgraded when using the new runtime.
Hope LINQ query syntax gets more updates to add the missing features. - it's so useful and elegant! "var topRoles = (from user in Users group user by user.Role into g let requests = g.SelectMany(u => u.UserLog.FailedRequest.Concat(u.UserLog.SuccessFullTransactions)) let count = requests.Count() orderby count descending select g.Key.DisplayName).Take(3);" (from my analytics dashboard - most active roles)
Partition, Window… basically just everything in kotlin’s Iterable
That Index() method still looks weird.... Why would it return a tuple? Why would anyone understand that Index returns a tuple with the Index and value?
C# dev team popping out new features every month just to avoid layoffs
Lol, they have over 5000 issues backlog. If they will be laid off it won't be because of lack of work.
.NET 8 was released in Nov. of 2023. How in the holy hell are we already talking about preview 2 of .NET 9 in early-mid February?
.NET features are very often already being considered for new versions before a previous version was even released. Heavily depends on if it should be part of a .NET version with how much time is left to implement and test.
How many times will this same type of comment happen? Development doesn’t stop once a version is released lol
There yearly releases at this point with the even number ones being LTS versions
I hear you. It's always been like this. At least .NET is relatively stable.
@@metaltyphoon Well, unless you worked on the VB compiler team. (Too soon?)
that is why i love .NET every year we get creat optimizations not like JAVA which is stuck since release xDD
"Lorem ipsum" is FAKE Latin. It is not Latin. It only looks like Latin. Not only that, but it does not mean anything. It is only placeholder text.
These ..by() extensions will be nice to replace this pattern. Groupby orderby firstordefault. The Linq group by just never feels intuitive to me.
I can imagine how slow the Index method is, because it looks like you are allocating a new tuple of index and string, each iteration. At this point i would just do a for loop instead.
First
You too fast
OrDefault
Single
@@nickchapsas oof. low blow, nick lmao
@@nickchapsas thanks for responding!
Mmmmm lasagna
i do not like linq MaxBy. if two results are tied for the max, you only get one back. it might be important to know if there was more than one value at the max. and if you're reading from a database, the order of the data will change over time so your expected results could change. i do not think i will ever use this method as a result. i would rather use morelinq maxima because at least it works the way i would expect which is anything with the maximum maxby value
Why don't they implement all that into .net 8 or lets say .net 8.1. something
9 .net 8 isn’t in lts yet
.net 9 ffs can we just slow down please
No weirder than any other. Maybe she used AI to write the lyrics?
So C# basically copied the Javascript's higher order functions
The flub with the "' sed" shows why one should never split words with string splitting characters. Even the Regex Split with "'\W" is far better than the naive solution. Or depending on what you want better Regex.Split(phrase, @"(\W|')+") for English.
📝 Summary of Key Points: 📌 The speaker introduces new link methods coming in .NET 9, acknowledging that link has faced criticism for its performance but believes the productivity gained outweighs any performance issues. 🧐 The first method shown is the "count" method, which calculates the count in a collection based on a specific property or value. 🚀 The second method shown is the "aggregate by" method, allowing for aggregation based on a key selector. 📌 The third method shown is the "index" method, a more concise way to achieve the same result as using a select statement with both the value and index. 📣 The speaker concludes by mentioning the possibility of more link methods being added in the future and encourages viewers to subscribe for updates. They also ask for viewers' thoughts on the new methods and any suggestions for future link methods. 💡 Additional Insights and Observations: 💬 "The productivity gained outweighs any performance issues." 🌐 The speaker encourages viewers to subscribe for more updates on new features. 📣 Concluding Remarks: The speaker introduces new link methods in .NET 9, addressing the criticism of link's performance by emphasizing the productivity gained. They demonstrate the "count," "aggregate by," and "index" methods with hands-on examples. The speaker concludes by expressing the possibility of more link methods in the future and encourages viewers to provide feedback and suggestions. Generated using TalkBud
Lorem ipsum isn't really Latin.. en.wikipedia.org/wiki/Lorem_ipsum