You're really comparing a small subset of what "LINQ-like functional programming" is to the (small) pieces that Kotlin can do.

LINQ is not (just) an interface over some collections. It is a comprehension syntax (that kotlin doesn't have) that works on any types that have Select/SelectMany/Where.

This gives you a lot more power than what Kotlin gives you, as you can 'extend' other things that don't inherit from an IEnumerable<T>; for instance Task or a custom data type that has its own inheritance hierarchy.

The 'comprehension' part means you can deeply nest things (similar to scala's for compehension) without building up a stack of {}. This is quite common when doing asynchronous programming, and Kotlin doesn't really help you out at all here.

It's not a small subset, it's the most popular subset that .NET developers use LINQ for everyday as identified by C#'s 101 LINQ Examples and compares them against the equivalent code in Kotlin. The C# examples does use the LINQ SQL-like DSL whereas other languages get by with a more readable and less indirection version using functional API's available on collections. It's up to the developer which they prefer however the LINQ DSL is no more powerful than regular function chaining with lambdas.

LINQ also allows capturing Expression Trees however that's only useful for developers creating LINQ providers or where they need to capture and rewrite/reproject the expression. None of these examples are in the published LINQ 101 examples as they're usefulness is limited to a small niche of use-cases.

>languages get by with a more readable

I'd love to see how you think the kotlin (or java) version of the following would be more 'readable'

     var result = 
         from a in taska
         from b in taskb
         from c in taskc(b) where c.Contains("blah")
       select c + a;

Again you're just cherry picking a rarely used niche example that benefits from a SQL-like cross join, that you couldn't even map to a real-world example. What's the point, to show it has terse syntax for rare use-cases?

Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent.

>Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent.

It has nothing to do with SQL cross joins across multiple collections.

LINQ is useful for things that aren't even collections! In my example I was using them on a Task<T> to represent an asynchronous computation. This is common code we would write in a large C# application I was on at my previous job.

It's not exactly helping your case that it isn't at all clear what that sample is actually doing and what kind of practical task it might be used for.

I've been doing C# for years, use and enjoy Linq, and I can't remember the last time I touched the comprehension syntax. IIRC, it does make a few relatively obscure things easier than they would be with method and lambda syntax, while there are a few different obscure things that are easier without it. On balance, I lean against it as being yet another sub-language for you and the rest of your team to learn and understand what it's really doing under the hood.

The sample is not clear?! How would you write the same asynchronous code in C# without the LINQ syntax? Can you give an example? All the code does is get a from async taska, b from async task b, feed the result of b into task c to get c, and if c contains blah return c+a asynchronously.

If you understand it, then exactly what are the return types of these tasks and the types of a, b, and c? Are they single objects or IEnumerables?

If they are enumerable, then what exactly does c + a do? It is creating a new enuerable of every a added to every c, like a SQL cross join?

If it is a single object, then what exactly does the where clause do? What does it return if c does not contain blah, and what becomes of a in that case? Does it get returned, added to null, disappear into the ether, or does it figure out that it doesn't need it, and never actually evaluate taska? What happens if taska modified some other state somewhere? For that matter, if it's figuring that out, that would control the order that the tasks are evaluated in. What is that, exactly? Is taska run at the same time as taskb, or does it wait to see if there is actually a c to add to it's result? Or maybe it gets evaluated before or after taskb, or at the same time.

That stuff matters. I'd rather make it clear at a glance what's going on than write something super short and clever that nobody can figure out the details of.

> "LINQ also allows capturing Expression Trees however that's only useful for developers creating LINQ providers or where they need to capture and rewrite/reproject the expression."

As far as I know, LINQ to SQL uses Expression Trees under the hood, I'd argue that even if you're not using them directly, LINQ to SQL is a pretty useful application of LINQ.

Effectively, Expression Trees are what enables custom macros for LINQ. Even if not everyone writes macros, the number of users of those macros is much more widespread.