back

by eatonphil·11y ago·view on hn ↗
I took a look at Erlang/Elixir a while ago and didn't get too far into it after realizing there was no compile-time type-checking.

My main question coming out of it: if you are going to go with a dynamic language, why go with Elixir over Python or Ruby (or Clojure or Racket or ...)? These have a larger mind-share and a more broadly recognized syntax.

Granted, Erlang (BEAM?) processes are appealing.

If you are using Erlang or Elixir, why?

9 comments
Elixir creator here. This is a very good question and a very hard one to answer because there are so many facets to consider. I will provide some bullets instead of doing direct comparisons.

* Concurrency is not an after thought. The primary abstraction are actors (Erlang processes) that are isolated and communicate with message passing. Data structures are also immutable which helps greatly with concurrency and also leads to clearer code (it is really comforting to know that a value won't change under your feet).

* The Erlang VM: we are leveraging 30 years of knowledge in building and running fault-tolerant systems, thanks to the underlying process model. We could really go deep into this topic so I will just link to an article I wrote some time ago talking about Elixir and microservices: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...

* Performance may also be a big deal depending on what you are doing. Elixir/Erlang are not good at number crunching but if you are running anything behind TCP/UDP, it will give you better throughput and a consistent latency compared to Ruby, Python, Node.JS, etc.

* We don't have compile time checking but we do provide type specifications and a way to check them: http://elixir-lang.org/docs/master/elixir/Kernel.Typespec.ht.... The integration between Elixir and Dialyzer is suboptimal today but if type checking is a big deal for you, it will certainly help.

TL;DR: Elixir is for building and running fault-tolerant, concurrent, distributed systems. It brings extensibility and great tooling to the Erlang VM. If what you are building requires 1. a TCP/UDP port and/or 2. running for a long time, you should definitely consider Elixir. An introduction to the language can be seen here: https://vimeo.com/131631884

Thanks for taking the time to reply here, Jose. Elixir is definitely a very impressive language and as a former PL student, I am definitely a huge fan of your work.

That said, if I were looking into a BEAM language in the future - and after this thread I am inspired to try again - I would probably be more inclined to go with Erlang. For the same reason that Java is probably an easier sell than Scala.

However, I am most likely not your target audience. I am neither an existing Erlang user nor a Ruby user (nor even a Node user).

I think Clojure is finding it pretty easy to sell its advantages over Java...
Not sure if you are trolling or not, but here goes.

I would choose Elixir over Ruby or Python if my service needed to high reliability or if it touched the network in any significant way. Ruby and Python suck at concurrency and are "fragile" when serving lots of connections. Clojure or Scala (seriously, no one is building a product in Racket...) would be appealing but the JVM brings its own set of headaches and even with bolt-on large-scale concurrency support the JVM languages are not significantly better at these problems.

Broadly recognized syntax? Elixir is much easier for people to read than either Clojure or Scala and is close enough to Ruby that Elixir is drawing over a lot of developers from that group.

I use Elixir because it is fun, it scales well and has high performance for the problems I am throwing at it, and it helps me develop solid and reliable solutions.

Not trolling. I used OCaml because it was "fun" and "highly-performant". Would I recommend it to my clients? No. Granted, this is almost entirely due to the POS stdlib - a problem Erlang and (by extension) Elixir do not share. However, the syntax and alternative MO are still a big sell. I'd argue that the majority of people out there doing web engineering (even the big ones) don't need it. Heck, look at Facebook using PHP.

I'm not sure what my point is - it's just not an easy sell?

The easiest sell to clients and stakeholders is reduced operational overhead, lower costs, and higher reliability. Real-world stories are coming out of 10-20x reduced server counts from Ruby and Python systems that have been replaced by Elixir. We also have stories like WhatsApp (Erlang) who supports their hundreds of million of users with a few dozen engineers. The dollar cents here make it a strong sell to stake holders, and the platform features make it a strong sell to the rest of your team and software requirements.
We have also heard stories such as LinkedIn, Netflix and Twitter migrating from different languages (such as Ruby for Twitter) to Scala. How do you think this success story of building distributed concurrent backends compare to Elixir's?
Objectively: Scala is dramatically larger than Elixir as a language. Akka is much larger than OTP.

Personal, subjective conclusion: Scala is substantially more complicated to use and learn than Elixir (to achieve the same ends).

Personal, subjective remark: Scala is substantially more complicated than Haskell. It's just so big.

Deciding on what language to use on a new project and rewriting a large app are two different things. It's much harder to sell a rewrite than it is to sell using a different language on a greenfield project.

If you know Elixir and are confident using it, you'll understand its benefits and when best to use it. I work for a dev shop where we use Elixir for client work. Elixir is performant and you end up making the most out of your server resources. That would be great for clients who end up having huge traffic. But more important than performance, I find it easier to maintain Elixir code largely because it's a functional language. Lastly, I think Elixir's Lisp-inspired macros are a great way to write reusable libraries/modules.

In essence, I'm more productive with Elixir than I am with Ruby even though I used Ruby for much longer. I find it a more pleasant experience maintaining Elixir code than Ruby code.

Do you have a link to the shop or any success stories? I'm pretty interested to read something in depth or even just hear more about your customers.
> POS stdlib

Try Jane Street's Core. I hear it's a better situation.

> "highly-performant"

On one core. Erlang and Elixir will blow it away when employing more cores, naturally.

Though OCaml would probably perform similarly or better (for certain CPU-bound tasks) when running N processes to N cores. You'll need to bring your own IPC mechanism - this is probably the key BEAM value add.

> syntax and alternative MO are still a big sell > web engineering > it's just not an easy sell?

You sell based on productivity, performance, and correctness:

"By using this technology, you will have less bugs, which is cheaper and more productive in the long-term."

Granted, this is a very hard thing to prove, it has anecdotally been my experience with ML-derivatives.

F# on BEAM would be a match made in heaven!
I've been watching Elixir (and Phoenix Framework) as well. In addition to lightweight processes, the functional style, immutability, pattern matching and Rubyish syntax are appealing too.
Elixir helps manage complexity by encouraging the structuring of code in terms of series of transformations on data. This makes code simpler, more readable, easier to read, reason about and maintain. It also helps avoid whole classes of complex bugs and problems that inevitable creep into large codebases of Java, Python or Ruby code.
> It also helps avoid whole classes of complex bugs

Whole "classes" indeed.

Especially for Ruby devs who are fed up dealing with concurrency and performance problems in Rails, Elixir is very attractive and will make you code in a different way.

So what differentiates it from Clojure or Racket then (which are ostensibly more interested in transformations on data)?
The concurrency model. I recommend Rich Hickey's talk "the language of the system" (ironic, I know). In erlang/elixir you use the same kinds of abstractions to design your fine-grained logic and you coarse services. This makes for a very unique approach to scaling.
I'll have to check that out. Thanks for the reference
Elixir (probably due to the Erlang roots) seems to actively make it hard for you to hold onto state. This ends up (in my experience) being a good thing... or at least a brain-stretching thing that may lead to fewer bugs on larger projects.

Clojure allows some OO if you'd like. I see that as a drawback, personally, but I've drank the functional koolaid.

> My main question coming out of it: if you are going to go with a dynamic language, why go with Elixir over Python or Ruby (or Clojure or Racket or ...)?

If your problem is one for which a fault tolerant, highly-scalable system with actor-model concurrency is an appropriate solution, Elixir (or Erlang) makes a good choice, and Ruby/Python/Clojure aren't particularly great choices for that. That they all happen to lack static type checking is not what is motivating the choice.

Also, Erlang/Elixir have fairly robust (for languages that are "natively" dynamic) type-checking available through dialyzer, which can be strength compared to other dynamic languages.

IMHO the main reasons compared to, say Ruby, would be: native support for concurrency, Erlang VM, fault tolerance and speed. However, I'm also disappointed that there's no type checking. EDIT: Although I don't agree with the comment below, I'm removing comment about Golang because it's unnecessary in the discussion about Elixir.
I'm not calling you out, but in general when I hear people compare Go to languages with more "intense" typing (including Erlang, though possibly not Elixir) I find it funny. Go has a very crude type system and can be more easily compared to C (in terms of types) than anything else I think.

If you ever try to do anything as interesting with types as you could in a dynamic language, you'd immediately start transporting interface{}s (essentially void*) all over the place and lose all static typing [0] (and context[1]).

[0] - https://github.com/eatonphil/gimpy/blob/master/net/http/http...

[1] - https://github.com/eatonphil/gimpy

> IMHO the main reasons compared to, say Ruby, would be: native support for concurrency, Erlang VM, fault tolerance and speed. However, I'm also disappointed that there's no type checking.

You should check out Dialyzer.

The thing that always kills me with Dialyzer is that it's just not an ML.
I've coded in Python and Go (which has compile time type safety and does inference to avoid verbosity) code professionally, and am loving Elixir. I build distributed systems and I while I love Python, I don't think it is the right language for that. Frankly, I prefer nodeJS's single thread to Python's GIL because you are under no illusions wrt concurrency. Go is better but I don't understand why channel communication across machines doesn't exist (I think it was there as an experimental feature early on but maybe I am mistaken). I'm very impressed by the capabilities of the Beam VM and hope that Elixir will let me build better distributed systems (despite the lack of type safety).

I'm trying to convince people at work to use Elixir but people seem to have language fatigue. The lack of a major company/product using Elixir is making me worried as well. But hey .. someone had to be first, right? :)

> The lack of a major company/product using Elixir is making me worried as well.

Anyone here who hasn't yet been burned by social proof, please raise their hands.

> The lack of a major company/product using Elixir is making me worried as well.

There are plenty of people using Erlang. That's good enough, IMO.

If there were ever a show-stopping problem with the Elixir compiler that couldn't (or wouldn't) be fixed, you could just write whatever functionality you needed in Erlang (Which decades of prior art exist for).

If you want an approach to functional programming that is "concurrent, pragmatic, fun."

https://pragprog.com/book/elixir/programming-elixir

This is a very nice book that introduces functional programming in a way that's very accessible to people coming from Python or Ruby. Elixir is probably more accessible than, say, Haskell or Scala for someone coming from one of those languages.

Have not coded Elixir in anger, but from the look of it the immutability and composability and other benefits of debugging functional programs could be a big win over writing the same program in Ruby or Python.

I haven't done much with it yet but I was under the impression that speed and performance were a big advantage.