
Ask HN: Who is not betting on Elixir and why not? - techiferous
It&#x27;s easy to find people talking about why they took the gamble to switch to Elixir. I&#x27;m interested in those who have tried out Elixir in production (or a serious prototype, not just dabbling) and then decided not to use it. Why not?
======
bjz_
I'm a bit biased in my development perspective and a bit jaded with the state
of back-end development, but here goes:

I've done a decent amount of Elixir in prod over the last year and a bit and
I've found the lack of a decent, modern static type system pretty frustrating.
I love the idea of failing fast, but most of the time we're throwing 500s from
trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries
like Streams or Ecto.Multi explode in weird, non-local ways because the types
are not checked at the call-site, making refactoring and iterating a chore.

I have tried out Dialyzer, but it lacks many things you would expect from a
modern type system (eg. parametric polymorphism). While experimenting with it
I've been able to get it to accept trivially broken programs without
complaint, which means I've never been really be sure it's got my back, so
have given up on it. And yes, this is with the flags ratcheted to their
highest settings. Not to mention all the third party libraries who forget to
keep their typespecs up to date.

I realise designing a type system that can handle hot-reloading in a cluster
is still an open problem (interesting work in progress on this front though),
but most folks aren't really at the scale where that is a problem. They'd
probably be far better served using a more traditional deployment process
while getting the immediate benefits of the improved iteration speed,
refactoring confidence, and data modelling that languages with modern type
systems provide. The front end is beginning to 'get it' with the likes of
Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their
good work and excitement will eventually flow back to us on the back-end...

~~~
zerr
> excitement will eventually flow back to us on the back-end

Like e.g. Java, Scala, C#?

~~~
bjz_
Scala maybe, but it has its share of problems, alas. On a purely features
level I'd definitely be looking for something with null safety, disjoint
unions, pattern matchin with exhaustiveness checking, local type inference,
and parametric polymorphism (ie. generics). These are what set a modern,
nicely typed language apart from the more constrained, frustrating kind that
caused many to escape to PHP, Ruby, Python, and now Elixir in the first place.
We need a richer experience beyond that though in terms of ecosystem, compiler
performance, teaching materials, etc. in order to really drive things in that
direction though and get more back-end devs on board. Obviously something in
our approach is not working - and it must be partly our failings. It's going
to take a while to turn the ship around, but I still have hope!

------
tatersolid
Coming from the banking industry, nobody looks at using unproven languages or
frameworks unsupported by a large community or major vendor. If you "guess
wrong" on a language you're looking at a multi-million dollar rewrite down the
road which is an unacceptable risk. It's also very difficult to find staff or
contractors who are familiar with new or unpopular tech. Basically any
industry that deals with "real money" or "life and death" intentionally does
not follow developer fads.

~~~
hellbanner
Would you consider Erlang to be a proven language?

