Functional programming languages, more often than not, distinguish themselves with some combination of the following features:

* First-order functions

* Partial function application / currying

* Type inference

* Algebraic data types

* Typeclasses

* An emphasis on pure functions (side effects must be explicitly annotated), opening up more possibilities for static analysis

* Lazy evaluation

This is not to say that the above features cannot be emulated by other languages. For instance, Rust has traits, which serve more or less the same practical purpose as Haskell typeclasses.

However, FP is designed to prioritize the above features, whereas other languages may not be.

This quote elsewhere in the thread lines up with my knowledge:

> Functional programming was never about first-class functions. It was always about programming with pure and total functions in their mathematical version.

Other people have correctly pointed out that this is an extremely ambitious idea, since, as they have noted, you can't build a turing-complete language with pure and total functions.

This very high bar explains why there has been so many different design decisions in languages, and why most fp languages make tradeoffs in order to reach a compromise between what they believe is important in that concept, and what they can pull in terms of usable software.

As I noted as a response to that thread, we have seen in the recent years languages that achieve pure/total functions, but this was only possible because so many forebearers had tried different designs, and comprmised to produce usable software they could iterate from.