
Elixir vs. Erlang, is Elixir safe bet for my time investment? - ssijak
http://stackoverflow.com/q/37964709/257501
======
eggy
I tried Erlang years back, but since sampling Elixir, it is going a lot faster
for me. I am not a web dev or Rubyist; it's just working out that way for me.

I like Lisp, and came upon LFE, and so I am doing a small task in both LFE [1]
and Elixir to see which I prefer. My work is not making huge web sites or the
like, so I can afford the luxury of choosing one for fun. I was going to use
LFE in a Lisp game jam, and after posting the idea to the LFE Google Groups,
an example was made and provided for me ant others using SDL by one of the LFE
contributors [2].

I am also working my way through The Handbook of Neuroevolution Through Erlang
[3], using LFE. Slowly but surely, but it is a good way to pick up a language,
and concepts in the OTP.

[1] [http://lfe.io/](http://lfe.io/) [2]
[https://github.com/lfex/sdl2-examples](https://github.com/lfex/sdl2-examples)
[3]
[http://www.springer.com/us/book/9781461444626?token=prtst041...](http://www.springer.com/us/book/9781461444626?token=prtst0416p)

~~~
ssijak
I stumbled on this book earlier. How would you rate it, it is pricey.. Does it
provide solid explanation of the concepts with the code to go with it?

~~~
eggy
I bought this book because I wanted to learn Erlang in the context of a
subject I am interested in - ANNs. I have been reading books about ANNs and
playing with them since the late 80s. Most high-level books on them are filled
with math, few diagrams, and assume some knowledge to start.

This book covers a special type of ANN, a TWEANN (Topology and Weight Evolving
Artificial Neural Network), and more importantly, how Erlang's distributed
computation model ties in really well with modelling this and other ANNs. You
may find the expository writing on the basics to be a rehash, but if you are
interested in this particular type of ANN, and Erlang, the book has many
applications.

The code is inline with the explanations in the book. I bought the book,
because for this type of learning I like to have it open in front of me and my
computer. I have seen bootleg PDFs here and there online, but I think the book
is well worth it.

The author is very enthusiastic about his work. Somebody has started or
completed the code in Elixir, and there is a start on the book in LFE too.
Sorry but I don't have time to find links just now.

------
kinofcain
Either you learn Erlang, or you learn Erlang _and_ Elixir.

This seems to be the case for languages running on a VM originally developed
for another language:

Writing in Scala, Kotlin, or Clojure? You'll still need to know Java.
Coffeescript or Dart? You'll still need to know Javascript.*

Usually this comes up during debugging or interfacing with existing libraries.

For some of these, they're really just a pretty syntax on top of the same
semantics as the 'host' language. Others can offer both a new syntax and some
improved semantics (to the extent of the capabilities of the underlying VM).

Whether the overhead of keeping the mental models for two languages in your
head is worth the gain I think depends on what you're familiar with and which
of these language pairs you're looking at.

For this pair in particular, I don't think you're getting around learning
Erlang. The syntax of Erlang is 'weird', but that ends up not being the hard
part of writing Erlang. The hard/wonderful part is the semantics, and Elixir
doesn't fundamentally change those.

Personally I don't think the benefits of most of these is worth the hassle of
keeping two languages in your head, but I do like the idea that people are
writing new languages and syntaxes trying to figure out how to make our lives
easier...

*(this also seems true to a lesser extent with Swift and Objective-C, but I think that has more to do with Cocoa and the library interface than the underlying runtime/debugging issues)

------
lostcolony
I think it depends on your goals and your background.

Already familiar with functional programming and the actor model? Elixir.
You'll pick up enough Erlang as you do to be fluent in both; except for macros
it's essentially just a syntax difference.

Not familiar with either functional programming or the actor model? Erlang.
Because the fact that almost none of the syntax is familiar I found helpful to
absorb the concepts, and the right way of doing things. I can't speak to
Elixir directly, as it wasn't around when I learned Erlang, but other
functional languages that offered me familiar constructs invited me to
misunderstand them and misuse them, and either write non-idiomatic code, or to
get frustrated when things behaved in ways I did not expect (and even Erlang
isn't perfect here, the 'if' construct behaves very differently than most
languages, and was a stumbling block for me initially).

In short, I found the unfamiliarity of the syntax helpful for grokking the
concepts. YMMV.

------
danso
I've been doing some reading about Elixir this morning...seems like the
reviews are overwhelmingly glowing. Though people argue that developers should
choose Rails (over Phoenix) because of its ecosystem...I haven't seen anyone
argue that they prefer Ruby to Elixir.

For folks who have switched over, what are the things you don't like about
Elixir?

edit: nm, plenty of discussion on this in the Elixir 1.3 thread:
[https://news.ycombinator.com/item?id=11945389](https://news.ycombinator.com/item?id=11945389)

~~~
tomku
So I switched from Python to Elixir for web backend stuff, but I also have
experience with other functional languages like Scala, Clojure, Haskell. I've
recently been learning Swift. I really like Elixir overall, these are the
parts that I find frustrating.

1) Erlang's (and by extension Elixir's) persistent data structures are great
but there are times when (for performance reasons) they're completely unusable
and you have to resort to things like using ETS or spawning a process for each
value you want to store. There are times when I would kill for something like
Clojure's transients.

2) The syntax has some weird edge cases, particularly around first-class
functions. For example, having to call closures as "closure.(arg1, arg2)"
rather than "closure(arg1, arg2)" or having to (seemingly) immediately invoke
a lambda to make it fit in a pipeline like "7 |> (&(&1 * 2).())". I know WHY
those two bits of ugliness exist but it doesn't really make me any happier
about them.

3) The BEAM VM is very much a world of its own, with limited and well-defined
entrance/exit points. It's very easy to do anything in Erlang/Elixir that
stays inside the VM or communicates via network socket. It's difficult to do
things that interact with the host OS or native processes, things that would
be trivial in Perl/Ruby/Python.

