It depends what you’re building. If you’re writing a library to do those things, they may well be first order. Certain extremely useful patterns like parser combinators rely on them. And of course, the current answer is just “do something else instead.” But I don’t really see why this has to be the answer. Surely the decision to leave them out is just as subjective as a decision to add them.

By the same token, functions in general are second-order things - you can build things just fine with GOTO, and plenty of real-world software was built like that back in the day. But we don't do that anymore.

Yeah, but programming is the business of building little tools to help you build what you actually want to build, over and over again. E.g., you might have some API calls in your code and need to implement an error handler on some of them. You could repeat the error handler code on all of them, or you could extract it out to a generic function and just use it as a wrapper for the others:

    let call1 arg = ...
    let call2 arg = ...

    let error_handler call arg = ...

    let call1 = error_handler call1
    let call2 = error_handler call2

Python made this kind of technique famous, but languages with generics can do it pretty well too.

One example of a thing you want generics for is image processing procedures that operate on many different image formats with different color spaces. If you use the built-in image libraries (which is perhaps already a mistake), then you have an image that owns its channels, and you pass it to some resizing method or whatever, and then that resizing method's innermost loop chases pointers to find out which kind of image it was *for every pixel*. For performance reasons, you may not want to chase pointers in your innermost loop. Without generics, you need to copy and paste a bunch of code once per color space.

To add to your point, not using generics in Go is a choice too, even if it’s now an option.

But some people like offloading that to the language: not having it in a language means you don’t have to control for it on your team/project contributors + some 3rd party library.

I felt Go filled this minimalist category well. It’s always nice having a modern mainstream option doing so, not just a niche one on the fringes (ala LISP), even if I’m not personally a fan.

I guess it’s hard to keep saying no.

Yeah, we should have kept using macro assemblers instead of needless abstractions.

If you believe that absolutely, the way you imply here, then we're all just chumps for not working in Haskell.

I feel like I should probably admit that I am just generally a fan of functional programming and I do think there are big benefits to it, most of the time (of course, some algorithms are just more elegant with loops and mutation). But my day job is writing services with Elixir, so ultimately complaining about generics in Go is a little rich coming from me.

At the end of the day, whatever gets the product built is what matters. I just fail to see how generics could be a hindrance.

Not necessarily Haskell, although it would be nice, there are already enough ML influences in modern languages, with exception of Go.

Confessions of a used programming language salesman

https://dl.acm.org/doi/10.1145/1297027.1297078

> As a result, functional programming has finally reached the masses, except that it is called Visual Basic 9 instead of Haskell 98.

Sure, but programming languages are also tools. Why bother having this discussion at all, if you don't care about tools?