6 ms·

Elixir vs. Erlang, is Elixir safe bet for my time investment?

91 points by ssijak 10y ago

tim333 10y ago
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
eggy 10y ago
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=prtst0416p http://www.springer.com/us/book/9781461444626?token=prtst041...
- ssijak 10y ago
  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 10y ago
    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.
lostcolony 10y ago
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.
anonyfox 10y ago
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 10y ago
  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 10y ago
    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.
dudul 10y ago
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 10y ago
  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?
  - SEMW 10y ago
    I'm not the person you replied to, but I feel the same way as they do. A fair proportion of libraries I've been using are Erlang libraries. That's not a problem -- one of the best things about Elixir is that you have that mature ecosystem to lean on. But inevitably with libraries, if you push them hard you get to a stage where you need to read the code to understand what they're doing, fix a bug, maybe add a feature or two. (Or at a minimum, understand their docs & examples, which'll be in erlang) Eg I use sockjs-erlang from elixir, and found myself forking it (https://github.com/SimonWoolf/sockjs-erlang/commits/master https://github.com/SimonWoolf/sockjs-erlang/commits/master) to fix a couple bugs and keep it up to date, since it's now more or less unmaintained by sockjs.
  - dudul 10y ago
    Elixir maintainers very often do not reinvent the wheel. When there is a good library in Erlang they do not re-write it in Elixir. Therefore, an Elixir developer should be able to read Erlang documentation and code. You won't miss anything in Elixir that you can do in Erlang, simply because you can call Erlang code from Elixir, including all the libraries.
  - loxs 10y ago
    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.
danso 10y ago
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
- xutopia 10y ago
  I've been a Rails developer for 10 years. I'm looking at Elixir and Phoenix today and I'm sad that I started my last project in Rails. My test suite takes upwards of 10 minutes to run and everything I hear about Elixir is that tests run 10 times faster.
  - smt88 10y ago
    > My test suite takes upwards of 10 minutes That is absolutely mind-blowing. Can you explain a little more about what is causing that? Are there lots of HTTP calls or something? What machine is this running on? (I'm not a Ruby dev, but I have heard Ruby is slow.)
  - segmondy 10y ago
    It's true that ruby is slow, but your algorithms and code organization matters more than the language. Quick sort in BASIC will still beat bubble sort in C for a sufficiently large data. Are you doing DB tests? consider using a clean in memory DB. Are you calling 3rd party API's? Black box it, mock, stub, dummy em. 10 minutes is really a lot, unless you happen to have thousands up thousands of tests and running on a raspbery pi. Put your tests through a profile to find out why it's taking too long.
- tomku 10y ago
  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.
lukasm 10y ago
Isn't it the better UTF-8 support what is in favour of Elixir?
pmarreck 10y ago
Yes.
kinofcain 10y ago
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)
pmarreck 10y ago
Go Elixir. You'll be able to do more, and you'll end up learning Erlang anyway. ;)

91 points by ssijak 10y ago

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

eggy 10y ago

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=prtst0416p http://www.springer.com/us/book/9781461444626?token=prtst041...

ssijak 10y ago
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 10y ago
  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.

lostcolony 10y ago

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.

anonyfox 10y ago

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 10y ago
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 10y ago
  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.

dudul 10y ago

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 10y ago
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?
- SEMW 10y ago
  I'm not the person you replied to, but I feel the same way as they do. A fair proportion of libraries I've been using are Erlang libraries. That's not a problem -- one of the best things about Elixir is that you have that mature ecosystem to lean on. But inevitably with libraries, if you push them hard you get to a stage where you need to read the code to understand what they're doing, fix a bug, maybe add a feature or two. (Or at a minimum, understand their docs & examples, which'll be in erlang) Eg I use sockjs-erlang from elixir, and found myself forking it (https://github.com/SimonWoolf/sockjs-erlang/commits/master https://github.com/SimonWoolf/sockjs-erlang/commits/master) to fix a couple bugs and keep it up to date, since it's now more or less unmaintained by sockjs.
- dudul 10y ago
  Elixir maintainers very often do not reinvent the wheel. When there is a good library in Erlang they do not re-write it in Elixir. Therefore, an Elixir developer should be able to read Erlang documentation and code. You won't miss anything in Elixir that you can do in Erlang, simply because you can call Erlang code from Elixir, including all the libraries.
- loxs 10y ago
  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.

danso 10y ago

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

xutopia 10y ago
I've been a Rails developer for 10 years. I'm looking at Elixir and Phoenix today and I'm sad that I started my last project in Rails. My test suite takes upwards of 10 minutes to run and everything I hear about Elixir is that tests run 10 times faster.
- smt88 10y ago
  > My test suite takes upwards of 10 minutes That is absolutely mind-blowing. Can you explain a little more about what is causing that? Are there lots of HTTP calls or something? What machine is this running on? (I'm not a Ruby dev, but I have heard Ruby is slow.)
- segmondy 10y ago
  It's true that ruby is slow, but your algorithms and code organization matters more than the language. Quick sort in BASIC will still beat bubble sort in C for a sufficiently large data. Are you doing DB tests? consider using a clean in memory DB. Are you calling 3rd party API's? Black box it, mock, stub, dummy em. 10 minutes is really a lot, unless you happen to have thousands up thousands of tests and running on a raspbery pi. Put your tests through a profile to find out why it's taking too long.
tomku 10y ago
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.

lukasm 10y ago

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

pmarreck 10y ago

Yes.

kinofcain 10y ago

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)

pmarreck 10y ago

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