The reason why none of these are deal-breakers is that I understand that
they're the result of tradeoffs, not poor engineering. It would be easy to
design a new language that has none of the above problems but it wouldn't have
the massive benefits that the BEAM VM gives Erlang and Elixir.

~~~
andy_ppp
Agree with what you have said but check out porcelain + goon (which is written
in go) for handling external processes [1] - it's really great.

[1] [https://github.com/alco/porcelain](https://github.com/alco/porcelain)

Also erlport looks interesting:
[http://erlport.org/docs/python.html](http://erlport.org/docs/python.html)

~~~
tomku
Wow, I actually thought about writing a process monitor in Go for my current
Elixir project before deciding to just muddle through/learn how to use ports
instead. The inability to send signals from Elixir was and continues to be a
pain point. I'll be trying out porcelain/goon, thanks!

------
tim333
I started watching RailsConf 2016 - Rails to Phoenix by Brian Cardarella
[https://www.youtube.com/watch?v=OxhTQdcieQE](https://www.youtube.com/watch?v=OxhTQdcieQE)

as suggested in some comment yesterday and it has some stuff on whether
learning Elixir is worth the time. Good talk in general.

Edit link to comment thread:
[https://news.ycombinator.com/item?id=11945747](https://news.ycombinator.com/item?id=11945747)

------
dudul
I have been playing with Elixir for 6 months or so. As far as I can tell, if
you do anything serious other than Phoenix (web framework) you _will_ have to
understand Erlang. Not necessarily be able to write Erlang, but you will at
least need to know how to read the code and the doc.

So if the choice is between Erlang and Elixir, I would say go with Elixir, and
on the way, you will learn some Erlang anyway.

~~~
ssijak
Understand Erlang in what sense? You would still write Elixir code but would
need to understand Erlang code and syntax because there is larger amount of
docs and examples for Erlang ? Have you ever felt that you miss something
greatly in Elixir?

~~~
loxs
For example, at one point (presumably very soon) you'll need to understand the
difference between Erlang strings (char lists) and Erlang binaries which are
called "strings" in Elixir. There might be quite a lot of confusion if you
don't understand the context in which Elixir lives.

~~~
andy_ppp
It is in the 6th section of the Elixir Getting Started Guide:

[http://elixir-lang.org/getting-started/binaries-strings-
and-...](http://elixir-lang.org/getting-started/binaries-strings-and-char-
lists.html)

~~~
loxs
Yeah, I was just giving an example. Not saying that this in particular will be
a stumbling stone.

------
lukasm
Isn't it the better UTF-8 support what is in favour of Elixir?

------
anonyfox
If only the Erlang VM would be a little bit faster at string operations and
number crunching at runtime. Using Elixir is really really great, but if I
could do some heavier text analysis without resorting to NIFs it would be
great.

Maybe we need some NumPy equivalent or the like for the Erlang VM.

~~~
eggy
I wonder if this is where Pony lang will fit in? It is an OO actor-model new
language that is supposed to be real fast, and yet have all of the positives
of Erlang. I believe it is currently duplicating the OTP features as well if I
understand it correctly [1].

You don't send a 'poison pill' to kill off actors like in Erlang's more manual
management. It is automatic in Pony.

[1] [http://www.ponylang.org/](http://www.ponylang.org/)

~~~
anonyfox
I am fed up with OOP languages for now and Elixir itself as a language just
"clicks" for me, like Ruby did years ago. I worked with dozens of languages in
the past, and only very few of them made me outright happy while
reading/writing:

Ruby (earlier versions), Elixir and more increasingly: Rust. Others have
advantages, too, but finally I value my own happiness higher than individual
features. It's an emotional thing.

This aside, Elixir already maps to the way I think about problems, with
pattern matching, piping and OTP it is a breeze to translate (or:
"streamline") complicated business requirements into "sequential" code that is
very easy to read, write, test and maintain.

For me, any task that software should accomplish is basically a initial state,
a target state and I just have to fill the gaps with the needed
transformations in between, mostly sequential but also some in parallel. So:

result = state |> func |> func |> func |> func.

and every "func" is defined for special cases individually through pattern
matching on its arguments. It incredibly clean and easy to understand how
stuff works even for curious non-tech stakeholders.

With the old OOP systems you can "model things" in different ways and then
define interactions between. This works also, but is _way_ more complicated in
the long run IMO.

As I said, Elixir is quite a perfect language for me. Its just that the
occasional raw computation tasks are slow. Something like NumPy/SciPy to call
into would be a major improvement here.

Not only this, but actually Elixir (and Erlang) is a incredibly cool language
to learn AI concepts because of the way how OTP works, especially when
grasping ANN. For general ML techniques the language itself is very great, but
... slow.

------
pmarreck
Go Elixir. You'll be able to do more, and you'll end up learning Erlang
anyway. ;)

------
pmarreck
Yes.

