HN Explorer

Ask HN: Is Elixir Still Relevant?

23 points by linkdd ↗ HN
Few years ago, I was developing in Erlang and a bit in Elixir. That was very enjoyable, because the features of those languages (and especially the OTP framework) makes many things way easier.

I've been looking back at Elixir for a few weeks for one of my project, and I'm worried.

95% of the libraries I would need have not seen any commit since a few years. What's more frightening is that most libraries listed on awesome-elixir[1] seems to be unmaintained too. Almost like the Elixir community died 5 years ago (which I do not believe).

Is this normal? Would you trust a seemingly unmaintained library? If not, would you implement all of that work from scratch?

[1] - https://github.com/h4cc/awesome-elixir

32 comments

[ 3.7 ms ] story [ 93.0 ms ] thread
uberman
I guess it could be argued that maybe Go, Rust, Crystal, or Nim have taken the wind out of the Elixir sails. I personally feel that Elixir is wicked.

Lack of project updates does not necessarily alarm me. I guess it would be a potential yellow flag rather than a disqualification. If it was possible to review bug submissions that might tell me more of a complete picture.

If something works correctly, it does not necessarily need to be always updated to include new features for features sake.

linkdd
> I personally feel that Elixir is wicked

"wicked" as in "great" (I agree) or as in "bad" (I disagree) ?

> Lack of project updates does not necessarily alarm me.

> it does not necessarily need to be always updated to include new features for features sake.

No new features is fine, but in such a state, it's impossible to know if the author still works on it.

When using such a library, I have to assume that if there is a problem, only I will be able/have the motivation to fix it.

linkdd
FWIW, a possible solution would be to build a small go/rust/whatever binary reading JSON from stdin and writing JSON to stdout.

Then call this binary from Elixir with "System.cmd". A bit like a microservice without the network layer in between.

This solves the critical (unmaintained) dependency problem by shifting the concern to another language.

kgraves
now you have two languages in your codebase that your team has to maintain :/
linkdd
The external binary serves only one purpose (UNIX style), therefore its source code is almost 50 LOC.

This is not a problem.

kgraves
until you need to change something in that binary.
linkdd
How is that a problem? The source code for that binary is in the same repository.

I expect developers to know more than one language, especially if one of them is Erlang/Elixir. It's not a stretch to expect a backend/fullstack dev to know Go, Javascript, and/or Python on top of Elixir. It would be more common for them to not know Elixir than the previous 3.

Also 50 LOC is small enough so there is not much complexity. Making that binary grow more than needed should not be validated during code review.

My use case is as follow: I need an implementation of the iCalendar RFC. The current Elixir implementation does not implement the full RFC, especially features that I need. Implementing this myself would be far more complex than 50 LOC in another language, relying on a fully implemented and well tested library.

kgraves
> How is that a problem? The source code for that binary is in the same repository.

OS upgrades, deprecations, maintenance are a thing that makes your binary stop working all of a sudden.

> Also 50 LOC is small enough so there is not much complexity. Making that binary grow more than needed should not be validated during code review.

I've seen bigger lines that makes the binary + Elixir approach not worth the huge maintenance effort. It's like choosing prolog in production, finding out that there is no libraries for it and then hacking together Go binary together with it.

Doesn't make sense.

linkdd
> OS upgrades, deprecations, maintenance are a thing that makes your binary stop working all of a sudden.

Good thing I deploy with Docker/Kubernetes and I have a CI/CD pipeline that will warn me about such cases.

> It's like choosing prolog in production, finding out that there is no libraries for it and then hacking together Go binary together with it.

Hence this thread.

Erlang/Elixir brings so much to the table when it comes to distributed computing.

Kubernetes + Elixir + libcluster + horde, I don't know any other language that gets better than this. And yet, there are still some librairies I would need, that I don't want to implement myself, because I don't trust myself to implement them properly (see other comments where I talk about iCalendar).

