Pattern matching is awesome, and ML definitely gets the credit here for putting it into practice, but matching is arguably not even part of the functional paradigm. Lots of non-functional languages could greatly benefit from pattern matching and sum types.
And indeed, when you look at a language like Nim and Swift, that's exactly what happened. Rust, too, although Rust is arguably a functional language.
I personally think Rust isn't functional, but rather multi-paradigm with a strong functional influence. But if you were to add TCO and a few other features, I think Rust would be a full-blown functional language, so it may get there yet.
In any case, it's useless arguing over (should have known better than say anything), so this will be my last word on the issue.
I wasn't actually looking to argue; I was looking to understand.
And I guess it's going to come down to "whose definition of FP are we using?" If FP means "I can write in a functional style", there are many more functional languages than if FP means "I can only write in a functional style". That debate - about whose definition of FP is correct - is one that I can't bother to care very much about.
I'm still trying to understand (not argue). How is Rust like Haskell and the ML family? My impression of Rust is that it's like C++ but with clear tracking of who owns what memory.
[Edit: I see that the link from jnbiche is probably going to answer my question, though it's going to take me a while to digest it...]
It's immutable by default, with mutation only when managed (most famously a Haskell thing). It has a rich type system with ADTs and generics but without subtyping (very much the ML/Haskell tradition). It distinguishes between validation-like failures and system-level errors, handling the former with values and the latter with panics (i.e. noncaught exceptions) - Erlang is the most famous example of this style, but it's common in Haskell and ML too. It tries to push functionality into libraries rather than the core language - it seems to care about having sensible, consistent semantics rather than ad-hoc.
It really depends on what you think are the features of Haskell that typify its "family". If you think it's typified by things like type inference, sum types, and typeclasses, then Rust will feel very Haskell-y, but if you think it's typified by higher kinded types, laziness, and functional purity, then it won't feel very Haskell-y at all.
Personally, I think Haskell and C++ are the two biggest influences I feel when using Rust: it has a lot of Haskell's philosophy around data types and polymorphism, and a lot of C++'s philosophy around the life cycle of resources, and the cost of abstractions.
I'm in the "no" camp, personally, but we _did_ inherit a lot of things from OCaml. The initial compiler was written in it, a lot of the syntax and features are inspired by it, and it just _feels_ more ML than Haskell.
Rust may not be a functional language, but it draws heavy inspiration from them.
And indeed, when you look at a language like Nim and Swift, that's exactly what happened. Rust, too, although Rust is arguably a functional language.