[http://www.erlang.org/about](http://www.erlang.org/about)

~~~
ZenoArrow
Erlang != Elixir. They run on the same VM, and you can reference Erlang code
in Elixir but that doesn't make them equally production ready.

~~~
hellbanner
Yes, I understand, I was just wondering if Erlang would be considered a
"proven language".

From my (limited) Erlang experience, Erlang & Elixir have the same core
functionality. Elixir has a "nicer" syntax (I prefer Erlang's syntax but most
devs I've talked to like Elixir's).

So if Elixir isn't proven but the concurrency model & programming paradigms
make sense, maybe Erlang is a good choice.

* WhatsApp Scaling to 1 Billion users in erlang: [https://www.youtube.com/watch?v=c12cYAUTXXs](https://www.youtube.com/watch?v=c12cYAUTXXs) * [https://www.erlang-factory.com/upload/presentations/395/Erla...](https://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf)

~~~
ZenoArrow
> "I was just wondering if Erlang would be considered a "proven language"."

Erlang is proven in production for server and telephony apps.

> "From my (limited) Erlang experience, Erlang & Elixir have the same core
> functionality."

Depends on what you mean by 'core functionality'. If you mean the
functionality provided by Beam VM or OTP, then there's a case to be made for
that. However, the library ecosystem for Elixir is separate from the one for
Erlang.

To use an alternate example, Java is definitely a 'production ready' language
for enterprise software. However, if I write a new language for the JVM, it's
not automatically 'production ready'. In most cases it's the library ecosystem
which is under evaluation, not the platform the language runs on.

~~~
di4na
Just saying, but so far, there have been more critical bugs in erlang solved
due to the Elixir community than Elixir critical bugs solved... so well...

~~~
erszcz
Can you give some examples?

------
whitepoplar
I _love_ elixir, but it's just a language. There are other great languages,
too. Use what fits your brain. Don't listen to what others carry on about. The
only downside I can see for me is that there are fewer, less battle-tested
libraries available as compared to, say, ruby. The most unexpected benefit of
getting into elixir has been the community--it's a positive place to be, and I
feel it has made me a better, more confident programmer. <3

~~~
zaphar
One of the great things about using different languages on my off time is that
the number of things that fit my brain has grown over time. It doesn't
actually take that long for an experienced polyglot programmer to pick up a
new language.

I think use what fits your brain is the kind of advice that sounds good but
does most people a disservice. At work use what allows you to ship high
quality code, on time, within the business constraints that you have. But
you'll have much better options in your career if you take at least some time
to expand your brain so more things fit in it.

~~~
whitepoplar
I guess what I meant by "use what fits your brain" is more along the lines of,
"try a bunch of languages first, then use the one you like most". Without
experimenting, you'll most likely be lulled into thinking your first language
is the one that fits your brain best. I would disagree with the notion that a
language fits one's brain after you've picked it up. I really don't like
javascript, for instance, and I've used it quite a bit.

------
atombender
As someone who spent a long time in Ruby land, the last thing I want right now
is another dynamically typed language.

I'm a big fan of Erlang and OTP, and really wish for that style of
concurrency, failure tolerance and distributed computing. For me, the lack of
static typing in Elixir struck me as a missed opportunity from the outset. The
Ruby-like syntax isn't enough to change the game for me (I find it
significantly less attractive than Ruby, but that's not important), even with
macros.

Since I don't use Elixir, the above isn't necessarily a criticism of it -- I'm
sure it's great. Just not for me.

Go is what I'm using now, and I've been playing with Rust and will probably
start using that when I have a new project. I've been using Haskell for some
side projects. I like OCaml a lot, but I won't touch it until multicore
support lands and matures. For web projects, my plan is to transition
everything from JavaScript to TypeScript, precisely for the type system.

No more dynamically types languages except for scripting.

------
jesses
Deployment is by far the biggest pain point I've seen in new Elixir
developers. Developers use Mix in development, but then build releases using
Distillery for production. There are a few gotchas and pitfalls that almost
everyone falls into when using Distillery like using `System.get_env` and
forgetting `server: true` in their `prod.exs`. Hot upgrades can also be a
source of a lot of confusion. Configuring distributed clustering in production
can be tricky especially if you're running on Docker/Kubernetes/etc.

That said, I built [https://gigalixir.com](https://gigalixir.com) to try and
help with some of these issues and improve the deployment story for Elixir.

------
Sailias
We are using Elixir in production for a site with traffic that can spike in a
short period of time.

Elixir has helped us reduce our costs by 1/3 and improve our API response
times from 50ms to 5ms. (Ruby -> Elixir)

Using erlang/Elixir processes forced us to reevaluate the way we handle state
and were able to find many ways to optimize.

I believe our code is now more organized, extensible and powerful. Our
infrastructure is also more complicated, but much more fault tolerant as we
have fallbacks for fetching data etc.

Deployment was pretty terrible but a simple scaleable solution with AWS is
build with a docker container, push to ECS and launch ECS + ElasticBeanstalk
and you're good to go.

------
hawkice
All my new server-side code is in Go (where all my old code was in Elixir)
because I wanted something I could build locally and deploy easier. The
deployment story for elixir is... substantially worse than ideal, for,
seemingly, no reason at all. At the time I was writing the deployment scripts,
not only was the hot-code-replacement not going to work, even AOT compiling to
.beam files was broken, with multiple 3rd party tools not helping.

~~~
iends
Elixir seems to have better abstractions at building CRUD apps (and
websockets) than Go. Are you building CRUD type apps? Have you writing lots of
SQL vs using ecto to be painful?

~~~
hawkice
Not exclusively CRUD apps, but some. I've not minded the DB work I've done so
far, but I also don't mind SQL. Changesets are a smart API, but fundamentally
aren't much different than normal SQL. Ecto is nicer for loading lots of
joined data, but... eh. Hasn't bothered me not having it. So I'd be hesitant
to say Elixir has lots of amazing APIs -- good, but not indispensable.

------
aczerepinski
We wrote a few small services in Elixir at work and I loved it. I had been
using it at home and reading all the books, and would have been happy to
commit 100%.

However, I don't think anyone else was getting excited about Elixir, or more
broadly about functional programming. When it came time to choose a stack for
a much bigger project, Go won out. The only specific complaint about Elixir
I'm aware of is that ramp up time would be too long every time we bring a new
dev onto the project. In hindsight I don't think Go is any different in that
regard. A Ruby/JS dev either needs to learn pattern matching, macros, list
comprehensions, and a bit of OTP for Elixir, or they need to learn static
typing, pointers, goroutines, and idiomatic error handling for Go.

Personally, I'm happy either way. I'd still probably choose Elixir if it were
my choice to make, but I'm loving Go too.

------
tmorton
I'm pretty strongly on the Elixir train, but here's where I see its greatest
weakness:

On many platforms, the best practice is to have stateless application servers,
with separate stateful data stores. On the other hand, the big advantages of
Erlang/Elixir are in managing state along with your application logic.

In a vacuum, that can be a big win. But I'm worried that the advantages are
not enough to overcome the weight of tooling, services, and best practices
built around the stateless model. For example, Heroku explicitly tells you to
avoid application state, and Docker is built around a destroy-and-rebuild
ethos.

For my project, Elixir/Phoenix is great as a "better Rails", but I know I'm
only scratching the surface of the platform's strengths.

~~~
jesses
I don't want this to feel like an ad, but
[https://gigalixir.com](https://gigalixir.com) should help in this area. Its a
platform-as-a-service, like Heroku, but it's designed to encourage stateful
application servers by not doing daily restarts and supporting hot upgrades.
Disclaimer: I'm the founder.

~~~
skrebbel
Very cool! Where do your servers run, and is there any callback planned in
case your service gets discontinued?

~~~
jesses
Right now, the servers are on Google Cloud Platform in the us-central1 region.
It's in multiple availability zones for reliability.

I highly doubt the service will be discontinued ever since traction looks good
and we have plenty of funding, but Gigalixir and Heroku are almost
interchangeable. The only difference really is that Gigalixir doesn't require
a Procfile. However, if you fallback to Heroku, you'll lose clustering, hot
upgrades, etc.

------
albertgoeswoof
99% of software developers haven't heard of elixir

~~~
qaq
Given the extent of coverage on HN I would say there are very few devs. on HN
who haven't heard of Elixir.

~~~
hpcjoe
I've been reading HN for years, and this is the first time I've seen/heard of
Elixir.

Sample size of 1, self selected, your mileage may vary, things in the mirror
are closer than they appear. That is, it isn't really meaningful as a data
point in isolation.

I only clicked this link out of morbid curiosity, on why someone would make
such a presumptuous statement. Put another way, the question asked is heavily
loaded. I was more interested in the discussion around the statement, to see
what people thought, than the content of the question.

You may have what you and others consider the greatest thing since sliced
bread. And you might not fathom why others would not see it that way. After
all, it is the greatest thing since sliced bread. It is a dessert topping and
a floor wax (obligatory SNL skit reference).

Even with all this, the criteria for success, oddly, rarely has being "the
greatest thing since sliced bread" as part of the core elements of being
successful. You don't need to be superior to be successful (though I am not
stipulating that Elixir is superior, I've never seen it, used it, etc.)

The question is why would people choose this over others? What benefit would
this language provide that others simply cannot?

I've used many languages during my professional and educational life. I've
never seen one that was universally appropriate for all tasks. I some that fit
the majority of tasks I worry about, very well. I've seen others fit very
poorly. I have no opinion on Elixir, other than to note a small vocal group
wondering aloud how anyone could not use it.

Reminds me of Python in the 90s.

~~~
qaq
That is a very lengthy reply to a very simple observation :) If you are
genuinely curious why people are interested the short version is all the power
of Erlang VM made available via way more conventional syntax. There are a lot
of very unique properties of BEAM (Erlang VM) that are truly not available
elsewhere: preemptive scheduler, per process GC (no STW crap), all the OTP
goodness for dealing with failures, node transparency hard to list all the
pros to be honest

------
thesmallestcat
Erlang and Elixir are both fine languages, but the BEAM is slow and not
suitable for anything computationally intensive. Extending your program
whether via NIFs or Ports is a PITA. It's great for anything requiring many
active connections like front controllers and P2P, but outside of that you're
better off with Clojure if you want an FP with immutability IMO. I think that
you need to be working on a niche concurrency-focused application, or have
engineering manpower to burn, to justify using a different language for such a
narrow case. Erlang library support still is not very good except for, again,
concurrency-focused ones (gproc for instance).

------
Rjevski
Personally I am a happy Python developer and I don't feel it's worth it for me
(in terms of time) to learn another language. Maybe once Python starts to be
obsolete I'll switch but in the meantime I can't afford spending time learning
something new just for the sake of it.

~~~
whalesalad
That's a really interesting (and, in my opinion, negative viewpoint)

I have been a Python developer since 2006/2007 and every time I depart to
another community for a while, I return with a ton of new ways to think about
problems. Not only that, you'll usually have a newfound appreciation for
things in Python you might not have really cared about before (eg decorator
syntax)

\- Becoming a Rails developer was a game changer. The Pythonistas tout it to
be 'magic', but it's really not. It's easy to understand what is going on.
Once you use a tool like Rails in more advanced situations – every Python web
framework looks like a horse drawn carriage.

\- On a related note, reading Eloquent Ruby was one of the most epic
nonfiction reading experiences of my life. After reading that book, I rarely
see "programming magic" to be magic anymore. I understand it all. A lot of the
knowledge from that book translates well to Python too, since Python and Ruby
are very similar.

\- Learning Clojure and using it day-to-day at FarmLogs has made me think more
functional than I did previously.

It's usually not just the language that is going to open your mind - but the
frameworks, tools and communities that grow around the language. It's like
visiting a new country. You're gonna love certain customs and dislike others.

Anyway... saying you don't have time for something that will open your mind
and make you a better programmer sounds like a grumpy old man who's missing
out on the world.

~~~
davidgf
If I saw your reply before writing mine, I wouldn't have bothered responding
:) Absolutely agree with every single word

------
swat535
I think this a great discussion topic. I am really glad that everyone loves
elixir on HN but I would like to hear both sides to analyze the weakness and
strong points of a given technology. This makes more a balanced discussion
instead of just praising a language. Honestly I would personally enjoy a more
technical scrutiny of a language / framework, especially from a technical site
like this one. Does anyone have a good write up on something like this for
Elixir?

------
andrenth
Personally I'm waiting for Alpaca :)

[https://github.com/alpaca-lang/alpaca](https://github.com/alpaca-lang/alpaca)

------
becga
The deployment can be difficult to automate especially if you are attempting
to inject application properties at runtime.

There are solutions out there,though documentation may not cover every use-
case, especially if you are deploying to something like AWS or GCP (Not
everyone can adopt Docker just yet).

The Hot-Upgrade is a great idea though you will have to do your research to
integrate this with your Cloud Provider.

Overall I'm betting adoption will be niche, and primarily via Teams coming
from Rails. Until a major cloud provider starts offering native support + the
community grows to a sizable percentage, it will be slow to catch on.

------
user5994461
Don't use. You're gonna be in big troubles to recruit developers who knows
that tech.

It's already an issue with Erlang. It's made 10 times worse with Elixir.

~~~
iends
Are you hiring developers who can't learn new languages?

~~~
icedchai
Learning languages and using them to develop an actual production-grade
product are two different things.

Pick something proven.

I worked in a Scala shop and people spent tons of time flailing about arguing
over syntax, dealing with bad IDE plugins / slow tools, etc. They'd have been
better off just sticking with Java.

~~~
iamd3vil
I would say Erlang VM is already proven.

~~~
icedchai
I agree. So use Erlang VM and Erlang language, don't use Elixir yet...

~~~
iamd3vil
Elixir and Erlang have similar symantics, compiles to same byte code. You can
use any Erlang library in Elixir without any overhead, all the tools
(debugging, profiling) which works with Erlang works with Elixir.I don't see
why you can use Erlang and not Elixir.

------
maxxxxx
After reading the second paragraph the headline should be rephrased "Who has
tried Elixir and then decided not to use it and why not?"

------
qaq
Lack of comments can be interpreted in positive light for Elixir I guess :).

~~~
always_good
I doubt everyone chomps at the bit on a Saturday morning (for most of them) to
remind others on the internet that, yet again, there are no silver bullets.

------
DeepRote
Elixir is just an AST transform for erlang/otp. I like erlang and there are
features that I wish it had sometimes, but elixir couldn't be further from
what I'd come up with if I decided to fix it myself. It takes all the bad
parts of lisp, shoves them into a bad ast format, and crunches it all down to
beam code. It's just a terrible implementation of a terrible idea.

I am actually moving components of my apps away from erlang to f# to shield it
from the destruction of beam that elixir will bring about.

2/10

~~~
hellbanner
What is elixir doing that's so bad to .beam format?

~~~
ZenoArrow
I wouldn't worry about it, the GP is clearly trolling, there's nothing of
substance in what they're suggesting.

