
An Open Letter to the Erlang Beginner (2011) - signa11
http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlooker.html
======
gooseyard
I've been working in Erlang full time for the last 6 months or so. My
background is in I guess what you'd call systems programming in C and C++. I
haven't found the Erlang syntax to be a problem at all, but I've had major
problems with a few things-

* The ambiguity of the term "application". It has a very specific meaning in the Erlang context but it used very generically elsewhere- it can be very confusing even just reading the docs.

* My background is in GNU Make/autoconf etc. and after a lifetime of building a binary, putting a binary onto a Unix machine, and then running the binary, figuring out how this works in the Erlang context was enormously confusing, and although the docs are very useful once you understand the build and deploy process, I think that some diagrams like those in this post would go a long way toward making it clear to a newbie what the division of labor between the local erlang install, systools, reltool (and possibly rebar since it seems to be nearly ubiquitous), and then once the release is built, what the boot script does, etc. Even little details like, why do I have a file called whatever_sup.erl and another called whatever_app.erl, and why are there a bunch of different functions named stop or start or init? I don't mean to slag on Erlang, as I like it a lot, but I found this part of the learning experience to be painful.

* Everybody talks about the hot code loading as if it just happens automatically, but as evidenced by the existence of Relx, it's not always trivial to work with, and if you don't know what you're doing you can mess things up for yourself pretty easily.

I am not a huge fan of jumping on third-party bandwagons for tools like rebar
or relx- I like to try to stay as close to the OEM tools (for lack of a better
term) as much as I can, so it'd be nice to see some of these tools become a
part of the canonical OTP distro.

BTW the "Learn You Some Erlang..." book, has maybe the clearest and most
gentle introduction to the building/releasing stuff that I've seen, but I
think it could benefit from some more detailed diagrams.

~~~
signa11
have you looked at 'erlang and otp in action' book ? might be useful...

~~~
gooseyard
yep that's a good one, it definitely has the most detail of al l the books
I've seen so far wrt release/deploy. Also several people have recommended
Francesco Cesarini's book as well, and I've seen a few posts about another guy
who is writing one specifically on the VM itself, I think that'll be helpful
also.

I would like to have one of these books that is more prescriptive than
descriptive when it comes to the practices, although I think I could squeeze
everything I'm looking for into a chapter-sized doc, might take a stab at it
myself!

------
untothebreach
Note that the author of this article also wrote "Learn You Some Erlang for
Great Good!"[1], which is a wonderful resource for someone who wants to learn
Erlang.

1:
[http://learnyousomeerlang.com/content](http://learnyousomeerlang.com/content)

------
616c
And now, you can even have Erlang without the syntax, a la Elixir.

But as a novice, I do not understand people whining and whinging about syntax
in language X or Y. Every language makes choices, and lots of those choices
are emphasized by focusing/adapting the syntax to doing those things well. In
each language that will be different, and that is the beauty of the diversity.

I cannot image Python without Python ranges, yields, and looping constructs. I
cannot imagine Ruby without do blocks and the class structure and sigils and
how really Rubinesque (this is a joke) code is for DSLs.

I like what the author of the OP did hear: if you complain the language syntax
is ugly, perhaps you do not really see the perspective of the language creator
quite yet. This explains how I struggled with different languages I studied in
school (C++, then Perl, then Python) and even ones I work with which I hate
(VBScript, Windows batch), because even those have logic to them when you keep
the goals in the forefront of your mind.

~~~
jerf
I've never proved this formally, but one of the big problems with the Erlang
syntax is that it has comma, semicolon, and period as distinct separators,
despite the fact that as far as I can tell, they are _never_ ambiguous in the
grammar. I've never been able to construct a series of tokens in which the
meaning changes based on which of those you use, and it's legal either way. If
you can, please, by all means show me (no sarcasm, I really would be intrigued
to see it), but I bet it won't be commonly found in the wild either.

Beyond that, most of my annoyances are not technically syntax, but I gotta
tell you that the above really is a big problem for newbies, and the annoyance
never goes away even after you know what you're doing since it always inhibits
moving code around.

But as Elixir shows, the annoyances really are mostly with Erlang-the-
_language_ , not the implementation. Personally I sort of hope the success of
Elixir helps the Erlang team take a fresh look at the Erlang language... there
are some fixups one could do to Erlang to make it less annoying, too, and I
think it could be all done compatibly. (A syntax to import functions from a
module... a "match & rebind" operator... unifying the , . ; operators...
something to clean up record manipulation... honestly, it wouldn't take much
to really polish up Erlang and make a lot of the recurring klunkiness go away,
that list alone would have cleaned up huge swathes of my code. A real string
type would help too, even if were _exactly the same_ as a binary but with a
different type for matching purposes for all I care, because that would clean
up a lot of interop issues I had.)

~~~
matthiasl

        > I've never been able to construct a series of tokens in
        > which the meaning changes based on which of those you
        > use, and it's legal either way.
    

Here's a series of tokens where switching comma to full stop means different
things and both are legal:

    
    
        1> 1,0.
        0
        2> 1.0.
        1.0
    

In the first line, the comma is an expression separator. Attempting to use a
full stop instead results in a floating point number.

    
    
        f(X, Y) when X, Y -> ok.
        g(X, Y) when X; Y -> ok.
    

In this case, the guard in f is turned into a guard sequence by switching a
comma to a semicolon. Both are legal.

Matt

~~~
jerf
Neither of those are valid examples of what I meant. In the first, the . is
not the function terminator, it's the floating point separator. Same ASCII
character, different semantic token. In the second, the comma is not the
statement separator, it's the value separator. Again, same ASCII character,
different semantic token.

The question is, can you produce a situation in which ; . , are interchangable
and valid in their capacity as statement separators.

My compliments for trying though, as I'm aware this smells like goalpost
hiking and I do want to be complimentary about what you did. If you read my
post again, though, I think it will become clear that this is what I meant all
along, but I agree this superficially looks like I'm trying to cheat.

------
solotraveller
We recently decided to shift some of our nodejs production code to erlang. One
of our main fears to shifting was the lack of really good online resources for
beginners ("Learn You Some Erlang for Great Good!" is really good but does'nt
cover topics like rebar etc).Also the learning curve is really steep compared
to say a language like ruby or java

~~~
davidw
Cool - how is it working out so far?

------
d4mi3n
I've recently started reading up on Erlang. While I can't comment too much on
the syntax or semantics, I'm very much impressed with Erlang's error handling
and the fact that it comes with some pretty good tooling out of the box (VM
level tracing, process inspection, etc).

------
rdtsc
> Jlouis had great arguments on the syntax with regards to his post: you have
> to differentiate semantics from syntax itself. Erlang's semantics are what
> should be seen as important, but it's rarely done.

Erlang syntax is small and self-consistent. Yes, it is not familiar. But those
are orthogonal. There are languages with curly braces and ; that are terribly
complicated, with ambiguous complicated syntax (C++), or ambiguous weak types
(JS).

My way to look at it, if syntax is the biggest stumbling block, that is a
warning sign that it will probably be hard to handle more difficult things --
thinking in terms of actors, reasoning about distributed systems, figuring out
supervision hierarchies and so on.

BUT, as some mentioned here, there is Elixir. You get something like Ruby
syntax. And you get variable-reassignment (x=1 then x=2 works). So maybe that
helps there too. One still need to learn the semantics of it. You still have
applications, supervisors and actors.

------
z3phyr
Hot code reloading is the most sought after feature for me :) Many other
technologies are borrowing this idea, namely the unreal engine 4, which comes
with a hot code reloading C++.

