Comment by pdimitar | Hacker News Reader

Comment by pdimitar | Hacker News Reader

I love Elixir and I bet the last 6.5 years of my career on it (and Rust) and I don't regret it for a minute.

And exactly as a guy like that, I would prefer intros be much more technical, cold, even robotic -- and elevator-pitch-like. Yes, even those in books, although I'll admit that it's expected that you have sought such an intro by yourself before reading the book. Still, if I was writing a book I'd include an elevator pitch right at the start.

I attended EuRoKo 2016 where Jose Valim made a lightning talk about Elixir. He did sell Elixir to me in 10 minutes indeed, for which I am extremely grateful. He showed right there and then how you can have two nodes (computers, VMs, even two separate shells on the same machine) distribute work to each other. Demo-ed a few other features and I got immediately interested.

Furthermore, trying to act cute or informal in such a material is a turn off for me. Let's keep it professional, folks.

---

Even with that, I recommend Elixir to anyone who doesn't need beastly speed in their programs and for whom the lack of strict static typing is not a problem. It offers a number of advantages that 99% of all other languages out there don't -- like almost completely transparent parallelization, preemptive scheduling and fault tolerance.

> He did sell Elixir to me in 10 minutes indeed, for which I am extremely grateful.

Could you elaborate on this more?

Elixir’s an interesting beast. On one hand, it’s just Erlang by another name. And yet Elixir also brings some merits of its own. How much of Jose’s pitch was for Elixir-the-alter-Erlang? And how much was for something other than Erlang?

Well I have no experience in Erlang -- only checked it out a few times and I like that Elixir removes some of the more manual aspects of Erlang (like manually exporting functions from a module).

So, why Elixir (and partially why Erlang):

- (Erlang + Elixir) Transparent parallelism. This is not a joke. You're a function + closure away from multiplexing stuff on all your CPU cores (or even more e.g. it's OK to have a limit of a worker pool be 100+ for e.g. network workers).

- (Elixir-specific) A lot of tools around fault tolerance and supervision trees. You can have static hierarchies and you can have dynamic ones (spawn children, have them do work, have them shut down). You can register green threads by name and enforce limits on how many of them are around, you can also load-balance work between several nodes.

- (Elixir-specific) Macros: you can generate code at compile-time which is extremely useful if you want to limit the set of values that you'd work with at run-time. Example: the Unicode functionality of Elixir is actually generated by macros that basically do a `for` loop of all codepoints / graphemes and utilizes pattern-matching on each value. Super tedious by hand, extremely trivial with macros / code-generation. Useful in many other scenarios as well e.g. you can inject code in a receiver module with macros.

- (Erlang + Elixir) Pattern matching. While the languages sadly have no static strong typing, pattern-matching helps a ton e.g. interacting with remote APIs you can match on several expected responses and report everything else to your monitoring system, leading to very effective and prototype-friendly development process.

- (Elixir-specific I think) Flow control. You can basically make pipes of functions exactly like all the classic UNIX tools allow you to. I've heard devs scoff at that a good amount of times... same devs were like "OMG how did I live without this so far?!" a few days later. :D It makes for extremely elegant and readable code that allows near-instant onboarding (or reminding oneself of the code they wrote a while ago).

- (Erlang + Elixir) Built-in in-memory cache. The ability to not care about Redis / memcached is a much bigger deal than many suspect. Granted it's a single-node only but honestly? Never mattered in my practice.

---

There are others but this comment became huge already. Main selling point for me as a senior backender and aspiring sysadmin is the extremely easy parallelism and very terse code (that's owed by the piping mechanism of Elixir). The ability to structure your app as a tree of supevisors and workers (that get auto-restarted on failure nonetheless) is a very close third.

Elixir absolutely isn't a silver bullet -- f.ex. it sucks for CLI apps because the VM takes no less than 0.5s to start -- but for a ton of server apps it's up there in the top 5-10 with Rust and Golang.

> - (Elixir-specific) A lot of tools around fault tolerance and supervision trees. You can have static hierarchies and you can have dynamic ones (spawn children, have them do work, have them shut down). You can register green threads by name and enforce limits on how many of them are around, you can also load-balance work between several nodes.

Maybe Elixir adds some tooling, but supervision trees comes from its Erlang/OTP heritage.

I know that OTP is the primitive below but Elixir adds many interesting and useful tools on top e.g. DynamicSupervisor and even a partitioned supervisor (executing tasks among several nodes).

It basically makes OTP even better by building several useful and often needed real-world tools on top of it.

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).

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.

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

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.

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

