Great news, more people discover how good Erlang(and obviously Elixir) is, especially comparing to Ruby/Rails. I hope more people are going to consider it.
A few weeks ago I wrote a very basic IRC server in Elixir to learn the language and was very impressed how fast I was able to get it running. Despite it being my first contact with a functional language the coding felt very intuitive to me.
The only thing I miss is good tooling support but I'm coming from Java and a bit spoiled in that regard.
I started using Phoenix for my most recent side project. So far, am really liking Elixir and everything that comes with it. Obviously, I am still learning, but the inclusion of the entire Erlang ecosystem is a big plus.
Will have to say that working with Elixir and Phoenix (so far) has been much more enjoyable than working with Rails.
I will say the only thing I really miss is extra tooling for debugging and so on, but I'm primarily a java developer, so I'm used to having all sorts of options at my fingertips for debugging.
The REPL is really powerful in elixir. You can get a command line into your running app, effectively.
Elixir projects tend to go thru three phases- early its' green code and everything's working, then there's a phase where you find a whole lot of errors and it looks like you're in trouble, but once you get past that you end up with code that you can put in production and literally forget about.
In that second phase, being able to connect to servers and inject data into them and see the results etc can be very useful.
> Immediate wins [...] We were able to get rid of some servers, and downsize the remaining servers [...] Response times are down as well [...] Development and deployment are also faster.
A case for new technology should be made more than just on pure technical features but also in terms of reduced ops load, say because of fault tolerance or saving in recurring infrastructure costs. Or it could be community friendliness and acceptance of new members. I feel Elixir does a great job there, as well.
Other thing I found using Erlang: It is simply more fun and easier to discover problems. Can launch observer. Setup traces with recon_trace (I started to do that more lately even instead of adding print statement to code, attaching traces to functions is just too easy). Even things like hot-patching have saved the day many time in terms of fixing an issue for some customers with 0-downtime. These seems like nice extras but they all add up and make a huge difference when taken together.
Ops wins should just be assumed, though. Not to be flip, but you'll gain performance wins picking just about any other language/stack than Ruby on Rails. Even Python blows it out of the water. Move to something like Erlang/Elixir with a ridiculously nice/tuned runtime, or compiled languages like Go, or a combination of the two like Java/.NET and you should see huge performance wins without much work.
Rails wins in some cases for development productivity, and is "good enough" for many things. But when it's time for scaling, the language/solution/stack choice almost doesn't matter if you're moving from RoR. That said, if free ops performance wins aren't part of the decision, you've done it wrong.
They should be, but often they are not I. It is mostly about "Look how fast it runs on my laptop, it means we can have millions of requests on a large server". I've heard people quote Techempower benchmarks as their reason to picking a language / library vs another.
"Elixir is blazing fast" it says, so I follow the link and notice that "blazing fast" apparently means 10x the speed of Ruby. I don't think that phrase means what they think it means.
Personally I've seen hundreds of projects in many languages called "blazing fast". To me they're meaningless words.
Elixir and Erlang are bad at number crunching, they aren't "fast" at computations like C is. However, because of the amazing piece of tech that is the BEAM, problems that are best solved through multiple processes/actors, concurrency, and distribution appear to be "blazing" fast because the two languages are very good at that type of stuff. Hence the Phoenix web framework being called "blazing fast"—the BEAM is great for servers.
Also since the VM is optimised for functional programming with no shared memory - it can do tricks you normally cant that help with speed. Like avoid GC in some cases.
If a given CPU can do X amount of work, with a C-based language you can maybe get 0.8X performance from that CPU.
With elixir you might get 0.4X performance. From that perspective Elixir looks slow.
But you can deploy 10 servers and thus get 4X performance overall, with essentially no cost for Elixir. On the other hand to make distributed system in C you will spend 10X the development time.
So Elixir is fast in the sense that you get a distributed system much faster, and you can get more overall performance by scaling across multiple CPUs.
(And I'm kinda avoiding that on a quad core CPU your C program is really going to only use one core out of the box while elixir will use all four.)
> And I'm kinda avoiding that on a quad core CPU your
> C program is really going to only use one core out
> of the box while elixir will use all four.)
I think that's a pretty major factor to avoid -- multicore processors are the immediate/commercial foreseeable future of CPUs, so its not inconsequential that Erlang/Elixir allow you to be able to use cheap processes in order take full advantage of this
Just a note for blog authors - please add link to your product on your blog, in visible. I almost didn't check what you do, because I'm almost too lazy to click on address bar and remove "blog" prefix.
I wanted to know, before reading article, what is their product, so I didn't notice links at the bottom.
Honesty I was expecting that logo, that says "GitMonitor" not "GitMonitor blog", will take me to their page, or something similar next to it.
We've being playing with Elixir and are planing to ship first production app in the Fall. Very productive and unique environment. Coming from node it's so much nicer for concurrency not to mention all the other cool features of BEAM VM.
Can someone explain this? "Umbrella projects ... [are] a really great concept that allows us to have multiple microservices living in the same codebase, while giving us the flexibility to scale each service separately". How is this any different from just storing the code for multiple services in the same repository?
21 comments
[ 2.7 ms ] story [ 60.8 ms ] threadThe only thing I miss is good tooling support but I'm coming from Java and a bit spoiled in that regard.
Will have to say that working with Elixir and Phoenix (so far) has been much more enjoyable than working with Rails.
I will say the only thing I really miss is extra tooling for debugging and so on, but I'm primarily a java developer, so I'm used to having all sorts of options at my fingertips for debugging.
Elixir projects tend to go thru three phases- early its' green code and everything's working, then there's a phase where you find a whole lot of errors and it looks like you're in trouble, but once you get past that you end up with code that you can put in production and literally forget about.
In that second phase, being able to connect to servers and inject data into them and see the results etc can be very useful.
A case for new technology should be made more than just on pure technical features but also in terms of reduced ops load, say because of fault tolerance or saving in recurring infrastructure costs. Or it could be community friendliness and acceptance of new members. I feel Elixir does a great job there, as well.
Other thing I found using Erlang: It is simply more fun and easier to discover problems. Can launch observer. Setup traces with recon_trace (I started to do that more lately even instead of adding print statement to code, attaching traces to functions is just too easy). Even things like hot-patching have saved the day many time in terms of fixing an issue for some customers with 0-downtime. These seems like nice extras but they all add up and make a huge difference when taken together.
Rails wins in some cases for development productivity, and is "good enough" for many things. But when it's time for scaling, the language/solution/stack choice almost doesn't matter if you're moving from RoR. That said, if free ops performance wins aren't part of the decision, you've done it wrong.
They should be, but often they are not I. It is mostly about "Look how fast it runs on my laptop, it means we can have millions of requests on a large server". I've heard people quote Techempower benchmarks as their reason to picking a language / library vs another.
Elixir and Erlang are bad at number crunching, they aren't "fast" at computations like C is. However, because of the amazing piece of tech that is the BEAM, problems that are best solved through multiple processes/actors, concurrency, and distribution appear to be "blazing" fast because the two languages are very good at that type of stuff. Hence the Phoenix web framework being called "blazing fast"—the BEAM is great for servers.
With elixir you might get 0.4X performance. From that perspective Elixir looks slow.
But you can deploy 10 servers and thus get 4X performance overall, with essentially no cost for Elixir. On the other hand to make distributed system in C you will spend 10X the development time.
So Elixir is fast in the sense that you get a distributed system much faster, and you can get more overall performance by scaling across multiple CPUs.
(And I'm kinda avoiding that on a quad core CPU your C program is really going to only use one core out of the box while elixir will use all four.)
These ratios are just examples, of course.
https://github.com/elixir-lang/elixir/wiki/Interoperability-...
I think that's a pretty major factor to avoid -- multicore processors are the immediate/commercial foreseeable future of CPUs, so its not inconsequential that Erlang/Elixir allow you to be able to use cheap processes in order take full advantage of this