Elixir vs. Erlang, is Elixir safe bet for my time investment? | Hacker News Reader

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

stackoverflow.com

91 pointsssijak34 comments

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)

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/ [2] https://github.com/lfex/sdl2-examples [3] http://www.springer.com/us/book/9781461444626?token=prtst041...

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?

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.

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.

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

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.

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

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.

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.

Thanks for the detailed writeup! I do Ruby and Python for all my backend/data work...but I would love to switch out for a more elegant glue language. That Phoenix seems to have the potential to be the next Rails is a nice carrot, but I'm hoping that just means that Elixir attracts more of the kind of community that I've loved in Ruby.

I don't have nearly the same breadth of exposure to functional languages that you do...I worry (prematurely, of course) that I don't have enough insight to understand what parts of the language are "weird" because I'm new, or legitimately weird, e.g. print-as-a-statement in Python 2 or `==` in Javascript.

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

Also erlport looks interesting: http://erlport.org/docs/python.html

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!

I've read about these issues before, and have run into 2 and 3. I wonder if there are other common complaints.

Niche languages overwhelming only have people saying good things about them, because very few people care about any complaints.

Well used languages have large numbers of people complaining about them, because a) change is harder b) more people care about the result, so you get heard more c) they are more likely to be forced by circumstance to use the language.

Reviews of languages are generally a rubbish metric for deciding if it's any good.

So what metric do you think is more optimal for deciding how to sort languages from "must try" to "meh", other than actually using the language in production? (Obviously, in an ideal world with infinite time, that would definitely be my choice)

While I agree that the nature and value of reviews is highly determined by things not inherent to the quality of the language (which is to be expected for anything that deals with the real-world), I do think reviews of nascent languages have significantly higher signal to noise ratio than they do for languages that are at their peak or heading towards legacy land:

1. New languages are rarely used by novice programmers. Which means that they are rarely written about by novice programmers. Doing a search for "state of Ruby/Node" requires a lot of work to find reviews authored by experienced developers who have a clear mindset (i.e not just personifying a shallow version of Bjarne Stroustrup's famous axiom), while filtering out everyone who just got out of coding bootcamp and has a good Medium presence.

2. The fact that a language is new means that nearly everyone, except for the creator and early dogfooders, is new to it, which means they come to it with roughly the same perspective (and needs and wants) as anyone who is curious to jump in. Moreover, they are often wont to compare the new language with whatever language they've been using, which helps as a metric for gauging the experience level and judgment of the reviewer.

Sure, there's the problem of early adopters not wanting to shit on a language before it is stable...on the other hand, the kind of people who like to try out languages before they hit saturation are generally opinionated and will make critiques as way to help influence the language, so it's not a total whitewash.

Speaking for myself, reviews are not my first metric for judging a new language or framework. Understanding why it was created and how it is currently doing in production is by far the most important thing to me. Even though React felt very strange to me and many others at first, I still gave it the benefit of the doubt knowing that it was being used in Instagram and Facebook.

"The fact that a language is new means that nearly everyone, except for the creator and early dogfooders, is new to it, which means they come to it with roughly the same perspective (and needs and wants) as anyone who is curious to jump in."

This is why I don't trust new languages. Everyone starts off as newbies who do not know what they are doing and will struggle to develop best practices. These programmers are just going to make new mistakes...that they won't realize until after the language reaches legacy status and are forced to clean up their mess.

New languages typically still use the same mental models of existing languages.

Elixir for example uses Erlang data-structures, and semantics for code execution, and functional calls/naming/parameters.

Elixir is an impure dynamic functional language where IO operates on its own green-threadlike process. This is from Erlang as well, but the concept of dynamic languages, and functional languages is not a new one. Neither is the concept of hygienic macros. Elixir is simply a very good implementation of such.

Personally? I wouldn't describe myself as an language early adopter.

I'd want to see significant commercial support, a genuine need, library support, some code samples among other things at least.

I think most languages don't have a genuine need - i.e. why would I use them instead of another language. This has to be compelling enough to get over the learning curve.

About Elixir, I don't have very many complaints due to the fact that it is built over Erlang which means for day-to-day operations its solid.

At the edge, performance relies heavily on implementation, and the ErlangVM is great at dealing with high concurrency, and methods that do small pieces of work. If your implementation works against that, then the VM is going to work against you as well because it was designed with those assumptions in mind.

Elixir however is a very new language. Coming from Python, the first things I noticed was:

1. There's no real consensus on if we should use exceptions or error return types. Support for return types is improving with the new with syntax, so perhaps that's what most people will use. The standard library uses both, and occasionally will just return nil on error.

2. The standard library is still evolving. For example Date/Time/Calendaring was all out of the STL until 1.3, and support is still currently anaemic comparative to Python.

3. Most OTP in the Erlang ecosystem are built in Erlang. Those built in Elixir are derived from some specific use case of some specific company. Language support for OTP constructs is improving though, and more generic forms are being built into the STL for Elixir 1.4, upcoming.

With regards to Phoenix, its a well thought out, throughly implemented library.... but its not Django; and makes different philosophical choices.

Short list:

1. no user system

2. no authentication or permissions

3. templates do not follow the engine/loader structure of Django

4. Plug is like Rack, not like Django middleware so whilst it is more powerful in some respects, it is unidirectional in control flow unlike Django where data flows up/down the chain of middleware.

5. Ecto is a pretty solid database layer, but its not integrated into Phoenix at all because #1/#2 do not exist, and Phoenix doesn't have a admin layer at all... so there's no real reason for the framework itself to tie itself to a single database layer. So you get into a situation that's akin to using SQLAlchemy with Django. Yes it works, no this library wasn't built for your framework.

I started watching RailsConf 2016 - Rails to Phoenix by Brian Cardarella 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

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.

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?

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) to fix a couple bugs and keep it up to date, since it's now more or less unmaintained by sockjs.

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.

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.

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

http://elixir-lang.org/getting-started/binaries-strings-and-...

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

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

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.

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/

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.

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

Yes.

Reply on news.ycombinator.com