So yeah, I need a "hack", and it makes sense to me to delegate the complexity wherever I can.

You could argue that I need to create a microservice, and make an HTTP call. But why make an HTTP call when I can just call the binary without the network layer in between?

elixir_sucks
Or maybe write your whole app in go, that works as well!
akagusu
I don't use Elixir but I can tell you it is still relevant despite the lack of popularity on Github or any other mainstream channel like HN.

Large fintechs, telcos, pharma and food corps use it.

Maybe it's not relevant on Silicon Valley and the Startup World, bbut outside it is.

readonthegoapp
i just started going thru some elixir/phoenix tutorials and it looks esoteric and interesting.

i hadn't really considered whether or not it was an 'alive' ecosystem because i was not considering building anything real with it/them.

but i did have a thought -- let's say Erlang/Elixir -- it's super-duper great, in part or mostly, because it has some insane parallelism/comm/microservices/threading/etc. model.

could we not just 'bolt on' a new language?

so, typescript 'transpiles down' to javascript/ecmascript/something.

scala runs on the java jvm.

can java run on the erlang jvm? or python?

maybe create a typescript-for-erlang?

maybe it already exists and it's called go/rust/etc.

linkdd 

  > it looks esoteric and interesting.
Esoteric maybe, interesting definitely, mainly because:

Elixir compiles to Erlang bytecode, executed by the BEAM (the Erlang VM).

The BEAM provides an implementation of the Actor Model, and Erlang/Elixir embed that model in their syntax.

Erlang's processes are actors, and they can send messages to each other, even if they are not on the same node, this is totally transparent.

On top of that, the OTP framework provides abstractions like:

  - Supervisor: to handle failure of your processes (actors)
  - Application: what you would call today a "microservice"
  - GenServer: to provide RPC to the rest of your application
  - Mnesia: to provide a replicated database to your application
  - and many more
An Erlang/Elixir node runs multiple applications, and they can talk to each other, making your applications aware of their distributed aspect (which enables complex logic that would not easily be done in another language).

Also *hot code reloading*. Whenever you call a function from another module, the BEAM will try to load the most recent version of that module, so you don't need to restart your application (this is not a very common use case, but you don't want to shutdown your flying drone during an upgrade, do you?). Therefore, every function is "async", and every function call (to another module) have an implicit "await".

  > let's say Erlang/Elixir -- it's super-duper great
At that point, it's not an hypothesis anymore to me :)

And I did not talk about pattern matching...

  > could we not just 'bolt on' a new language?
  > maybe create a typescript-for-erlang?
  > maybe it already exists and it's called go/rust/etc.
Typescript/Javascript async model (Promises and the NodeJS event loop) does not translate well to the actor model.

Go & Rust are faaaaaaaaaar behind in term of distributed computing. Maybe because it's not their target?

Erlang provides an interface to build nodes without the BEAM, that can still talk with BEAM nodes:

  - C/C++: https://erlang.org/doc/apps/erl_interface/ei_users_guide.html
  - Java: https://erlang.org/doc/apps/jinterface/jinterface_users_guide.html
  - Python: https://github.com/Pyrlang/Pyrlang
