In case you are wondering what to use as your next programming language, please consider Elixir!
It has a lot of advantages:
- it is an easy to use, well-designed functional programming language, that happens to boost productivity and be (a lot of!) fun at the same time
- it is modern, with modern tooling around the language (e.g. mix, edeliver)
- it has Phoenix, a modular web framework, ideal for APIs and traditional MVC, very modular
- it is rock-solid for a relatively young language
- stack traces are clean, readable, and point you in the right direction most times
- performance is decent on a single-core, but since it's basically Erlang, it scales better on multicore than most solutions out there
- it has a world-class concurrency model powered by OTP, but more approachable to the average programmer, lots of high-level concurrency abstractions built-in
- Umbrella projects for those who need or want a truly modular application without going all-in with microservices
- it is the only language besides Erlang proper, that runs on the ErlangVM that seems to be getting a lot of traction (or at least a lot more compared to the alternatives)
- the community is very welcoming and open, lead by José Valim and Chris McCord who are smart, pragmatic and very nice people
I love Elixir as much as the next guy, probably more, but I want to temper your enthusiasm a bit:
> it is modern, with modern tooling around the language (e.g. mix, edeliver)
Sort of. Mix is a nice package manager. Edeliver is a series of hacks on deliver, a five-year-old Capistrano clone. But don't expect Elixir to fit into 2015-class deployment systems just yet.
> stack traces are clean, readable, and point you in the right direction most times
Other times, the error happened in another process, all you see is a timeout, and it takes some spelunking. Not uncommon in my experience.
But I'll also add a couple of points:
- the docs system is fantastic, in particular the automatic generation of handsome docs websites, and the `doctest` system which allows example code in your docs to double as test code
- I'm not sure there is anything better than supervisors for isolating and recovering from errors. Defensive programming is one thing, but sometimes your RAM stick gets hit by a cosmic ray. Shit happens; have a plan.
Elixir looks interesting, but coming from many years of using Ruby, another dynamically duck-typed language is the last thing I need, and (in my humble opinion!) the last thing I think anyone should need in this day and age.
I have been using Go almost exclusively on the backend for the last 18 months or so, and it's a huge safety net. Go is nothing new, of course (it's basically Borland Pascal/Delphi -- which I also used for many years -- with GC), but it brings to the table a strictness that is very much needed (not to mention very good single-core performance).
Almost all the problems I encounter in large-scale Ruby programs have to do with wrong types or wrong shapes of data being passed around. It's an antipattern, but we have a lot of code lying around that uses Ruby hashes (dictionaries) instead of classes, because it's easy to do; but even if you create classes to wrap you data and validate the type of every single piece of data you pass around, the surface area is too large to cover perfectly. Not to mention that Ruby suffers from its own icky form of null pointer problem, the nil value.
And of course, static typing has many benefits -- not least allowing programmatic introspection (autocompletion, automatic refactoring etc.) in ways dynamic languages will never permit.
I know Elixir mitigates the lack of static typing with pattern matching, guards and the possibility of using @spec together with Dialyzer, but I'm not at all convinced that this is sufficient.
> stack traces are clean, readable, and point you in the right direction most times
I really have not found this to be the case. You'll get obscure unmatched function clause errors coming from the opposite side of your program, that can eat up most of the day trying to track down, ending up having to carefully look at the function guards deep in library code to attempt to figure out where things broke. And not to mention the parse errors - completely unhelpful coming from languages like Elm and Rust. And then there is the huge overuse of metaprogramming - just use functions dammit! And how you have to go trawling through the source code to figure out what `__using__` is going to dump into your module. And cargo-culted Ruby syntax that's pretty hostile to FP...
I am curious if you or any of the other Elixirists(not sure what the community is called) spent time learning Erlang first or jumped right to Elixir? If yes would you recommend spending time with Erlang first or is not necessary? I guess I don't know if there is an Interop similar to Clojure and Java.
You talk a lot about how easy and approachable it is to an average programmer. Can you say anything to an experienced above average programmer as to why Elixir should be my next language?
P.S.: If you're learning a new language, as a deliberate practice exercise, learning that language should be hard to you, or it won't be as effective in making you better.
Does Elixir have step through debugging (breakpoints, etc) with accurate referral back to source code? Once one gets used to a modern, civilized debugging environment it is very difficult to go back into the wild.
I'm curious about the performance of Elixir code compared to Erlang. I guess I'm what I'm really asking is how different is Elixir from Erlang in regards to the paradigm, and what performance costs does it pay for it?
It's great to see this list. As an Erlanger there's one thing that's started to bother me of late, and that's how subdued and declining the community feels. There are a handful of passionate and capable people making great strides to improve things (rebar3 is excellent for instance), but the momentum seems to be all behind Elixir these days.
Most of the action around Erlang (conferences, etc.) seems rooted in nostalgia not in finding ways to connect to new users or new use cases. Looking at the speaker list for Erlang Factory 2017 I'm trying to figure out why there's nobody from Whatsapp, MZ, Facebook, Amazon, Visa, Goldman Sachs, etc., and why so many of the speakers are repeats of years past (in some cases multiple times over multiple years past).
Despite having a ~15 year head start, and some really high-profile use cases, it seems like the Erlang powers-that-be haven't figured out how to capitalize on much of that, and it's a real bummer for people in my situation (and I'd argue the industry as a whole is worse off for it too). I'd really like to have my team use Erlang, but I'm feeling increasingly irresponsible suggesting they invest in it instead of Elixir.
Erlang Just Works(tm) for me, I have a problem and I write code to solve it, no whiz-bang new features or frameworks needed. That said I do partially agree, in particular advancing the state-of-the art in regards to inspecting and debugging would be great. Rebar3 is indeed excellent!
The programming style encouraged by Erlang/BEAM is a good multi-computer style as well as a good multi-core style. Everything is passed by value -- there are no pointer or reference types to put in messages. If you want a shared value then it has to be a key into a database.
If a company gets its major apps onto BEAM one could imagine a fairly straightforward auto-scaling story. As the number of scheduled BEAM processes grows for a given app, the need for CPU and memory could be expected to grow more or less linearly with it.
I'm really sad about the fate of Reia. It could have been the OO like language that migrated millions of developers to concurrent functional languages. Potentially much more effective at that than Elixir, which looks like Ruby at a distance but it's very different when one sits at the keyboard.
I'm diving into Elixir now to compare it with Golang for a new web app backend I'm working on. I really enjoy the functional paradigm but from what I've seen deployment can be a bit annoying. Whereas with Go you can compile and drop it easily into production.
A non-autoscaling deployment is quite easy to accomplish. Build releases with Distillery[1], and deploy them with Edeliver[2]. You get zero-downtime upgrades and rollbacks for free, as well as nearly automatic server clustering. I gave a talk about this last year in New York[3].
A deployment that can autoscale is harder to accomplish, but still not impossible. AFAICT, most people doing this are building releases with Distillery, wrapping those releases in a Docker image, then using the deployment and orchestration tools of their choice. Monica Hirst gave a talk about doing this with AWS CodeDeploy last year at Empire City Elixir as well[4].
Deploying releases has been fairly painless in my experience, but I also have had my head in Elixir and releases in general for a long time, so I may not be a great sample. You get a tarball containing everything the app needs to run, and all you do is extract it and run the boot script - other than entirely self-contained binaries like Go produces, I don't think it gets much better. Deploying without releases is probably a lot more painful though, due to the number of dependencies required, particularly web applications (Erlang, Elixir and Node). I recommend anyone deploying Elixir applications look into releases - it makes life much easier (imo).
Deploying to production is a pain in the ass to setup the first time and has a lot of gotchas. I know, I've done it.
It is getting better but right now the few things I can recommend the most are:
• learn what an "OTP release" actually is and what it means. This alone will save you days of your life.
• do rolling restarts, doing live upgrades is difficult and not necessary for the vast majority of applications.
• read the prod.exs config, there's a commented out setting you'll need to enable. I forget the name of it, but it's on my github "tehprofessor" with the repo "flying with Phoenix" (its probably outdated in many ways but that setting is essential).
• remember the application is compiled and then run, so you really won't get any runtime configuration (likes Rails' environments).
• Docker can alleviate build pain a bit, as it stabilizes your environment-- I don't use it myself but it makes building a bit more pleasant from what others have told me.
• you'll very likely need to include all the applications, including ones listed in your dependencies (it's a pain in the ass), in your mix.exs applications list if you're using exrm.
... it's been a couple months as I've been on a coding hiatus for health reasons (and a broken arm) but I believe most of the above should still be very true.
That said and even with all the bitching I've had about it, I still love Elixir and Erlang. Though I've been moving more to pure Erlang as time goes on (FWIW).
Edit: clarity and note about loving me some elixir/erlang.
We have Elixir/Phoenix in production on Heroku (with Heroku Pipelines) using a custom buildpack [0]. It's been great. We'll probably look at Docker. We use CircleCI, and this setup script [1] was a great starting point.
Where do you plan to deploy? Its easy enough to deploy to Heroku, and I imagine dockerizing an Elixir app is also a straightforward process. If, on the other hand, you are taking a more traditional approach and just deploying to a Linux box/vps there are solutions for that too (i.e. Chef, Capistrano).
It should be pretty far down in the list of things that influence your choice, imo, since it's basically a solved problem.
As far as deployment goes, I've had great success with flynn.io and an Elixir buildpack.
Flynn is amazingly easy to deploy. It provisions DO/AWS/Azure then bootstraps a single node or cluster literally at the push of a button. Then you just add it to your repo and push (provided the buildpack is already set up)
Even without exrm (Distillery nowadays), I've had quite a bit of success with using Docker, complete with hot patching. I come from a Linux administration background, though, so I'm a bit more open to abusing Docker's semantics in horrific ways.
I run erlang in production; our deploy is push code, compile, l(foo) from debug shell. (push code and compile driven by Makefile). It doesn't follow the OTP deployment model, but it's easy.
I've experimented with LFE, but I've generally found that if I want a Lisp, I'm better off with a more traditional Lisp. I also very much prefer using a Lisp-1 (like Scheme).
Joxa and CSCM are on my to-do list now (especially the latter, since it's supposedly a proper R7RS on BEAM) for that reason, but I haven't gotten around to giving them a serious go yet.
I went to a couple of meetups at OpenX. It's majority older programmers.
The topic of the day was how to attract new programmers to Erlang.
I've stated perhaps we need to emulate Ruby and have some killer framework such as Rails. Their community is very vibrant.
The response was no, stay the course, we don't need to do anything. What's the point of this talk of attracting new programmers to Erlang if the consensus was stay the course and do nothing?
This way back before Elixir was on the radar.
Stopped going to that Erlang meetup, the programmers were out of touch.
I am mighty glad that Elixir and Phoenix is taking off. Shows them that I was right. Either Erlang community change their mindset or stay the same.
There was a lot of chatter in a post a few weeks ago about Ruby shops adding Elixir to their toolkit. Erlang remains a niche, sadly, but Elixir looks poised to be mainstream.
It's developing I've seen a number of large companies starting adoption on a small scale and searching for devs.
GoPro, Adobe, Pinterest, Rakuten, Bleacher Report is a major user and has open positions. I am sure this is not a complete list.
[+] [-] iagooar|9 years ago|reply
It has a lot of advantages:
- it is an easy to use, well-designed functional programming language, that happens to boost productivity and be (a lot of!) fun at the same time
- it is modern, with modern tooling around the language (e.g. mix, edeliver)
- it has Phoenix, a modular web framework, ideal for APIs and traditional MVC, very modular
- it is rock-solid for a relatively young language
- stack traces are clean, readable, and point you in the right direction most times
- performance is decent on a single-core, but since it's basically Erlang, it scales better on multicore than most solutions out there
- it has a world-class concurrency model powered by OTP, but more approachable to the average programmer, lots of high-level concurrency abstractions built-in
- Umbrella projects for those who need or want a truly modular application without going all-in with microservices
- it is the only language besides Erlang proper, that runs on the ErlangVM that seems to be getting a lot of traction (or at least a lot more compared to the alternatives)
- the community is very welcoming and open, lead by José Valim and Chris McCord who are smart, pragmatic and very nice people
[+] [-] gamache|9 years ago|reply
> it is modern, with modern tooling around the language (e.g. mix, edeliver)
Sort of. Mix is a nice package manager. Edeliver is a series of hacks on deliver, a five-year-old Capistrano clone. But don't expect Elixir to fit into 2015-class deployment systems just yet.
> stack traces are clean, readable, and point you in the right direction most times
Other times, the error happened in another process, all you see is a timeout, and it takes some spelunking. Not uncommon in my experience.
But I'll also add a couple of points:
- the docs system is fantastic, in particular the automatic generation of handsome docs websites, and the `doctest` system which allows example code in your docs to double as test code
- I'm not sure there is anything better than supervisors for isolating and recovering from errors. Defensive programming is one thing, but sometimes your RAM stick gets hit by a cosmic ray. Shit happens; have a plan.
[+] [-] atombender|9 years ago|reply
I have been using Go almost exclusively on the backend for the last 18 months or so, and it's a huge safety net. Go is nothing new, of course (it's basically Borland Pascal/Delphi -- which I also used for many years -- with GC), but it brings to the table a strictness that is very much needed (not to mention very good single-core performance).
Almost all the problems I encounter in large-scale Ruby programs have to do with wrong types or wrong shapes of data being passed around. It's an antipattern, but we have a lot of code lying around that uses Ruby hashes (dictionaries) instead of classes, because it's easy to do; but even if you create classes to wrap you data and validate the type of every single piece of data you pass around, the surface area is too large to cover perfectly. Not to mention that Ruby suffers from its own icky form of null pointer problem, the nil value.
And of course, static typing has many benefits -- not least allowing programmatic introspection (autocompletion, automatic refactoring etc.) in ways dynamic languages will never permit.
I know Elixir mitigates the lack of static typing with pattern matching, guards and the possibility of using @spec together with Dialyzer, but I'm not at all convinced that this is sufficient.
[+] [-] bjz_|9 years ago|reply
I really have not found this to be the case. You'll get obscure unmatched function clause errors coming from the opposite side of your program, that can eat up most of the day trying to track down, ending up having to carefully look at the function guards deep in library code to attempt to figure out where things broke. And not to mention the parse errors - completely unhelpful coming from languages like Elm and Rust. And then there is the huge overuse of metaprogramming - just use functions dammit! And how you have to go trawling through the source code to figure out what `__using__` is going to dump into your module. And cargo-culted Ruby syntax that's pretty hostile to FP...
[+] [-] bogomipz|9 years ago|reply
[+] [-] didibus|9 years ago|reply
P.S.: If you're learning a new language, as a deliberate practice exercise, learning that language should be hard to you, or it won't be as effective in making you better.
[+] [-] lenkite|9 years ago|reply
[+] [-] clishem|9 years ago|reply
- good marketing
[+] [-] braveo|9 years ago|reply
[+] [-] im_down_w_otp|9 years ago|reply
Most of the action around Erlang (conferences, etc.) seems rooted in nostalgia not in finding ways to connect to new users or new use cases. Looking at the speaker list for Erlang Factory 2017 I'm trying to figure out why there's nobody from Whatsapp, MZ, Facebook, Amazon, Visa, Goldman Sachs, etc., and why so many of the speakers are repeats of years past (in some cases multiple times over multiple years past).
Despite having a ~15 year head start, and some really high-profile use cases, it seems like the Erlang powers-that-be haven't figured out how to capitalize on much of that, and it's a real bummer for people in my situation (and I'd argue the industry as a whole is worse off for it too). I'd really like to have my team use Erlang, but I'm feeling increasingly irresponsible suggesting they invest in it instead of Elixir.
[+] [-] dxhdr|9 years ago|reply
[+] [-] solidsnack9000|9 years ago|reply
If a company gets its major apps onto BEAM one could imagine a fairly straightforward auto-scaling story. As the number of scheduled BEAM processes grows for a given app, the need for CPU and memory could be expected to grow more or less linearly with it.
[+] [-] pmontra|9 years ago|reply
http://reia-lang.org/
[+] [-] sergiotapia|9 years ago|reply
Languages with great support for these hardware features will be the languages of the future and today.
Elixir is definitely a great bet, you'll max all your cores and not break a mental sweat about it.
Really compelling stuff and great developer UX.
[+] [-] kungfooguru|9 years ago|reply
[+] [-] Ambrosia|9 years ago|reply
[+] [-] nerdywordy|9 years ago|reply
Does anyone have experience with this?
[+] [-] gamache|9 years ago|reply
A deployment that can autoscale is harder to accomplish, but still not impossible. AFAICT, most people doing this are building releases with Distillery, wrapping those releases in a Docker image, then using the deployment and orchestration tools of their choice. Monica Hirst gave a talk about doing this with AWS CodeDeploy last year at Empire City Elixir as well[4].
[1] https://github.com/bitwalker/distillery
[2] https://github.com/boldpoker/edeliver
[3] https://www.youtube.com/watch?v=H686MDn4Lo8
[4] https://www.youtube.com/watch?v=mRspOj_sRgo
[+] [-] bitwalker|9 years ago|reply
[+] [-] rubyn00bie|9 years ago|reply
It is getting better but right now the few things I can recommend the most are:
• learn what an "OTP release" actually is and what it means. This alone will save you days of your life.
• do rolling restarts, doing live upgrades is difficult and not necessary for the vast majority of applications.
• read the prod.exs config, there's a commented out setting you'll need to enable. I forget the name of it, but it's on my github "tehprofessor" with the repo "flying with Phoenix" (its probably outdated in many ways but that setting is essential).
• remember the application is compiled and then run, so you really won't get any runtime configuration (likes Rails' environments).
• Docker can alleviate build pain a bit, as it stabilizes your environment-- I don't use it myself but it makes building a bit more pleasant from what others have told me.
• you'll very likely need to include all the applications, including ones listed in your dependencies (it's a pain in the ass), in your mix.exs applications list if you're using exrm.
... it's been a couple months as I've been on a coding hiatus for health reasons (and a broken arm) but I believe most of the above should still be very true.
That said and even with all the bitching I've had about it, I still love Elixir and Erlang. Though I've been moving more to pure Erlang as time goes on (FWIW).
Edit: clarity and note about loving me some elixir/erlang.
[+] [-] ivarvong|9 years ago|reply
0: https://github.com/HashNuke/heroku-buildpack-elixir 1: https://gist.github.com/joakimk/48ed80f1a7adb5f5ea27
[+] [-] HalcyonicStorm|9 years ago|reply
[+] [-] hamandcheese|9 years ago|reply
It should be pretty far down in the list of things that influence your choice, imo, since it's basically a solved problem.
[+] [-] ch4s3|9 years ago|reply
[+] [-] geakstr|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] afro88|9 years ago|reply
Flynn is amazingly easy to deploy. It provisions DO/AWS/Azure then bootstraps a single node or cluster literally at the push of a button. Then you just add it to your repo and push (provided the buildpack is already set up)
[+] [-] yellowapple|9 years ago|reply
[+] [-] toast0|9 years ago|reply
[+] [-] marianoguerra|9 years ago|reply
http://marianoguerra.org/talks/beamba-buenos-aires-meetup/#/...
follow the commits on this repo from the beginning to se how a fairly complete language is built
https://github.com/marianoguerra/otl
[+] [-] ocschwar|9 years ago|reply
[+] [-] metalon|9 years ago|reply
[+] [-] yellowapple|9 years ago|reply
Joxa and CSCM are on my to-do list now (especially the latter, since it's supposedly a proper R7RS on BEAM) for that reason, but I haven't gotten around to giving them a serious go yet.
[+] [-] gamache|9 years ago|reply
[+] [-] xor-xor|9 years ago|reply
https://notamonadtutorial.com/interview-with-robert-virding-...
[+] [-] digitalzombie|9 years ago|reply
I went to a couple of meetups at OpenX. It's majority older programmers.
The topic of the day was how to attract new programmers to Erlang.
I've stated perhaps we need to emulate Ruby and have some killer framework such as Rails. Their community is very vibrant.
The response was no, stay the course, we don't need to do anything. What's the point of this talk of attracting new programmers to Erlang if the consensus was stay the course and do nothing?
This way back before Elixir was on the radar.
Stopped going to that Erlang meetup, the programmers were out of touch.
I am mighty glad that Elixir and Phoenix is taking off. Shows them that I was right. Either Erlang community change their mindset or stay the same.
[+] [-] bogomipz|9 years ago|reply
[+] [-] macintux|9 years ago|reply
[+] [-] qaq|9 years ago|reply
[+] [-] jchassoul|9 years ago|reply
[+] [-] etiene|9 years ago|reply