[rekoros]

Oh, I don't think there's a universal "better" when it comes to such things, and I'm not implying that one is universally better than the other.

I discovered the Elixir runtime (BEAM) a few years before Elixir was created (we were using the Erlang language then), and for my specific use cases, when I understood the principles of concurrency, error handling, and introspection in BEAM, it caused quite an epiphany. It was also scary, because I had to unlearn pretty much everything I knew :)

From a purely esthetic perspective, I find that pattern matching and tail recursion-enabled programming patterns are more concise, easier to comprehend, and are less error-prone than those offered by the more mainstream languages that don't have those features.

In my experience - and I'm not a particularly great programmer, so it was welcome - I found that I produced code with signifcantly fewer dumb errors when I no longer had access to imperative programming paradigms and was forced to come up with more "functional" solutions.

I don't believe that functional programming is inherently more complex than what we learn in school/college/work with conventional languages. My question really stems from the idea of learning functional first - and I do wonder what that would look like.

[sosodev]

That's a fine perspective but the way you worded your comment was evocative of the typical "X is objectively better than Y" tech comment. Are you aware that Ruby includes a lot of functional programming features (including pattern matching)?

[rekoros]

I think it’s great that functional programming is making its way into traditional imperative languages - even JavaScript (I recently came across https://gcanti.github.io/fp-ts/ as a pretty extreme example)

Elixir/Erlang has function-level pattern matching, which I really like. I’ve yet to see it anywhere else, though my understanding is it came from Prolog.