Functional programming patterns are very common in Rust code. It doesn’t have automatic currying or higher-kinded types but it has generic associated types, anonymous functions, closures, and a rich set of collections with functional processing methods in the standard library.

A lot of the standard library and an extensive part of the community ecosystem lives and breathes mutation at both the edges and in the internals, something people normally would avoid when trying to stick with functional programming. Sure, some mutation is always needed, but Rust wouldn't be the first language I'd pick if I want to focus on functional programming for sure.

No, but it’s widely acknowledged that functional programming features are useful even in imperative languages. Almost every imperative language that isn’t C, Go, or Hare has them. Java, C#, JavaScript, Python, Ruby. You should take a look at all the functions available on iterators in Rust if you haven’t. The Rust community tends to prefer using iterators to express things like looping when possible, which is a more functional style.

Mutation within a single program flow is a well-known functional programming pattern, e.g. as supported by the ST feature in Haskell. Shared mutability is much harder to reason about, so is generally excluded and Rust implements it separately.

Rust is a functional programming language, that's exactly what's implemented in the basic borrow checking rules. Interior mutability is added to that featureset, so as to support procedural programming with shared mutable state.

I can not agree with Rust being a functional programming language. I don’t think it has NO functional style idioms, but the borrow checking does not make it functional. That would imply that the only characteristic of functional programming is some sort of ‘variable’ mutability constraint. I may not be up to defining functional programming by exclusion, I think any definition of functional programming includes things Rust does not have.

It borrowed some FP concepts, it's influenced by FP but it's definitely not an FP language. It's very much a language about imperative, explicit control. And that's a good thing for the use-cases that Rust targets.

It doesn't have in-built immutable data structures, most basic data structures and types are mutable and have mutate in place methods as their primary way of interaction. Struct fields being private by default is a dead giveaway (unnecessary in an FP language). Closures and functions are not the same thing and you cannot do much with them except calling them and passing them around.

I would rather describe it as an imperative language with lightweight OO (via traits) and some FP sprinkled on top. Note I'm not saying you cannot write FP code in it or that Rust doesn't have great unique benefits.

> It doesn't have in-built immutable data structures

Immutable data structures by default would involve avoidable overhead, so that's why they aren't a built in. There are well-known crates that do provide persistent data structures in Rust.

> Struct fields being private by default is a dead giveaway (unnecessary in an FP language).

Data hiding is just as useful in functional programming; in particular, it enables you to expose an interface to data that stays valid under any isomorphism, while preserving desired invariants. Structs with generally accessible and updatable fields are a special case.

You can't do proper functional programming without garbage collected closures. There is a reason why Haskell has a garbage collector ... and it's not "the borrow checker wasn't invented yet".

Haskell uses a garbage collector to enable closures to extend the lifetimes of values they capture within their context. You can do the exact same thing in Rust by using Rc or Arc, it just isn't required in most cases because the borrow checker can verify that the value is not outlived by the closure.