An Open Letter to the Erlang Beginner (2011)

http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlooker.html

by signa11 • 12 years ago

46 20 12 years ago

z3phyr• 12 years ago

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

d4mi3n• 12 years ago

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

untothebreach2• 12 years ago

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

616c• 12 years ago

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.

untothebreach2• 12 years ago

I like Elixir more for the consistent APIs, better Strings, and metaprogramming. I don't mind Erlang, but the more I used it, the more I felt the pain of those other issues.

rdtsc2• 12 years ago

That's great. Use whatever works for you, make you more productive and happy. It is good to have a choice. I feel JVM has been getting newcomers from Clojure and Scala communities. Erlang is doing that too.

jerf3• 12 years ago

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

kungfooguru• 12 years ago

Luckily, for me, most of us who use Erlang do not want the changes you mention in your list :). Except records, which are a pain to nest.

Unifying , . ; is the most baffling one to me that I hear all the time.

But I'm glad Elixir exists and it is getting more people using BEAM.

matthiasl• 12 years ago

    > 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:

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

fenollp• 12 years ago

they are never ambiguous in the grammar

I'm building a grammar for a sleeker Erlang here [1], and it tries to prove just that.

[1] https://github.com/fenollp/kju/blob/master/grammar/Kju.g4

solotraveller• 12 years ago

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

davidw2• 12 years ago

Cool - how is it working out so far?

gooseyard2• 12 years ago

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• 12 years ago

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

gooseyard2• 12 years ago

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!

felixgallo• 12 years ago

ferd did a pretty good webcast that goes over some of the design points for erlang-node deployments:

http://www.oreilly.com/pub/e/2877

rdtsc2• 12 years ago

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.

An Open Letter to the Erlang Beginner (2011)

Related Stories