Hacker News Reader

Comment by arms | Hacker News Reader

I love the concept of Elixir, but is it used out in the wild much? A language's popularity, or lack thereof, has little influence on whether I'll learn it or not, but I'm always curious about this.

View on HN

I use it for some minor automation tasks at work (munging data in files and the like). That's one of the coolest things about Elixir in my opinion; it's great for the kind of stuff you used to use Perl for, while still being fantastic at the kind of stuff Erlang is used for. I'm obviously not using the full power of the language by any means and I'm yet to use all the OTP stuff except for toy applications for fun. But it's a refreshingly enjoyable language to work in. I haven't built anything that a client has directly paid for with Elixir yet, but sooner or later I hope to get something like an Elixir version of one of our Rails apps going in my free time and convince my boss we should give it a try for real.

I definitely see how this would be useful for automated tasks. I have some python scripts doing a fair bit of automated data munging that would probably benefit from being written in Erlang/Elixir.

Slight tangent - people often say learning Haskell is worth it for the eye opening experience it provides, regardless of whether you get to use it day-to-day. Would you say the same of Erlang and Elixir?

Funny you should ask. I actually started giving an honest go at learning Haskell before I started learning Erlang and later Elixir. So for me, I wouldn't say they were as eye opening as Haskell (truthfully Common Lisp and Scheme gave me more "woah!" moments than anything else so far) simply because of the order in which I learned them.

However, if you've never learned Haskell, OCaml, or F# I don't think it's a stretch to say that Elixir/Erlang's similar use of pattern matching and guards would have an eye opening effect that makes it worth learning. In both Haskell and Elixir/Erlang they're a core part of using the languages idiomatically. Once you see it in action you'd be hard pressed to not take some of the lessons with you elsewhere.

So, yes. Elixir and Erlang will make you rethink some assumptions about how to solve problems you probably never knew you had. Such as the "necessity" of explicit conditional statements. If anything you'll get better at using recursion to solve actual problems instead of just for contrived classroom-type problems.

I can't say explicitly; Haskell is something I keep coming back to playing with but I've never used for any real development, so I can't directly compare them.

With that caveat though, Erlang and Elixir are gentler introductions to FP if you've never experienced one, yes. But I wouldn't describe them as functional programming languages, but rather -concurrent- ones. They -will- change how you think about concurrency, distribution, and fault tolerance if you're coming from a more typical OO paradigm.

Let it crash, and all the mechanisms and decisions made to ensure that that is a viable strategy, the per process encapsulation of state, the message passing paradigm, the extremely cheap concurrency, and yes, the functional aspect of it, have changed my coding patterns in pretty fundamental ways.

To give a real world implication, I had a situation where an unknown number of scheduled tasks had to fire, each one involving multiple steps, with each step being itself a scheduled event (and those times could change). Some could start at the same time. Each one entailed a non-trivial amount of work, IO bound.

The traditional approach would be to create a thread pool of the maximal number of simultaneous things I wanted to support, create a heap or similar of all scheduled tasks, peek at the top of the heap, sleep until that amount of time, then put that task onto the threadpool. Repeat. Any changes though...the heap would have to be rebuilt. Or whatever. A whole lot of bookkeeping, basically, and a data structure that does not map to what I'm doing, and which requires locking, and possible race conditions and bottlenecking.

In Erlang (and Elixir)? A new process per scheduled event, with a paired timer process to send it a message when it's supposed to start up. Each process is responsible for its own timer; updates to a process cause it to modify its timer, and if a task involves multiple time separated steps, it just creates a new timer when it finishes one, to wake it when it's supposed to do the next. There is no interaction between scheduled items, so why should I have to code around dealing with all of them simultaneously? No locks, no race conditions, no bottlenecking. Bugs are pretty much guaranteed to be in the task code itself, rather than in the task scheduling code, and are much easier to track down and solve.

Great usecase.

Currently any large Erlang/OTP production system uses a combination of Erlang for long-living servers and Python/Ruby scripts for the automation/deployment/scrapping/scripting. There are escripts, but they awkward to use.

With Elixir it's easy to do scripting and have much greater code reuse.

There are a couple companies in the wild using Elixir. Once Elixir hits v1(August is the estimate) it will change less week to week and will be more suitable for production usage.

I recently emailed with a company using it for the back-end of multiplayer video games they make. They seemed to be interested in hiring open minded programmers with Ruby, Python, Erlang, and likely other experience, but didn't seem to expect any actual professional Elixir experience. Just an anecdote of course, but perhaps proof that there is at least a fledgling market for the language!

I swear those guys must have contacted half of the devs in the US.

We're pushing 7 billion api calls/month through it. on two aws boxes.

So it's ~1300 RPS per EC2 instance on average? What the peak RPS and which EC2 instance type?

    julia> 7e9 / (30.4*24*60*60) / 2
    1332.5414230019496

that's about right. > 3k at peak. it's a simple POST for logging views. not a lot of data in each POST. not sure on EC2 box size. using https://github.com/extend/cowboy and pushing to a 16 server cassandra cluster.

Elixir is still very young. The only language I know of that had any appreciable acceptance at this point in its life is Go.

In my limited experience (about 2 weeks) with elixir, that's really the only thing I'm having a hard time with. Problems you encounter (due to the fact that you're learning a New Thing...not any fault of the language itself) aren't super google-able, so there's a lot more struggling.

The documentation is pretty good though.

Glad you like the documentation!

If you are running into issues, feel free to post issues to the elixir-talk mailing list or stack overflow. I check those daily (and many others too).

You can also join the #elixir-lang channel on IRC. It is not as fast as having google-able solutions but we will get there!

Thanks!

I understand the googleability is a bit of a chicken and egg problem, but I've really enjoyed the language so far so I'm trying to stick with it and lean a little bit every day. Thanks for all the work you've done.

I'm looking forward to learning Elixir, but expect that it will have no work relevance. I had a look for Go jobs on Brit job sites - three. Great learning experience, both, but the wild is slow to change.

Reply on news.ycombinator.com