Comment by mnd | Hacker News Reader

Comment by mnd | Hacker News Reader

Parent Full thread

Erlang is a great programming language after one takes the time to understand the principles underlying it and its design. Everything fits very nicely into place. There are definitely things that could be done better, but then that’s the case with most programming languages and technologies after they have accumulated some dust. Elixir on the other hand, in my personal opinion, is a false prophet simply because it looks like something which it isn’t. It looks like Ruby and gives the programmer the feeling that he’s right at home, except it is in fact a very different beast with very different semantics, Erlang semantics, as opposed to Ruby. Therefore, if you want to program on the BEAM (the Erlang virtual machine) you better make sure you actually understand the system, its design, principles and also some of the semantics of Erlang itself, point at which you might as well just learn Erlang. I’m not saying that you cannot learn those things coming from Elixir, I’m just saying that if you want to build systems of reasonable complexity (like the ones that Erlang is known for) on top of the Erlang virtual machine, as opposed to CRUD web applications, then you must understand a lot more than just Elixir or Phoenix.

This is a big part of the reason why I appreciate having learned at least the basics of Erlang before moving on to Elixir, having come from Ruby. It helped establish an appreciation in my brain for declarative programming - something which is possible to do in Ruby, but nowhere close to the extent possible in Erlang or Elixir (or any other language with a similar approach to "pattern matching" as a first-class programming paradigm).

Of course, I tend to feel much more productive in Elixir than Erlang, and thus use Elixir way more often than Erlang directly, but I'm able to come at Elixir with a more Erlangy perspective and approach.

Elixir is prettier than Erlang but it really mess up on certain things.

Erlang have pattern matching via function with same name and you can tell if it's a group of pattern matching with semicolon and period. But with Elixir you can't tell it's just def and end.

Erlang's:

-module(recursive).

-export([fac/1]).

fac(N) when N == 0 -> 1;

fac(N) when N > 0 -> N * fac(N-1).

You can tell fac(N) both are in a group of pattern matching cause ';' and '.'. The '.' denote the last pattern matching function.

Elixir:

defmodule Factorial do

    def of(0), do: 1

    def of(n), do: n * of(n-1)

end

You can't tell because there is no ';' and '.'. This is a trivial case but when your Elixir's module have a tons of function in it, this issue become relevant.

How does that matter? Anyone who uses this defines them in groups one after another. You aren't looking at the punctuation at the end of the line, you're looking at the following line to see if it's the same function name.

It matter because you're assuming they will group it. IIRC Erlang forces you to group it.

It's an incredibly safe assumption to make, though. This isn't enough of a problem in practice to amount to a negative for elixir or a pro for erlang.

I think you make the Erlang definition look unnecessarily awful.

fac(0) -> 1;

fac(N) -> N * fac(N-1).

Or is there a particular advantage to write it using guards?

having a semantically significant distinction between ; and . is unnecessarily awful. That kind of crap is one of the reasons Elixir has so much support.

What you said is equivalent to a Python programmer saying that adding semantical value to the “end” keyword in Ruby is unnecessarily awful because you can achieve the same by giving meaning to the indentation level. It’s an entirely subjective matter.

I would also like to point out that Erlang has also very good support and has seen adoption in some very critical systems as opposed to CRUD web applications which is the main domain of Elixir. Most of Ericsson’s products use Erlang to a certain degree, there are a lot of banking systems and aviation systems which make use of Erlang as well, quite a few Internet companies use it to great success, and many more.

And by the way, the semantic meaning of “;” and “.” is an awful lot similar to their use in the English language, you are blowing it out of proportions. This is a trivial thing which you learn after a 10 minutes introduction to Erlang. For me, personally, if one has a problem understanding the meaning of “;” and “.” or learning a new syntax for that matter, I can easily conclude that I probably should not give that person any decision power in designing systems.

It's an example from http://learnyousomeerlang.com

I honestly don't understand how this messes anything up... the elixir syntax produces something semantically equivalent with a lot less garbage. Opinions may differ I guess, but I find your Elixir example much easier to read than your Erlang example (I program in Elixir, so that's not much of a datapoint).

Most of the garbage is because those aren't the closest equivalents.

This is the closest Erlang equivalent:

   fac(0) -> 1;
   fac(N) -> N * fac(N-1).

It's not only that. I think the bigger issue is that because of it's Ruby-like syntax it encourages newcomers to think in Ruby rather than in Erlang. Rather than emphasising what's the core of Erlang it attracts people with it's syntax, which is the least important aspect of a language.

I strongly agree. I've found it tremendously convenient to have an "alien" syntax (Erlang) to help me think Erlang-y.

(Now, of course, when I see more "traditional" C/Ruby/Perl/Python/Rust syntax, I can't help but roll my eyes, but that's a slightly different subject.)

Reply on news.ycombinator.com