If you build a language that is based around doing everything with stateless data transformations but doesn't address state and branching, it will eventually be a problem, because the reality is that the vast majority of non trivial software needs to deal with plenty of state and branching, not to mention the state and branching that will go in to managing resources.

There are a lot of domain specific tools that are used for specific tasks where the main software is taking care of architecture, high level decisions and resources. Shaders are one example of this. Trying to write non trivial software like this is problematic because the structure you are using is so disconnected from what the software needs to do.

> If you build a language that is based around doing everything with stateless data transformations but doesn't address state and branching, it will eventually be a problem

I'm assuming you are referring to Haskell? It's a general purpose programming language so of course it handles state, branching, etc...

  data Tree a = Empty | Leaf a | Node a [Tree a]
    deriving stock (Show, Functor, Foldable, Traversable)

  label :: Tree a -> Tree (a, Int)
  label t = evalState (traverse f t) 0 where
    f t' = state (\c -> ((t', c), c + 1))

The above code labels nodes of a multiway tree using a counter. State and branching.

That's not state or branching on a high level of a program. It is in some ways the opposite of what I was talking about and a good representation of the problem.

This looks like it is lazily evaluating parts of a tree, which means that you aren't controlling that state, you are hoping that everything works out when you query it with regards to resources, caching, memory layout, memory freeing, etc.

In a non-trivial program that either will need to optimize memory and cpu usage to scale or be careful about how things are structured to maintain interactivity, something like this is likely to be a big problem if that tree gets big.