Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 60 posts

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

#51

Post by feffe »

pjmlp wrote: post #44
mohanmcgeek wrote: post #5

Earlier quoted context omitted.

People who prefer golang use it _because_ it is verbose. Nothing is implicit and that makes good easy to read.

25 years ago.... "People who prefer Java use it _because_ it is verbose. Nothing is implicit and that makes good easy to read." The irony.

Well yes, I was one of the haters back then because it was too verbose (for me). IMHO Go is less verbose than early Java.

It could be less verbose without loosing readability. My two top picks would be to add a ternary expression and a real while loop so that you could write better iterators.

while next := some.Next(); next != nil { // ... }

Such a while loop would be consistent with the if statement support for an assignment and following check.

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

#52

Post by Zababa »

mushyhammer wrote: post #17
davidashe wrote: post #2

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

That habit makes zero sense. Reduce already is a map and filter and one, why do you need to loop it 3 times? Reduce itself is awful to begin with. https://twitter.com/jaffathecake/status/1213077702300852224

> Reduce already is a map and filter and one, why do you need to loop it 3 times?

Because being explicit about intent is important. Map means "transforming each element of the collection", filter means "keeping only some elements of the collection". With both, you only have to write what happens to one element, and it will happen to the whole collection. This makes code easier to read. You don't have to spend energy to understand if the loop is only a transformation, or also filtering. Since you chain them, you can easily isolate each transformation, which makes code easier to read and easier to test.

> Reduce itself is awful to begin with.

I don't really understand what's supposed to be awful about reduce. It's just another form of for loop. I don't see people arguing that for loops are awful. The thread you linked is just someone that's biased against reduce for some reason that I don't quite understand. Reduce makes explicit that when using a for loop and accumulating a result, you need both a base case, and what to do when going from n to n+1. Again, this allows you to isolate the "going from n to n+1" part easily. Recursion itself is great for some problems.

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

#53

Post by assbuttbuttass »

chrismorgan wrote: post #6

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/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, r…

Right, go is just not designed for this kind of functional style, and it will always require a lot of boilerplate and fighting the language to try to write code like this.

I predict that production go code will continue to use for loops for this kind of thing, even once generics are widely established.

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

#54

Post by jackling »

avl999 wrote: post #31

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…

I work with Java day to day. And I definitely fall victim to overuse of a functional style. Starting to think I shouldn't try to fit everything into a stream, but it's hard because that seems to be the general direction my company is going with their SDK.

I do heavily prefer Optionals however when dealing with Values that can be null. Dealing with nullity checks is annoying.

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

#55

Post by geoffjentry »

adam_arthur wrote: post #4

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

My very anecdotal experience has been that all (most?) of the Go fans I know have a heavy Python background and most (all?) of them also have some amount of C experience as well.

From what I've seen of Go, this makes sense to me.

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

#56

Post by kevincox »

geoffjentry wrote: post #55
adam_arthur wrote: post #4

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

My very anecdotal experience has been that all (most?) of the Go fans I know have a heavy Python background and most (all?) of them also have some amount of C experience as well. From what I've seen of Go, this makes sense to me.

I definitely see the C aspect. Go is like a cleaned up C with a tracing garbage collector.

However I'm surprised that many python fans like Go. It seems like just enough static typing to make the patterns that you are used to painful, without enough to actually describe your program.

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

#57

Post by geoffjentry »

kevincox wrote: post #56
geoffjentry wrote: post #55

Earlier quoted context omitted.

My very anecdotal experience has been that all (most?) of the Go fans I know have a heavy Python background and most (all?) of them also have some amount of C experience as well. From what I've seen of Go, this makes sense to me.

I definitely see the C aspect. Go is like a cleaned up C with a tracing garbage collector. However I'm surprised that many python fans like Go. It seems like just enough static typing to make the patterns that you are used to painful, without enough to actually describe your program.

Thinking about it more, I suspect the pattern I've noticed is "C programmers who switched to Python along the way" and less "Python programmers who happened to dabble in C". I'm of a certain age where most everyone started as a C programmer, so there's a bias towards that background in my circle.

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

#58

Post by Mawr »

kevincox wrote: post #56
geoffjentry wrote: post #55

Earlier quoted context omitted.

My very anecdotal experience has been that all (most?) of the Go fans I know have a heavy Python background and most (all?) of them also have some amount of C experience as well. From what I've seen of Go, this makes sense to me.

I definitely see the C aspect. Go is like a cleaned up C with a tracing garbage collector. However I'm surprised that many python fans like Go. It seems like just enough static typing to make the patterns that you are used to painful, without enough to actually describe your program.

Go is follows Python's original principles more closely than modern Python does. Take a look at the Zen of Python [1]. Go fits it far better than Python, sadly.

[1]: https://www.python.org/dev/peps/pep-0020/#the-zen-of-python

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

#59

Post by mushyhammer »

Zababa wrote: post #52
mushyhammer wrote: post #17

Earlier quoted context omitted.

That habit makes zero sense. Reduce already is a map and filter and one, why do you need to loop it 3 times? Reduce itself is awful to begin with. https://twitter.com/jaffathecake/status/1213077702300852224

> Reduce already is a map and filter and one, why do you need to loop it 3 times? Because being explicit about intent is important. Map means "transforming each element of the collection", filter means "keeping only some elements of the collection". With both, you only have to write what happens to one element, and it will happen to the whole collection. This makes code easier to read. You don't have to spend energy…

> what to do when going from n to n+1

You mention the only worthwhile exception: sums and other 3-character operation.

If you’re using reduce to construct objects you’re just better off with a for loop. Having a random awkward named function that only makes sense when plugged into reduce is not any better than just have a function that includes the loop itself:

    - newArray = array.reduce(operation, [])
    + newArray = operation(array)
If you’re used to having infinite chains of loops then of course that’s not going to work.

The problem is that reduce can do anything and most people use it to do anything. It has no advantage over regular for loops unless you’re proficient with real functional programming (if you use forEach() in JavaScript, you’re not)

> With both, you only have to write what happens to one element, and it will happen to the whole collection. This makes code easier to read.

Filter and map are ok. Filter, map and reduce are not, at least not in JavaScript. Try writing the equivalent for loop and you’ll find that it’s just as simple to follow.

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

#60

Post by mohanmcgeek »

marcus_holmes wrote: post #45
mohanmcgeek wrote: post #5

Earlier quoted context omitted.

People who prefer golang use it _because_ it is verbose. Nothing is implicit and that makes good easy to read.

This is me. I've been programming for decades, and the simplicity of Go appeals. Projects like OP's just tell me that OP doesn't understand Go, and why Go was designed the way it was. They're trying to make this cool thing from another language (that they understand and know how to use) work in Go. But if they really understood the philosophy behind Go they wouldn't be doing this (and their life as a Go programmer wo…

I share your opinion overall especially the rails part

but let's not assume the intentions of the OP here. It's perfectly okay for someone to try and implement collections API using generics in go just to see if they could

Post reply on HN