Elixir is a functional language for the Erlang VM. Most C++/Java/Rust/... programmers wpuld have hard time understanding it.

But if you are in a bubble where everyone uses Haskell and talks about Monads, then OPs statement may be valid

I think Elixir is closer to an easier to read Lisp than to Haskell. In fact if someone claimed to know Rust, but couldn't figure out Elixir then I'd simply assume they were lying about their Rust experience.

Monads and Haskell is not a requirement to understand a functional programming language.

Also, I find it hard to believe that anyone who knows N+1 programming languages would have a hard time understanding Elixir quickly, it looks like most mainstream programming languages used today, with slightly different syntax for some things.

Take a look at https://elixir-lang.org/crash-course.html and you'll see what I mean, it's basically Ruby with some slight modifications.

As much as I love Elixir, it's really not just "basically Ruby with some slight modifications". The syntax is similar at a glance, but there are some major design differences (e.g. immutability); solving the same problem in Elixir and Ruby can require a completely different structure to your code.

I wrote this blog post about what I think are the three most important differences between Elixir and Ruby: https://phoenixonrails.com/blog/elixir-for-ruby-developers-t... . There's definitely a learning curve, although it's not insurmountable.

No monads though. No pure functions, no Option types, pretty much no recursion in practice. Really it’s got none of the stuff that makes some FP languages hard to learn. (Except maybe “no for loops”).

That's true - Elixir is simpler to learn than, say, Haskell. All I'm saying is that it's not a trivial jump from Elixir to Ruby, despite the superficially similar syntax.

I don’t think eg ruby->go is a bigger jump. Learn defer, structural typing, interfaces vs learn to replace all loops with map/filter/etc + pattern matching. Feels similar, no?

> it's basically Ruby with some slight modifications.

It /looks/ like Ruby in a lot of ways, but treating it like Ruby w/ modifications is a mistake that I've seen lead to a lot of really bad usage that (at best) fails to take advantage of the underlying Beam VM, and at worst [and more commonly] actively works against it.

I picked it up pretty quickly as primarily a JS dev at the time.

I’ve also worked on several projects where I’ve pair programmed with a dev new to the language. They’re usually pretty productive within a few days. Not writing their own DSLs or going deep into OTP, but productive in terms of writing application code.

Phoenix is pretty straightforward for those who have experience with Rails, Laravel or a similar full-stack web framework.

Don’t forget having to know beam and erlang especially if post junior/intern level where it’s more than just “it looks like ruby”

I’ve used Elixir for half a decade and never had to dig into Erlang.

Rust screams Erlang influence, but maybe it's just me. IIRC, in the beginning they even tried to put in a green threading VM for tail calls, which seems insane for something that you want to be a systems language.

Early Rust was pretty expressly influenced by Erlang.

The green threading runtime was removed in 2014, shortly before the 1.0.0 release in May 2015.

The reason for the waning influence was exactly that: couldn’t be reconciled with systems use cases effectively.

Native green threading instead of async/await would have made for a much more pleasant to use Rust language IMO.

I hate async/await with a passion.