
Ask HN: Who regrets choosing Elixir? - seancoleman
I’ve seen a few Elixir success stories posted here recently. Virtually all comments are from raving fans that have nothing but the best to say about Elixir.<p>As someone with primarily a Ruby &#x2F; Rails background, I’m choosing a language for a new API project and considering Elixir. I’m interested in hearing some counterpoints to Elixir, especially in how a smaller ecosystem Of 3rd party libraries slowed down development.
======
as-j
TL;DNR, use a language your company can support. It doesn't matter how suited
to the job a language is, if it's single Engineer or small team, what happens
when they move on? How do you support it? Who's on call?

Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our
IoT backend was written in Erlang, this was the early days of IoT, so sure it
made sense as a technology, could scale well, handle all the symmetric
sessions, etc. It was a good tool for the job and in theory could scale well.

But, there's always a but. We're a Python shop on the backend and C on
embedded devices. Engineers move on, there some lean times, and after a few
years there was no one left who could support an Erlang system. So we hired
for the position, and it's key infrastructure, but not really a full time
project, so we hired a Python+Erland person.

But! Now they're on call 24/7 since the regular on call roster are python
people and when the Erlang service goes wrong, it's call the one engineer. So,
do you hire 2 or 3 people to support the service? No, you design it out. At
the time is was 2018, and IoT services were a plenty, so we could use an
existing service and python.

Another way of looking at it, let's say it's a critical service and you need
at least 3 people to support it/be on call. If each engineer costs $200k/year,
that's $600k/year. Does this new language save you that much over using a more
generic and widly known language in the org?

~~~
craigsmansion
> there was no one left who could support an Erlang system.

If you have $200k "python engineers" on the payroll who wouldn't jump at the
opportunity to do some additional Erlang, maybe it's time to reconsider your
hiring practices and that is the real cautionary tale.

~~~
carapace
This, twice.

Back in the day people would balk at hiring Python programmers saying, "there
are so many more Java programmers", and I used to say, "Why would you hire a
Java programmer who was unwilling or unable to learn Python?"

Same logic applies here: Why would you hire a Python programmer who was
unwilling or unable to learn Erlang? (Especially if you're going to _pay_ them
to do it!)

If you can't switch languages you're a kind of _technician_ not a programmer.

FWIW, having done it professionally for ~15 years I'll never write another
large project in Python again. Erlang's runtime is so much better than
Python's it's just ridiculous. I feel stupid for not realizing this sooner.

~~~
icedchai
If I had a Python job (a language I enjoy) and I was forced to work in a
language I don't (say, Perl), I'd start complaining about it and looking for
something else to do. I personally wouldn't mind working with Erlang, but that
isn't the point. Many developers "can" do these things but it doesn't mean
they want to.

~~~
kenhwang
It's pretty much how we treat our Python projects. All of us hate it, but data
science is done in Python so we still need some percentage of the engineering
team fluent enough in it to sustain operations with it (on-call, maintenance,
bugs, eventual decommissioning).

The moment we can get rid of it, you bet we will. But it's much easier tearing
it down when you understand it enough to discern designs driven by the
limitations of the tech vs requirements for the product. Black box ground up
replacements are hard and expensive compared to ports. Also, thankfully it's
Python and nothing something more difficult/complex.

At the end of the day, it's a job, and there's an expectation of
professionalism to do what's necessary. A lot of people on HN like treating
tech jobs like a paid hobby which I think is detrimental to career
development.

------
alex55
I work for a Ruby on Rails shop and we used Elixir for two projects about a
year or two ago when it was getting a lot of good press.

The first project was an API that was intended to serve as a middleman between
a few legacy services. Basically the company that hired us was building a new
JSON API but didn't want to rewrite all their old code and our job was to
consume the output from their ugly legacy APIs and produce nice JSON.

Elixir/Phoenix worked for the first service, but after that we ran into
problem after problem. One of the legacy services used HMAC authentication and
Phoenix (at the time?) didn't really support that. We were eventually able to
hack around it without too much pain. Another service used XML and we had a
lot of trouble finding XML libraries. There were some but nothing remotely as
nice as Nokogiri. While all of this was happening, adding to our frustrations,
a new version of Phoenix was released with a lot of changes. The only
documentation for how to migrate an existing app was a typo laden GitHub Gist
by the author of Phoenix. The final straw was when we got a call from the
client about another service we had to integrate. This one used JSON but the
_order of the keys_ was important (please for the love of whatever god you
believe in never do this). When we had to decide whether to write a custom
JSON parser or move to Ruby, we rewrote the thing in Rails.

The second project was already a few thousand lines of code when we started
working on it. It was a dumpster fire of a project but the devs who built it
praised Elixir to the skies and said it was way better than their old Rails
version. So take that for what it's worth.

We've decided not to do any new projects in Elixir for now but we're leaving
it open for the future. It is a nice language to work with and, as you can see
from the other comments, there are some projects where it shines.

I have two suggestions for you:

1\. Talk to people in real life about Elixir/Phoenix. Most other devs I talk
to in person at other agencies that tried Elixir have (surprisingly) neutral
or slightly negative feelings about Elixir/Phoenix. Some percentage of people
on Hacker News absolutely love Elixir (and often hate Ruby/Rails) and they
usually flood the comment section of any Elixir article.

2\. If you don't fully know the problem domain, use something with good
library support. I don't know what your project is, but if you control the
front and back ends or if you know exactly what features you'll need, there
will probably be no problems choosing Elixir. Plus, it's always fun to learn
something new. If your project is "some kind of API that needs to do X and
maybe some other things we don't know yet" I would stick with Rails (or
Python/Java/something with a lot of libraries). The worst place to be is not
being able to do something simple because of a lack of library support and
having to explain to your client/manager/coworker that it's because you read
on Hacker News that writing "a |> b" instead of "a.b" is the future.

~~~
PopeDotNinja
> If you don't fully know the problem domain, use something with good library
> support.

I think this is completely fair. As my friend says, "I don't know what library
I'll need for every project, but I know where will be one for Python."

~~~
nikofeyn
just because there is one doesn't mean it's quality. so then it's a worse
scenario because you thought there was a solution, planned on it, but then
once you use it you see it doesn't work the way you expect.

------
bluesnowmonkey
Been paid to write mainly Elixir full time since 2017. Still quite positive
about it overall but I can talk about some constraints in an enterprise
environment.

In a large company with lots of services in many languages, avoid putting
business logic in your Elixir code. Business logic adds coupling to related
code in other systems that often all need to change together, or get changed
in a hurry. Either way, the engineer trying to do the change probably won’t
know Elixir. Likely they were appointed to make the change by a PM who doesn’t
know or care much about which systems were built in which languages and who
knows those languages. And that engineer won’t know Elixir, and they’ll
complain about being unable to work on your Elixir system, and it will give
Elixir a bad reputation at your company in the eyes of managers and PMs. It
won’t matter much if your system has high uptime or low tail latency or
whatever.

