Functional programming has been the future of programming for 50 years - and always will be. :)
Functional programming doesn't work in applications where you have a large dataset, and need to change some parts of it asynchronously. If you have a 10G array in RAM and need to change one million elements as a function of the values of surrounding elements, you don't want to pass it to a function that computes a new 10G array.
And, since traditional programming lets you write functions, it sounds like functional programming is just a restriction on what you can do. In which case, I can write functional code in Java.
I'm not convinced that "functional" is high on the list of useful programming distinctions. LISP and Prolog are both functional programming languages; yet they are very different.
Also, whenever you build a pure functional language, like pure LISP or pure Prolog, you find you can't use it. So you build in a lot of stuff that isn't functional, like seq and setf, or the cut operator. Then it isn't easy to prove stuff anymore. (If it were possible to develop a programming language that you could prove things about using predicate logic, we would program in predicate logic.)
I disagree regarding your "large dataset' argument. Very frequently, such problems can be easily solved in a functional language using immutable data structures that share portions of their structure. In your example, if that 10GB array were represented as a functional immutable tree with a high branching factor, you could efficiently copy the bits that changed, and point the rest of the tree back to the original copy, incurring a negligible performance penalty.
Because I have been learning about Type Theory, I have become much more aware of and interested in Functional Programming.
If you are unfamiliar with functional programming, Real World Haskell describes functional programming like this:
Because of this functional languages have a number of interesting differences with traditional programming. In functional programming: