Answer by Tikhon Jelvis:
There's a big difference between design patterns in the enterprise Java "gang-of-four" sense and design patterns in the "commonly recurring idioms" sense.
The gang-of-four patterns are largely not particularly useful in functional languages. They're heavily coupled to imperative languages with some sort of OOP. In a functional language (admittedly, I'm thinking more about Haskell than Scala, but I'm sure it's similar), most of the concrete patterns are either obviated by language features or replaced by libraries. In either case, you don't need to learn anything beyond the language and standard library.
For example, Visitor is replaced by pattern matching and factories are often replaced by curried functions. Once you understand these currying and pattern matching—which are pretty core language features—you don't need any equivalent to visitors or factories or builders or anything. I think language features aren't design patterns. The same goes for patterns like observer which are replaced by things like functional reactive programming—generic, general-purpose libraries. You don't need to think about patterns here because they're entirely encapsulated in a library.
However, functional languages have their own design patterns. We just call them idioms and are much less bureaucratic about it. A concrete example from Haskell would be "smart constructors": in order to enforce an invariant on a data type, you don't export the actual implementation and instead just export a bunch of functions to construct it. I would say that smart constructors are a design pattern, but one which fits functional programming with algebraic data types more than OOP.
In short: the standard Java patterns largely do not apply, but functional programming has patterns of its own.