4 ms·

I'm really intrigued by Elixir/Erlang and would love to learn more about it. The problem (and this isn't a criticism of the language at all) is that I just can'

I'm really intrigued by Elixir/Erlang and would love to learn more about it. The problem (and this isn't a criticism of the language at all) is that I just can't figure out what I would use it for. Currently I'm mostly working on webapps, and although I have control over the technology I use I'm not sure I can justify using Elixir in my projects. I'm working mostly with rapidly-changing MVPs, and the ability Rails gives me to iterate quickly is valuable to me. If I understand the Erlang value proposition, it's really meant for sending and dealing with millions or billions of messages in a distributed, fault-tolerant way. But since I'm nowhere near that scale (if my MVP can handle 5 concurrent users that's typically good enough to start with), I feel like switching to a language with less of an ecosystem would be almost all downside, even if the resulting code would be more scaleable. I'd love it if someone tells me that I'm wrong.

davidw 12y ago
I'm a fellow Rails user - and also an Erlang user. I think you're mostly right about where Rails and Erlang's sweet spots are, but one thing where you could use Erlang that Rails doesn't do so well is with web sockets, where they hold open a connection. Erlang's a nice complement to Rails in some ways, as it covers some things Rails doesn't do well very, very well. It's definitely a nicer model than Node.js, and for some things, better than Go, which is another one that's strong for some things Ruby's weaker at.
polskibus 12y ago
If you design your MVP with a REST layer in between written in Erlang/Elixir and use Mnesia for prototyping it could take you a long way and would be v. easy to scale. Mnesia has its limits as a NoSQL database so later you would probably switch to a RDBMS. For HTML-generation it will be better to write the code in Ruby or Python or whatever else.
- Akkuma 12y ago
  The large trend of SPA makes this even less of a concern, since nearly all of the views are actually generated on the client.
knewter 12y ago
We're building an app for a startup right now. Most of the application is a microservices architecture designed in Ruby/Rails (primarily using rails-api). There's a need for a realtime communication piece though. We've built websocket apps in Ruby with Celluloid before, and they started to be hard to manage after 5k concurrent connections. I expect to have to break that hurdle pretty quickly with this app, so we built an Elixir websockets component for this. We just push messages onto RabbitMQ from Ruby, and then we subscribe to those queues and retransmit them down client websockets where appropriate on the elixir side. It's a very nice approach, and an good reason to put Elixir in your stack if you have a similar situation. The Elixir code is around 100 lines of code sitting on top of Phoenix, and very easy to maintain and expand upon. (Also, I'm the guy that created the survey and that does ElixirSips)
chrismccord 12y ago
Our goals with Phoenix should accommodate your needs very well. We're building a framework that's highly productive, lets you iterate quickly, but is there to scale once you're ready. If you're curious what Phoenix has to offer, my ElixirConf presentation gives a good overview, particularly about our realtime websocket layer: http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-the-phoenix-building-an-elixir-web-framework http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-... Also, to counter the HTML generation point, Phoenix/Elixir is great for template generation.
rubiquity 12y ago
I was in your shoes not that long ago. Here's a few things I use Elixir for currently: - Background job processing. Ruby can communicate with Elixir via BERT-RPC[0] so instead of deploying Redis, Sidekiq, etc. I can just setup a machine with Elixir and use BERT-RPC to send background jobs to Elixir from Ruby and process background jobs in Elixir. It's faster and easier to deploy than any Ruby background processing library I've ever used (and I'm extremely fond of Sidekiq btw!). - WebSockets. As others have pointed out, Rails isn't good for this and the programming models of other tools like Node.js just don't sit well with me. - Command line apps. It's easy to roll some basic CLI apps in Elixir for getting things done. Go is probably better suited for this overall but I still find Elixir nicer for this than Ruby. I hope I was able to give you a few ideas. Keep in mind Elixir is maturing fast and already has a lot of great libraries in both Elixir and from Erlang. I don't think we're that far way from having Phoenix being great for things Rails is predominantly used for (rendering HTML). 0 - https://github.com/mojombo/bertrpc https://github.com/mojombo/bertrpc
pron 12y ago
> But since I'm nowhere near that scale... This is a problem I've been thinking about a lot. In the 90s, I don't recall developers saying, "I don't need the power that comes with the new Intel CPU" (or maybe I just ignored those voices). Whatever extra power you had -- you found some use for in terms of more interesting logic. Now, I'm not saying Erlang or Elixir achieve this, but the goal of many modern -- let's call them performance driven -- platforms (and I'm well aware that wasn't Erlang's original selling point, and probably not its current selling point either, but I'm addressing the parent's particular concern) is to basically give you more available computing power to use as you see fit. The fact that there are many voices like yours means one of two things: either those platforms are not transparent or general enough to bring back the old "free lunch" of clock-speed increases, or that contemporary application developers have grown used to a decade of less-than-dramatic increase in computing performance, and as a result, their imagination has suffered. I'm pretty sure it's mostly the former (in particular, we don't see enough software -- like PC games in the 90s -- that clearly demonstrate the advantages of harnessing more computing resources) but I fear the latter also holds some truth.
- angersock 12y ago
  Third option: Most problems faced by the working programmer simply don't benefit from a more powerful language, and the additional cost of switching isn't borne out. I suspect that's the case--single-threaded node apps or Rails apps are more than sufficient for a lot of client work (hell, even WordPress can get you quite a ways).
  - pron 12y ago
    But are they really sufficient or is it lack of imagination? I mean, why wasn't the XT sufficient? Or the 386? Is it a universal constant that a single, ~3GHz stream of x86 instructions (forget about ILP and friends for the moment) is sufficient for human needs (but, say, 1GHz isn't)?
