3 ms·

This isn't an argument in bad faith or anything but if all this is so good why is Elixir not more popular? If it's basically Ruby on Erlang (which is what it fe

This isn't an argument in bad faith or anything but if all this is so good why is Elixir not more popular? If it's basically Ruby on Erlang (which is what it feels like), you'd think it would've been trivial to retool a rails project to it and take advantage of this insane benefit. Instead the big switch was first to Scala (because of Twitter) and then Python (Dropbox et al.). But yet here we are. Python is absolutely dominant in web and ML stuff. C is still one of the most popular languages to date. Elixir and Rust barely break top 50. We can't say people don't know about it. Surely if it was insanely powerful Google, Facebook, etc or some huge popular open source project would prove it's utility. Why isn't it more popular? I ask this, because I have a hard time staking any project I make or work I do on languages that are always sold as extremely powerful but end up being a niche that has been memed into popularity (Rust falls in this category).

Jtsummers 4y ago
I'd wager Twitter switched to Scala instead of Elixir because it existed when they were moving away from Ruby and Elixir didn't. Maybe they still would have if Elixir had existed, but it didn't so we can't know. And Elixir is not "basically Ruby on Erlang". It adopts some Ruby stylings and Ruby's metaprogramming habits, but the language and underlying libraries are quite a bit different. If for no other reason than Elixir is not an OO language and Ruby is (and heavily depends on its OO model for many things). "trivial" is probably a word most of us need to excise from our vocabularies, translating Ruby -> Elixir may not be the hardest thing in the world, but it's not trivial.
querulous 4y ago
elixir is (was?) very parochial. for a long time it didn't fit neatly in the same shaped box as comparable applications written in ruby or python or java or whatever. part of this was technical (it's a compiled language without any of the effort c or java got in packaging and distribution so operations were complicated when compared to mainstream languages) and part of this was cultural (the infamous 'you don't need x if you use elixir' testimonials) but it combined to scare people who weren't interested in being elixir enthusiasts away. there was definitely a sort of stepford wives vibe around the community where people who just wanted to know how to use elixir to read some data from kafka or redis or deploy an http api or whatever were met with scolding and admonishment for not embracing elixir and eschewing everything they knew. things are definitely better now but i think the damage was done. elixir has a reputation now for being an outsider language i also think elixir was hurt early by overselling of erlang and the erlang vm. a lot of the "groundbreaking" technology in the erlang vm was groundbreaking but in 1996 not post 2015. even now you can see people talking about how elixir makes parallel programming trivial when it's more or less trivial in all languages now (albeit via libraries or extensions sometimes and not natively). elixir's implementation is quite crude in comparison to some of it's competitors. the same goes for the "seamless distribution" that erlang/elixir proponents talk up. it's just a fully peered tcp mesh and a very simple binary encoding with a tiny rpc framework on top. it's something you could replicate in any language in a weekend (but you probably wouldn't bother. it's not very useful in a modern context). the promise very rarely delivered and people went back to more familiar languages i think elixir had a brief window to get popular when go was still in it's infancy and nodejs was all written callback style pre async/await and java.util.concurrent was considered arcane knowledge but it failed to get a big enough community that could sustain it once go and nodejs and java got almost as good at concurrency as it was and didn't expect you to forget half of everything you knew about building and operating software. without a clear technical advantage people preferred the familiar
- shiryel 4y ago
  Elixir has tradeoffs that many languages refuse to do, like green-threads (from Erlang), that enables you to do many cool things with the concurrency / parallelism / distributed computing bits (and there is a whole ecosystem around these tradeoffs). But the selling point of Elixir for me is the quality of life for the dev, the docs and tooling are amazing, the community is very focused, the language itself is easy to read and extend (with the powerful macro system) and the pattern match system, is one of those things I wish every language had.
  - querulous 4y ago
    elixir's strength is really the dev experience, agreed. i think if the community had leaned harder into that aspect and less on the 'whole new paradigm' aspect of the language it would have been more successful. people want to do the same thing they are doing now but in a more pleasant way. very few people want a revolution
- josevalim 4y ago
  > the erlang vm was groundbreaking but in 1996 not post 2015. even now you can see people talking about how elixir makes parallel programming trivial when it's more or less trivial in all languages now I have to strongly disagree with this argument. :) It borders on “all languages are Turing complete, therefore they are equivalent”, but the truth is that the idioms a language highlights make a huge impact on the software we write. For example, take immutability and concurrency. Making concurrency first class (not an extension), makes you think about concurrency first and you are usually better positioned to deal with Amdahl’s law (i.e. you can use all cores more efficiently). When it comes to distribution, the same abstraction is used by both concurrency and distribution, which is more accessible, easier to test, etc. You get a unified model that is more than bytes over a socket, it includes dispatching to Erlang processes, entity monitoring and naming, etc. Thats not even mentioning other features that come from Erlang processes, such as fault tolerance, preemptive scheduling, and instrumentation. The only confusion - and perhaps what I would have done differently - is that many people equated Erlang distribution to RPC, and that’s something we should have made clearer from day one. Still, I would prefer any language that makes concurrency first class (such as Erlang, Clojure, Go), than one that doesn’t, and there are very few languages that make both concurrency and distribution first class. Personally, if a language doesn’t allow one to transparently multiplex on both IO and CPU, such as Node, then it does not have a good concurrency story.
bongobingo1 4y ago
Scatter shot: Functional programming is and has been, getting more popular, but I think it's hard to argue that it doesn't impact language uptake. Popularity is hard to judge as for every article about it, say 50 people bookmark it to read later, 10 read it and 1 try it, and outside of that there are 10,000 devs who never even clicked the link. That ratio isn't as bright as it appears initially. (1) I also think the deployment story was a bit muddy with Elixir/Phoenix initially, with a few speed bumps. Now Phoenix has a "generate dockerfile" command, as well as more explicit tooling around configuring releases, which I think is a good move. Also it's easy to miss that when you build an Erlang/Elixir release (on the same architecture as your target AFAIK) you actually do get a transportable package (not a single binary) that ships the BEAM runtime etc, so you can actually just rsync the dir somewhere and run it if you want. Deployment even outside of containers is actually pretty easy. I think this is actually undersold by the documentation/community. It's surely no single-binary-multi-arch Go story, but it's easily done. Personally I think it's 110% worth it. Anecdotally, Did people say the same thing about python somewhere in it's 30 year span? "If it's so good why is perl cgi still so popular", "It wont ever be as fast as C", etc. Similarly, Rails came out at a time where webframeworks were ... Symphony? Webforms? None really had the wow that Rails had, but it's not uncommon now so unseating it is a larger task? 1. I think probably Haskell, Clojure and F# probably have the widest "name a functional language" penetration and they all have some baggage. Haskell, IMO most known by osmosis, has obscure syntax and terms, Clojure (probably known of if you write Java) has (what some would term) the dreaded parenthesis-itis and F# has the C#/windows history. Probably some self-biasing here but I think many programmers first exposure will be via Haskell because that's what sticks in your mind as "oh yeah, people say that's cool", then repeatedly bounce off it's pretty dense syntax, terminology and type/side-effect strictness.
- Test0129 4y ago
  Thanks for the post that makes sense. Maybe I'll consider it.
shakow 4y ago
> If it's basically Ruby on Erlang Really, it's not. I don't know how it acquired this reputation if not for using begin/end instead of {}, but it has no more similarities to Ruby than e.g. Perl or Python.

Jtsummers 4y ago

I'd wager Twitter switched to Scala instead of Elixir because it existed when they were moving away from Ruby and Elixir didn't. Maybe they still would have if Elixir had existed, but it didn't so we can't know. And Elixir is not "basically Ruby on Erlang". It adopts some Ruby stylings and Ruby's metaprogramming habits, but the language and underlying libraries are quite a bit different. If for no other reason than Elixir is not an OO language and Ruby is (and heavily depends on its OO model for many things). "trivial" is probably a word most of us need to excise from our vocabularies, translating Ruby -> Elixir may not be the hardest thing in the world, but it's not trivial.

querulous 4y ago

elixir is (was?) very parochial. for a long time it didn't fit neatly in the same shaped box as comparable applications written in ruby or python or java or whatever. part of this was technical (it's a compiled language without any of the effort c or java got in packaging and distribution so operations were complicated when compared to mainstream languages) and part of this was cultural (the infamous 'you don't need x if you use elixir' testimonials) but it combined to scare people who weren't interested in being elixir enthusiasts away. there was definitely a sort of stepford wives vibe around the community where people who just wanted to know how to use elixir to read some data from kafka or redis or deploy an http api or whatever were met with scolding and admonishment for not embracing elixir and eschewing everything they knew. things are definitely better now but i think the damage was done. elixir has a reputation now for being an outsider language i also think elixir was hurt early by overselling of erlang and the erlang vm. a lot of the "groundbreaking" technology in the erlang vm was groundbreaking but in 1996 not post 2015. even now you can see people talking about how elixir makes parallel programming trivial when it's more or less trivial in all languages now (albeit via libraries or extensions sometimes and not natively). elixir's implementation is quite crude in comparison to some of it's competitors. the same goes for the "seamless distribution" that erlang/elixir proponents talk up. it's just a fully peered tcp mesh and a very simple binary encoding with a tiny rpc framework on top. it's something you could replicate in any language in a weekend (but you probably wouldn't bother. it's not very useful in a modern context). the promise very rarely delivered and people went back to more familiar languages i think elixir had a brief window to get popular when go was still in it's infancy and nodejs was all written callback style pre async/await and java.util.concurrent was considered arcane knowledge but it failed to get a big enough community that could sustain it once go and nodejs and java got almost as good at concurrency as it was and didn't expect you to forget half of everything you knew about building and operating software. without a clear technical advantage people preferred the familiar

shiryel 4y ago
Elixir has tradeoffs that many languages refuse to do, like green-threads (from Erlang), that enables you to do many cool things with the concurrency / parallelism / distributed computing bits (and there is a whole ecosystem around these tradeoffs). But the selling point of Elixir for me is the quality of life for the dev, the docs and tooling are amazing, the community is very focused, the language itself is easy to read and extend (with the powerful macro system) and the pattern match system, is one of those things I wish every language had.
- querulous 4y ago
  elixir's strength is really the dev experience, agreed. i think if the community had leaned harder into that aspect and less on the 'whole new paradigm' aspect of the language it would have been more successful. people want to do the same thing they are doing now but in a more pleasant way. very few people want a revolution
josevalim 4y ago
> the erlang vm was groundbreaking but in 1996 not post 2015. even now you can see people talking about how elixir makes parallel programming trivial when it's more or less trivial in all languages now I have to strongly disagree with this argument. :) It borders on “all languages are Turing complete, therefore they are equivalent”, but the truth is that the idioms a language highlights make a huge impact on the software we write. For example, take immutability and concurrency. Making concurrency first class (not an extension), makes you think about concurrency first and you are usually better positioned to deal with Amdahl’s law (i.e. you can use all cores more efficiently). When it comes to distribution, the same abstraction is used by both concurrency and distribution, which is more accessible, easier to test, etc. You get a unified model that is more than bytes over a socket, it includes dispatching to Erlang processes, entity monitoring and naming, etc. Thats not even mentioning other features that come from Erlang processes, such as fault tolerance, preemptive scheduling, and instrumentation. The only confusion - and perhaps what I would have done differently - is that many people equated Erlang distribution to RPC, and that’s something we should have made clearer from day one. Still, I would prefer any language that makes concurrency first class (such as Erlang, Clojure, Go), than one that doesn’t, and there are very few languages that make both concurrency and distribution first class. Personally, if a language doesn’t allow one to transparently multiplex on both IO and CPU, such as Node, then it does not have a good concurrency story.

bongobingo1 4y ago

Scatter shot: Functional programming is and has been, getting more popular, but I think it's hard to argue that it doesn't impact language uptake. Popularity is hard to judge as for every article about it, say 50 people bookmark it to read later, 10 read it and 1 try it, and outside of that there are 10,000 devs who never even clicked the link. That ratio isn't as bright as it appears initially. (1) I also think the deployment story was a bit muddy with Elixir/Phoenix initially, with a few speed bumps. Now Phoenix has a "generate dockerfile" command, as well as more explicit tooling around configuring releases, which I think is a good move. Also it's easy to miss that when you build an Erlang/Elixir release (on the same architecture as your target AFAIK) you actually do get a transportable package (not a single binary) that ships the BEAM runtime etc, so you can actually just rsync the dir somewhere and run it if you want. Deployment even outside of containers is actually pretty easy. I think this is actually undersold by the documentation/community. It's surely no single-binary-multi-arch Go story, but it's easily done. Personally I think it's 110% worth it. Anecdotally, Did people say the same thing about python somewhere in it's 30 year span? "If it's so good why is perl cgi still so popular", "It wont ever be as fast as C", etc. Similarly, Rails came out at a time where webframeworks were ... Symphony? Webforms? None really had the wow that Rails had, but it's not uncommon now so unseating it is a larger task? 1. I think probably Haskell, Clojure and F# probably have the widest "name a functional language" penetration and they all have some baggage. Haskell, IMO most known by osmosis, has obscure syntax and terms, Clojure (probably known of if you write Java) has (what some would term) the dreaded parenthesis-itis and F# has the C#/windows history. Probably some self-biasing here but I think many programmers first exposure will be via Haskell because that's what sticks in your mind as "oh yeah, people say that's cool", then repeatedly bounce off it's pretty dense syntax, terminology and type/side-effect strictness.

Test0129 4y ago
Thanks for the post that makes sense. Maybe I'll consider it.

shakow 4y ago

> If it's basically Ruby on Erlang Really, it's not. I don't know how it acquired this reputation if not for using begin/end instead of {}, but it has no more similarities to Ruby than e.g. Perl or Python.