35 ms·

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

by areski 11y ago

davidw 11y ago
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/ 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.
maze-le 11y ago
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).
- davidw 11y ago
  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.
  - pbowyer 11y ago
    I think that's because programmers are humans, not machines :)
- k__ 11y ago
  But I still don't understand why Elixir didn't drop ends.
  - tormeh 11y ago
    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 "}".
    - k__ 11y ago
      > "end" is just equivalent to "}". And an unnecessarily verbose one.
    - yellowapple 11y ago
      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: ...
  - yellowapple 11y ago
    Because it was heavily influenced by Ruby (no matter how much us Elixirists want to convince ourselves otherwise). Alternately: what's wrong with `end`?
    - k__ 11y ago
      I tasted the syntactically significant whitespace rainbow and now all languages without it feel unnecessarily verbose :\
- phamilton 11y ago
  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.
  - rdtsc 11y ago
    Good point. Jose made the exact same point during Erlang Factory keynote.
    - alxndr 11y ago
      Here's a video of José's keynote: https://www.youtube.com/watch?v=V5fMQcSy3y8 https://www.youtube.com/watch?v=V5fMQcSy3y8
- eggy 11y ago
  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'.
  - yellowapple 11y ago
    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.
- toast0 11y ago
  > 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.

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

by areski 11y ago

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

maze-le 11y ago

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

davidw 11y ago
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.
- pbowyer 11y ago
  I think that's because programmers are humans, not machines :)
k__ 11y ago
But I still don't understand why Elixir didn't drop ends.
- tormeh 11y ago
  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 "}".
  - k__ 11y ago
    > "end" is just equivalent to "}". And an unnecessarily verbose one.
  - yellowapple 11y ago
    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: ...
- yellowapple 11y ago
  Because it was heavily influenced by Ruby (no matter how much us Elixirists want to convince ourselves otherwise). Alternately: what's wrong with `end`?
  - k__ 11y ago
    I tasted the syntactically significant whitespace rainbow and now all languages without it feel unnecessarily verbose :\
phamilton 11y ago
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.
- rdtsc 11y ago
  Good point. Jose made the exact same point during Erlang Factory keynote.
  - alxndr 11y ago
    Here's a video of José's keynote: https://www.youtube.com/watch?v=V5fMQcSy3y8 https://www.youtube.com/watch?v=V5fMQcSy3y8
eggy 11y ago
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'.
- yellowapple 11y ago
  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.
toast0 11y ago
> 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.