When you code in a functional style (i.e. not OOP, passing functions as arguments, avoiding mutable state), which Design Patterns are still useful/interesting?
Trivial Builders are often used in java due to lack of named parameters or object literals. Trivial Visitors are sometimes used due to the anemic switch/enum support, although it's gotten a little better with switch expressions and switch patterns. Singletons and factories are used since java metaprogramming usually requires an instance of an class and can't use the class itself. E.g. you can only call interface methods on an instance, unlike e.g. a rust trait where you can call a trait method on a type without an instance of that type.
In non-trivial cases, these are still useful patterns though in many languages. E.g. traversing a complex AST is often an ideal case for a Visitor. Builders are useful e.g. you want to validate relationships between objects, so you keep a hashmap while building so you can do O(1) validation while building and provide targeted error messages, but then throw away the hashmap after building. Builders are especially useful if you avoid mutable state since you can often contain the mutable parts to the Builder and make the built object entirely immutable.
A lot of the patterns are useful, but you would unknowingly "use" them when appropriate without ever having explicitly learned them. E.g. the Adapter pattern is an obvious solution to a particular problem. I think the only contribution the book has for these patterns is giving these names.
All languages have patterns. They differ some between languages as language features dictate what problems need conceptualized solutions that are different from what the language provides. There are also lots and lots of domain specific patterns that are not very documented but which people that work within a domain tend to recognize.
It's been a while so I just looked through the list and... pretty much all of them?
It would be easier to identify the ones that don't make sense. The only obvious one is Observer, since without mutable state there's nothing to observe. Everything else looks relevant for immutable objects.
Alternatively, if you think of the patterns not as names of things, but as the actual solutions presented in the design patterns book, none of them. None of them can be implemented in a non-class language when all the patterns are intrinsically class oriented, and quite heavily so, often actually dependent on inheritance.
Not saying this is the only way of viewing them; there is validity to both but it is I think it is important to keep in mind that the patterns are also supposed to be solutions and not just the names of problems.
What happens as you move around languages is not so much a binary thing, but the relative importance of them changes. Plus you should expect patterns to appear in a new language that weren't in the old language, both because the pattern would be too easy to be a pattern and too difficult to be a pattern. Some will fade away so far that maybe they aren't useful any more.
I really know someone doesn't get the GoF pattern thing when I see "Design Patterns in X" for X != ["Scheme", "C++"] and they are exactly and only the GoF design patterns, implemented in the target language. That is not what they are for. Generally in my experience they're some combination of "wrong", "unidiomatic", and "not the easiest alternative" in the target language anyhow.
Arguably, Haskell's use of monads is a pattern. It just isn't in the GoF, since it doesn't solve a problem that was a problem for the languages the GoF was written for.
