To answer the headline: Functional languages are as useful in pretty much any context non-functional ones are, they just need to be handled a little different.

Functional languages’ goal tend to lean towards static or predictable typing and reduction of clandestine mutable state changes. State has to change in a program, it’s just about how its handled, and this is more about reducing referential update behavior.

Like in Python, you can have a list, pass that to a function that returns None, but deep inside that function appends to the list, and you may be surprised that your list is different as a result. This would (typically) not happen in an FP language, you would have to explicitly return the changed list up the stack of functions, and as a dev you could see from a glance that the list could change as a result of the function, leading to less surprises.

“IO” is of course an outlier, as it’s leaving the safety bubble the language provided. I could read the same database row twice in 60 seconds and get a different result, because someone else could make a transaction in that time. But once I have read the row and parsed it into a data-model, I can expect that my model in-code won’t change unless I tell it to.

Functional programming languages can be extremely beautiful when doing a task suited to them, but extremely ugly and cumbersome when doing anything not suited.

With an imperative language you can always fall back on C-style for loops and manipulating state. It may not be beautiful but it’s fine. But if you need to use an STArray in Haskell, every single access is through a verbose function call without even array access syntax.

So I would suggest either finding a toy project to do in a pure functional language, or else use a mixed paradigm language and make maximum use of its functional features.

On databases, yeah database access is by definition stateful. It can be encapsulated in a monad, but that just means it’s not a good fit for pure functional programming.

It’s good to have some experience with them even just to know what tools may work best for a situation. I’d suggest something close to what you already know, C# -> F#, java -> clojure or scala, declaritive -> ML or Haskell, etc. dynamic vs static and strong vs weak typing systems can have a big impact on how you think about programs. Debuggers vs REPLs vs compiler warnings vs generic logs are all going to be different too on top of the paradigm like functional that will have different approaches. Minimizing the other differences makes it easier to focus on and learn the functional stuff.

If you look at samples of a bunch and none are clicking I’d start with any that has dynamic typing, REPL style like common lisp, scheme, elixir. They are simple to get started with coming from python dynamic typing and options for interpreter & compiled, and you can add dependency management and interop and other stuff on top later. RDMS SQL is generally a static typed, declaritive style language. If you want a similar functional language look at ML, Haskell. But even in functional languages you’ll usually use a library or driver or language feature specifically for interacting with RDMS, you may use pandas in python and datomic in clojure.

The big things to focus on are understanding common idioms like combining functions in call chains using basic functions map, reduce, & filter, etc, creating new objects with charges instead of changing in place (non mutable), and higher order functions/function composition that lack of mutability restriction allows.

deleted by creator

Not at all. Plenty of functional services run at scale at multinational companies. I personally prefer them over OOP.

What’s so special about database access? You pull data out. You transform it. You put data in. It’s just functions all the way down!