The solution to this is to only use Elixir for building infrastructure. Nobody
cares much what language PostgreSQL or RabbitMQ or Kafka are written in. You
don’t modify the source code for those things typically, you just use them
through some kind of API. Similarly if your company needs a notification
delivery system, you can build that in Elixir. You just have to do it in such
a way that nobody will ever be blocked trying to launch a new kind of
notification because they need to learn Elixir first. Make it fully accessible
and extensible through its API so they never need to know what language you
used.

------
briansteffens
Erlang/OTP is really cool and I found the Elixir language pretty reasonable
and even nice but:

1\. Elixir is still a pretty leaky abstraction over Erlang. In my experience
it's not enough to learn just Elixir, I regularly had to dive into Erlang
library source code to debug or answer questions. This somewhat negates the
benefit of a small, stripped down syntax when you often have to learn another
one in conjunction.

2\. Maturity of ecosystem. This should improve over time but I've had
challenges finding high quality libraries, especially for things like database
connection drivers or making network requests. It's often hard to tell how
well-supported or complete a library is and regressions were a regular
occurrence.

3\. Documentation. In practice I rarely found official documentation complete
or even helpful (outside of big projects like Phoenix / Ecto). Even core
Erlang libraries had surprising chunks missing. It's been awhile but I
remember it being very hard to figure out what options were supported in
Erlang's TLS wrapper. I ended up stitching together pieces from the OpenSSL
documentation, Erlang source code, and lots of trial and error.

4\. OTP overlap with other scheduling systems. This isn't a design flaw as
much as a potential footgun depending on how you deploy Elixir code, but there
is a lot of overlap between the cluster management support in Erlang/OTP and,
for example, container orchestration in Kubernetes. Both support scheduling
some concept of tasks, configuring redundant copies of tasks, detecting
problems, and restarting tasks according to policy. Deploying an OTP
application on top of Kubernetes (on top of Linux) results in 3 layers of OS-
like task scheduling to learn, teach, maintain, and debug through, all with
distinct tooling, terminology, and limitations.

All in all, I found Erlang/OTP to be a pretty interesting and compelling
platform, especially for certain special purpose applications. If I ever use
it again I'll probably skip the extra layer of Elixir syntax and write
straight Erlang.

~~~
RobertKerans
I've hit number 4 quite a bit. If there's a system that's entirely
Erlang/Elixir it tends to work well, and is generally very pleasant to work
with. This afaik is the actual usecase? ie not big distributed systems, but
small(ish) self contained and self sustaining systems. And then you start
layering these systems together with containers and ugh <shudders a bit>

I've certainly found it to be much more specialist than I think many
cheerleaders would have it. It can do most things out of the box (and that I
guess is the point of OTP), but to make it do those things requires quite a
deep understanding of the platform (and that it is a platform, that the
language is just a way to interact with that platform). Elixir is my favourite
of any language I've worked with, so I'm not down on it, but it's not general
purpose

------
tonyarkles
Right tool for the right job, I think. I’ve had absolutely wonderful
experiences with Elixir doing web apps (both LoB style and SaaS style).
Probably the best one, and it’s such a canonical example, is a group chat app
using Websockets. It just feels so good, and with libcluster, multiple nodes
in K8s can autodiscover and join each other. No problems at all having chats
where the members are connected to websockets on different nodes; everything
mostly Just Works.

On the flip side, I prototyped out a drone flight controller in Elixir
thinking that the “fail and restart” portion would be awesome for reliability
(if the RTK receiver craps out and restarts, no big deal, the EKF can just
fall back to using the IMU until the RTK is back online). That part of it all
worked great, but doing real-time numerical computing in Elixir is painful. As
was generating the signals for the ESCs. I was making C modules to try to talk
to the ESCs, and errors in those modules had the ability to corrupt the BEAM.
I started looking at ports too (where the C code runs as a separate process),
but gave up when it felt like everything was feeling way too complex and
fragile. Let it crash is great, but “it crashes all the time” is not. I could
have probably gotten it working, but... not a great domain for it.

~~~
brudgers

      let it crash != robustness not required
    

Let it crash is an engineering design for systems large enough that
statistically unlikely failures occur regularly. Like a data center or the
original use case, telephone switch centers.

Even if let it crash worked, it seems philosophically inappropriate for a
drone controller.

~~~
TickleSteve
Not at all, "let it crash" is simply a way of phrasing "consider reset in your
flow of control".

In embedded systems, certainly safety-critical ones, you have to consider the
possibility of a reset path at all points in your flow of control. Your code
resetting is a valid flow of control.

This is absolutely necessary to get a properly robust system.

Your drone system needs to be able to handle a reset at any point and still
maintain adequate control of the aircraft. This is "Let it crash".

"Let it crash" is essentially the same thing. Take account of the necessity of
reset, because you can't stop it happening.

------
pavel_lishin
My employer has chosen it, and while it was fun to learn and is very neat, I
don't think I'd ever write Elixir code for anything but a hobby project,
especially if a large team is working on it.

1\. Dialyzer is just a huge piece of shit. It's an incredibly impressive piece
of shit, and makes it possible to pretend that Elixir supports typing, but it
has so many edge cases that we've run into them writing even trivial code -
and it misses a lot of things that, e.g., Java or Typescript would have no
problems with.

2\. Testing is kind of fiddly and annoying. It's very difficult to
consistently mock things out. And yes, yes, it's a functional language so in
theory every function should be small and trivially testable, but unless
you're writing toy code, eventually you _will_ have dependencies you would
like to mock out in tests, and you will have complicated business logic living
_somewhere_.

~~~
bluesnowmonkey
With regard to mocking, I’ve found that it works better to swap in a fake
process rather than a fake module. If you have a FooClient genserver that
makes RPC calls to a service or database, make a FakeFooClient that responds
to the same kinds of genserver calls and returns canned responses. Or even
implement a simplified version of the external service in the genserver.

~~~
dnautics
I did this and I found that as I increased the paralellism of my tests, the
genserver got bottlenecked and the test suites started throwing heisenbugs,
which is not what you want. You should really be using the Mox library, which
I don't believe suffers from this problem.

~~~
cvlasdkv
Echo use of the Mox library! I found testing in Elixir to be by far my
favourite experience (outside of Scheme, I guess, but I haven't done
production Scheme). The REPL is really nice as well for exploratory
development.

------
anonyfox
Doing Elixir since 2016, deployed multiple Phoenix Projects to Production.

Of you want to build dynamic web applications, phoenix+LiveView is imo _the_
best Option currently. It also keeps the promises: reliable (zero-maintenance
apps running for years on heroku), productive (prototyping things is really
fast: like rails 2/3 days), fast (templates render fast even when complex). It
is also great to have actor processes and ETS at your fingertips.

Having said that: dynamic typing truly sucks for bigger projects/large teams.
It is awful how much you have to write tests for, and these tests will slow
down further velocity when things will change... stellar opposite to Rust.

Never attempt to do any serious number crunching in Elixir/Erlang, the BEAM
truly is not made for this stuff. Plan to use/write NIFs or Ports for
computational tasks. Even compiling larger Phoenix codebases will take minutes
if you aren’t cautious of using „import“ in modules.

Finally: deployment is really the major pain point. I love the single file
deployment story of rust and go.

