Hacker News Reader

Comment by areski | Hacker News Reader

Great article!

For a language that has been there for 29years, it's very hard to get such momentum.

Thanks!

I actually wrote about Erlang's "strange birth" - for an open source language, at least - here: http://journal.dedasys.com/2009/06/18/the-erlang-paradox/ and what it has meant for the language. Basically, that it was born into a production environment and therefore very difficult to change much once it was released into the wild.

Well, Erlang has kind of a cumbersome syntax, and it is hard to learn for someone who has never seen a functional programming language.

IMO Elixir does a great job at reducing the inherent complexity of the Erlang syntax, while keeping its powerful features (Erlang-procs, horizontal scalability, fault-tolerance).

As someone fairly entrenched in the Elixir community, I think the syntax is the wrong selling point. Macros and protocols add far more to the language. The Enumerable protocol (along with Enum and Stream modules) is reason enough to my mind to use Elixir over Erlang.

Good point. Jose made the exact same point during Erlang Factory keynote.

Here's a video of José's keynote: https://www.youtube.com/watch?v=V5fMQcSy3y8

I think syntax matters more than some would like to imagine. I tried ruby, erlang and elixir. I went with python over ruby, lisp over erlang and I am playing with lfe (lisp flavoured erlang) over elixir. Function is important, but if you get most of it, why not choose the best syntax as a second factor in deciding? Besides, all the 'end's in elixir play out in my head of somebody ending all sentences with 'like'.

The great thing about the Erlang/Elixir/LFE/etc. ecosystem right now is that, since all these languages leverage BEAM, they're all (theoretically at least) compatible with one another. Right now the tooling isn't quite there yet (trying to manage non-Erlang dependencies with Rebar or non-Elixir dependencies with Hex isn't quite as intuitive as I'd personally like), but eventually, I'd expect it to be possible to mix-and-match BEAM-based languages freely, using the right tool for the right job without having to fiddle with microframeworks or FFIs or other such things?

This is already possible with other VM-centric ecosystems (particularly the ones surrounding the JVM and the .NET CLR), but it feels like the BEAM ecosystem is making that sort of interoperability more of an explicit goal.

> Well, Erlang has kind of a cumbersome syntax, and it is hard to learn for someone who has never seen a functional programming language.

Ok, the syntax is weird (and sometimes infuriatingly so), but I didn't find it that hard to learn, and I had never seen a functional language (I came from mostly PHP, with some perl, and a small amount of C and/or C with a C++ compiler, and a little bit of Javascript). Single assignment is new and different, but really the only thing that really causes problems with is something like a for loop; and you learn the two or three ways to do a for loop differently pretty quickly. C, Perl, PHP and Java all have function pointers too, you just don't use them as often.

The important thing is starting to learn Erlang on a project that has a lot of concurrency, so you're making that part of the project easier in exchange for having to learn to think a little differently.

I think people who are professional programmers should be able to easily get over one syntax or the other in order to gain access to something powerful, but the reality is that it does seem to matter. I suppose it's better to deal with that reality rather than gnash one's teeth about it.

I think that's because programmers are humans, not machines :)

But I still don't understand why Elixir didn't drop ends.

I think they should keep the "end"s, but they should say what they end! "end function" tells me that a function ends here. "end if" tells me that an if statement ends here. "end" is just equivalent to "}".

Some Ruby (and Elixir and Julia and other languages that use `end`) will just add a comment at the end of the `end` if they want to be more explicit about it. For example:

    def foo(bar,baz) do
      ...
    end # foo

This brings me to why a bare `end` makes more sense (in the case of Elixir, at least): because every use of `end` corresponds to a `do`. The above code is basically equivalent to `def foo(bar,baz) { ... }`, since `def` takes a function specifier and a block as its arguments.

If you really don't like `end`, you can also (at least with Elixir) use the shorthand form:

    def foo(bar,baz), do: ...

> "end" is just equivalent to "}".

And an unnecessarily verbose one.

Because it was heavily influenced by Ruby (no matter how much us Elixirists want to convince ourselves otherwise).

Alternately: what's wrong with `end`?

I tasted the syntactically significant whitespace rainbow and now all languages without it feel unnecessarily verbose :\

Reply on news.ycombinator.com