Comment by querulous | Hacker News Reader

Comment by querulous | Hacker News Reader

Parent Full thread

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

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

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

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!

Reply on news.ycombinator.com