Elixir 1.12 (opens in new tab)

> Mix.install

This is game changing for me (my life is boring). I totally didn't even know this was coming. It's like unexpected Christmas! For folks not in the know, it's been kind of a PITA to have packages loaded in an Elixir repl without a proper project. This should enable a lot more developer tooling to exist too; I'm stoked because I have one tool in particular that's going to be immediately be useful thanks to this change.

Yep, when you consider a language "done", you can focus on bringing up the DX. I have been loving Elixir since 2016 and haven't looked back since, using it as my primary language for what it's good for, which is web based/distributed workloads.

Hey, thanks for this super useful breakdown. I loved Elixir looking at it a few years ago but never got productive enough in it to do more than a few smaller toy projects. I'm going to dig into it again.

Wait Elixir didn't have a good approach for env vars until recently?

That is like, item one on my list of things I need to be able to handle in a backend web application.

> Not really Elixir, but I'm jazzed about Erlang/OTP 24 JIT support for better performance.

I'm really interested to see how the JIT effects our app. I've seen some reports suggesting that a 20% bump in speed isn't unreasonable to expect.

excellent list, thanks for sharing this.

Timex was never needed. We have a library Calendar.DateTime that has all the functionality we need

It makes me really sad that Elixir isn't more popular than it is. I'm just a hobbyist but would jump at a good opportunity to write it full time (though I'm really happy with my current employer and want to put more time in with them). There's just so little BS in the language itself (by my standards). A good Elixir program reads SO well thanks to some strong conventions. I particularly like how it's very common to forgo imports and just prefix functions with their module name. That coupled with it being functional make for very little need to jump around when trying to understand a function--everything is just right there. It's also so nice having a performant, query-able key-value store at your fingertips. Anyway, I dunno, I know that it being a dynamic language is a deal-breaker for many but gah, I'm rambling at this point. I just really, really like it.

Sadly that HN thread is biased toward the person/team that is "leaving" Elixir because it wasn't a good fit for them. For the people who understand Elixir/OTP's strengths it's excellent. We use Elixir for several apps and haven't had any issues recruiting/training people (remote). If we were to chose again we would 100% pick Elixir; nothing else comes close for our use-case.

Disclaimer: I use Elixir in production (e.g. here on the French national transport data hub https://transport.data.gouv.fr/?locale=en), but I also like other tools (Ruby, Rust, Crystal etc).

My impression is that some (not all) people had a bad experience partly because they may have reached for Elixir at a period where everything wasn't "settled" (a bit too young). The "first vague of hype" generated some libraries which are now unmaintained (e.g. oauth2), and some parts are still rough (XML, I look at you).

Having upgraded a number of old apps, though, I find that library quality has gone up, the overall developer (and maintainer) experience has improved, and there is a sense of stability which will have a real impact I believe.

There is a need to reach a larger critical mass I believe to really enjoy things in full, but as far as I am concerned, I would be perfectly confident to build my next SaaS on top of it.

I'm actually surprised by that thread, every time I see an Elixir related article on hear the comments are usually all talking about what a joy it is to work in. (as you can see in this thread).

I have been doing elixir for the past ~1yr and from my experience it's the language itself is pretty good, but I really wish it had better tooling, static typing, and more mature libraries for interacting with common tools. Just my own opinion, but I would chose another language for future projects.

>with great insights about the language.

most insights there, in relation to leaving, are not about the language but in relation to the environment, e.g available packages, integration with external tools etc. as reasons for the aforementioned departures.

I believe it is due to 2 things: excellent vision and work first, but also the nature of the language (not a coincidence) tend to lead to strong "lever effect", 2nd level order benefits, hard focus on composability.

I'm, though, curious if other people have more insights about that, because it is truly impressive :-)

That's partly because Jose is a machine. I have one anecdote that might provide some insight:

I filed a bug that turned out to be an incorrect dialyzer spec on a library function. Jose fixed it and merged the fix to master within 40 minutes of me filing the bug. It was a small issue, and I had done a reasonable job at bug filing (small test case, pointers to source of problem) but to have that level of discipline and responsiveness on bug fixing is spectacular.

I wish they'd instead fix the compiler to not require .then

But in absence of that this is a huge QoL improvement.

tap though... OMG yes!

I work in the Wireless and Digital Systems department of Cambridge Consultants (Cambridge, UK). We build weird and wonderful radio systems for clients. We are using an increasing amount of Elixir and Erlang because it's a great fit for what we do, but it's still in the minority.

V7(v7labs.com) is based in London and we are going to be looking for junior engineers quite soon. We use Elixir quite extensively. Drop us an email!

Oh really cool! Which University then?

I highly recommend using the hexpm docker images, which you specify with elixir, erlang, and distro versions, e.g. hexpm/elixir1.12-erlang24.0-debian-buster.

Since the official Elixir versions aren't pinned to a version of Erlang, we had issues where either Erlang or the distro should change out from under us. But not with the hexpm ones.

https://elixirschool.com is really good

I found going through the official Elixir guide top-to-bottom to be an excellent crash course:

https://elixir-lang.org/getting-started/introduction.html

For a frame of reference, an Erlang VM running all of Phoenix will consume 16MB memory on startup, so we need more details on what exactly you've heard and for what usecases. For the Phoenix channels 2M connection benchmark, some folks claimed go uses less memory for websockets, but neglected to consider our realtime layer monitors connections for multiplexed messaging, handles distributed PubSub, etc, so it wasn't a proper comparison. There are certainly nuanced convos we could have about memory usage vs other platforms, but a blanket "non memory efficient for web" anecdote is inaccurate :)

This runs on 256mb VMs and works well even when it gets busy: https://liveview-counter.fly.dev

And I'm biased, but we are a pretty good place to run an Elixir app: https://fly.io/docs/getting-started/elixir/

> Looking into Elixir, but from what i've heard, Elixir isn't very memory efficient when it comes to web servers.

It really depends on your reference point and what your web servers are doing. The Elixir website has a series of cases and perhaps you can find an example closer to what you are doing: https://elixir-lang.org/cases.html - there are also cases where companies reduced the number of nodes in production once they migrated to Elixir.

Regarding deployments, Heroku, Gigalixir, Fly.io, Droplets, K8s, etc are all viable options.

Because of the way that Phoenix handles HTML templates it’s probably one of the most memory efficient.

https://bignerdranch.com/blog/elixir-and-io-lists-part-2-io-...

My Elixir backend, doing background processing, admin interface, data ingestion and serving data via GraphQL consumes 300 MB RAM on average, which is 20% less memory than the Node/Next.JS React frontend. YMMV.

I host a pet project Slack bot on a Digital Ocean droplet. You can compile an Elixir app into an executable that treeshakes the BEAM. I can't speak to memory usage, but deployment for me is as easy as compiling an executable and putting it on the server.

For me, it's: libcluster (automatic clustering with Kubernetes Service) + horde (distribute workload across cluster) + Kubernetes Deployment

Whenever I need to upgrade, I perform a rollout, new OTP application instances perform a takeover, once it's done previous pods are taken down.

I've heard some stories, mostly around XML handling if I recall well, and also due to people not using a form of streaming when it would have been necessary.

I'm curious to know what you have heard with more precision, if possible.

I have https://elixirdaily.link (an elixir/beam news aggregator running) on the smallest, free Gigalixir VM just fine. Does a ton of memory intensive work and doesn't go OOM (had to be careful with # outbound http connections).

> Elixir isn't very memory efficient when it comes to web servers.

I'm serving (https://domovik.app) for a few dozen people on a few dozens MB of RAM. Sure, it's not Google scale, but I really can't complain about memory usage.

Just to get a frame of reference, what is memory efficient for web servers?

You could create a Phoenix project, launch it and use the erlang observer or the Phoenix LiveDashboard to monitor memory consumption and decide if that suits you.

Huh? Elixir isn't memory effecient, compared to what exactly :)?

Render.com does a great job at running distributed Elixir.