But it's nowhere near perfect IMHO.
brudgers
Erlang is the well maintained OTP language on Beam. Elixir being newbie friendly tends to generate first blushes of excitement...I mean “awesome erlang” is approximately OTP and the standard libraries. Nobody is trying to become famous with it. The idea is to avoid churn instead.
linkdd
Erlang/OTP can evolve as much as it wants (and I'm glad it does), if the ecosystem does not follow it will slow down its adoption/usefulness.

OTP does not cover all the use cases, you may still need to talk to a database/service for example. Take a look at erlmongo[1], whose last commit is 2 years old.

What I understand from what you're saying is "Erlang/OTP is enough, just reinvent the wheel", which does not seem like a viable solution for any business.

  [1] - https://github.com/SergejJurecko/erlmongo
brudgers
What I am saying is that Erlang is predictable. If it ships with a library that library will almost certainly be maintained ten years from now. And it will probably have been written by people with many years of Erlang experience.

It supports OBDC for SQL databases and has Mnesia built in.

But what about Mongo? Mongo says it has OBDC support. https://docs.mongodb.com/bi-connector/master/reference/odbc-...

In the Erlang ecosystem dependencies on random GitHub repositories is a bit of a code smell.

bigbassroller
I have wondered this too. I think it is still relevant, but very niche. Many companies are using Elixir and striving against their competitors, see Mux. IMO the reason libraries aren’t updated often is because Elixir is a completed language with no breaking updates planned [0], so libraries can be created and not need constant breaking updates. Also, you can do many things without using libraries because of Elixir’s and Erlang’s standard libraries and features. As an Elixir developer, I never go to Awesome Elixir to search for libraries. Its recommended to first look at Elixir docs, Erlang docs, Hex package manager or if still no solution found or have questions go to the Elixir Forum or Stackoverflow.

[0]: https://youtu.be/oUZC1s1N42Q

PS: Elixir is f’n awesome!

linkdd
> libraries can be created and not need constant breaking updates.

Yeah, but I've been traumatized by the Javascript ecosystem where a library can end up abandoned any day without warning.

> As an Elixir developer, I never go to Awesome Elixir to search for libraries.

I needed a full implementation of the iCalendar RFC (including recurrence rules), this is a solved problem in Go, Python and Javascript, but not in Elixir.

And I didn't want to spend weeks on partially implementing that huge RFC.

I ended up using Rambo[1] and an external binary in Go that I ship with my release in a Docker image.

I set up a build system based on Makefiles to build everything properly, and compile-time configuration per environment to locate the binary.

  [1] - https://github.com/jayjun/rambo
awful_waffle
I have been working with the PETAL stack and it is incredible. I love Elixir and have only picked it up over the past year or two. There has been a noticeable increase in recruiters reaching out to me about Elixir jobs lately, too.

I think Elixir should be a lot bigger than it is. I have not had an issue or encounter with unmaintained libraries.

runawaybottle
It’s not a resume builder. Your interest is the only thing that matters here.

For example, I could care less about Typescript but that is part of resume driven development.

Elixir is not part of that at the moment.

linkdd
Who talked about "resume builder"?

I could not care less about a resume for 2 reasons,

First, I'm trying to decide if Elixir would be a viable option for my business, based on its ecosystem.

Secondly, the skills I look for in a resume are:

  - methodology (design patterns)
  - data structures knowledge (algorithmic)
  - debugging
Because those are the skills that matter, not the number of language you know. Those skills are needed in ANY language.

The language is just a syntax to express those skills, it can be learned.

joelbluminator
> would be a viable option for my business, based on its ecosystem

You really need to have a compelling reason to use Elixir imo. There are widely used alternatives both for standard web development (php/.net/java/ruby/node) or for special concurrency needs (node/golang). All these alternatives have huge communities and many people you can recruit. It will be way easier to recruit a php / golang guy than an Elixir dev, which means you may have to onboard a person into Elixir. Elixir is still enjoying being somewhat novel, in 5 years it won't even have that - it will just be another stack that is quite small in adoption.

juhatl
My hunch echoes that of other commenters here. That is, it seems like many core libraries have been quite steady and "complete" for a while now, and many people are just using them today to get work done. That isn't to say the language ecosystem would have stagnated, however.

One interesting piece of data comes from Elixirforum.com, arguably the central hub for the Elixir community. In their recent MOTY update [1], they announced that "..to give you an idea of how far we’ve come and how fast Elixir has been growing, in the forum’s first year we served just over 1M pages for the entire year, now, we’re serving a million a month".

The official Elixir language site has also been steadily accumulating more and more case studies [2], which one might consider as sign of health in terms of Elixir being used in the industry. Obviously it's only the success stories being told, though.

Recent news regarding Nx [3], Livebook and Axon suggest there are new doors being opened for Elixir as a language in the AI/ML space. This expands what the language can be used for, and as such, could be considered as another sign of health and vibrancy in the ecosystem.

Looking at something like GitHut [4], it seems like Elixir has maintained a steady position on its rankings in terms of pull requests. This suggests that usage of the language hasn't declined in the recent past.

Lastly, the 10-year Dashbit blog post [5] by José might highlight some other development. While "development" is not synonymous with "health", I feel like the contents can suggest lack of death :)

