One book[1] I read explained this in detail, amongst other similar concepts. It was really interesting and helped me think of how functional concepts could work in OOP languages.
I agree with a lot of those suggestions, but I am still scratching my head at what it means to have "objects with no state", at that point it seems like we just have static methods that are in some namespace which is the object. Having immutability does not get rid of state existing.
Objects do have state, but they can be either mutable or immutable. The link in my original comment describes an immutable stack (written in OCaml, but is fairly readable) where both push and pop returns a new stack object. The original object is never changed. In a mutable stack, push would return void (or unit in OCaml), which signifies a side-effect. pop would return the element, and the object changes in-place.
Yeah, I'm familiar with the pattern, but I wouldn't say that this is a 'stateless' pattern because even having that object is 'state'. I don't think 'stateless' makes sense if objects are involved. I would agree that it's immutable.
There is mutable state on the conceptual level, i.e. what is modelled, but not on the language level abstraction of an object.
There is no mutable data/state on the language level, at least how things are understood in pure functional programming.
But of course mutable state in the real world (for lack of a better term) can still be modeled there.