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.
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!
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.
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.
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.)
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.
I've used Erlang for about 6 years now. The thing is, I haven't used only Erlang for 6 years, so I've never forced myself into cognitive dissonance about the ways in which other languages do things better, or worse, simply failed to be exposed to them.
It's a bit sad to see the Erlang community start wearing the embracing its flaws as a badge of pride. It's a short-term solution, but long term it leads to community death. I guess I'm getting out of that world none too soon. There are reasons why it has not become more popular than it has, and if the community is going to chose to embrace them rather than deal with them, well, more power to them. You can do it without me. Which I do not mention as if that's some sort of major threat or anything, because of course it's not.
Or if they choose to run around claiming that 6 years of experience just isn't enough to get Erlang, well, more power to you too.
You have to be willing to confront the ugly truth sometimes. Of course, sometimes that means "yeah, that sucks, but changing it is more pain than it's worth", which does not fix the problem, but is at least honest.
I agree with jerf about the "ant turd tokens": they're hard to see, and irritating when you rearrange code. But the rest of Erlang has lots of good stuff, so I just deal with it.
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.
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.
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
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).
> 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.
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++.
* 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.