> what's the perception re: current blockers for widespread adoption? Years ago, it was nothing more or less than third-party libs and frameworks. That must be better by now, or there's a short-list of what's missing?
It's complicated.
The library/framework situation is much better than it used to be. There isn't much that's glaringly missing anymore. Some things have lighter maintenance than one might like, but most stuff is there.
I think Elixir and the BEAM have a weird problem in that it's somewhat hard to understand their benefits until you use them. This is not the case with a lot of other stuff. If you were coming from Java in the 90s and you saw Ruby, you didn't have to use Ruby to realize just how much less code it took to do similar things. You could just see code examples.
If you used Perl back in the day, you didn't have to actually use Python to see how much easier it was to read Python as a novice compared to Perl's eccentricities.
The BEAM is tough to sell because its benefits are not something you can easily see on a screen at a meetup, for example. "What if you had a VM that was designed for the ground up for concurrency" doesn't sell. People respond with "well my language already has threads and promises". "What if your language gave you a builtin toolkit to partition and restart the various different subsystems in a rigorous, well-defined way?" People say, "I already have systemd and it restarts my services."
Having done it for some years now, the BEAM kinda has "the quality without a name"[0]. It feels "whole" in a way that other environments don't, and that's difficult to show. This is not something that shows up trivially on a slide deck or a landing page, and most people don't want to take a gamble on a smaller language community that's seen as different and weird compared to the more mainstream language they already know, especially when the most positive things they hear are "it's a functional language that does concurrency better". For most people, this just isn't a compelling enough pitch to get them to leave Python or Javascript or Java (or Ruby).
By the way, I'm not blaming folks, this is both a rational and normal way of evaluating risk when faced with an unintelligible upside and an immediately apparent downside (small community, uncertain career prospects, questionable library coverage, etc.). I think as a community, we (Elixir) have done a poor job in making Elixir seem less risky.
> Somewhat of a tangent, but TFA doesn't mention python and I would think for rubyists this is (still) the elephant in the room. It kind of won to the extent they target the same niches and same audiences, for better or worse.
IMHO Python won the war. Ruby won server-side webapps battle with Rails, which is still going strong, but Python won literally everything else by a landslide. And Python still even has Django. Python is _everywhere_. There's no stats on this that I know of, but I bet 90%+ of Ruby usage is Rails. This is not the case with Python.
To be clear, this is all in the context of adoption. Ruby may never have Python's adoption, but Ruby has been hugely influential. Tons of other technology can trace its lineage to Ruby, whether it's Elixir as a language, or Rust's tooling (Cargo), etc.
> I know it's kinda naive, but I was really hoping elixir would get all of the ruby crowd excited, and they'd move the best parts that they can't live without into elixir. Why didn't they / don't they?
Rails still has a large amount of inertia, both technically and culturally. It's still very good at its niche. Getting Rails folks to move away from Rails would take something as better as Rails was than the Java stuff that came before it. Plus, some people just love Ruby! Elixir isn't Ruby. Elixir is more explicit, doesn't have mutability, doesn't have objects, etc. The similarity really ends at syntax, and I think a lot of Ruby folks are happy with what Ruby is, which is totally fine.
Sorry for the long answer.
[0] - https://onluminousgrounds.wordpress.com/2010/04/24/the-quali...