~~~
lejboua
From your remark about deployments, I'm assuming you're not using Distillery
or Mix releases? If you use a release, you can deploy a tar.gz with
"batteries" included (everything you need to run your app, including the
BEAM). At work we have a dozen of elixir apps running smoothly in Production
on plain Debian containers.

------
freedomben
I've done both, much more Rails than Phoenix, but I'm not doing any new
development in Rails.

I do regret choosing Elixir at times for the following reasons:

1\. I am new to the language (I've been using it for "years" but only very
part time (not part of my day job)). While the functional approach does lead
to much more elegant code, it can also be super esoteric to me as I'm new to
and somewhat uncomfortable with the idea of recursion for everything. There
are pre-written macros to help of course, but it's just training wheels. This
will improve with time and experience. I also don't fully grok how to write my
own macros. What I really need to do is spend a couple of days deep diving
until I get it.

2\. Phoenix is changing quickly (tho slowing down). I wrote some stuff if
Phoenix 1.2, 1.3, and the upgrade path is a bit involved (no more so than a
rails upgrade was tho). I suspect it's stabilizing, but when I first created
one project it used brunch for assets, now it uses webpack (which is a good
choice, but as a non-frontend person I'm not well equipped to make the change
myself to upgrade my project). 1.3 (IIRC) also dropped models, so that
required some refactor to work as a 1.3 project.

3\. Deployment changes quite a bit. The old rules for Ruby go out the window.
You can still treat your Phoenix app like a rails app if you want, but it's
like buying a Ferrari to drive around the neighborhood at 25 mph. This takes
some learning, and while much of the old rules about scalability, etc are
still applicable, they do change a bit and it requires making new mistakes and
learning from them.

4\. I get irritated now when working with non-functional code in other
languages. My tolerance for side-effects is down to nearly zero, and I get
irritated when there's a dozen lines to do something that in Elixir is a
couple of pipes.

That said, overall I much prefer Phoenix/Elixir. None of the downsides are the
fault of Elixir, so I believe with time It'll be a no-brainer. I am already at
the point where I don't start any green field projects in Rails (tho I do use
Ruby extensively for scripting as it's by far the best scripting language
IMHO).

~~~
tyurok
The annoyance over non-functional code is real.

I can't tolerate OOP stuff that `obj1.calls(obj2)` and changes `obj2` anymore.
I didn't care before, now it makes me want to refactor everything or not write
it at all.

Using Elixir kind of made me not want to use anything else.

