Elixir Users' Survey 2014 | Hacker News Reader

Elixir Users' Survey 2014

blog.elixirsips.com

71 pointsnithinbekal20 comments

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.

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.

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.

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

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)

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-...

Also, to counter the HTML generation point, Phoenix/Elixir is great for template generation.

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

> 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.

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).

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)?

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...

I've been looking at Elixir more and more over the last few weeks since it seems to incorporate many of the things I find lacking in Python. So far the only real hurdle was that I found the introduction text a little obtuse when it came to Mix and OTP (I'm often slow to get through introductory guides, since I'm a learn-by-doing person).

Would love to hear from other people who have come from a JavaScript / Python heavy background what their experience has been with the language. Or from people who do web development in general if they feel its a good fit.

I come from a javascript/python background, you might want to take a look at the Phoenix web framework[1], as it will give you a good introduction into the language, but also introduce some new concepts (OTP-wise) that will help you think more "elixir-y" (or "erlang-y").

One thing I constantly keep in mind when programming in Elixir is that, using it in the same way you would use Python is a waste. For example, when I use Python, I'm not typically thinking of concurrency (outside of, "how many gunicorn workers will I need?"), because of the situation with concurrency in Python. Using Elixir (or Erlang), you really aren't taking full advantage of the language/runtime/VM if you don't take concurrency into account. If all you want to do is a little string munging, you can do it in Elixir, but it is probably not the best tool for the job.

The Mix & OTP guides available on elixir-lang.org are great, but if you want more information on OTP, the OTP chapters in "Learn you some Erlang"[2] are wonderful. You will have to do some translation from Erlang syntax to Elixir, but it is a great way to learn how to think concurrency.

1: https://github.com/phoenixframework/phoenix

2: http://learnyousomeerlang.com/content

Point well taken as far as concurrency, really reading up on GIL along with working a lot with SOA is part of what is informing my desire to find a more appropriate language. I want to become more proficient in developing web services that scale, as well as expanding my mind somewhat by working with a different model / from a different perspective.

I will have a look at the links, for sure. Thanks!

I was primarily a Ruby programmer so before I dove into Elixir I mostly wrote Sinatra and Rails apps, and occasionally some Node.js. When I first came to Elixir I mostly approached it as a fun thing to do in my spare time. The language really has some great features for solving problems in concise ways. But as I've spent more and more time with the language I've started to realize it can replace far more of the projects that I used to use Ruby for than I first though.

I've worked on a couple projects in Elixir already. I do still like Ruby/Rails for rendering HTML (there's years of hard work in making that an easy thing to do in Rails), so a common web app that I create lately will be Rails as a very thing wrapper around the database for rendering HTML and then an Elixir component for background jobs and WebSockets.

That said, a ton of great work is going into Phoenix[0] and I think it's very close to being suitable for both rendering HTML and WebSockets. On my next project I'll probably try and just use Phoenix entirely.

0 - https://github.com/phoenixframework/phoenix

I'm really excited about Exilir because it makes creating DSL like the Phoenix Web Framework, trivial.

However, I am concerned though that developing in Erlang is a paradigm shift for most developers (eg letting apps crash when unexpected behavior occurs, concurrency model, etc) and Exilir makes it too easy to think you're developing in a procedural language when you're not.

I wonder if I'm alone with this concern. One thing simply the Erlang syntax does well is re-enforce the idea of how to fundamentally change how to develop applications to fit its model yet Exilir hides all of that

Edit: typo

Are you by any chance familiar with Flask/Sinatra? Is Phoenix in any qualitative way better (more flexible/costumizable/simpler) than those two?

Phoenix sits somewhere in b/w Sinatra and Rails custom/simplicity wise, while offering features that neither address, i.e. (realtime communication with browsers, native iOS, & soon android clients). "Qualitatively better" is a loaded question, but by virtue of Erlang VM, Phoenix apps can be distributed across a cluster without extra fanfare. You could run 20 Phoenix routers, load-balanced on a cluster, and everything like Webscokets/pubsub would "just work". i.e., no extra layer in b/w like redis or rabbit, no code changes, and no issues with things like sticky sessions.

FYI it's called Elixir, not Exilir.

100% agreement here. Erlang doesn't look like an procedural language, so I'm not tempted to think in procedural terms. Also, Erlang's single-binding variables tends to keep me honest.(edit: add next sentence) That being said, Elixir does have some very nice features and is quite well designed; José Valim and other contributors are very open to input.

Reply on news.ycombinator.com