

Show HN: LINQ for Go - aabalkan
http://github.com/ahmetalpbalkan/go-linq
s
======
suzuki
The 'LINQ for Go' passes around slices as sequences. It differs in both space
and time complexities from the 'LINQ to Objects' in C#.

A rather proper LINQ implementation in Go is

[http://www.oki-osk.jp/esc/golang/linq3/linq.go.html](http://www.oki-
osk.jp/esc/golang/linq3/linq.go.html) [http://www.oki-
osk.jp/esc/golang/linq3/linq_test.go.html](http://www.oki-
osk.jp/esc/golang/linq3/linq_test.go.html)

and its design and implementation are explained in

[http://www.oki-osk.jp/esc/golang/linq3.html](http://www.oki-
osk.jp/esc/golang/linq3.html)

------
bsaul
I've read many compliments about LINQ and how it was something fundamentally
more powerfull than just a sql wrapper ( i think i remembered the dreaded word
"monad", but i'm not suree), but i haven't found any detailled analysis of the
theory behind that technology.

Anyone got a link to something like that ?

------
macca321
This looks more like a list comprehensions library for Go than a LINQ library.

Actual LINQ is a lot more powerful.

------
monoid
Didn't explore both in depth, but at first glance I prefer the GO underscore
approach: [https://github.com/tobyhede/go-
underscore](https://github.com/tobyhede/go-underscore)

------
viggity
I love everything linq. I love how I can be more expressive and do more with
less. I'm assuming you've had exposure to C# otherwise you wouldn't have
ported the main functionality over to Go. What are your thoughts - I know that
Go has its special use cases but do you find that the more "verbose" nature of
their lamdas junk up your code? Is the extra verbosity offset by Go's other
redeeming qualities?