~~~
bb010g
Haskell's nice. Got some mature web stacks if you ever want to give those a
try. [https://github.com/Gabriel439/post-
rfc/blob/master/sotu.md#s...](https://github.com/Gabriel439/post-
rfc/blob/master/sotu.md#server-side-web-programming)

------
jeremyjh
I've been developing Elixir since 2013, and professionally full-time since
2017. Honestly my only complaint is the lack of static typing. There is no way
I'd prefer Ruby; Elixir gives you a lot more compile time checking and static
analysis. As a project gets larger, it gets harder and harder to refactor
because of the despair that sets in when contemplating fixing dozens or
hundreds of broken tests that you can only discover by running them.

I really don't know what I'd prefer to it though, every language has its pros
and cons and static typing systems while nice also can introduce their own
problems. I've spent days tinkering with type abstractions in Haskell rather
than getting work done - not because I had to but because I knew more
expressive solutions were possible and the allure of them was too hard to
resist. Elixir is a fantastic language for getting work done.

~~~
sanderjd
Just throwing it out there because I've had similar thoughts - that is, I
enjoy Elixir but would be uneasy embarking on a large project without better
static analysis, and also wonder what better fits the bill of a statically
typed server application language - maybe check out Kotlin. I was very
pleasantly surprised when going back to Java from Ruby that I found it much
nicer, and Kotlin looks very similar but with a few key ergonomics
improvements. I haven't used it for anything sizable myself, but I will
definitely evaluate it next time I start something new.

~~~
jeremyjh
That's funny you say that - I've been following Kotlin a long time and lately
have been getting interested in it again; somehow my thoughts keep leading
there.

If anything holds me back its my experience with Scala. I used Scala for
awhile (actually it was my introduction to functional programming) and I like
the language but everything about it that seemed to make me unhappy was
related to the tooling and JVM ecosystem in general. I should give Kotlin a
real chance on a small project though as I haven't done that yet, I've just
read the language guides.

~~~
blandflakes
Though I prefer Scala the language, Kotlin is really nice and has pretty
straightforward tooling (seriously why is sbt what I'm stuck with), as well as
really awesome (unsurprisingly) Intellij support.

~~~
sanderjd
I may prefer Scala in theory but it seems to me that Kotlin would work better
in practice. And my thinking has shifted to where I've started preferring
languages that I prefer in practice in theory too.

------
mistyfud
I've been using Elixir for three years in a production setting with a small
team of engineers. I still love the language, the community, and everything it
has taught me as an engineer. However, there are real downsides to moving
forward with Elixir:

\- If your engineers are used to the Ruby, JS, Python etc. ecosystems of
finding a library for everything, they may become frustrated with the smaller
Elixir ecosystem. In my experience, this is actually fine because it means you
have fewer external dependencies to wrangle.

\- Differences between compile-time and run-time configuration is a foot gun.
We ended up moving almost everything to run-time configuration, which is not
what you see recommended by many libraries and examples. This is slowly
changing however.

\- Deployment is a bit unique, and working with building releases can be
confusing for those used to deploying dynamic languages that are not compiled.

\- Functional programming requires unlearning many OOP best practices. This
can slow down engineers new to the language.

A lot of these issues IMO comes from how Elixir was initially marketed as a
"fast Ruby" and Phoneix "fast Rails". Once you get past the syntactical
similarities you realize the semantics are very, very different. Elixir is
much closer to Erlang and Clojure than it is to Ruby.

Elixir is an excellent language for motivated engineers solving novel
problems. If you are building a standard CRUD app, I think you will find more
success with Rails or Django in 2020.

------
brandonmenc
We are EOL'ing Elixir at work - almost all of our stuff is built with Rails.
My personal web projects are back to using Rails. I also never did contract
work that produced Phoenix apps because I don't want to leave clients with
something that they can't easily find support for later on.

Lots of great ideas in Elixir, Phoenix, and Ecto, but it just didn't hit the
critical mass or completeness that makes the Rails ecosystem impossible to
walk away from.

And because abandoning Rails is not a practical option, maintaining brainspace
for an additional thing that is not widely used and nearly identical in
function is not worth the cost.

Sadly.

------
s3cur3
I’m primarily a C++ dev, so that colors a lot of what I think about the 3rd
party library situation in Elixir. Because of the abysmal state of package
management in C++, it’s usually easier to implement stuff yourself (tailored
exactly to your own needs, and therefore with an extremely limited scope) than
it is to bring in a heavyweight third-party library.

For that reason, I was pretty comfortable coming to Elixir and implementing
Somewhat esoteric, games-specific networking stuff myself. It would have been
nice if the library had already existed, but I am so glad I went with Elixir
rather than Node or PHP (which both do have the game networking library I
needed).

My experience has basically been that the “fat head” of open source libraries
exists in Elixir, but the long tail of more esoteric stuff does not. By its
nature, though, you won’t need 99% of the esoteric stuff available in other
languages.

------
to11mtm
I deal with Elixir currently.

Although, actually, I'm converting it all to C#, since we don't really have a
lot of elixir people in the shop (I had to learn Elixir just to do the
maintenance when I came onboard.)

The lack of APIs can be painful at times. What is there sometimes isn't the
most fun to deal with outside of the ecosystem (the driving force of the
language conversion was issues using Phoenix Channels reliably with non-elixir
consumers, and during the conversion we are dealing with the minor pain of
pulling certain data out of an mnesia data store.)

But, I mostly enjoyed my time playing with it.

Biggest observation was that the IDE Tooling didn't feel as nice as, say, F#,
which makes a bit of a difference when you're not dealing with the language
day-to-day and need helpful reminders for how you're getting certain things
wrong.

------
phunehehe0
I can't say I regret learning Elixir, but a coworker once said he thought I
thought it was the worst programming language in the world :)

My biggest annoyance with Elixir is that the ecosystem seems to impose a lot
of opinion on how things should be done, and sometimes actively makes it hard
to do things differently. In some edge cases I couldn't do the easy thing
because it's "wrong", and couldn't do the right thing because it was not yet
implemented. I believe this is with good intention and is mainly a side effect
of the relatively small and young community, as in many areas the de facto
libraries are made by the same few people. I suppose this problem will get
better as there are more libraries to choose from and/or more contributors to
those libraries.

Another, milder source of annoyance for me is the lack of functional
programming features in a functional programming language. To invoke a
function that has been passed as a parameter you need a dot. No currying etc.
Still, you can get things done and with these limitations it's harder to get
yourself into a mess of functions being passed around (but not too hard if you
try).

All in all, to me what Elixir brings to the table is more than enough to
offset its annoyances. However when it comes to choosing Elixir, I agree with
other comments suggesting to choose something the team is comfortable with.

------
neya
I'm one of those raving fans you talk about. I always love sharing the success
stories of Elixir with everyone because it deserves so much more love than it
currently receives.

I came from a Rails background too and Elixir is so much better than even Ruby
(which I'm a huge fan of already) simply because it forces you to think in
terms of functions rather than OOP based. Most people who try and give up
early on Elixir - including myself (I gave up initially after a few weeks
actually, before going back to it again) was simply because I was trying to
code things like I would normally do in an OOP setting.

For example, you don't use FOR loops in Elixir, you don't nest switch cases.
If you try to be in an OOP mindset with this language, you WILL fail. And
that's a good thing. The language constantly challenges you to rethink a lot
about your code. And it always results in better code when you do it
functionally. Eg. using pattern matching instead of multiple if else clauses.

The downside of Elixir is the ecosystem isn't as mature as Ruby, so, for some
of the things you're trying to accomplish, you won't find ready made
libraries, or they won't be maintained anymore. Sometimes, you will be forced
to write something from scratch and that can cost valuable developer time.
Integration of stuff like GraphQL can be too verbose compared to other
programming environments as well. But, the language itself? It's hard to
complain. My entire consulting career has been built around Elixir since I
made the switch ~3+ years ago. That's how good it is.

~~~
Trasmatta
> And it always results in better code when you do it functionally

Hard disagree here. Functional code is often better, but certainly not always.

~~~
enraged_camel
That sounds more like a "soft" disagree. :)

------
strzibny
You are asking the right questions.

In our particular case,

1, we did not have good libraries for file uploads to Azure and to handle the
signing for securely displaying them.

This was solved by 2 very simple modules. In the end, both things are fairy
simple unless you want them complicated (ActiveStorage can sure do "more" out-
of-the box).

This also means the code it's super straight-forward and understandable.

2, we did not have a good library for SOAP.

We started to build a simple SOAP library. This I would consider a pain, but
there is always option to avoid it (see no. 3).

3, we did not have good PDF libraries.

I happened to package my Ruby library (using Prawn) as a Docker container and
simply call its API. This could also simply solve no. 2.

On the other hand hand,

1, we got one of the best GraphQL libraries out there (Absinthe)

2, we got a really fast test suite (once everything compiles, that is)

3, we are getting great tooling like Phoenix LiveDashboard for free

Also I want to note that deployment is now quite easy with "mix releases" (as
compare to what it was). You even get a remote console that connects to your
running cluster. No problem.

[0] [https://nts.strzibny.name/phoenix-livedashboard-request-
logg...](https://nts.strzibny.name/phoenix-livedashboard-request-logger/)

------
vinhnglx
I'm working for a software consultant in Singapore. We tried Elixir for a few
projects, and now we're still trying. So, I can share a few experiences from
my view.

\- Elixir and the Phoenix framework is perfect when building concurrency
systems. Our company had made a ticketing system, solving the tickets for
"Cirque du Soleil - Hongkong 2018". During two months of the event, our system
(one Elixir/Phoenix server - scale up to two - one load balancer) can handle
more than 5000 tickets per second. We were so excited. Unfortunately, the
client's company closed after that. So the project was closed too.

\- The second project was a product of a finance startup. Not so much thing I
can share in this project, but the main feature is chatting. We used the
Phoenix Channel and Graphql Subscription for this feature.

\- In the side project, one member of the team used Phoenix Liveview to build
a Coup game (board game).

So, in general, when I work with Elixir, I see a few pros and cons:

Pros:

\- Fast. Functional programming is really fun. I love pattern matching.

\- Not so hard to write tests. It's easy to mock external APIs. (Check out
this blog: [http://blog.plataformatec.com.br/2015/10/mocks-and-
explicit-...](http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-
contracts/))

\- Easy to deploy. After dockerize the application, I can run it anywhere. The
ticketing system was run on AliCloud, and the second project was run on
Kubernetes (AWS).

Cons:

\- Lack of supported libraries for external services. Sometimes, our team has
to write a wrapper library to call directly to external services' APIs.

\- Not easy to hire an Elixir developer in Singapore. Our team tried to hire
Ruby on Rails developers and train them. But they were not feeling interesting
in learning Elixir, so they left the team.

------
choiway
A couple thoughts after using it for a couple years.

1\. It actually takes a while to get your head around the fact that the
biggest advantage of elixir is having access to the battle tested features in
OTP. It takes longer to realize that these benefits don't come for free and
elixir might not be the best solution to your problem.

2\. The learning curve for writing functional code is different for different
people. As a result, it's impossible to figure out before hand how long it
will take a team used to writing pythonic code, for example, to start writing
functional, elixir code.

3\. You're able to emulate something like type checking between pattern
matching and ecto schemas but it's not type checking. Be prepared to spend
time coming up with best practices for writing tests.

------
emerongi
What are the alternatives to Elixir? I'm a proponent of functional/LISPy
languages and when it comes to developing web applications, Elixir with
Phoenix and Ecto just works extremely well. Maybe the next best would be
Clojure since the JVM brings a huge ecosystem with it, but I did a cursory
look into it a while ago and the frameworks just didn't seem to be on the same
level as Phoenix/Ecto.

The main complaints are valid: hiring issues, lack of a good typesystem, small
ecosystem. Yet I have been the most productive with Elixir and would rather
move to something _better_ than regress to the mean just because Elixir isn't
a mainstream language yet (which would solve the hiring and small ecosystem
issues).

~~~
elwell
> I did a cursory look into [Clojure] a while ago and the frameworks...

Most Clojurists tout "libraries over frameworks", accordingly perhaps with the
flexibility of the language itself. Personally, I think acceptance of
frameworks would bring much needed standardization to the Clojure experience.
On the frontend, I enjoy the lightweight Re-frame.

------
wnevets
I've found elixir easy to write but a pain to read, especially when it comes
other people's code.

Elixir is also dynamic but with annotations that gives the illusion of types.
It's really the worst of both worlds.

------
Areading314
Recently was involved with an elixir backend being phased out in favor of
python because of the following reasons:

* Not enough engineers can write/understand elixir which kept leading to people being blocked

* Library ecosystem for scientific applications is lacking

* The language itself is confusing and the macro capability causes code to be uniquely incomprehensible in each different module

It was a worthwhile experiment but you just can't beat the advantages of
having extensive documentation and expertise in the more mainstream languages
unless you have very specific performance requirements.

------
phtrivier
If you come from the Ruby / Rails world, then you've probably developed some
level of skin thickness about my biggest problem with elixir: it's dynamically
typed, therefore almost impossible to write right the first x times. (For a
value of `x` that's big enough for me.)

Coupled with the relative slowness of the compiler, this means your average
development session is a loop of

1\. trying to get something that pass syntax check

2\. starting your application

3\. making a request

4\. `no match of right hand side...` because you had a function that expected
`{:error {:ok {:foo %{bar: 0}}}` down a five-level-deep stack, and you typed
`%{"bar" => 0}`, you fool ! Or maybe you typed "baar". Or maybe you did not
type it, and some of your colleague did. How would she know ? `dialixir` was
probably disabled a few years ago because the error messages were not helping
anyone, and you're not going to write `@spec` anymore at this point.

I heard some people managed to overcome this by using the REPL, but in my
experience it just means making the spelling mistakes in a terminal rather
than in an editor.

Elixir is great for code that mostly does "routing" of messages from sources
to sources.

Phoenix channels are a blasts.

Pattern matching would be great if the compiler could help you with the
obvious mistakes.

Libraries are exactly how you would expect for a few-years-old language. Name
one topic, and there are three competing libraries : one of them does not
work, the other one is unmaintained, the third one has completely changed its
API in latest alpha. You're going to pick the wrong one anyway.

If I could go back in time, I'd avoid writing any kind of business logic in
it.

(Opinions mine.)

------
triskweline
Our Ruby / Rails agency tried implementing a project in Elixir. After 3 weeks
we stopped the experiment and re-did everything in Ruby.

What stopped us was not so much the lack of libraries, but programming
ergonomics. E.g. when using keyword lists for function options, callers need
to pass the keywords in the exact same order. Also mocking was difficult in
tests.

Elixir is a great project with a friendly community, it just didn't work for
us. YMMV so by all means try it out if you're interested!

~~~
mapcars
>when using keyword lists for function options

Proplists should be replaced with maps pretty much everywhere.

>Also mocking was difficult in tests

Interesting, what exactly was difficult? You just replace one function with
another.

~~~
pavel_lishin
> _Interesting, what exactly was difficult? You just replace one function with
> another._

I'm not the person you're asking, but iirc, that replacement is _global_ \- so
once you replace function/module X with MockX, you can't test X itself, nor
anything _else_ that relies on X.

~~~
dnautics
This is 100% correct, and a very huge pain point, and why you're supposed to
use Mox, which solves that problem (arguably in a more conceptually "correct"
fashion than ad-hoc Ruby Mocks). Admittedly there is a _very_ steep learning
curve, but it's worth it, because once do it you start to be able to do things
you can't do in any other PL (not even erlang).

It's a pity that the elixir community doesn't make this clearer, because I'm
seeing "not being able to Mock" be a common complaint.

~~~
jeremyjh
It probably depends more on where they are coming from. Mox has more overheads
for sure than options in Ruby or Javascript. Its more like mocking in Java or
C++; where you declare an interface(behaviour), program against that, and then
use dependency injection to load the mock or real code at the right time. I'd
been working with Elixir for several years when I first tried using Mox and it
still took awhile to get my head around it and figure out how to integrate it
into our project. I would not be surprised to hear that newer teams really
struggle with it.

~~~
dnautics
> I would not be surprised to hear that newer teams really struggle with it.

I completely agree. Not having an expert Elixirist able to help me: It took me
a full six months of fooling around with Mox (and a cryptic feature
announcement in the 1.8 release) to really dig into and grok it. At this stage
in my elixir experience, I have even PR'd a feature that's been integrated
into Mox, so it's not completely incomprhensible, it's a super-well-written
library.

Honestly, It's a totally (alien/from-the-future)-technology (in both the good
and bad senses) library. The bad senses could be almost trivially fixed with
an in-depth, free, online video masterclass or, hell, even a conference
lecture on it, and blog posts. More people that really know how it works
should blog about how amazing Mox is. Unfortunately, I suspect that the people
who are using Mox to its fullest extent are too busy pushing code to prod, ha.

------
raarts
I wrote an Elixir GraphQL-to-multiple-REST-backends proxy two years ago. It
used OAuth and ran redundant in a Docker Swarm. Also wrote an Expo+Apollo PoC
for the mobile Dev group to start from.

The backends were swagger which allowed me to autogenerate the Elixir source
code for the GraphQL resolvers from the swagger.json file. It was a project
for a telecom company which also employed Erlang programmers.

My experience: stability was outstanding, performance reasonable. Got a lot of
praise for it. Only got one big report in two years.

Would I recommend it? Only to experienced software engineers.

Would I recommend it to companies? Only if you understand that every new tool
or stack is a strategic decision.

------
CompuIves
We've been using Elixir for our API server from the start. It's a great
language and scales really well. We needed to add a websocket API at some
point, and now it's our channel with most throughput. Phoenix handles it fine,
and we're still able to triple the throughput comfortably.

The one thing that we struggled with Elixir with is that it's quite hard to
find people that know Elixir. For a long time I was the only one doing Elixir
in the company, which introduced a bottleneck. That said, when you find
someone who knows Elixir they tend to know Elixir (and a bit of infra) quite
well.

------
asfarley
I tried implementing an algorithm for tracking multiple objects based on
graph-cuts using Elixir. I was disappointed in the lack of strict typing in
the language, since this is one of the things that made me want to try
functional programming.

In order to tell the type of various method signatures, it seems like you have
to go looking at other areas of your program. I’m aware that it’s possible to
annotate method signatures, but this still didn’t lead me to feel secure. I
think I was hoping for/expecting something more Haskell-like.

~~~
atraac
Why would you "try to implement" stuff in a language that is clearly
dynamically typed and then be disappointed about lack of types? It's like
trying Python and being disappointed about it lacking types. Do you often try
languages without even googling for a basic description and then are
disappointed because it's not like other programming language or what you
expected?

~~~
asfarley
Hah, well I was focused on the benefits of functional programming rather than
the dynamic aspect of the language.

It’s easier to recognize that a feature (dynamic typing) is an issue in some
applications after trying it for a while rather than just taking a theoretical
view. I’ve sometimes misunderstood how a feature works in practice by relying
too much on my theoretical understanding.

Also, because Elixir allows type annotations, I was thinking that I might not
need static typing. It turned out (at least for me) that I would prefer to
have a language that insists on type annotations by default rather than
allowing them as options.

------
iloveitaly
I _really_ enjoy Elixir. I've used for a fun side project. It's an awesome
language with some really interesting concepts.

However, I wouldn't use it for a real project:

1\. The ecosystem doesn't compare to ruby/python/javascript. There's a lot of
missing packages and abandoned libraries. I ended up having patch a bunch of
libraries I used.

2\. The tooling that exists is nice and 'just works' but there's a lot that's
missing from ruby land: [https://elixirforum.com/t/help-an-elixir-beginner-
find-missi...](https://elixirforum.com/t/help-an-elixir-beginner-find-missing-
development-tooling/24632)

3\. The deployment story is horrible. The heroku/dokku buildpacks didn't work
by default and it's not obvious how you can easily deploy a mix/distillery
release without writing your own deploy scripts.
[https://elixirforum.com/t/official-heroku-dokku-
buildpack/28...](https://elixirforum.com/t/official-heroku-dokku-
buildpack/28867)

4\. Phoenix != Rails. There's many many obvious things that are missing.
`mail_to` for example.

------
throwaway286
I've spent some time learning it that I don't regret.

However, I dislike the GenServer syntax, it feels too complicated with random
tuples all over the place. Also, I feel like the job market is too small. I
wasn't able to find a job using it (although maybe COVID is to blame here).

------
brenden2
I've done a fair bit of both Ruby and Elixir. My impression is that Elixir
leaves a lot of the legacy cruft behind, and it has a much smaller language
feature set (which is IMO big bonus). The language is pretty easy to grasp
quickly as a result. There isn't much in the way of quirky syntax or backward
compatibility weirdness.

Probably the biggest advantage of Elixir over Ruby is the runtime. The Erlang
VM has proper concurrency, and it provides really nice primitives for working
with it.

The ways in which Elixir sucks tend to be the same as Ruby: dynamic types,
somewhat slow runtime (compared to C, Java, Rust, Go, etc). I'd also add that
library support is still a bit weak with Elixir, but it's always getting
better.

~~~
treis
How close does it come to matching the Ruby/rails gem ecosystem?

~~~
brenden2
Phoenix is the closest, and while it's not exactly a Rails clone, it provides
most of what you need to get started. It's similar to Rails in that there's a
CLI to generate code, and frameworks for unit testing, DB modeling,
templating, etc.

Where Phoenix really shines is its support for fancy stuff like Websockets and
distributed messaging in your backend. Trying to do these things in Rails
leaves much to be desired.

~~~
treis
I mean more stuff like Devise for authentication, Apartment for multitenancy,
ancestry for hierarchical data, etc. Seems like every common problem has a gem
that solves it. Does Elixir/Phoenix have equivalents?

~~~
rahimnathwani
Triplex / Apartment Coherence / Devise ExAdmin / ActiveAdmin

~~~
treis
Are they as good as the Rails equivalent?

------
yodi
I've spent roughly 3-4 years working experience on Django + Python in total.
I've switched to Elixir / Phoenix since 2 years ago. I can say, the two
biggest cons (despite is many cons) is the packages maturity and doing heavy
lifting processing.

The first one, I can't complaint. Every programming language have it's
weakness, to solve that I'm offload processing stuff into Rust. Luckily,
Elixir have NIF integration with Rust.

------
flaque
One counter point to elixir is that there's a significant learning wall to
onboard new developers, more so than simpler a language like Go or Python.

~~~
brenden2
I'm not a genius, but I found the opposite to be true. Go and Python seem non-
intuitive to me, whereas Elixir felt natural and easy to grok.

~~~
nojito
Because of it's magic.

Debugging it it a nightmare especially when you have to roll up your sleeves
and go into Erlang.

~~~
dnautics
This is not my experience. Just yesterday I had to debug an error in staging
that had cropped up because erlang had changed its public API for ssh_file in
OTP/23\. Despite being three private libraries down (and in an obscure option,
and being not well documented) I had the bug identified in 30 minutes and the
patch rolled out on all three library levels in another hour.

The biggest help was IO.inspect, and then the next biggest was elixir_ls,
which had used typespec analysis and highlighted the error for me in my ide.

~~~
bostonvaulter2
As one of the contributors to ElixirLS this makes me happy :)

