robpike

filter

Go2015–2022

robpike / filter

filter

Simple apply/filter/reduce package.

Explore on GitHub Read Hacker News discussions

15Distinct people

17Mentions

0Explicit recommenders

865GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Simple apply/filter/reduce package.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2015-01-08 09:42:47 UTC to 2022-04-30 02:02:58 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	6	2	4
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	3	0	3
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	0	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	3	0	3
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	0	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	0	1
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	2	0	2

What Hacker News says

17 sources

Mawr·Apr 30, 2022

> I didn't get that desire for purity that you gleaned from it. 'Folks who develop an allergic reaction to "big balls of mutable state without sum types" tend to gravitate towards languages that gives them control over mutability, lifetimes, and lets them build abstractions.' This mutability argument is present throughout the article. Seems like nothing sans Rust or niche functional languages is enough. > Nil pointer exceptions, for example, don't have to exist anymore.. The language most notorious for those is Java due to almost everything being passed via a nullable reference. When everything can be nullable, how can you know where to check for it? Go addresses this to an extent by explicitly separating pointers from values. Values are the default and cannot be nil, so the opportunity for null dereferences is greatly diminished. It's no

Read the rest

t a perfect solution, but it's not nothing either. > and yet they do in Go because they couldn't be bothered to add sum types. Damn those lazy Go devs! > Its type system is barely a step above a dynamic language. Turns out even a basic type system is a huge improvement over none. Just being able to restrict values to concrete types goes a long way. > You have to write the same imperative looping code over and over because Rob Pike would rather just use a for loop than something mildly expressive like map or filter (https://github.com/robpike/filter). There are arguments to be made either way, but I definitely agree generics (along with iterators) should have been there since day 1. > Every function that does meaningful work is littered with if err != nil { return err }. One big positive of this that I don't see in other languages is every `return` in a function must be on the start of a line. That is, every single exit path of a function is easily findable by visually scanning the start of each line for `return`. > you can't encode invariants explicitly I'm curious, are there any limitations here besides enums/sum types?

In Lies we tell ourselves to keep using Golang

thatswrong0·Apr 29, 2022

I didn't get that desire for purity that you gleaned from it. The fact is that (as the author pointed out) Golang is missing basic language features that other languages have adopted since the creation of C that eliminate whole classes of errors, and it's pretty easy to accidentally do the wrong thing as a result. Nil pointer exceptions, for example, don't have to exist anymore.. and yet they do in Go because they couldn't be bothered to add sum types. Its type system is barely a step above a dynamic language. You have to write the same imperative looping code over and over because Rob Pike would rather just use a for loop than something mildly expressive like map or filter (https://github.com/robpike/filter). Every function that does meaningful work is littered with if err != nil { return err }. Etc. It is easy to write code in Go, but I

Read the rest

MO it's not easy to write and maintain a production grade system with any amount of complexity in Go because you _have_ to be careful, you can't encode invariants explicitly and let the compiler find problems for you, and you have to repeat yourself so often.

In Lies we tell ourselves to keep using Golang

WoodenChair·Dec 2, 2021

Go has first-class functions and now has generics. So, you can definitely implement zip, sum, map, filter, reduce, etc. The fact that they're not included in the standard library I think has more to do with the opinionated creators of the language than any limitation[0]. You can absolutely implement them yourself (and a couple of these are pretty trivial to implement) in a library as an aid. I've done that in the past. I miss them too. In fact at the link below you'll see one of the creators explicitly say they're easy to implement (and his own implementation pre-generics) but he doesn't think you should use them (Rob Pike). "Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops. You shouldn't use it either." 0: https://github.com/robpike/filter

In Advent of Code 2021

qtplatypus·Feb 7, 2020

While it was the official position was not passive aggressive. There has been passive aggressiveness coming from the team over it. One of the reasons many people wanted generics so that they could support map/filter/reduce in a type safe manner. This is the response we got from Rob Pike https://github.com/robpike/filter For the longest time the answer about generics was "There are no plans for generics. I said we're going to leave the language; we're done" And the people who have been advocating for generics understand that have downsides. That trade of different forms and placement of complexity (the lack of generics creates complex code in duplicate code for write arounds).

In Proposals for Go 1.15

yahyaheee·Dec 22, 2019

https://github.com/robpike/filter

In The Road to Scala 3

thatswrong0·Jul 17, 2019

Rob Pike would rather use a for loop than map or filter.. so yeah don’t dream too big https://github.com/robpike/filter

In Declined Proposal: A built-in Go error check function, “try”

a-saleh·Jun 19, 2019

I think Rob Pike, one of the inventors doesn't see the value of the functional style, at least that is what I gather from the readme of https://github.com/robpike/filter :P Personally, I would love if the language design was a step closer to I.e. ocaml, especiall if I see the 'this is a struct, but only one of the fields should be not-null' hack to implement sum-types, or when I see how closely select over a channel resembles pattern-matching. But the library ecosystem is good and 'just using forloops' is fine.

In Ask HN: Why Isn't Go Functional?

djur·Jul 13, 2017

Unfortunately, Go is a language whose original creator is of the opinion that map/filter/reduce are just ways to make your program "fit on one line"[1], and that you should just use a for loop[2]. [1]: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... [2]: https://github.com/robpike/filter

In Toward Go 2

AdieuToLogic·Aug 22, 2016

>After all, Go ignores all progress in programming languages for the last 40 years. I've seen this meme being spouted so much every time Go's mentioned it's ridiculous. Is it a meme when it is true? To support this question, witness the statements of Rob Pike[0] below. --- Regarding the utility of supporting first-order functions[1]: I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard. Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops. You shouldn't use it either. --- Regarding progress in programming languages[2]: One thing that is conspicuously absent is of course a type hierarchy. Allow me to be rude about that for a minute. And[2]: Programmers who come to Go from C++ a

Read the rest

nd Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive. --- The part about "particularly inheritance and subclassing and all that" is ironically a meme spouted by Go's community so much it is, if you'll pardon my borrowing your description, ridiculous. For the curious, there are many community "Go-isms" explainable by the Pike talk[2]. Even a casual reading of the "list of significant simplifications in Go"[1] (35 in all) is enough to reasonably support the "ignoring all progress" position. Of course, YMMV. 0 - https://en.wikipedia.org/wiki/Go_(programming_language) 1 - https://github.com/robpike/filter 2 - https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

In What Golang Is and Is Not

thatswrong0·Aug 21, 2016

Yep. Add those and a proper type system and you have yourself a decent language. But when the creator of the language doesn't see the value in abstractions [0], then it's probably never going to happen. [0] https://github.com/robpike/filter

In What Golang Is and Is Not

reycharles·Apr 14, 2016

Rob Pike's repository 'filter'[0] contains implementations of map ("Apply"), filter ("Choose", I believe), and fold/reduce ("Reduce"). The code is an ugly mess, and the implementation shows that he probably hasn't used any of these standard functions in other languages (see the weird permutations of 'filter' in apply.go, or my patch for his fold/reduce implementation[1]). The README is also quite arrogant, IMO. > I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard. > Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops. > You shouldn't use it either. [0]: https://github.com/robpike/filter/ [1]: https://github.com/robpike/filter/pull/1

In Proposal: Go should have generics

Immortalin·Jul 27, 2015

Here's Pike's implementation:https://github.com/robpike/filter

In Show HN: Map, Reduce and Filter in Go

mpweiher·Apr 14, 2015

> mutation and effects can happen anywhere. That's a red herring and a scare-story that FPers tell each other. They can't happen "anywhere". They happen where you tell them to happen. Do you have any evidence that actual reasoning is simpler? "At the end you usually get a tight loop that is easy to follow. It is also much more imperative/operational than before, which may bug Haskell-style people." -- Jonathan Blow https://twitter.com/jonathan_blow/status/588007366618062848 "I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard. Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops. You shouldn't use it either." -- Rob Pike https://github.com/robpike/filter This matches my experience pretty well. When I firs

Read the rest

t created Higher Order Messaging, I was also really into creating chained higher order ops. After a little while, I noticed that a small for-loop was actually more readable than the really cool filter-chains I had created. Less cool, but more readable, comprehensible, easier to reason about, not least because of named intermediate values, something that tends to get lost in point-free style (and trust me, having been a heavy user + implementor of Postscript, I know a little about point-free style).

In Less is more: language features

EugeneOZ·Apr 3, 2015

I don't want to say interface{}=void (at least while type assertion isn't used). But please read comment to Apply function [0] and tell me you don't see usual generics record. [0] https://github.com/robpike/filter/blob/master/apply.go#L19

In Simple apply/filter/reduce package in Go

hyperpape·Apr 3, 2015

This only handles functions of type a -> a -> a (https://github.com/robpike/filter/blob/master/reduce.go), whereas a generic reduce takes functions of type a -> a -> b. So this is certainly not proof that you can write generics in go. See also pmahoney's comment in this thread: https://news.ycombinator.com/item?id=9315721.

In Simple apply/filter/reduce package in Go

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.