Ask HN: An Acceptable Erlang
I am fully on-board with the async, share-nothing, message-passing, "let it crash" paradigm. I think it's inspired, and I'd really like to build some applications in it. Except for the fact that the syntax completely mangles my mind. I can't seem to understand it at all. Given a code snippet, my guess for the correct statement ending is a total shot in the dark. Comma, semicolon, period? No idea. I can't imagine I'll ever be able to build something with any real functionality, apart from passing messages from one place to another.
I know this is the sort of question that will raise the ire of most aficionados, but is there an "acceptable Erlang"? Something you can write day-to-day, but get close to the same programming paradigm? I've seen Akka on Scala, but that looks like it's going to be really heavy. Node.js, AFAIK, is async, but the fault-tolerant bits aren't there. Stackless Python or Twisted don't seem to be very similar.
Any ideas?
33 comments
[ 0.23 ms ] story [ 64.9 ms ] threadAnd no I havent found anything that comes close to erlang that isnt erlang, I dont think thats an accident, erlangs primitive syntax is a distinct advantage.
To start, a comma goes at the end of a normal line of code. Most lines end in a comma. There are exceptions though, but easy to manage ones. A semicolon will go at the end of a case statement or an if statement. But no punctuation goes at the end of the last case or if statement in a block. The same logic holds for ending a function. A function is ended with a period, unless there is another function with the same signature. In this case, you end with a semicolon.
I answered a similar question on SO a while back: http://stackoverflow.com/questions/1110601/in-erlang-when-do...
That was my answer back in '09 as I was learning Erlang. I absolutely love the language and agree that there is a learning curve, but the syntax learning curve is pretty small.
1- http://www.swi-prolog.org/
2- https://sites.google.com/site/prologsite/prolog-problems
1 - http://stackoverflow.com/questions/3542891/erlang-programmin...
That said I'm not sure it's a big win compared to learning Erlang directly.
The syntax is actually pretty friendly IMHO - it's specifically meant to be as side-effect free as possible.
Keep plugging at it (like many things) and it will grow on you.
They tried to teach us recursion in college using C, and I remember it just confusing me. Learning it in Scheme with TLS, it clicked immediately, and now I can implement it in any language.
I generally feel completely lost when reading or writing Erlang; there's never been a point where I feel like I truly understand what's going on in the code, it's like I've just had some happy accident that seems to be performing the way I had hoped. I'm fairly intimidated to try doing anything bar what I'm told in the tutorials, and I've been plugging away for a fair while now.
I first did it in Python (non-threaded) and for like five urls in the list it was acceptable. Then the list started growing and the system started bogging down a lot. I then thought to myself, "okay, well I should thread the python script then..." and that's when another thought kind of barged in and said, "uhm...Erlang would be perfect for this..." So I implemented it in Erlang - it was the perfect first production Erlang program.
I only had to do three things:
1. Query the DB and get the current list of URL's
2. Scrape the URL
3. Run my regex on the result and insert something in the DB
So, I did it non-parallel style first to get a grip. Worked great. Now how do I go and make this a parallel program? Two major issues presented themselves:
A) I want to (basically) map() the list of URL's from the DB and spawn a process per item in the list that handles the scraping and regexing of the item's URL. This was difficult for me but Armstrong's pmap examples in Programming Erlang helped a lot.
B) Handle proper locking with the DB. It was immediately apparent to me that doing DB calls from inside the spawn'ed proc was probably stupid and hard. So I decided the spawn'ed proc would only do the work of requesting the site and regexing the result - it then had to pass the result as a message back to a delegator (that handled all communication between the spawn'ed procs and the parent program) which would aggregate the results and insert into the DB once all of them had finished/failed.
So the pmap implementation not only had to split the list and pmap() on each item of the list, but had to also aggregate the results &c... It was complicated but so complicated I couldn't handle it. The whole thing took me about five days but holy god was it fast! I finally grok'ed Erlang too - I known now how amazing it is for programs that truly require parallel execution models and I also know how unproductive I would be trying to bend it to any project that didn't explicitly need that kind of paradigm.
[EDIT] It was complicated for me because I didn't want to just pmap() down the entire list, I wanted to only pmap() on a set of 10. So the list had to be split into ten, map the items, then break off another 10 &c...
The syntax is very familiar to me now after having written several other large production programs that we use (I can "read" Erlang) and it feels perfect for what Erlang is meant to do. I can't really imagine doing the same kind of thing so expressively in Python.
A semicolon separates two clauses, either two if/case/receive clauses or two function clauses and means or. Either choose the first clause or the clause following the semicolon. An if/case/receive is terminated with an 'end' while a function is terminated with a dot.
Fred Hebert, the author of Learn You Some Erlang, wrote this on syntax: http://ferd.ca/on-erlang-s-syntax.html
Reia is a Ruby-like scripting language for the Erlang virtual machine. Reia brings you the best of both worlds between Ruby's friendly syntax, reflection, metaprogramming, and the amazing power of blocks, and Erlang's immense abilities for concurrency, distribution, hot code swapping, and fault tolerance.
http://reia-lang.org/
Lisp Flavored Erlang:
LFE, Lisp Flavoured Erlang, is a lisp syntax front-end to the Erlang compiler. Code produced with it is compatible with "normal" Erlang code. An LFE evaluator and shell is also included.
https://github.com/rvirding/lfe
As far as I know, both languages are still a work in progress (I'm not very familiar with either, though). Even if you try either of these options, I really recommend also sticking with Erlang until you "get" it. It will click eventually.
I know that I should stick it out with Erlang, but it's difficult to feel like its anything but something for writing little servers in (partly due to the very small language as mentioned by Dale, which is a strength or a weakness depending on your POV, I suppose). That makes it very hard to motivate sticking it out as it's hard to see a cool end game.
I'm fairly OK with functional design, I get on with Haskell well (until those monads!) and I somewhat grok Prolog.
http://reia-lang.org/
Once you're done with Erlang, you should move on to Haskell. :)
LFE is probably your best bet in case you never learn to like Erlang's syntax, as it's only a thin layer above Erlang to provide a Lisp syntax + more powerful macros and doesn't try to bolt on any new semantics a la Reia.
It's not like I am a noob, either, I have a ton of experience programming and I have used functional languages before (my first university language was gofer, an implementation of haskell).
I've attempted Erlang in anger twice now and have ended up terribly frustrated1.
I am currently working on a node.js spike - experimenting with zerommq and node.js to see if I can get something acceptable working robustly.
On the bright side, https://github.com/josevalim/elixir was recently released and made me actually like Erlang a bit more. Ruby like syntax with the power of Erlang without a performance hit.
[1] http://golang.org
After that I switched to writing programs, some for fun and some for work. Coming from Python, I did face a lot of resistance in using erlang, but the upside is so great (message passing, insane concurrency, pattern matching) that sticking in was a no brainer. Erlang has introduced me to a totally different way of solving problems. Its quite an experience.
I will advice you to write some real world applications using erlang. The entire semicolon, comma, fullstop argument will vanish within a couple of minutes. You will realize the power once you start architecting a solution. I implore you to not quit.
You can contact me if you need help regarding erlang.
Hopefully the entry helps understanding the logic/meaning behind the punctuation in Erlang's syntax. Also, as pointed out in another blog post (http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlo...), I would just add that a different syntax helps getting in a different mindset, which is particularly useful when learning new paradigms. It might seem like something really annoying, but you'd be surprised how often we see people trying to shoehorn whatever concept they know from imperative or OO programming (or even some functional idioms) into Erlang. That just doesn't work most of the time. You have to learn the basics and forcing you out of your comfort zone by way of syntax might help with this.
It's not all bad!