lostcolony 12y ago
There are a few different web frameworks (someone mentioned Phoenix for Elixir; Chicago Boss is Rails-like in Erlang) you could make use of. Less of an ecosystem depends on what you're doing; if there's a real challenging component that a Ruby library makes easy, and no compelling Erlang/Elixir equivalent, yeah, that's a major consideration, but I suspect it happens less often than you think (I've never had a situation in Erlang/Elixir where I could reasonably expect a library and not found a decent, if not ideal, one). The time to ramp up certainly would count as a downside, but I also find I work surprisingly fast in Erlang (not really used Elixir professionally), enough to where I find it more pleasurable, and easier to debug, than I did Ruby. For specific use cases where you'd -really- benefit writing Erlang/Elixir; the Erlang language and VM was built to be fault-tolerant. All the design considerations were for that. Talk of scaling is possible because having a sane distribution and concurrency model fell naturally out of a need for fault tolerance, being able to isolate execution paths from each other and resume them individually, etc. Scaling is what makes it 'cool' right now, but it's not where the real benefit to a webapp writer is initially, fault tolerance and concurrency are. Each request can be handled concurrently, while being isolated from all the rest, and a failure in one will generally have no effect on any of the others. That is awesome. So, what are your requirements? Is one of them "we need maximal uptime"? Erlang/Elixir becomes a contender then. And if there's ever an expectation of it needing to scale, it suddenly becomes a serious consideration. And if you want real time server pushes, Erlang/Elixir websocket support > Ruby's, as others have indicated. And if the library functionality you need is equally well supported in both languages (or an equitable tradeoff between a couple different ones), and you can justify the time it would take to learn the language, or have already put in the time to get comfortable with it...

davidw 12y ago

I'm a fellow Rails user - and also an Erlang user. I think you're mostly right about where Rails and Erlang's sweet spots are, but one thing where you could use Erlang that Rails doesn't do so well is with web sockets, where they hold open a connection. Erlang's a nice complement to Rails in some ways, as it covers some things Rails doesn't do well very, very well. It's definitely a nicer model than Node.js, and for some things, better than Go, which is another one that's strong for some things Ruby's weaker at.

polskibus 12y ago

If you design your MVP with a REST layer in between written in Erlang/Elixir and use Mnesia for prototyping it could take you a long way and would be v. easy to scale. Mnesia has its limits as a NoSQL database so later you would probably switch to a RDBMS. For HTML-generation it will be better to write the code in Ruby or Python or whatever else.

Akkuma 12y ago
The large trend of SPA makes this even less of a concern, since nearly all of the views are actually generated on the client.

knewter 12y ago