------
zulgan
it was huge mistake for us, it was chosen for the wrong reason, to solve a
non-problem, complicated everything without adding any value.

* cant find people for it and if you do they come because of the tech not because of the real world problems we are trying to solve.

* the no types thing makes people write tests that test for typos and make refactoring incredibly difficult because you have to fix gazillion pattern matching tests

* the tooling is just horrible, cant jump, because of pattern matching that makes it much more annoying

* phoenix was complete misfit for us as well, so i ended up hating it for no reason

so because of no-tooling and on-refactoring, accidental complexity only grows,
and we ended up with much more fragile system with infinite failure domain.

i wrote briefly about why it was chosen at
[https://eng.rekki.com/kitchen/kitchen.txt](https://eng.rekki.com/kitchen/kitchen.txt)
and why we moved to go.

that being said, i am sad that this was my first real world experience with
elixir, in a project where it was not a good fit, so now i am totally biased
against it. when i tried it briefly for few hobby projects it seemed like a
quite cool language.

-b

------
0peth
A language is a tool. You are right with your analysis about the 3rd party
libraries, it will absolutely slow you down.

Elixir is an okay language at best, if you look at it in comparison with let's
say Python:

1\. It is not any safer than python 2\. Not any faster than python 3\.
Abstracts away a lot of things away from you "magically" just like python 4\.
It is harder to read elixir cause you will have people writing all sorts of
random macros.

Where Elixir is good: 1\. Concurrency (Processes!) 2\. Based on BEAM but you
won't care for your simple API project and you shouldn't have to. 3\. Other
erlang goodness supervisors, otp etc.

Personally I detest Python, but you would be better off writing your app in
Python cause using Elixir you have gained nothing much substantially but lost
on all ecosystem and community support Python has gained in its long history.

As a sidenote, I hope you use a strongly typed language.

------
fogfish
I would recommend Erlang over Elixir. Rubyish syntax and leak of Erlang
abstraction is a tough combo.

------
samtechie
I have been using Elixir for about a year and the only problems I have found
is the much smaller ecosystem. It's still a niche language. This means you may
be the first one to encounter some problems although I have found the
community quite helpful. Even if the number of libraries cannot really stack
up to Rails the few libraries tend to be high quality. Overall, I find things
more explicit and understandable. There's a lot less magic and I find
functional code easier to reason about. At the end of the day, every popular
language was niche at one time but some people took a chance on it. Maybe
Elixir hasn't yet gone mainstream but its a fairly healthy ecosystem with many
brilliant, passionate people.

------
rubyn00bie
I've seen places regret Elixir, usually the following issues cause the biggest
regret:

1\. Hiring. Generally speaking, finding experienced Elixir engineers is not
cheap nor easy. Also, chances of finding someone willing to work in an office
is even more slim (very remote heavy talent pool)...

2\. Deployment/monitoring. Shipping your first Elixir application to
production will likely be one giant act of frustration if you're used to Ruby
or other scripting languages. Compile time vs runtime settings and environment
variables are a HUGE gotcha. Also, as fate would have it, BEAM is more like an
operating system than a simple runtime and thinking you can toss it into
container and be off to the races is a recipe for disaster. Hope you didn't
want to use distributed Erlang... (though this has gotten better recently,
tbh). A lot of common monitoring tools and methodologies have to be thrown out
the window because of how BEAM works internally (there are great ones to
accomplish most anything, but its just more to learn).

3\. Distributed systems, make for distributed problems. Yes, Erlang/Elixir and
BEAM give you some fucking amazing tools to build distributed systems... that
doesn't make building distributed systems themselves "easy" or "quick."

4\. Performance. Erlang/Elixir will probably take a hot-fast shit on most
scripting languages when it comes to network requests; however, if you need to
do any long-running number crunching or complex string manipulation, you'd be
better off almost anywhere else. This could also be categorized as "use the
right tool for the job, dummy."

5\. Learning curve is real and vastly underestimated. You aren't just learning
a language, you're sort of embarking on a quest to learn a new paradigm.
Erlang/Elixir, BEAM, and OTP (I'm going to refer to them as the "Triforce")
were designed together to solve a specific set of problems. The Triforce has
been in-use, 24/7, 365 days a year, for 30 years, in real, critical,
production systems. If you ever wanted to learn the "Actor" pattern, BEAM is
the most _metal_ implementation I know of... Also, really sit down and make
sure you understand it's all "non-blocking" thanks to the scheduler being able
to pre-empt processes.

\----

With regards to 3rd party libraries, I find in Elixir and Erlang, I need and
use way less of them... BEAM and OTP give you soooooooo much it's kind of
absurd how little you end up missing or wanting.

\----

Lastly, while a lot of the success stories here are great to read, a lot of
them have bad code, or things that are just silly to the trained eye. And
that's totally okay, the authors are learning, we all have do it, but I'd
probably not recommend the code as study material. In general, try and find
examples from people who have seem to have been using it for a few years.

\----

Addendum (via edit):

FWIW, I've been writing Elixir for about six years now (just checked some
commits), and have been employed full-time writing Elixir for five of those. I
wrote Ruby before that, and have never looked back... If you want my number
one selling point to any Rubyist :trollface: (but also very real), is in
Elixir a "horrible, slow, wretched monolithic test suite" still will take less
than 90 _seconds_ to run.

------
qgadrian
I don’t, I’ve being pushing everywhere I go to use it.

The main question is always the same, “how much effort it will take me to find
Febe if I need them”.

And my answer is always the same, “make them come and work with you, and focus
people excited and open to learn a new technology”.

------
joelbluminator
I think a big question is how much you like functional programming, afaik
you're not in OOP land anymore with Elixir. That's a very big mind shift and
might be a bigger consideration than even community size or ecosystem.

------
PopeDotNinja
I love Elixir, but I found the learning curve to be very steep for non-web use
cases. It's just different than anything else, and other than syntax, I'd
argue it nothing like Ruby.

------
s1gs3gv
You might also ask 'Who regrets not choosing Elixir'.

------
nickjj
I really like Elixir and want it to be even more popular than it is but...

My only real complaint with Elixir (and this covers Phoenix and Live View too)
is that things tend to get announced WAY before they're anywhere near being
production ready, so you may find yourself postponing building anything
because you're waiting for the announced thing to be ready to use.

For example Live View was talked about in the later months of 2018 but there's
still some things missing today that make it pretty sketchy to really use it
in a non-trivial production app, and the docs leave much to be desired. Things
like LV based file uploads as being part of the library was in the "near
future" or "on the horizon" a year ago, etc..

I only spent a weekend using it for a project to play with about 6 weeks ago
and ended up uncovering some bugs and even some feature requests that quickly
ended up making its way into the master branch of LV after reporting them. But
these are for things that seemed very basic to me in the sense that if the
folks who were developing it were using it in larger production apps, there's
no way those things wouldn't have made it into the library sooner.

In other words, I don't feel comfortable or confident at all to use it in
production because I'm afraid if I spend some real time working with it, I'm
going to end up being patient zero for so many bugs and edge cases. I want to
focus on building my apps and trust the libraries I use, not be a pioneer
(software is already difficult enough without bugs!).

On the flip side, Rails is a champion here and IMO it's very much why it's so
popular and will remain popular 5 or even 10 years from now. It's because most
of the things in Rails come from tech focused businesses using it to drive
their services and the core team also use it to drive their business.
Everything feels like it's really battle hardened, production ready when
features are talked about and was carefully designed based on months of real
world usage.

With Elixir, Phoenix and LV that feeling isn't there -- at least not to me. It
sort of kind of feels like the libraries are being built from a theoretical
point of view. I mean, I know the creators of those libraries do consulting
work, but it's super behind closed doors. There's never any talk about what
drives the development of practical features and it's kind of a bummer to get
glimpses of things on the horizon, but then years later they aren't ready for
production.

That's the thing that worries me about the future of the ecosystem. I also
think it's partly why it hasn't exploded in popularity. It's a nice ecosystem
for sure, but it's missing critical components for it to be adopted by the
masses.

That and I think generally speaking the language is very hard to pick up. I
know I struggle hard with Elixir with ~20 years of general dev experience
across half a dozen non-functional languages before touching Elixir. I still
feel like I have trouble reading Elixir code I've written 2 months ago when it
uses some "real" functional bits that I had to ask for help on.

I often feel like I hit 100% dead ends and have to ask another human for help.
I don't think I would be using the language if it wasn't for the IRC / Slack
channels. There's some folks going above and beyond to help people out there,
including Jose himself (the creator of Elixir).

With Python and Ruby I rarely encounter situations where I had to ask for help
like this. Google always had the answer for everything I couldn't figure out
based on tinkering and reading the docs.

It's not just due to less blog posts existing for Elixir / Phoenix too. It's
the language overall. I want to love it, but for whatever reason my brain
won't accept it naturally. I get hung up so frequently. I know this is just my
brain being an idiot, but I do wonder if anyone else feels the same.

My gut tells me yes because otherwise the language would already be one of the
most popular choices for building web apps. There's a lot of great things
surrounding the language.

------
hartator
I’ve played with Elixir/Phoenix a little bit and was not very happy with a few
things:

\- Debugging is hard. You can’t throw a REPL wherever your want in your code
and pipe states are hard to inspect.

\- Serving static files in Phoenix is oddly super hacky.

\- Deploy is hard. Mostly by the lack of support out there in term of
documentation and services.

~~~
dnautics
1\. IEx.Pry, if you are used to ruby's pry. Pipe states are extremely easy to
inspect:

    
    
        abc
        |> foo()
        |> bar()
    

to

    
    
        abc |> IO.inspect(label: "a")
        |> foo() |> IO.inspect(label: "b")
        |> bar() |> IO.inspect(label: "c")
    

If you use vscode, this user snippet will inject this (with line numbers as
labels) when you type "ins <tab>", which can be used to great effect with
multiline cursors. Since line numbers are usually the same length in any given
block of code, it's equally easy to ninja those IO.inspects out with the
delete key.
[https://gist.github.com/ityonemo/00875891748bed3ee68e5f1b75c...](https://gist.github.com/ityonemo/00875891748bed3ee68e5f1b75c1ffe1)

2- agreed

3- Mix releases have solved 80% of this problem, for me. Since it's trivially
extensible, I do a series of compile-time checks, include verifying that the
current branch is on master and correctly git-tagged; and then uploading to
Amazon S3. I haven't done this yet, but it's going to eventually trigger an
automated blue-green deploy.

~~~
rorygreen
Oh. Dropping IO.inspect into the pipeline is embarrassingly obvious! I can't
believe I didn't think to do that. I always used IO.inspect as a pretty
printer during development but I guess I didn't think it would return/pass
through its input. Thanks for pointing that out.

I clearly hadn't bothered to read the 'Getting Started - Debugging' page on
the Elixir website at any point.

~~~
dnautics
Oh man I'm so sorry. The difference between using io.inspect like this and not
is a the difference between "huge pain, worst ever" and "best concurrent
debugging feature ever". IO in erlang is atomic, so in concurrent systems IO
output will never be interrupted by IO output from another thread, which is
not generally true in other systems (c, c++, rust, go). It makes a HUGE
difference.

------
59nadir
I've used Elixir since 2015 and I find Elixir to be unusable for any kind of
intelligent domain modelling, but that's primarily because it's dynamically
typed and has no concept of real sum types, etc., not necessarily because it's
any worse at this than Ruby.

Any codebase beyond fairly small will be harder and harder to work with to an
unreasonable degree, in my experience, and any perceived "velocity" gained
from the dynamic nature of it is paid for doubly so by the lack of safety you
get beyond toy projects.

I'm only slightly more for Erlang as a choice mostly because it's simpler than
Elixir and doesn't have as much obfuscation of logic added to it that Elixir
does, but in reality it's also a bad choice for any bigger system. The runtime
is absolutely great, but the languages on it are generally not good enough.

~~~
kerkeslager
I'm a bit confused by this comment. Having used both Ruby and Elixir (more
Ruby) both languages have type systems which are quite capable of modeling
domains[1]. They lack static type _checking_ , but I find that a thorough test
suite catches most type errors anyway. And while creating a thorough test
suite is costly, static types _in most languages_ [2] don't reduce this burden
much: there isn't an alternative to thorough testing.

[1] This looks fine to me? [https://elixir-lang.org/getting-started/typespecs-
and-behavi...](https://elixir-lang.org/getting-started/typespecs-and-
behaviours.html#defining-custom-types)

[2] I have limited experience with Haskell, but my impression is that the type
capabilities do actually allow you to forego testing in a lot of cases. The
next best static type system I've used is C#'s, which I used professionally
for years, and in C# I think automated testing is still very necessary.

EDIT: I regret even talking about type checking here--that's not my point. My
point is that for _modeling domains_ , Elixir's type system is totally
adequate. I'll agree that Elixir's type checking could be better, but that's
not what the comment I was responding to said.

~~~
james-mcelwain
When people refer to "typing", it is almost certainly reasonable to assume
they are referring to static typing, as implemented by most languages. I don't
think this should be confusing.

Specs/contracts are cool but ultimately don't afford the same kind of
descriptive and expressive power that a static type system does.

> static types in most languages[2] don't reduce this burden much: there isn't
> an alternative to thorough testing.

However, there definitely is a burden about _how much_ testing you have to
write. I generally don't want to have to test every branch of my program to
make sure a string doesn't slip through where an int should be or that
variables are initialized and not null, etc.

~~~
alexbanks
I see that language parroted all the time - "With thorough enough testing a
dynamic language shouldn't be a problem", and I have never understood it.
Arguing to build what is essentially a build-time type checker in the form of
automated tests seems twice as cumbersome for half the benefit. Instead of
building tests that check each branch of a program's types, why not use a
language that forbids dynamic typing? You should still have tests, but IMO
tests that are just checking that a string is a string are A.) Time consuming,
and B.) largely useless beyond type validation.

