There’s a lot missing from Go’s stdlib, including obvious uses for its builtin types. If you want Common Lisp’s

  (remove-if-not #'oddp #(1 2 3 4 5))

you have to write a loop from scratch, and then everyone has to read it carefully to learn what it’s doing (and especially what it’s not).

Don’t get too excited about having HTTP or JSON built in, we weren’t using those in 1990 and they’ll surely be replaced by 2050.

Strangely, ANSI CL says that remove-if-not is deprecated.

That probably wouldn't be the case if it had been named retain-if or keep-if; the issue is likely the double negative.

A function which pares down a sequence to just those elements which match a predicate is very useful; why would you deprecate such a thing.

Probably because the idea of the standards group was that you already had REMOVE and COMPLEMENT, so there was no need for it.

These days the function is usually called filter, but I'm not sure it was a commonly used term then.

Even GNU make has $(filter ...) and $(filter-out ...).

It'a terrible name, by the way. A filter separates; it has two outputs. Does a function named filter return the filtrate or the residue? And I just had to look up filtrate to check which one of the two it refers to and what is the opposite term. From now on I will remember that there is residue captured in a filter, and filtrate is not that.

> you have to write a loop from scratch

That would be terrible, those loops are crazy dangerous. I would avoid writing a loop and rather come up with a whole different programming paradigm. Maybe a macro system or something based on category theory?

The problem is that find first, find last, find all, filter, map, flatmap, and reduce all look pretty much the same when written as loops, and writing and reviewing any of these more than once is a poor use of time.

This probably won’t make sense to most people who haven’t used lisp at work for real work, but…

You just really don’t need much to get stuff done with a lisp.