> 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.

i don't disagree with you that writing concurrent and parallel programs in erlang/elixir is nicer than in nodejs or go or java. erlang picked a nice set of primitives and elixir extended that with some very good apis. i don't even disagree that language idioms influence software architecture and that elixir and erlang are particularly strong here -- particularly considering otp. however, i just don't think elixir/erlang's concurrency/parallelism story is as important now as it was when erlang was first getting attention for it

at that time the concurrency story in most languages was terrible. non blocking i/o was rare. truly parallel programming was esoteric. that's not the case today though. i am not a huge fan of go but it's undeniable that it has a strong concurrency story AND a strong parallelism story. java has nio and better libraries for concurrent and parallel than it did 10 years ago. even nodejs (which was always the equal of erlang when it came to non blocking i/o) has a very straightforward and fairly efficient worker api for doing parallel computation. languages like rust and swift and julia were born with compelling concurrency and parallelism features

elixir still beats out ruby and python (although python is getting close) but people using ruby and python today largely don't care about these things. they know the limitations and they accept them. if they didn't they have a wealth of languages to pick from

elixir/erlang no longer occupy a unique niche. the other languages have caught up and offer "good enough" libraries and apis. they also bring much to the table that erlang/elixir don't. elixir may lead in concurrent programming but users choose languages that lead in community, ecosystem, compatibility, commercial appeal, etc. for elixir to compete with go, node, java, python it needs (or needed) to offer more

(i say all this as someone who really wishes erlang had 'won'. it's by far my favorite language when you consider solely the syntax and semantics of the code itself. pattern matching should be ubiquitous in modern languages. data should be immutable, full stop. i'd rather write a foldl than a for loop. it didn't win though and the erlang vm is roughly identical today to the erlang vm i was using in 2012 (this isn't to say it hasn't seen improvement but the improvement has been incremental and modest). the ecosystem moves at a glacial pace compared to that of node or go or even a relatively unpopular language like rust or julia)

Agreed that the concurrency gap has narrowed in certain cases or either people don’t care, but I have always seen concurrency/distribution as “enablers”.

You can have the best concurrency story in the world, but if you don’t have good tooling or you don’t focus on the DX, then people will just leave (or perhaps not even start).

Concurrency/distribution is what allows Phoenix to be a real-time, productive, and scalable web framework on its own.

Nerves rely on fault tolerance to bring sanity to embedded systems.

And so on.

In turn those are led by teams who saw the language features and noticed they addressed many issues they were struggling with in other platforms.

But at the end of the day, for languages like Elixir, the frameworks and tools are much better equipped to attract developers than “raw” language features.

PS: disagree on the Erlang VM bit. JIT, dirty NIFs, and maps immediately come to the top of my head as big and important changes in the last 10 years. There have been many usability focused changes in the last 2 years too, in error messages, the shell (upcoming), etc.

we had a third party integration taht required creating a websocket connection for each customer.

Using elixir, all I had to do was hookin hoard, write a genserver and hoard registry. It took about a day without knowing how to do it beforehand. Out of the box it clusters these process accross several machines and handles failover and crash recovery.

yea, try doing that in another language. where else is doing that trivial? Elixir doesn't just handle multicore. it handles multi machine parallelism with ease

> i also think elixir was hurt early by overselling of erlang and the erlang vm.

I remember when this was popular. I picked up erlang myself in the craze and then dropped it. As for the outsider language I think this is why Haskell suffers as well. The community is really not great and it's small enough you tend to run into the same kind of person. The entire community is filled with zealots and you're a heretic if you just want to get things done. I didn't realize elixirs community was the same. Thanks for the insights.

> I didn't realize elixirs community was the same.

This can't be further from the truth. ElixirForum is extremely welcoming. Please don't take the word of one person as a fact just because it seems to confirm a bias about Haskell.

Go and check for yourself. Elixir's community is everything else but elitist or looking down on people.

I can also confirm this, the elixir community is by far one of the most welcoming communities that I have ever seen!

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.

Thanks for the post that makes sense. Maybe I'll consider it.

> 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.

Reply on news.ycombinator.com