today in "Rob Pike thinks you are literally too stupid and will personally make Go worse because of it" https://www.dolthub.com/blog/2024-12-20-collection-functions-in-go-1-23/

@whitequark he's said that publicly multiple times iirc. golang is designed for the average google employee

@bob oh yes, that's what i'm referring to

can't he, like, retire or something

@whitequark high level programming??? wait until I tell you about this great new thing called low level programming

@whitequark for loops are too complex, should just use goto

@whitequark honestly one of the major things that turns me off of Go (the attitude, not the lack of some API in particular).

Also his "juvenile" comment wrt syntax highlighting. I suspect he may be something of an asshole!

@conorh yeah that one pisses me off to no end, especially with how https://go.dev/play is a bland low-contrast slab of mediocrity as a result

@whitequark The source is long gone, but this quote lives rent-free in my head:

Go: Your only limit is Rob Pike's imagination

@ryan 🔥

@whitequark In fact, everything that wasn't in the original FORTRAN (1957) is too complicated, obscures overhead and allocation, and tends to be overused, and thus should be removed from these newfangled languages.

@whitequark It's easier to `break` or `continue` in a for loop.

Never used go, so I'm curious how would you support functionality that in a `Filter()` method.

Do you use exceptions and try/catch?

Do you make the language itself more complicated by supporting the `break` and `continue` keywords inside the lambda function?

Do you have a specially handled value that is returned on the lambda function to break/continue at that point?

Use abort callbacks / effect tracking and algebraic effects?

@spartanatreyu
@whitequark .Filter is not intended to be a 1:1 replacement for for loops

But you can have a .TakeWhile terminate iteration early for example

@charlotte @whitequark ooh nice, take while sounds useful.

Either way I can see not wanting to implement Filter() if it's going to cause unneccessary overhead.

Filter would be more useful it there's no overhead because all the chained functions are using a pull-generator-yield style iterator rather than the classic push iterator but if the language is already set up for classic push style iterators then it wouldn't be useful adding it.

@whitequark I believe he hasn’t been active in Go development for a few years now.

@emmy this is from 2024!