I’m of the firm opinion that Elixir is the going to be, for me, the main language for backend production systems for the next decade of my career–having tried PHP, Ruby, JS/Node, Java, Python, C/C++…it just feels right. But.
Buuuuut.
The thing that makes Elixir good beyond the points mentioned in this article is a pervasive conservatism and desire for quality, mostly because of its adjacency to Erlang/OTP and that community of responsible engineers solving unsexy problems. Elixir has adapted the (often clunky) tooling of Erlang and has done a lot to bring it up to standards developers expect in modern projects, but without going whole-hog new-shiny as we’ve seen with, say, ActiveRecord or Rails or Meteor or whatever else.
Except, that doesn’t last. As more and more developers (looking at you, Rails folks) come streaming in to get into the Next Big Thing, expect that conservatism to give way to poorly-written libraries, to new frameworks to give conference talks, and to code written in complete ignorance of the performance characteristics in the underlying system.
I’m currently neck-deep in a legacy Phoenix system (yes, such things do exist!), and I’ve seen (in our and others’ projects):
Well-meaning developers using Verk (a port of Sidekiq/Resque, basically) for work queuing instead of just normal supervision trees
Excessive use of tooling for hot code swapping/reloading just because Elixir/Erlang/OTP supports it, regardless of the cost when things don’t work correctly. Simpler deployment makes sense
Pipeline operators used in place of bog-simple nested parens for arithmetic
Pervasive use of maps where structs would be better typed and more reliable
Pervasive use of string values where atoms would be more efficient
Use of blind exception throwing instead of god-fearing Erlang {:ok, ... }, {:error, ... } tuples that can be handled correctly
Overly-clever metaprogramming (I’m looking at you, Phoenix router)
Ignorance of core Erlang documentation and features (docs, for some reason, not reliably included by the Elixir folks…probably to discourage their use)
And outside of that, I’ve seen a (subjectively) massive increase in the number of me-too and one-off projects on Hex that show that people are sharing buggy, poorly-tested libraries and others are piling on because Elixir is TEH NEW AWESOME.
I fully expect somebody (maybe @355e3b) to write something like “The Gentrification of Erlang/OTP” to explore this troubling trend further.
The way to fix this is not to complain and grumble but to do the blogging, talking, and teaching to make things better. To that end I’d much rather see @355e3b teach us what he knows and help us all get better at Erlang/OTP and maybe even Elixir as a byproduct.
This is the problem with technologies that get HN/blog hype. Add to this mediocre learning materials written by people with no production experience to make a quick buck (“buy my book/course on Elixir for $5!!!”).
The issue is simple: People rushing to get experience with Elixir and not learning it or OTP properly. It’s all about being able to put it on your resume or GitHub instead of actually learning it.
–
I fully expect in five years to see people say that you don’t need OTP to be an Elixir programmer.
Personally I’ve also seen the OTP use go the other way - “There is this great OTP stuff so we gotta use it!”, where a simple function would suffice people try to use supervisors etc. for no reason other than to just do it. Or “I have to use OTP so I create a single GenServer which I’ll delegate all requests to”, which is basically you taking a parallel system (all requests in phoenix are their own process) and creating an artificial bottle neck by sending it all to a single process.
A serious question about your Verk remark (note I haven’t used so I don’t know what it does, more general about background job system): I see that I’m less likely to need a background job system in BEAM land. However, when I have it in the BEAM (Supervisors, Genservers maybe ETS etc.) and don’t do hot code upgrades the jobs get lost when I restart/stop&start the application, don’t they? Am I missing something? Same thing with maximum retries and exponential back off - should everyone re implement those themselves (like we do a lot of API calls to notoriously unreliable APIs of partners)? When I really need those, I’d happily use a library to achieve them. Am I missing something essential here?
My initial reaction for that would be to look at dets and even an Elixir-wrapped Mnesia. For the retries and exponential backoff, again there are Erlang libraries that have solved them for quite a while, and yet people are still kinda introducing new ones. It’d be nice if we got more of that standardized into the standard lib. :)
And yeah, excessive use of OTP is also a problem–people get really enamored with tools and may misapply them.
The code examples are really wonderful to back up the points he’s making. I’ve only dabbled with Erlang/Elixir but am bookmarking this to see how I can apply these techniques to current problems I’m trying to solve with small one-off scripts.
These articles are really making me impressed with Elixir’s design from maintainability point of view. That MP3 parser looked close to the informal pseudocode and header definition. I also like how it lets you specify something while also saying to ignore it.
EDIT: @PragTob I just read the Bleacher Report article since that was new to me. It seems to be an exception to your claim next to the link that “if you re-read the articles, though, other benefits of Elixir take as much the stage as performance…” In the Bleacher Report, performance and resource efficiency is about all they talk about. It’s the main reason they switched and justify further investment. They even went on to explain how they had to invest in new ways of benchmarking performance due to the difference. So, maybe you might want to change it to not imply performance was a footnote in that one since it was about all they talked about.
Hey, yeah thanks - I think I rewrote/rearranged that portion late some night :| You are definitely right, the good code is just a minor part in that post. Will adjust.
It’s certainly a fad, just like Ruby and JS. Which is to say something that is going to deliver a ton of business value over the next decade and foster its own pop culture in a feedback loop we’re all accustomed to.
As someone who learned a good bit of Erlang 10+ years ago, I was initially worried about added complexity. Especially after being burned by the CoffeeScript nightmare.
I started writing Elixir daily at work about 10 months ago. A couple weeks of using Elixir disabused me of that. Elixir is a really seamless implementation and provides valuable support for everyday programming. The only reason I might end up reading Erlang code is if I have a problem with a dependency.
If you’re a glutton for punishment you can call Elixir code from Erlang.
Saša Jurić wrote up some excellent points about why elixir. Not saying we all should do it, but there are some advantages, helpful features and superb Erlang interoperability.
Another thing that I enjoy about Elixir is the community. Not just the people, but the community is a “melting pot” different communities - Erlang and Ruby mainly but there’s also a good amount of people from Haskell, JavaScript and others. Together ideas meet and new concepts and ideas emerge.
But Erlang is not the same as OTP and BEAM, and Elixir is “just” another language the uses OTP and BEAM. Sure, it’s close to Erlang in some (many even) respects, but it’s not simply a “prettier Erlang”. If anything, it’s a better engineered and much faster Ruby.
Didn’t know that elixir had doctests! I find them one of the most fascinating parts of python, the first draft of an incredible feature that just never got a second draft. Does elixir do anything different with them than Python? Seems so based on your positivity.
Hey, I haven’t written Python in a long time so I didn’t even know Python had doctests. What I find though (compared to how I’d see doctests if they existed in Ruby) is that it is easier to do due to the immutable nature. As the effects of methods aren’t side effects it lends itself better to doctesting as what you wanna see is jut the return value of the method.
Also, the increased usage of simpler data structure makes the session setup easier than I’d imagine it would go with most objects.
I’m of the firm opinion that Elixir is the going to be, for me, the main language for backend production systems for the next decade of my career–having tried PHP, Ruby, JS/Node, Java, Python, C/C++…it just feels right. But.
Buuuuut.
The thing that makes Elixir good beyond the points mentioned in this article is a pervasive conservatism and desire for quality, mostly because of its adjacency to Erlang/OTP and that community of responsible engineers solving unsexy problems. Elixir has adapted the (often clunky) tooling of Erlang and has done a lot to bring it up to standards developers expect in modern projects, but without going whole-hog new-shiny as we’ve seen with, say, ActiveRecord or Rails or Meteor or whatever else.
Except, that doesn’t last. As more and more developers (looking at you, Rails folks) come streaming in to get into the Next Big Thing, expect that conservatism to give way to poorly-written libraries, to new frameworks to give conference talks, and to code written in complete ignorance of the performance characteristics in the underlying system.
I’m currently neck-deep in a legacy Phoenix system (yes, such things do exist!), and I’ve seen (in our and others’ projects):
{:ok, ... },{:error, ... }tuples that can be handled correctlyAnd outside of that, I’ve seen a (subjectively) massive increase in the number of me-too and one-off projects on Hex that show that people are sharing buggy, poorly-tested libraries and others are piling on because Elixir is TEH NEW AWESOME.
I fully expect somebody (maybe @355e3b) to write something like “The Gentrification of Erlang/OTP” to explore this troubling trend further.
Haskell’s policy of “avoiding success at all costs” is looking more sane by the year.
(I’m probably misusing that quote.)
misbracketing it at any rate (:
The way to fix this is not to complain and grumble but to do the blogging, talking, and teaching to make things better. To that end I’d much rather see @355e3b teach us what he knows and help us all get better at Erlang/OTP and maybe even Elixir as a byproduct.
This is the problem with technologies that get HN/blog hype. Add to this mediocre learning materials written by people with no production experience to make a quick buck (“buy my book/course on Elixir for $5!!!”).
The issue is simple: People rushing to get experience with Elixir and not learning it or OTP properly. It’s all about being able to put it on your resume or GitHub instead of actually learning it.
–
I fully expect in five years to see people say that you don’t need OTP to be an Elixir programmer.
Hey - thanks for your excellent remarks!
Personally I’ve also seen the OTP use go the other way - “There is this great OTP stuff so we gotta use it!”, where a simple function would suffice people try to use supervisors etc. for no reason other than to just do it. Or “I have to use OTP so I create a single GenServer which I’ll delegate all requests to”, which is basically you taking a parallel system (all requests in phoenix are their own process) and creating an artificial bottle neck by sending it all to a single process.
A serious question about your
Verkremark (note I haven’t used so I don’t know what it does, more general about background job system): I see that I’m less likely to need a background job system in BEAM land. However, when I have it in the BEAM (Supervisors, Genservers maybe ETS etc.) and don’t do hot code upgrades the jobs get lost when I restart/stop&start the application, don’t they? Am I missing something? Same thing with maximum retries and exponential back off - should everyone re implement those themselves (like we do a lot of API calls to notoriously unreliable APIs of partners)? When I really need those, I’d happily use a library to achieve them. Am I missing something essential here?My initial reaction for that would be to look at dets and even an Elixir-wrapped Mnesia. For the retries and exponential backoff, again there are Erlang libraries that have solved them for quite a while, and yet people are still kinda introducing new ones. It’d be nice if we got more of that standardized into the standard lib. :)
And yeah, excessive use of OTP is also a problem–people get really enamored with tools and may misapply them.
The code examples are really wonderful to back up the points he’s making. I’ve only dabbled with Erlang/Elixir but am bookmarking this to see how I can apply these techniques to current problems I’m trying to solve with small one-off scripts.
Ha, thanks for the nice words! I hope it helps you!
These articles are really making me impressed with Elixir’s design from maintainability point of view. That MP3 parser looked close to the informal pseudocode and header definition. I also like how it lets you specify something while also saying to ignore it.
EDIT: @PragTob I just read the Bleacher Report article since that was new to me. It seems to be an exception to your claim next to the link that “if you re-read the articles, though, other benefits of Elixir take as much the stage as performance…” In the Bleacher Report, performance and resource efficiency is about all they talk about. It’s the main reason they switched and justify further investment. They even went on to explain how they had to invest in new ways of benchmarking performance due to the difference. So, maybe you might want to change it to not imply performance was a footnote in that one since it was about all they talked about.
Hey, yeah thanks - I think I rewrote/rearranged that portion late some night :| You are definitely right, the good code is just a minor part in that post. Will adjust.
I kind of feel like Elixir is a fad which adds complexity - if you want to use erlang, just write erlang.
It’s certainly a fad, just like Ruby and JS. Which is to say something that is going to deliver a ton of business value over the next decade and foster its own pop culture in a feedback loop we’re all accustomed to.
As someone who learned a good bit of Erlang 10+ years ago, I was initially worried about added complexity. Especially after being burned by the CoffeeScript nightmare.
I started writing Elixir daily at work about 10 months ago. A couple weeks of using Elixir disabused me of that. Elixir is a really seamless implementation and provides valuable support for everyday programming. The only reason I might end up reading Erlang code is if I have a problem with a dependency.
If you’re a glutton for punishment you can call Elixir code from Erlang.
Saša Jurić wrote up some excellent points about why elixir. Not saying we all should do it, but there are some advantages, helpful features and superb Erlang interoperability.
Another thing that I enjoy about Elixir is the community. Not just the people, but the community is a “melting pot” different communities - Erlang and Ruby mainly but there’s also a good amount of people from Haskell, JavaScript and others. Together ideas meet and new concepts and ideas emerge.
But Erlang is not the same as OTP and BEAM, and Elixir is “just” another language the uses OTP and BEAM. Sure, it’s close to Erlang in some (many even) respects, but it’s not simply a “prettier Erlang”. If anything, it’s a better engineered and much faster Ruby.
Didn’t know that elixir had doctests! I find them one of the most fascinating parts of python, the first draft of an incredible feature that just never got a second draft. Does elixir do anything different with them than Python? Seems so based on your positivity.
Hey, I haven’t written Python in a long time so I didn’t even know Python had doctests. What I find though (compared to how I’d see doctests if they existed in Ruby) is that it is easier to do due to the immutable nature. As the effects of methods aren’t side effects it lends itself better to doctesting as what you wanna see is jut the return value of the method.
Also, the increased usage of simpler data structure makes the session setup easier than I’d imagine it would go with most objects.
great article! so many times I caught myself saying ‘yes!’. thanks so much for writing this.
ha, thanks a lot for the nice words. Glad you enjoyed it! :)