Go Chainable: .map().filter().reduce() in Go

Hmm. Implemented on a custom type that wraps []T, so you have to create a List to get the methods, meaning more boilerplate (a common theme in Go); eager, like JavaScript’s Array methods rather than like the iterator methods in Rust or most&#x2F;all functional programming languages; and since methods can’t have generics (which really surprised me in the Go generics proposal), Map() can only work on the same type (T → T, rather than T → U), and Reduce()’s output type is a generic parameter on the <i>list</i>, so you can only ever reduce to one type (unless you deconstruct and reconstruct the List) which must be specified at instantiation time.<p>As one who works mostly in Rust and JavaScript and is passingly familiar with Go (I used it for a couple of projects eight and nine years ago), these seem some pretty severe limitations.<p>Rust’s trait-based iterator system is <i>delightful</i>, so that you can map, filter, reduce, <i>&amp;c.</i> on any iterator, lazily, and even define an extension trait to define your own methods on any iterator, thereafter accessible by just importing that trait.<p>In the end, I think the current scope of generics and interfaces won’t be enough to produce any feeling other than “shoehorned” for this functional style in Go. It’s just not a style that works well in all types of programming languages.

<a href="https:&#x2F;&#x2F;github.com&#x2F;AlexanderYastrebov&#x2F;stream" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;AlexanderYastrebov&#x2F;stream</a> is my take on this that does not re-allocate full slice on every filter&#x2F;map operation

Are there people with experience in a wide variety of languages that prefer Go?<p>I&#x27;ve only used it in passing, but everytime I see examples they&#x27;re verbose and look clunky.<p>For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code.<p>Do you find Go preferable to other languages for solo projects?

This actually became a problem in Java after the streams API was introduced. A bunch of people in my company started writing Java code that looked nothing like Java with a bunch of chained functional style functions with liberal use of the Optional API where trying to decipher what was actually being done required stopping in your tracks and using the help of the IDE to figure out what type was being returned by each level of the chain. I myself fell victim to this and wrote code which made me feel clever in the moment but looking at it a couple of days later even I couldn&#x27;t understand my own code.<p>If people want to write functional code they should use functional languages rather than writing non-idiomatic code in other languages.<p>Thankfully this style is unlikely to gain popularity in Go because they make the syntax for doing this verbose enough and ugly enough that most people aren&#x27;t gonna bother with it except a top level map or filter.

I hate this. I don&#x27;t know why people insist on forcing this programming style into every language. Loops exist for a reason. They are simple, they work, and nine times out of ten, they are faster than this crap.<p>Not every program needs to be golfed down to one line.

Now that generics are in beta, here&#x27;s a library for those who want ergonomic slice&#x2F;map wrappers that make chainable operations easy.<p>Or, a gateway drug for ECMAscripters who can&#x27;t drop their `.map(x =&gt; y).filter(x =&gt; y).reduce(x =&gt; y)` habit.