We're building an app for a startup right now. Most of the application is a microservices architecture designed in Ruby/Rails (primarily using rails-api). There's a need for a realtime communication piece though. We've built websocket apps in Ruby with Celluloid before, and they started to be hard to manage after 5k concurrent connections. I expect to have to break that hurdle pretty quickly with this app, so we built an Elixir websockets component for this. We just push messages onto RabbitMQ from Ruby, and then we subscribe to those queues and retransmit them down client websockets where appropriate on the elixir side. It's a very nice approach, and an good reason to put Elixir in your stack if you have a similar situation. The Elixir code is around 100 lines of code sitting on top of Phoenix, and very easy to maintain and expand upon. (Also, I'm the guy that created the survey and that does ElixirSips)

chrismccord 12y ago

Our goals with Phoenix should accommodate your needs very well. We're building a framework that's highly productive, lets you iterate quickly, but is there to scale once you're ready. If you're curious what Phoenix has to offer, my ElixirConf presentation gives a good overview, particularly about our realtime websocket layer: http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-the-phoenix-building-an-elixir-web-framework http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-... Also, to counter the HTML generation point, Phoenix/Elixir is great for template generation.

rubiquity 12y ago

I was in your shoes not that long ago. Here's a few things I use Elixir for currently: - Background job processing. Ruby can communicate with Elixir via BERT-RPC[0] so instead of deploying Redis, Sidekiq, etc. I can just setup a machine with Elixir and use BERT-RPC to send background jobs to Elixir from Ruby and process background jobs in Elixir. It's faster and easier to deploy than any Ruby background processing library I've ever used (and I'm extremely fond of Sidekiq btw!). - WebSockets. As others have pointed out, Rails isn't good for this and the programming models of other tools like Node.js just don't sit well with me. - Command line apps. It's easy to roll some basic CLI apps in Elixir for getting things done. Go is probably better suited for this overall but I still find Elixir nicer for this than Ruby. I hope I was able to give you a few ideas. Keep in mind Elixir is maturing fast and already has a lot of great libraries in both Elixir and from Erlang. I don't think we're that far way from having Phoenix being great for things Rails is predominantly used for (rendering HTML). 0 - https://github.com/mojombo/bertrpc https://github.com/mojombo/bertrpc

pron 12y ago

> But since I'm nowhere near that scale... This is a problem I've been thinking about a lot. In the 90s, I don't recall developers saying, "I don't need the power that comes with the new Intel CPU" (or maybe I just ignored those voices). Whatever extra power you had -- you found some use for in terms of more interesting logic. Now, I'm not saying Erlang or Elixir achieve this, but the goal of many modern -- let's call them performance driven -- platforms (and I'm well aware that wasn't Erlang's original selling point, and probably not its current selling point either, but I'm addressing the parent's particular concern) is to basically give you more available computing power to use as you see fit. The fact that there are many voices like yours means one of two things: either those platforms are not transparent or general enough to bring back the old "free lunch" of clock-speed increases, or that contemporary application developers have grown used to a decade of less-than-dramatic increase in computing performance, and as a result, their imagination has suffered. I'm pretty sure it's mostly the former (in particular, we don't see enough software -- like PC games in the 90s -- that clearly demonstrate the advantages of harnessing more computing resources) but I fear the latter also holds some truth.

angersock 12y ago
Third option: Most problems faced by the working programmer simply don't benefit from a more powerful language, and the additional cost of switching isn't borne out. I suspect that's the case--single-threaded node apps or Rails apps are more than sufficient for a lot of client work (hell, even WordPress can get you quite a ways).
- pron 12y ago
  But are they really sufficient or is it lack of imagination? I mean, why wasn't the XT sufficient? Or the 386? Is it a universal constant that a single, ~3GHz stream of x86 instructions (forget about ILP and friends for the moment) is sufficient for human needs (but, say, 1GHz isn't)?

lostcolony 12y ago

There are a few different web frameworks (someone mentioned Phoenix for Elixir; Chicago Boss is Rails-like in Erlang) you could make use of. Less of an ecosystem depends on what you're doing; if there's a real challenging component that a Ruby library makes easy, and no compelling Erlang/Elixir equivalent, yeah, that's a major consideration, but I suspect it happens less often than you think (I've never had a situation in Erlang/Elixir where I could reasonably expect a library and not found a decent, if not ideal, one). The time to ramp up certainly would count as a downside, but I also find I work surprisingly fast in Erlang (not really used Elixir professionally), enough to where I find it more pleasurable, and easier to debug, than I did Ruby. For specific use cases where you'd -really- benefit writing Erlang/Elixir; the Erlang language and VM was built to be fault-tolerant. All the design considerations were for that. Talk of scaling is possible because having a sane distribution and concurrency model fell naturally out of a need for fault tolerance, being able to isolate execution paths from each other and resume them individually, etc. Scaling is what makes it 'cool' right now, but it's not where the real benefit to a webapp writer is initially, fault tolerance and concurrency are. Each request can be handled concurrently, while being isolated from all the rest, and a failure in one will generally have no effect on any of the others. That is awesome. So, what are your requirements? Is one of them "we need maximal uptime"? Erlang/Elixir becomes a contender then. And if there's ever an expectation of it needing to scale, it suddenly becomes a serious consideration. And if you want real time server pushes, Erlang/Elixir websocket support > Ruby's, as others have indicated. And if the library functionality you need is equally well supported in both languages (or an equitable tradeoff between a couple different ones), and you can justify the time it would take to learn the language, or have already put in the time to get comfortable with it...