~~~
kerkeslager
> You should still have tests, but IMO tests that are just checking that a
> string is a string are

The correct completion to this sentence is "irrelevant.", because that's not
what anyone is proposing.

The fact is, behavioral tests catch a lot of type errors even without
intending to, and more to the point, if you test all the behavior you care
about, then you don't care if there are type errors, because they only occur
in situations where you don't care.

~~~
pavel_lishin
> _if you test all the behavior you care about, then you don 't care if there
> are type errors, because they only occur in situations where you don't
> care._

If I test all the situations I care about, the one situation I thought I
didn't care about is going to fuck me in production.

~~~
kerkeslager
If you test all the situations you care about and statically type check, the
one situation you thought you didn't care about and that wasn't caught by the
type checker is going to fuck you in production.

It's not useful to talk about a binary "bugs versus no bugs", because "no
bugs" isn't plausible in most codebases.

It's also not useful to talk about "more bugs versus fewer bugs" because
that's only part of the picture: the other parts of the picture are how much
development effort was necessary to achieve the level of bugs you have, and
whether the number of bugs you have, and when you have them, is acceptable.

If it's a life or death application where any bugs at runtime are
unacceptable, then of course we want static types, but static types aren't
enough: I'd also want a theorem prover, fuzzer, a large number of human
testers, and a bunch of other things that require way too much effort to be
useful in an average software project.