[1] - https://elixirforum.com/t/2020-motys-and-our-5th-birthday-up... [2] - https://elixir-lang.org/cases.html [3] - https://dashbit.co/blog/nx-numerical-elixir-is-now-publicly-... [4] - https://madnight.github.io/githut/#/pull_requests/2020/4 [5] - https://dashbit.co/blog/ten-years-ish-of-elixir

joelbluminator
Elixir was dropped from the 2020 Stackoverflow survey due to lack of usage (it was there in 2019). In Tiobe index Elixir isn't in the top 45. Jobs aren't that plentiful. Seems like as a community Elixir needs to use alternative measures ("Elixir Forum") because the conventional measures don't look good. And saying Elixir may become a popular option for ML is beyond wishful thinking.
joelbluminator
I think it's hard to get a straight answer to your question. People who are heavily invested in Elixir will tell you everything is fine and use esoteric metrics to prove their case. Follow your hunch and common sense.
mercer
My experience is that most Elixir devs are very excited about their language of choice, but also fair about the pros and cons. In fact, I've been surprised by this compared to the many other language ecosystems I've explored.

For example, while for many Elixir has been a 'step up' from Rails, most advice given, even deep in Elixir land, is that Rails might still be the preferable choice for a variety of reasons.

I imagine part of the reason is that most of 'us' don't use Elixir exclusively, so we can't just bail out of all other ecosystems and do the whole us vs them thing.

On the other hand, the above commenter seems to actively go out of their way to comment negatively about Elixir whenever it's mentioned on HN, and I still don't really understand why anyone would put in that kind of targeted effort.

joelbluminator
Im not at all negative about Elixir. It could be a fantastic tool, I never used it. I do think that its past it peak, is very small and not a wise choice for a new business due to the very small ecosystem. I would say the same about Clojure or Lisp. As a Rubyist, I grudgingly admit it would have been wiser to start a business on Python or PHP than Ruby (though it matters much less than Elixir; Ruby is huge compared to Elixir). But all things being equal as a project owner you go with the ecosystem that has the brighter future. For Elixir it really doesn't look too good imo. It never gained traction like its contemporaries (Golang, Node, Rust, even Scala) and I have no reason to believe some sudden surge in popularity is about to happen. And soon Elixir won't even be new anymore; there will be shinier toys to play with. You will then see a massive exodus of the early Elixir adopters migrating to the new toys and writing blogs "Why we left Elixir for X". It's very painful when it happens, as a Rubyist I can attest. Anyway we can exchange data if you want or you can attack me personally because you don't like what I have to say...
midrus
I used to work for a company that picked up elixir at its peak and after struggling a lot with hiring a few years later they deprecated it and started to replace it where possible with other technologies.

So I totally understand and agree with what you said.

joelbluminator
Thanks! Was it only hiring though or were there other factors? When you dig in Elixir criticism there's quite a lot of issues. Missing / abandoned libraries comes to mind and I suspect its purely functional nature doesn't fit in the brains of many people. Elixir devs try to sell it as just a better Ruby/Rails which is outrageous in my eyes.
midrus
Yes, the ecosystem is a lot smaller. There are not as many well maintained libraries as in Ruby, or node. Just look and compare the numbers in the package managers websites.

Also, the vscode editor plugin for elixir is atrocious.

And finally, this is more of a personal preference, but I don't like compilation, makes development a lot slower. So ruby/python/raw node are better for me.