In LINQ, the extension methods defined on IEnumerable are useful, but not that interesting, because they are standard functionality in most modern languages. I also think the naming used (e.g. Where, Select) is unfortunate and it would be better to go with the naming used by other languages/frameworks that are much more standard, like filter() or map(). This implementation is also missing SelectMany (e.g. flatMap or bind), which is much more interesting than Select and Where (i.e. you can implement Select and Where in terms of SelectMany).<p>What makes LINQ special is IQueryable, e.g. the ability to transform a C# expression at runtime into something else, like a database query. Whenever I see article titles like "LINQ in X", I somehow know that it doesn't refer to IQueryable, which is a pity.<p>Anyway, these functions should be standard in any modern programming language and because Go is missing such standard functionality is one reason for why I don't like Go. Lack of generics has much to do with it, but also Go's interfaces are weaker than type-classes, combined with Google's disregard for everything we've learned about type-systems in the past 30 years (behold Dart's covariant generics) and so I do have reasons for not holding my breath waiting for a fix. Of course, Go is what many people want, so Go is what many people receive.
Another approach using code generation is gen:
<a href="http://clipperhouse.github.io/gen/" rel="nofollow">http://clipperhouse.github.io/gen/</a><p>(Disclaimer, I work with the guy behind it)<p>Personally these sorts of libraries just strengthen my opinion that golang really needs proper generics. However, if you're already gonna use Go they're pretty neat.
From the documentation:
> So if you have 1M elements as input to a plinq function, you will end up 1M goroutines.<p>> Theoretically, there is not much wrong with that.<p>Understatement in the finest tradition of man pages and RFCs.
Worth noting that the syntax example is slightly incorrect.<p>Since go auto-postpends ; to lines, you must have a trailing . on the line to allow the compiler to consider multiline statements like this as multiline statements instead of multiple (syntactically incorrect) single statements.<p>I presume this is just done for readability in the docs, but it's a little misleading. Correctly, it would be:<p><pre><code> over18Names, err := From(students). // <--- Notice the trailing . to prevent ;
Where(func (s T) (bool,error){
return s.(*Student).age >= 18, nil
}).
Select(func (s T) (T,error){
return s.(*Student).name, nil
}).
Results()
</code></pre>
It's argued now and then that this is one of the reasons go isn't useful for chain expression libraries like this; it becomes hard to tell at a glance the difference between two consecutive statements and one chained long statement.<p>(The other reason typically given is it breaks error return expectations, but whatever. I've never really understood what's so hard about simple having the .Final() or .Resolve() or .Results() statement at the end of a chain to get the return code and/or error details <i>shrug</i>)
The real language part of LINQ isn't the simple sequence functions (.NET had them before LINQ), it's the LINQ monad embedded into the language.<p>While personally I don't think I've ever used the LINQ monad syntax, and wish it had been implemented as a generic feature, not every language with support for anonymous functions or closures or function pointers is "LINQ".