The vast majority of software projects, runtime bugs are acceptable as long as
they don't lose data, cause downtime, or expose private information. If you
catch these bugs during unit testing instead of 30 seconds earlier at compile
time, that's fine. Static types might catch a few more bugs, but it is very
much not in evidence that the level of effort involved is lower than
equivalent unit testing in situations where reliability requirements are
typical.

------
Ceezy
The worst part of elixir is Jose Valim. Like the worst part of linux is Linus
Torwald...

~~~
thijsvandien
When you say something like that, you’d better provide solid justification.

------
danbmil99
Go with Django. Save yourself a lot of pain

~~~
uxcolumbo
What pain?

And what use cases?

I heard Elixir & Phoenix are great for web apps.

------
sergiotapia
Here's some Elixir negatives from someone who's worked with it for four years,
nearing five, and currently director of engineering at a startup where we use
Elixir for 100% of backend code.

1\. Expensive to find talent. 2\. Deploy story was kind of shit until recently
with mix release. 3\. In Rails or .NET you can find a package for literally
anything you can think of. In Elixir-land, it's not 100%. It's more like 80%.
One example, there's a Twilio elixir lib, but bad luck one of the calls we
need isn't supported by the package. In rails it's all supported.

\---

But on the other end of this, it's all rainbows and happiness. It's fast,
predictable, boring. I love that about the language.

I still use Nim for hobby projects, but anything professional I will write in
Elixir.

