They are purely functional in the sense that NO VARIABLE inside your code can be ever mutable.
However, they do have ETS (which is an in-process cache inside the VM) which is fully mutable and people have long made wrapping libraries around it for transparently working with mutable arrays, double-linked lists, queues, matrices, graphs and what have you.
The philosophy basically is "always work with immutable data except when mutable is more performant or is otherwise more practical". They don't shut the door on you, they just force you to make your intention to work with mutable storage very explicit and clear. That helps a lot when you go hunting inside your code for side effects, too.
As a maturing Elixir dev I can say this philosophy works incredibly well in practice. Code is smaller, much more readable, you don't worry about side effects like ever -- except in very, and I mean VERY RARE occasions (for 1 year of working with it I only had to do that twice) -- and finding a bug is times faster compared to Ruby, Javascript, PHP, Java.
(a) strong visibility of and control over effects,
(b) an emphasis on powerful tools to represent and manipulate data, and
(c) straightforward imperative/stateful aspects when required.
Of course that isn’t to say that no such language exists, but if it does then sadly I have yet to become aware of it. New ideas are always welcome…
For example you can do functional, imperative and OO programming in Common Lisp, and it brings extensive features for working in all these three paradigms.
More recent examples, Racket and Julia.
Now, I am by no means a Lisp expert, so it’s entirely possible that I’m completely unaware of something here. However, I’ve yet to encounter much of an effect system in any flavour of Lisp. Indeed, it’s hard to see how the sort of explicit visibility and control of effects that I’d find useful could be achieved in a language with primarily dynamic typing using any of the approaches I’ve encountered so far.
I don’t know much about Rust so I can’t comment much on that. The intended point of my example was that in a purely functional environment, you can’t have a local, low-level cache, because updating a cache is inherently stateful. So either you need something like a mechanism that lets you break the rules locally, like say unsafePerformIO in Haskell, or you need to infect your entire call chain with whatever mechanism you use to manage effects top-down. While that is perfectly reasonable, given the constraints you choose by adopting a purely functional language, I don’t think it’s particularly helpful.
My conclusion was that I’d rather have a hybrid of imperative and functional styles, contrary to the suggestion in the original presentation and in general agreement with stdbrouw’s comment.