Several versions ago Jose talked about how Elixir is basically "done", which is so refreshing these days!
But since then, the developer experience has improved by leaps and bounds through all these improvements other than the core language. As a professional Elixir developer for the last 4 years, I'm loving it. A few improvements in the last few versions off the top of my head that have been really nice:
* Robust, timezone handling DateTime support in the standard library. I don't need Timex anymore!
* Finally a good approach for configuring applications ar run time (e.g. with ENV vars), that works for dev, test, prod and releases, via config/runtime.exs.
* Better compiler warnings verging on a little "light" type checking
* Mix.install in this release finally makes Elixir work well for one-off little scripts, since you can just throw a Mix.install([:jason, :mojito]) on top.
* LiveView is amazing, and I now keep open a LiveBook notebook for doodling in code, exploring an API, CSV, etc
* Not really Elixir, but I'm jazzed about Erlang/OTP 24 JIT support for better performance.
Basically, if you took a look at Elixir a few years ago and thought it wasn't ready, might be worth another peek now.
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.
Does that mean you're going to be able to drop into an Iex.pry session right in the middle of an exs script without having to wrap it all in a project?
I always found I had to do that and found it quite annoying (working through adventofcode with elixir..)
Agreed that this is huge for quality of life - the ability of Ammonite (a Scala shell) to require remote dependencies in the script is amazing, compared to having to set up a whole project and build a jar.
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.
It had them. But if you did a System.get_env inside the config.exs/dev.exs/prod.exs etc it would be at compile time. Various patterns arose to do that at runtime, by using things like `{:system, "FOO", Integer}` as conventions, but it was always a bit ad hoc. If a lib saw that they would know to punt the actual reading to runtime, which is what many folks did before releases.exs, which runs at RUNTIME, so things like System.get_env work as expected.
The mechanism that Elixir used for providing different configuration values for dev, test, and prod (via dev.exs, test.exs, and prod.exs files), did not work well with environment variables, since those configuration files were evaluated at build time, which wouldn't work if you built, e.g., a single prod app and wanted to run it with different ENV vars in staging and prod.
Meanwhile, as of Elixir 1.10, there was a file called releases.exs which you could use to configure your release (basically a compiled artifact that included the BEAM VM runtime system that you could drop on your server to run, the preferred way of deploying production apps). However, those values didn't affect running the app not as a release, which is common when developing locally.
In the end, our organization kind of standardized on an approach of reading the ENV vars in the app start up, at the top of the supervision tree, which kind of worked in all scenarios.
But then in Elixir 1.11 there's finally a great (IMO) way of configuring: a new file called runtime.exs which is the best of all worlds. Like the old dev/test/prod files, it's evaluated when you run a mix project, so it's used during local development, and has access to Mix.env, so you can set variables based on environment. But it instead of being evaluated at build time, it's evaluated at run time, so you can refer to environment variables, too. And, it's used by releases!
So now there's a very slick standard way to configure your app, that works in all situations.
Haven't had a chance to observe a lot of runtime stats yet but I can tell you that my compile times in big projects fell down dramatically with Erlang/OTP 24.0, at times with 35%.
Havent's measured by myself but I'd expect performance noticeable improvement for GraphQL apps that use Absinthe, since significant time is spent on parsing, validating and serializing data around resolvers.
DateTime was added in Elixir 1.8.0. Timex filled a vacuum for a long time, and still has a few nice convenience functions. In new codebases, I of course drop Timex, but it was very much needed until those APIs were added.
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.
The point how all of Erlangs strengths are now obsolete because of XYZ that now exists misses the point how with Erlang/Elixir all of those things are at your fingertips using a single technology stack that is not hard to use and will scale very well for practically anyone.
I think I saw this one. In many cases there are some crazy good, purpose built solutions that are better than what Erlang/Elixir can offer, but that requires learning and managing all that tooling. Often, good enough is fine - especially for small productive teams.
I'm on my second team that has adopted Elixir and it has really helped our productivity being able to keep so many capabilities in one kit.
That's basically it, yes for sure I could install some external pubsub software & associated frontend & backend boilerplate with any other stack but I just wouldn't bother doing it for just refreshing a tiny counter whereas with phoenix pubsub & liveview, it's just one line of code.
It helps you to add lots of tiny quality of life improvements to your product that you wouldn't bother with normally.
I went though that persons submissions/comments on HN. its literally the only time they mention Elixir, everything else is ruby/rails or python. Makes me wonder if it's a troll post.
Oh yes, @joelbluminator, the troll-in-chief when it comes to Elixir posts. You really have an axe to grind against this language, do you?
> For one I really do think Elixir is a horrible career choice and I wanna save young average developers who still have time to correct that mistake (https://news.ycombinator.com/item?id=27204755)
Sadly, your trolling is too subtle to get shadow banned, so we are doomed to keep reading your inane comments in every Elixir thread, hiding under the cowardly guise of "doing it for the young developers."
Of course not. But reading how somebody who is strongly convinced that their current tech choice is good is trashing another tech that didn't immediately solve all their problems isn't a compelling or objective criticism either, wouldn't you say?
Thinking back, I remember that the guy had 1-2 good points but the rest was mostly ranting. They are fun to read but rarely are informative.
I'll add that even without understanding OTP in full, people will get good results.
I have also had good results with non-Elixir coders learning it with a bit of coaching, and recruiting is OK these days due to interest of developers for the language.
> Sadly that HN thread is biased toward the person/team that is "leaving" Elixir because it wasn't a good fit for them
Having a balanced pros and cons are great for everyone. Not every thread should be praising Elixir else people won't be able to make an informed decision before selecting a language to build their business on.
I'm personally more interested in cons of a tool as opposed to the pros. This way I can assess whether the failure points are within the acceptable parameters or not.
> For the people who understand Elixir/OTP's strengths it's excellent.
Is there any place to read about this on a more or less basic level? I bet many people will just ask what benefits they may get from this instead of apps build using Go (for example) + rabbitmq
If you're trying to limit your exposure to different technologies, then I think Elixir is a great choice.
If you're going all in on cloud, microservices, and managed services, then - outside some specific problems - I'm not sure if Elixir is any better of a choice than other language. I personally like immutability+FP but that feels a bit subjective.
But I've worked at small companies for most of my career, and it's my (obviously subjective) opinion that Elixir will let you build a better system if you don't have the luxury of using the "right tool for each task".
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.
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.
The one thing I’ll say about Elixir I’m always impressed how disciplined they are with the issue tracker on GitHub. Currently 17 issues for such a broad piece of work seems nothing less than astonishing.
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 :-)
I'd also add it is pretty amazing how responsive and friendly the core team is. They generally are very clear, but polite when they don't accept something and super fast about addressing bugs.
I started following phoenix and a few other important Elixir repos on github several months ago. I'm amazed how many times the community has taken the time to help someone debug why their specific scenario isn't a bug with the library and pointed them to the right solution.
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.
Basically, in Elixir pipelines are not very friendly to simple destructuring: if a call at the beginning of the pipeline returns a tuple of `{:ok, result}`, you can't use either of shortcut syntaxes for lambdas (&Mod.fun/arity and &Mod.fun(&1)), you have to use `fn` and destructure in its head. pattern_tap solves this quite elegantly, but I was told that it's a "non-standard macro that people don't know, so it shouldn't be used"... So when I saw `tap` in Kernel, I though that maybe it's similar at least... unfortunately, it's not similar at all, and now the global identifier `tap` is taken, which made the situation even worse :(
> if a call at the beginning of the pipeline returns a tuple of `{:ok, result}`
In my understanding, pipeline are mostly reserved for “unfailable” operations operating on raw data; whereas the where/else/do macro is more oriented towards errors handling; would it work better in your case?
I think you mean `with`, not `where`? Yes, it helps a bit in some cases, but it's not a replacement for a pipeline - mainly because you'd need to name your intermediate results and "thread" them through the calls yourself.
I think I gave a bad example, the better one would be a function returning datetime in the format of :erlang.localtime: `{{Year,Month,Day},{Hour,Min,Sec}}`. I would like to be able to use this value in a pipeline, by passing only a `{Hour, Min}` tuple to the next call in the pipeline.
Without - there are at least 3-4 ways of doing this, each with pros and cons, but all of them are more verbose than pattern_tap. If you want a single value only, there's `elem`, but if you need a few - you're out of luck. `destructure` only works on lists, and `match?` only return a boolean, not whatever was matched.
`then` macro makes it a bit better, but you still need to create a lambda with the longhand syntax, which is exactly what I wanted to avoid, so it's hardly a solution, even though it may be the best way to do this for now...
EDIT: this is in contrast to Clojure, where maps and vectors are callable, and you get `juxt` in the stdlib. So it's not like pipelines in general can't support convenient extraction of subsets of data flowing through the pipe, it's just that Elixir decided not to support this.
As an aside, I teach Elixir as part of my distributed systems MSc course. Anyone here in the London area (or even UK) looking for junior engineers? It would be nice to have some companies to point my students at when they start looking for jobs (or year in industry).
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.
If you are working through a programming textbook and doing the exercises in elixir, LiveBook is great https://github.com/elixir-nx/livebook (vs one big mix project)
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.
I second this - it is the best solution if one wants to decouple upgrades of Elixir vs OTP, and is really useful for long term upgrades (one step at a time).
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 :)
> 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.
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.
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.
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.
But since then, the developer experience has improved by leaps and bounds through all these improvements other than the core language. As a professional Elixir developer for the last 4 years, I'm loving it. A few improvements in the last few versions off the top of my head that have been really nice:
* Robust, timezone handling DateTime support in the standard library. I don't need Timex anymore!
* Finally a good approach for configuring applications ar run time (e.g. with ENV vars), that works for dev, test, prod and releases, via config/runtime.exs.
* Better compiler warnings verging on a little "light" type checking
* Mix.install in this release finally makes Elixir work well for one-off little scripts, since you can just throw a Mix.install([:jason, :mojito]) on top.
* LiveView is amazing, and I now keep open a LiveBook notebook for doodling in code, exploring an API, CSV, etc
* Not really Elixir, but I'm jazzed about Erlang/OTP 24 JIT support for better performance.
Basically, if you took a look at Elixir a few years ago and thought it wasn't ready, might be worth another peek now.